mysqld crashed in BH_Clear

Bug #1155474 reported by fengyi on 2013-03-15
This bug affects 1 person
Affects Status Importance Assigned to Milestone

Bug Description

Version information:
mysql: 5.5.28a-MariaDB-log
galera: wsrep_23.7rc1.rXXXX

I have a galera cluster of 2 nodes(A and B), I added a third node(C), when C get synced with A and B, I put some pressure(using sysbench update script) on A, not for a while C crashed, the following is the error log information:

130315 13:39:34 [ERROR] mysqld got signal 7 ;
This could be because you hit a bug. It is also possible that this binary
or one of the libraries it was linked against is corrupt, improperly built,
or misconfigured. This error can also be caused by malfunctioning hardware.

To report this bug, see

We will try our best to scrape up some info that will hopefully help
diagnose the problem, but since we have already crashed,
something is definitely wrong and this may fail.

Server version: 5.5.28a-MariaDB-log
It is possible that mysqld could use up to
key_buffer_size + (read_buffer_size + sort_buffer_size)*max_threads = 5965890 K bytes of memory
Hope that's ok; if not, decrease some variables in the equation.

Thread pointer: 0x0x0
Attempting backtrace. You can use the following information to find out
where mysqld died. If you see no messages after this, something went
terribly wrong...
stack_bottom = 0x0 thread_stack 0x174000
The manual page at contains
information that should help you find out what is causing the crash.
Writing a core file

symbols got lost, so I decided to find some clue in the core file:

$gdb --core data/core.19350 bin/mysqld

Core was generated by `/u01/mariadb-galera-5528/bin/mysqld --defaults-file=/u01/mariadb-galera-5528/my'.
Program terminated with signal 7, Bus error.
#0 0x0000003659e0c6bc in pthread_kill () from /lib64/
Missing separate debuginfos, use: debuginfo-install glibc-2.12-1.25.el6.x86_64 keyutils-libs-1.4-1.el6.x86_64 krb5-libs-1.9-9.el6.x86_64 libcom_err-1.41.12-7.el6.x86_64 libgcc-4.4.5-6.el6.x86_64 libselinux-2.0.94-5.el6.x86_64 libstdc++-4.4.5-6.el6.x86_64 nss-softokn-freebl-3.12.9-3.el6.x86_64 openssl-1.0.0-10.el6.x86_64 zlib-1.2.3-25.el6.x86_64
(gdb) bt
#0 0x0000003659e0c6bc in pthread_kill () from /lib64/
#1 0x00000000006e157b in handle_fatal_signal (sig=7) at /u01/fengyi/mariadb-5.5.28a/sql/
#2 <signal handler called>
#3 BH_clear (this=0x20e6ec8, size=591) at gcache/src/gcache_bh.hpp:47
#4 gcache::RingBuffer::get_new_buffer (this=0x20e6ec8, size=591) at gcache/src/gcache_rb_store.cpp:172
#5 0x00007f3c5f613309 in gcache::RingBuffer::malloc (this=<value optimized out>, size=<value optimized out>) at gcache/src/gcache_rb_store.cpp:192
#6 0x00007f3c5f614a57 in gcache::GCache::malloc (this=0x20e6da8, size=591) at gcache/src/GCache_memops.cpp:46
#7 0x00007f3c5f6c2752 in gcs_gcache_malloc (df=0x7f3bd0000c20, frg=0x7f3c5d22fd20, act=0x7f3c5d22fdf0, local=false) at gcs/src/gcs_gcache.h:16
#8 gcs_defrag_handle_frag (df=0x7f3bd0000c20, frg=0x7f3c5d22fd20, act=0x7f3c5d22fdf0, local=false) at gcs/src/gcs_defrag.c:108
#9 0x00007f3c5f6c8069 in gcs_node_handle_act_frag (conn=0x20ee640, recv_act=<value optimized out>, timeout=9223372035999999999) at gcs/src/gcs_node.h:95
#10 gcs_group_handle_act_msg (conn=0x20ee640, recv_act=<value optimized out>, timeout=9223372035999999999) at gcs/src/gcs_group.h:157
#11 core_handle_act_msg (conn=0x20ee640, recv_act=<value optimized out>, timeout=9223372035999999999) at gcs/src/gcs_core.c:483
#12 gcs_core_recv (conn=0x20ee640, recv_act=<value optimized out>, timeout=9223372035999999999) at gcs/src/gcs_core.c:999
#13 0x00007f3c5f6ceb20 in gcs_recv_thread (arg=0x20edf60) at gcs/src/gcs.c:1114
#14 0x0000003659e077e1 in start_thread () from /lib64/
#15 0x0000003659ae68ed in clone () from /lib64/

It seems like that the crash happens in BH_Clear, but I can't figure out.

To post a comment you must log in.
This report contains Public information  Edit
Everyone can see this information.

Other bug subscribers