| Bug #42553 | mysqld crash (signal 11) | ||
|---|---|---|---|
| Submitted: | 2 Feb 2009 19:16 | Modified: | 2 Feb 2009 20:40 |
| Reporter: | Mattia Merzi | Email Updates: | |
| Status: | Duplicate | Impact on me: | |
| Category: | MySQL Server | Severity: | S1 (Critical) |
| Version: | 5.1.30/5.0.51a/6.0 | OS: | Linux |
| Assigned to: | CPU Architecture: | Any | |
[2 Feb 2009 19:37]
Mattia Merzi
just tried on an "old" mysql 5.0., very same script, log follows: 090202 20:35:13 - 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=16777216 read_buffer_size=258048 max_used_connections=5 max_connections=100 threads_connected=3 It is possible that mysqld could use up to key_buffer_size + (read_buffer_size + sort_buffer_size)*max_connections = 92783 K bytes of memory Hope that's ok; if not, decrease some variables in the equation. thd=0x2aaab000d930 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=0x4418d0e0, backtrace may not be correct. Stack range sanity check OK, backtrace follows: (nil) Stack trace seems successful - bottom reached 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 0x21fb960 = UPDATE test SET a=IF(b > NAME_CONST('variable_a',_binary'2009-02-02 07:14:15' COLLATE 'binary'),b, NAME_CONST('variable_a',_binary'2009-02-02 07:14:15' COLLATE 'binary')) WHERE id= NAME_CONST('variable_a',5322115) thd->thread_id=9247 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 090202 20:35:13 mysqld restarted InnoDB: Log scan progressed past the checkpoint lsn 18 2197442189 090202 20:35:13 InnoDB: Database was not shut down normally! InnoDB: Starting crash recovery. InnoDB: Reading tablespace information from the .ibd files... InnoDB: Restoring possible half-written data pages from the doublewrite InnoDB: buffer... InnoDB: Doing recovery: scanned up to log sequence number 18 2197444485 090202 20:35:14 InnoDB: Starting an apply batch of log records to the database... InnoDB: Progress in percents: 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74 75 76 77 78 79 80 81 82 83 84 85 86 87 88 89 90 91 92 93 94 95 96 97 98 99 InnoDB: Apply batch completed InnoDB: Last MySQL binlog file position 0 1012224854, file name ./mysql-bin.000001 090202 20:35:15 InnoDB: Started; log sequence number 18 2197444485 090202 20:35:15 [Note] /opt/mysql/libexec/mysqld: ready for connections. Version: '5.0.51a' socket: '/tmp/mysql.sock' port: 3306 Source distribution
[2 Feb 2009 20:31]
MySQL Verification Team
Version: '6.0.10-alpha-Win64-debug-log' socket: '' port: 3600 Source distribution
090202 18:30:20 - mysqld got exception 0xc0000005 ;
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=8384512
read_buffer_size=131072
max_used_connections=1
max_threads=151
thread_count=1
connection_count=1
It is possible that mysqld could use up to
key_buffer_size + (read_buffer_size + sort_buffer_size)*max_threads = 338230 K
bytes of memory
Hope that's ok; if not, decrease some variables in the equation.
thd: 0x46d9330
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...
0000000000000000
00000001400BEFD6 mysqld.exe!Arg_comparator::can_compare_as_dates()[item_cmpfunc.cc:759]
00000001400BF55D mysqld.exe!Arg_comparator::set_cmp_func()[item_cmpfunc.cc:851]
00000001400D7C89 mysqld.exe!Arg_comparator::set_cmp_func()[item_cmpfunc.h:70]
00000001400D7BC3 mysqld.exe!Item_bool_func2::set_cmp_func()[item_cmpfunc.h:338]
00000001400BE072 mysqld.exe!Item_bool_func2::fix_length_and_dec()[item_cmpfunc.cc:525]
0000000140108B62 mysqld.exe!Item_func::fix_fields()[item_func.cc:201]
00000001401088FD mysqld.exe!Item_func::fix_fields()[item_func.cc:173]
00000001400C58BA mysqld.exe!Item_func_if::fix_fields()[item_cmpfunc.cc:2353]
0000000140296985 mysqld.exe!setup_fields()[sql_base.cc:6625]
0000000140406E8E mysqld.exe!mysql_update()[sql_update.cc:295]
000000014030FC9E mysqld.exe!mysql_execute_command()[sql_parse.cc:3006]
0000000140318B9B mysqld.exe!mysql_parse()[sql_parse.cc:5742]
000000014030B10F mysqld.exe!dispatch_command()[sql_parse.cc:1011]
000000014030A728 mysqld.exe!do_command()[sql_parse.cc:691]
000000014046BDB6 mysqld.exe!handle_one_connection()[sql_connect.cc:1145]
000000014058A4EB mysqld.exe!pthread_start()[my_winthread.c:62]
00000001409E35D5 mysqld.exe!_callthreadstartex()[threadex.c:348]
00000001409E35A4 mysqld.exe!_threadstartex()[threadex.c:331]
000000007763495D kernel32.dll!BaseThreadInitThunk()
0000000077768791 ntdll.dll!RtlUserThreadStart()
Trying to get some variables.
Some pointers may be invalid and cause the dump to abort...
thd->query at 0000000004611728=UPDATE test SET a=IF(b > NAME_CONST('variable_a',_binary'2009-02-02 07:14:15' COLLATE
'binary'),b, NAME_CONST('variable_a',_binary'2009-02-02 07:14:15' COLLATE 'binary')) WHERE
id= NAME_CONST('variable_a',5322115)
thd->thread_id=1
thd->killed=NOT_KILLED
The manual page at http://dev.mysql.com/doc/mysql/en/crashing.html contains
information that should help you find out what is causing the crash.
c:\dbs>
[2 Feb 2009 20:40]
MySQL Verification Team
Thank you for the bug report. Duplicate of bug: http://bugs.mysql.com/bug.php?id=42014
Description: after issuing an update query, mysqld crashes because of a signal 11, log follows: 090202 20:02:52 - 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=33554432 read_buffer_size=16384 max_used_connections=1 max_threads=32 threads_connected=1 It is possible that mysqld could use up to key_buffer_size + (read_buffer_size + sort_buffer_size)*max_threads = 99140 K bytes of memory Hope that's ok; if not, decrease some variables in the equation. thd: 0x41bc4a0 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 = 0x440490f8 thread_stack 0x20000 /opt/mysql/libexec/mysqld(my_print_stacktrace+0x24) [0x82e0b4] /opt/mysql/libexec/mysqld(handle_segfault+0x327) [0x59ed87] /lib64/libpthread.so.0 [0x2b713cee8fb0] Trying to get some variables. Some pointers may be invalid and cause the dump to abort... thd->query at 0x41d8330 = UPDATE test SET a=IF(b > NAME_CONST('variable_a',_binary'2009-02-02 07:14:15' COLLATE 'binary'),b, NAME_CONST('v ariable_a',_binary'2009-02-02 07:14:15' COLLATE 'binary')) WHERE id= NAME_CONST('variable_a',5322115) thd->thread_id=3 thd->killed=NOT_KILLED The manual page at http://dev.mysql.com/doc/mysql/en/crashing.html contains information that should help you find out what is causing the crash. 090202 20:02:52 mysqld_safe Number of processes running now: 0 090202 20:02:52 mysqld_safe mysqld restarted InnoDB: Log scan progressed past the checkpoint lsn 0 2057664073 090202 20:02:53 InnoDB: Database was not shut down normally! InnoDB: Starting crash recovery. InnoDB: Reading tablespace information from the .ibd files... InnoDB: Restoring possible half-written data pages from the doublewrite InnoDB: buffer... InnoDB: Doing recovery: scanned up to log sequence number 0 2057668050 090202 20:02:53 InnoDB: Starting an apply batch of log records to the database... InnoDB: Progress in percents: 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74 75 76 77 78 79 80 81 82 83 84 85 86 87 88 89 90 91 92 93 94 95 96 97 98 99 InnoDB: Apply batch completed 090202 20:02:53 InnoDB: Started; log sequence number 0 2057668050 [.......] How to repeat: create table test ( id bigint(20) unsigned not null primary key auto_increment, a datetime, b datetime) engine=innodb; UPDATE test SET a=IF(b > NAME_CONST('variable_a',_binary'2009-02-02 07:14:15' COLLATE 'binary'),b, NAME_CONST('variable_a',_binary'2009-02-02 07:14:15' COLLATE 'binary')) WHERE id= NAME_CONST('variable_a',5322115);