Details
-
Bug
-
Status: Open (View Workflow)
-
Major
-
Resolution: Unresolved
-
5.5.29-galera
-
CentOS release 5.3 i386 libgcc 4.1.2-44.el5
Description
We have a package installation test, which does the following:
- install MariaDB-Galera server, MariaDB client and Galera library;
- start server with the default configuration (that is, without any wsrep* options);
- run
mysql -uroot -e 'set global wsrep_provider="/usr/lib/galera/libgalera_smm.so"; set global wsrep_cluster_address="gcomm://"'
When it's run on CentOS 5.3 i386, it crashes on the 2nd SET statement.
The problem is 100% reproducible, both on our pre-built RPMs and on a custom debug build.
Debug doesn't help much though, since the coredump comes corrupted, and stack trace printed in the error log is not very good either; but everything starts with "terminate called after throwing an instance of 'gu::NotFound'":
130331 19:54:04 [Note] WSREP: Start replication
|
130331 19:54:04 [Note] WSREP: Setting initial position to 00000000-0000-0000-0000-000000000000:-1
|
130331 19:54:04 [Note] WSREP: protonet asio version 0
|
130331 19:54:04 [Note] WSREP: backend: asio
|
terminate called after throwing an instance of 'gu::NotFound'
|
130331 19:54:04 [ERROR] mysqld got signal 6 ;
|
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 http://kb.askmonty.org/en/reporting-bugs
|
|
|
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.29-MariaDB-debug
|
key_buffer_size=134217728
|
read_buffer_size=131072
|
max_used_connections=1
|
max_threads=153
|
thread_count=1
|
It is possible that mysqld could use up to
|
key_buffer_size + (read_buffer_size + sort_buffer_size)*max_threads = 465455 K bytes of memory
|
Hope that's ok; if not, decrease some variables in the equation.
|
|
|
Thread pointer: 0x0xa15c068
|
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 = 0x93b34384 thread_stack 0x48000
|
mysys/stacktrace.c:246(my_print_stacktrace)[0x88f646b]
|
sql/signal_handler.cc:155(handle_fatal_signal)[0x83dbdc9]
|
??:0(??)[0xca7420]
|
??:0(??)[0x34f691]
|
??:0(??)[0x2884c0]
|
??:0(??)[0x285f25]
|
??:0(??)[0x285f62]
|
??:0(??)[0x28609a]
|
??:0(??)[0x7f1ca6]
|
??:0(??)[0x85a8fc]
|
??:0(??)[0x87a262]
|
??:0(??)[0x89844e]
|
??:0(??)[0x8e475b]
|
??:0(??)[0x8e1430]
|
??:0(??)[0x8d83bb]
|
??:0(??)[0x8dcc9c]
|
??:0(??)[0x927544]
|
??:0(??)[0x9431ae]
|
sql/wsrep_mysqld.cc:679(wsrep_start_replication())[0x836ed54]
|
sql/wsrep_var.cc:333(wsrep_cluster_address_update(sys_var*, THD*, enum_var_type))[0x837810a]
|
sql/set_var.cc:200(sys_var::update(THD*, set_var*))[0x817e373]
|
sql/set_var.cc:670(set_var::update(THD*))[0x817ff1a]
|
sql/set_var.cc:574(sql_set_variables(THD*, List<set_var_base>*))[0x817f0c1]
|
sql/sql_parse.cc:3540(mysql_execute_command(THD*))[0x821d27e]
|
sql/sql_parse.cc:6318(mysql_parse(THD*, char*, unsigned int, Parser_state*))[0x8222774]
|
sql/sql_parse.cc:6155(wsrep_mysql_parse)[0x8223362]
|
sql/sql_parse.cc:1250(dispatch_command(enum_server_command, THD*, char*, unsigned int))[0x8224882]
|
sql/sql_parse.cc:891(do_command(THD*))[0x8226834]
|
sql/sql_connect.cc:1291(do_handle_one_connection(THD*))[0x83118c1]
|
sql/sql_connect.cc:1200(handle_one_connection)[0x8311a29]
|
??:0(??)[0x77249b]
|
??:0(??)[0x3f642e]
|
|
|
Trying to get some variables.
|
Some pointers may be invalid and cause the dump to abort.
|
Query (0xa1668c0): set global wsrep_cluster_address="gcomm://"
|
Connection ID (thread ID): 2
|
Status: NOT_KILLED
|
|
|
Further investigation shows that the crash goes away after the currently installed libgcc 4.1.2-44.el5 is upgraded to 4.1.2-54.el5.
I cannot positively determine whether it's a libgcc problem or a server/wsrep/galera bug, passing it to Codership to decide.
Attachments
Issue Links
- relates to
-
MDEV-4242
Galera in buildbot: SELinux in CentOS 5 and RHEL5 builders breaks Galera installation tests
-
- Closed
-