Description:
I was trying out the new information_schema.processlist table to see if I could hack together a "max_query_time" limit using the event scheduler. I belive I have found a bug in the 'kill' command.
Here's the error log entry:
Version: '5.1.7-beta-log' socket: '/var/lib/mysql/mysql.sock' port: 3306 MySQL Community Edition - Max (GPL)
mysqld got signal 11;
key_buffer_size=16777216
read_buffer_size=2093056
max_used_connections=2
max_connections=100
threads_connected=2
It is possible that mysqld could use up to
key_buffer_size + (read_buffer_size + sort_buffer_size)*max_connections = 271983 K
bytes of memory
Hope that's ok; if not, decrease some variables in the equation.
thd=0x8cd7638
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=0x4309fcbc, backtrace may not be correct.
Stack range sanity check OK, backtrace follows:
0x81be5a0
0xffffe420
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 0x8cdebd0 = kill (select id from information_schema.processlist where Command = 'Query' and Time > 30)
thd->thread_id=2
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.
Resolved stack trace:
0x81be5a0 _ZN17sys_var_timestamp4typeEv + 0
0xffffe420 _end + -141185872
How to repeat:
mysql> kill (select id from information_schema.processlist where Command = 'Query' and Time > 30);
Variations on the query cause some differences in the stack trace but all result in the same problem in "_ZNI7sys_var_timestamp4typeEv + 0"
kill (select Id from information_schema.processlist where Command = 'Query');
Gives:
0x81be5a0 _ZN17sys_var_timestamp4typeEv + 0
0xffffe420 _end + -141185872
(nil)
0x818f8f7 _ZN13Field_newdate5storeEPKcjP15charset_info_st + 23
0x818bc7d _ZN11Field_short7val_intEv + 45
0x81d91e1 _Z7yyparsePv + 49121
0x81ddd6c _Z7yyparsePv + 68460
0x81d49fb _Z7yyparsePv + 30715
0x81d454d _Z7yyparsePv + 29517
0x81d3a80 _Z7yyparsePv + 26752
0x4003b7f3 _end + 932806787
0x4016f62a _end + 934067898
Suggested fix:
Not sure...
It would be nice for "kill" to accepted input from a sql command as shown above, or at the least not die when it does. This would give us the ability to terminate all connections to a database or from a particular user/host.
