MySQL Bugs: #26638: Mysql 5.0.27 crash repetitive crash

Bug #26638	Mysql 5.0.27 crash repetitive crash
Submitted:	26 Feb 2007 14:31	Modified:	13 Apr 2007 11:39
Reporter:	Jean Dupond	Email Updates:
Status:	No Feedback	Impact on me:	None
Category:	MySQL Server: General	Severity:	S1 (Critical)
Version:	5.0.27	OS:	Linux (Linux Mandriva. Kernel 2.6.17)
Assigned to:		CPU Architecture:	Any

Description:
We use Mysql in a replication environnement (one master and 20 slave) since more than 4 years. We have migrated half of our slaves (10 servers) to mysql 5.0.27 (community binary compiled RPM) since september 2006 and had a very big crash of ALL of the slave upgraded to 5.0 a few days ago (after 4 month without noticed problems). It's intersting to note that none of remaining 4.1 installed server crashed.
When looking in logs, we noticed that 5.0 server crashed from time to time, with a frequency of something like once a week (but never simultaneously since the "big crash").
When backtracking all crashs, we get that output :
0x80a3877 (?)
0x82f21d8 trx_commit_step + 24
0x82b27b2 row_sel_store_mysql_rec + 1314
0x82b2055 row_sel_store_row_id_to_prebuilt + 229
0x813db35 _ZN17Item_in_subselect21row_value_transformerEP4JOIN + 3605
0x80f62ce _ZN18Item_default_value10fix_fieldsEP3THDPP4Item + 190
0x80f4729 _ZN15Item_hex_stringC2EPKcj + 249
0x80f457c _ZN10Item_float5printEP6String + 124
0x80f4729 _ZN15Item_hex_stringC2EPKcj + 249
0x80f457c _ZN10Item_float5printEP6String + 124
0x80f4260 _ZN17Item_int_with_ref8new_itemEv + 176
0x80e4c71 (?)
0x80e5fa7 _init + 2363
0x817994c _Z16dispatch_command19enum_server_commandP3THDPcj + 2300
0x8179496 _Z16dispatch_command19enum_server_commandP3THDPcj + 1094
0x80d9a3d (?)
0x80b5bde (?)
0x80bc8da (?)
0x80b4264 (?)
0x80b3af4 (?)
0x80b3044 (?)
0x82ef98c trx_allocate_for_background + 188
0x83192ca fseg_get_first_extent + 234

----
or this one :
0x80a3877 (?)
0x82f21d8 trx_commit_step + 24
0x806e11f (?)
0x8375176 chk_data_link + 3190
0x80e2e87 (?)
0x80e5f4e _init + 2274
0x80e2341 (?)
0x80b5db5 (?)
0x80bc8da (?)
0x80b4264 (?)
0x80b3af4 (?)
0x80b3044 (?)
0x82ef98c trx_allocate_for_background + 188
0x83192ca fseg_get_first_extent + 234 

I don't think theses crash come from a hardware or memory problem as every 5.0 server crashed and none of 4.1 did.

How to repeat:
I really don't know how to submit a repeat case but this problem forces us to stay to 4.1

Jean,

the resolved stack traces are not sensible. Are you sure that you used the right mysqld.sym file for them?

Regards,

Heikki

I installed : MySQL-server-5.0.27-0.i386.rpm for the server binaries and MySQL-debuginfo-5.0.27-0.glibc23 for mysqld.sym file
Is there a problem ?

Can you identify SQL statements that lead to these crashes? Are you sure you resolved stack traces with that same binary that crashed?

In fact, i can not identify SQL statements that lead to these crash (that's the most important problem).
As i said, i installed MySQL-server-5.0.27-0.i386.rpm for the server binaries and
MySQL-debuginfo-5.0.27-0.glibc23 for mysqld.sym file
Are these 2 package compatible for sym file ?

Looks like your server RPM is statically linked against glibc 2.2.5, while you use *.sym file from dynamically linked server. Please, try to resolve stack trace as described in the manual, http://dev.mysql.com/doc/internals/en/using-stack-trace.html, against your real mysqld, and send the results.

When i issue a :
nm -n /usr/sbin/mysqld > /tmp/mysqld.sym
i get : 
nm: /usr/sbin/mysqld: no symbols

Please, try to use newer version, 5.0.37, and inform about the results.

No feedback was provided for this bug for over a month, so it is
being suspended automatically. If you are able to provide the
information that was originally requested, please do so and change
the status of the bug back to "Open".