Bug #34133 Crash Dump on Signal 11.
Submitted: 29 Jan 2008 14:27 Modified: 30 Jan 2008 19:15
Reporter: J. Jefferson Gray Email Updates:
Status: Unsupported Impact on me:
None 
Category:MySQL Server Severity:S2 (Serious)
Version:4.1.20 OS:Linux (Redhat Enterprise v3u5)
Assigned to: CPU Architecture:Any

[29 Jan 2008 14:27] J. Jefferson Gray
Description:
Mysqld crashed for us last night with the following information in the logs:

mysqld got signal 11;
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.
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.

key_buffer_size=134217728
read_buffer_size=1044480
max_used_connections=513
max_connections=512
threads_connected=27
It is possible that mysqld could use up to
key_buffer_size + (read_buffer_size + sort_buffer_size)*max_connections = 117759
6 K
bytes of memory
Hope that's ok; if not, decrease some variables in the equation.

thd=0x694cc168
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...
Cannot determine thread, fp=0xbfc5ed18, backtrace may not be correct.
Stack range sanity check OK, backtrace follows:
0x808d8b3
0x82e8d48
0x80b8360
0x80b8458
0x8089aa9
0x80b8eb3
0x80b8d7d
0x80d32dd
0x809f390
0x80a21ef
0x809c69f
0x809c088
0x809b757
0x82e64fc
0x830fdba
New value of fp=(nil) failed sanity check, terminating stack trace!
Please read http://dev.mysql.com/doc/mysql/en/Using_stack_trace.html and follow
instructions on how to resolve the stack trace. Resolved
stack trace is much more helpful in diagnosing the problem, so please do
resolve it
Trying to get some variables.
Some pointers may be invalid and cause the dump to abort...
thd->query at 0x9a2e040 = INSERT INTO Loc1201594094 VALUES('1324458', '6', '6',
'Main course took a long time to arrive.

Steaks ordered not cooked as ordered.

Steaks smelt off.

Poor meal.

Restaurant staff knew nothing about meal booked.')
thd->thread_id=23412403
The manual page at http://www.mysql.com/doc/en/Crashing.html contains
information that should help you find out what is causing the crash.

Number of processes running now: 0
080129 03:08:21  mysqld restarted
080129  3:08:21 [Warning] Asked for 196608 thread stack, but got 126976
080129  3:08:21 [ERROR] Can't start server: Bind on TCP/IP port: Address already
in use
080129  3:08:21 [ERROR] Do you already have another mysqld server running on por
t: 3306 ?
080129  3:08:21 [ERROR] Aborting

080129  3:08:21 [Note] /usr/local/mysql/bin/mysqld: Shutdown complete

080129 03:08:21  mysqld ended

Following the instructions on how to eval a stack trace I get the following:

[root@pilze stack]# resolve_stack_dump -s ./mysqld.sym -n  ./mysqld.stack
0x808d8b3 handle_segfault + 423
0x82e8d48 pthread_sighandler + 184
0x80b8360 table_is_used__FP8st_tableb + 24
0x80b8458 wait_for_tables__FP3THD + 116
0x8089aa9 mysql_lock_tables__FP3THDPP8st_tableUiUi + 393
0x80b8eb3 lock_tables__FP3THDP13st_table_listUi + 99
0x80b8d7d open_and_lock_tables__FP3THDP13st_table_list + 49
0x80d32dd mysql_insert__FP3THDP13st_table_listRt4List1Z4ItemRt4List1Zt4List1Z4It
emT2T215enum_duplicatesb + 409
0x809f390 mysql_execute_command__FP3THD + 7812
0x80a21ef mysql_parse__FP3THDPcUi + 211
0x809c69f dispatch_command__F19enum_server_commandP3THDPcUi + 1547
0x809c088 do_command__FP3THD + 188
0x809b757 handle_one_connection + 615
0x82e64fc pthread_start_thread + 220
0x830fdba thread_start + 4

How to repeat:
Unknown at this point.  But we've been having issues lately like too many processes, locking up, this crash, while the database is supposed to be backing up.

There seems to be an issue that may be related in where we're backing up a db with this command:

mysqldump --quick --single-transaction --flush-logs --add-drop-table --master-data

It seems that in 4.1.20 it doesn't release the table lock properly right away as it should, suggested by the options we use.

Unless I'm reading this all wrong, it seems to be trying to unlock the table to so an insert and can't.  Maybe?
[30 Jan 2008 16:05] Susanne Ebrecht
Thank you for taking the time to report a problem.  Unfortunately you are not using a current version of the product you reported a problem with -- the problem might already be fixed. Please download a new version from http://www.mysql.com/downloads/

Our newest version at the moment is: MySQL 5.0.51.

If you are able to reproduce the bug with one of the latest versions, please change the version on this bug report to the version you tested and change the status back to "Open".  Again, thank you for your continued support of MySQL.
[30 Jan 2008 19:15] J. Jefferson Gray
So you can't even tell me if its fixed? Upgrading would be a bitch.. To do so and then have the problem would be a lot of work and frustrating.

I think the generic answer to upgrade is somewhat of a copout if you can't tell me what the problem is, and if it's even fixed.

Especially when I can still download this version from your website.

Cheers.
[31 Jan 2008 16:54] Sergei Golubchik
You're right. But there is not enough information in the bug report for us to repeat the bug to determine whether it's fixed or even to recognize a known fixed bug.

Upgrading wold be a easiest option for you. Alternatively, you could try to repeat the bug and create an isolated test case.