5.5.13 main.kill causes mysqld crash when using pool of threads
Affects | Status | Importance | Assigned to | Milestone | |
---|---|---|---|---|---|
percona-projects-qa |
Fix Released
|
Medium
|
Laurynas Biveinis |
Bug Description
main.kill [ fail ]
Test ended at 2011-05-13 14:07:10
CURRENT_TEST: main.kill
mysqltest: In included file "./include/
included from ./include/
At line 42: Error running query 'SELECT MY_KILL(@id)': 2013 Lost connection to MySQL server during query
The result from queries just before the failure was:
SET DEBUG_SYNC = 'RESET';
DROP TABLE IF EXISTS t1, t2, t3;
DROP FUNCTION IF EXISTS MY_KILL;
CREATE FUNCTION MY_KILL(tid INT) RETURNS INT
BEGIN
DECLARE CONTINUE HANDLER FOR SQLEXCEPTION BEGIN END;
KILL tid;
RETURN (SELECT COUNT(*) = 0 FROM INFORMATION_
END|
SET DEBUG_SYNC= 'thread_end SIGNAL con1_end';
SET DEBUG_SYNC= 'before_
SET DEBUG_SYNC='now WAIT_FOR con1_read';
Warnings:
Warning 1639 debug sync point wait timed out
Server [mysqld.1 - pid: 16486, winpid: 16486, exit: 256] failed during test run
Server log from this test:
----------SERVER LOG START-----------
110513 13:02:08 InnoDB: !!!!!!!! UNIV_DEBUG switched on !!!!!!!!!
110513 13:02:08 InnoDB: The InnoDB memory heap is disabled
110513 13:02:08 InnoDB: Mutexes and rw_locks use GCC atomic builtins
110513 13:02:08 InnoDB: Compressed tables use zlib 1.2.3
110513 13:02:08 InnoDB: Using Linux native AIO
110513 13:02:08 InnoDB: Initializing buffer pool, size = 8.0M
110513 13:02:08 InnoDB: Completed initialization of buffer pool
110513 13:02:08 InnoDB: highest supported file format is Barracuda.
110513 13:02:08 InnoDB: Waiting for the background threads to start
110513 13:02:09 InnoDB: 1.1.6 started; log sequence number 1595675
110513 13:02:09 [Note] Event Scheduler: Loaded 0 events
110513 13:02:09 [Note] /root/new_
Version: '5.5.12-debug-log' socket: '/root/
mysqld: /root/new_
110513 13:07:10 - 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.
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_
read_buffer_
max_used_
max_threads=21
thread_count=3
connection_count=3
It is possible that mysqld could use up to
key_buffer_size + (read_buffer_size + sort_buffer_
bytes of memory
Hope that's ok; if not, decrease some variables in the equation.
Thread pointer: 0x34f3290
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 = 0x47146108 thread_stack 0x40000
/root/new_
/root/new_
/lib64/
/lib64/
/lib64/
/lib64/
/root/new_
/root/new_
/root/new_
/root/new_
/root/new_
/root/new_
/root/new_
/lib64/
/lib64/
Trying to get some variables.
Some pointers may be invalid and cause the dump to abort.
Query ((nil)): Connection ID (thread ID): 2
Status: NOT_KILLED
The manual page at http://
information that should help you find out what is causing the crash.
Writing a core file
----------SERVER LOG END-------------
Related branches
Changed in percona-projects-qa: | |
milestone: | none → 5.5.13-eb |
assignee: | nobody → Laurynas Biveinis (laurynas-biveinis) |
Changed in percona-projects-qa: | |
status: | New → In Progress |
importance: | Undecided → High |
Changed in percona-projects-qa: | |
status: | Triaged → In Progress |
Changed in percona-projects-qa: | |
status: | In Progress → Fix Committed |
Changed in percona-projects-qa: | |
status: | Fix Committed → Fix Released |
The bug is in debug sync facility, will fix after high priority bugs.