Bug #28766 MySQL crashes when tables with many partitions opened
Submitted: 30 May 2007 8:25 Modified: 5 Jun 2007 15:05
Reporter: Victoria Reznichenko Email Updates:
Status: Can't repeat Impact on me:
None 
Category:MySQL Server Severity:S1 (Critical)
Version:5.1.20 OS:Any
Assigned to: CPU Architecture:Any

[30 May 2007 8:25] Victoria Reznichenko
Description:
There are several tables and each have 500 partitions.
When you try to use any GUI tool, for example MA, MySQL server crashes with the following back trace:

======= Backtrace: =========
/lib/libc.so.6[0xb7e4f911]
/lib/libc.so.6(__libc_free+0x84)[0xb7e50f84]
/var/lib/vita/mysql-5.1bk/libexec/mysqld(_myfree+0x258)[0x8656216]
/var/lib/vita/mysql-5.1bk/libexec/mysqld(mi_close+0x479)[0x85680dd]
/var/lib/vita/mysql-5.1bk/libexec/mysqld(_ZN9ha_myisam5closeEv+0x2a)[0x853d14a]
/var/lib/vita/mysql-5.1bk/libexec/mysqld(_ZN12ha_partition4openEPKcij+0x5bf)[0x83c5117]
/var/lib/vita/mysql-5.1bk/libexec/mysqld(_ZN7handler7ha_openEP8st_tablePKcii+0x129)[0x8384ee3]
/var/lib/vita/mysql-5.1bk/libexec/mysqld(_Z21open_table_from_shareP3THDP14st_table_sharePKcjjjP8st_tableb+0x9d5)[0x82d4f15]
/var/lib/vita/mysql-5.1bk/libexec/mysqld[0x82c9dee]
/var/lib/vita/mysql-5.1bk/libexec/mysqld(_Z10open_tableP3THDP13st_table_listP11st_mem_rootPbj+0xe90)[0x82cc388]
/var/lib/vita/mysql-5.1bk/libexec/mysqld(_Z11open_tablesP3THDPP13st_table_listPjj+0x2d6)[0x82ccfa6]
/var/lib/vita/mysql-5.1bk/libexec/mysqld(_Z30open_normal_and_derived_tablesP3THDP13st_table_listj+0x91)[0x82cd363]
/var/lib/vita/mysql-5.1bk/libexec/mysqld(_Z14get_all_tablesP3THDP13st_table_listP4Item+0x919)[0x83f9263]
/var/lib/vita/mysql-5.1bk/libexec/mysqld(_Z24get_schema_tables_resultP4JOIN23enum_schema_table_state+0x26d)[0x83e8615]
/var/lib/vita/mysql-5.1bk/libexec/mysqld(_ZN4JOIN4execEv+0x8d1)[0x82ff86b]
/var/lib/vita/mysql-5.1bk/libexec/mysqld(_Z12mysql_selectP3THDPPP4ItemP13st_table_listjR4ListIS1_ES2_jP8st_orderSB_S2_SB_yP13select_resultP18st_select_lex_unitP13st_select_lex+0x323)[0x82fcb4f]
/var/lib/vita/mysql-5.1bk/libexec/mysqld(_Z13handle_selectP3THDP6st_lexP13select_resultm+0x201)[0x83012f1]
/var/lib/vita/mysql-5.1bk/libexec/mysqld[0x8283c58]
/var/lib/vita/mysql-5.1bk/libexec/mysqld(_Z21mysql_execute_commandP3THD+0x709)[0x8285471]
/var/lib/vita/mysql-5.1bk/libexec/mysqld(_Z11mysql_parseP3THDPKcjPS2_+0x1e8)[0x828df0a]
/var/lib/vita/mysql-5.1bk/libexec/mysqld(_Z16dispatch_command19enum_server_commandP3THDPcj+0x9bb)[0x828ea3b]
/var/lib/vita/mysql-5.1bk/libexec/mysqld(_Z10do_commandP3THD+0x253)[0x828fbe1]
/var/lib/vita/mysql-5.1bk/libexec/mysqld(handle_one_connection+0x104)[0x827d964]
/lib/libpthread.so.0[0xb7f8834b]
/lib/libc.so.6(__clone+0x5e)[0xb7ea965e]

All tables are identical:

mysql> create table p_1( id int auto_increment primary key, name varchar(20)) partition by key() partitions 500;
Query OK, 0 rows affected (0.55 sec)

mysql> create table p_2( id int auto_increment primary key, name varchar(20)) partition by key() partitions 500;
Query OK, 0 rows affected (0.60 sec)

mysql> create table p_3( id int auto_increment primary key, name varchar(20)) partition by key() partitions 500;
Query OK, 0 rows affected (0.56 sec)

mysql> create table p_4( id int auto_increment primary key, name varchar(20)) partition by key() partitions 500;
Query OK, 0 rows affected (0.57 sec)

mysql> create table p_5( id int auto_increment primary key, name varchar(20)) partition by key() partitions 500;
Query OK, 0 rows affected (0.56 sec)

How to repeat:
no 100% repeatable test case. server crashes in 50% cases, in all other cases it reports error 24 ("too many open files").

bug report will be updated later with test case.
[30 May 2007 8:26] MySQL Verification Team
From the server error log:

070530 12:11:40 - 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_size=8388572
read_buffer_size=131072
max_used_connections=3
max_threads=151
threads_connected=2
It is possible that mysqld could use up to
key_buffer_size + (read_buffer_size + sort_buffer_size)*max_threads = 337602 K
bytes of memory
Hope that's ok; if not, decrease some variables in the equation.

thd: 0x8fd8608
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=0xb2fd9d78, backtrace may not be correct.
Stack range sanity check OK, backtrace follows:
0x8275169
0xffffe410
0xb7e15ea3
0xb7e49f8b
0xb7e4f911
0xb7e50f84
0x8656216
0x85680dd
0x853d14a
0x83c5117
0x8384ee3
0x82d4f15
0x82c9dee
0x82cc388
0x82ccfa6
0x82cd363
0x83f9263
0x83e8615
0x82ff86b
0x82fcb4f
0x83012f1
0x8283c58
0x8285471
0x828df0a
0x828ea3b
0x828fbe1
0x827d964
0xb7f8834b
0xb7ea965e
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 0x8fd9c78 = SHOW TABLE STATUS
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.
[30 May 2007 8:32] Sveta Smirnova
test case

Attachment: bug28766.test (application/octet-stream, text), 604 bytes.

[5 Jun 2007 15:05] MySQL Verification Team
Wasn't able to reproduce it.