mysqld innodb_information_schema segfault when using pool of threads
Affects | Status | Importance | Assigned to | Milestone | |
---|---|---|---|---|---|
percona-projects-qa |
Fix Released
|
High
|
Laurynas Biveinis |
Bug Description
OS: CentOS 5 x86_64
[root@gval-
revision-id: <email address hidden>
date: 2011-05-30 13:48:10 +0400
build-date: 2011-05-30 18:07:25 +0400
revno: 3480
branch-nick: mysql-55-eb-blobs
[root@
Using saved parent location: http://
No revisions to pull.
[root@
Logging: ./mtr innodb_
MySQL Version 5.5.12
Checking supported features...
- skipping ndbcluster
- skipping SSL, mysqld not compiled with SSL
- binaries are debug compiled
Collecting tests...
vardir: /root/mysql-
Checking leftover processes...
Removing old var directory...
Creating var directory '/root/
Installing system database...
Using server port 46132
=======
TEST RESULT TIME (ms) or COMMENT
------
worker[1] Using MTR_BUILD_THREAD 300, with reserved ports 13000..13009
worker[1] mysql-test-run: WARNING: running this script as _root_ will cause some tests to be skipped
innodb.
Test ended at 2011-05-30 18:05:34
CURRENT_TEST: innodb.
mysqltest: At line 169: query 'DROP TABLE t_min, t_max, ```t'\"_str`' failed: 2013: Lost connection to MySQL server during query
The result from queries just before the failure was:
< snip >
X RECORD `test`.```t'\"_str` `PRIMARY` 3 '2', 'abc', '"abc', 'abc"', 'a"bc', 'a"bc"', '"abc""'
X RECORD `test`.```t'\"_str` `PRIMARY` 3 '2', 'abc', '"abc', 'abc"', 'a"bc', 'a"bc"', '"abc""'
X RECORD `test`.```t'\"_str` `PRIMARY` 4 '3', 'abc', '\\abc', 'abc\\', 'a\\bc', 'a\\bc\\', '\\abc\\\\'
X RECORD `test`.```t'\"_str` `PRIMARY` 4 '3', 'abc', '\\abc', 'abc\\', 'a\\bc', 'a\\bc\\', '\\abc\\\\'
X RECORD `test`.```t'\"_str` `PRIMARY` 5 '4', 'abc', '\0abc', 'abc\0', 'a\0bc', 'a\0bc\0', 'a\0bc\0\0'
X RECORD `test`.```t'\"_str` `PRIMARY` 5 '4', 'abc', '\0abc', 'abc\0', 'a\0bc', 'a\0bc\0', 'a\0bc\0\0'
X RECORD `test`.`t_min` `PRIMARY` 2 -128, 0, -32768, 0, -8388608, 0, -2147483648, 0, -92233720368547
X RECORD `test`.`t_min` `PRIMARY` 2 -128, 0, -32768, 0, -8388608, 0, -2147483648, 0, -92233720368547
X RECORD `test`.`t_max` `PRIMARY` 2 127, 255, 32767, 65535, 8388607, 16777215, 2147483647, 4294967295, 922337203685477
X RECORD `test`.`t_max` `PRIMARY` 2 127, 255, 32767, 65535, 8388607, 16777215, 2147483647, 4294967295, 922337203685477
X RECORD `test`.```t'\"_str` `PRIMARY` 1 supremum pseudo-record
X RECORD `test`.```t'\"_str` `PRIMARY` 1 supremum pseudo-record
lock_table COUNT(*)
`test`.`t_max` 2
`test`.`t_min` 2
`test`
lock_table COUNT(*)
"test"."t_max" 2
"test"."t_min" 2
"test"
More results from queries before failure can be found in /root/mysql-
Server [mysqld.1 - pid: 12374, winpid: 12374, exit: 256] failed during test run
Server log from this test:
----------SERVER LOG START-----------
110530 17:05:32 InnoDB: !!!!!!!! UNIV_DEBUG switched on !!!!!!!!!
110530 17:05:32 InnoDB: The InnoDB memory heap is disabled
110530 17:05:32 InnoDB: Mutexes and rw_locks use GCC atomic builtins
110530 17:05:32 InnoDB: Compressed tables use zlib 1.2.3
110530 17:05:32 InnoDB: Using Linux native AIO
110530 17:05:32 InnoDB: Initializing buffer pool, size = 8.0M
110530 17:05:32 InnoDB: Completed initialization of buffer pool
110530 17:05:32 InnoDB: highest supported file format is Barracuda.
110530 17:05:32 InnoDB: Waiting for the background threads to start
110530 17:05:33 InnoDB: 1.1.6 started; log sequence number 1595675
110530 17:05:33 [Note] Event Scheduler: Loaded 0 events
110530 17:05:33 [Note] /root/mysql-
Version: '5.5.12-debug-log' socket: '/root/
110530 17:05:34 InnoDB: Assertion failure in thread 1193482560 in file ha_innodb.cc line 1553
InnoDB: Failing assertion: ((thd) == _current_thd())
InnoDB: We intentionally generate a memory trap.
InnoDB: Submit a detailed bug report to http://
InnoDB: If you get repeated assertion failures or crashes, even
InnoDB: immediately after the mysqld startup, there may be
InnoDB: corruption in the InnoDB tablespace. Please refer to
InnoDB: http://
InnoDB: about forcing recovery.
110530 17:05:34 - 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=9
thread_count=10
connection_
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: 0x0
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 = (nil) thread_stack 0x40000
/root/
/root/
/lib64/
/lib64/
/lib64/
/root/
/root/
/root/
/root/
/root/
/root/
/root/
/root/
/lib64/
/lib64/
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: | |
status: | Triaged → In Progress |
Changed in percona-projects-qa: | |
status: | In Progress → Fix Committed |
Changed in percona-projects-qa: | |
status: | Fix Committed → Fix Released |
valgrind log