| Bug #36751 | Segmentation fault in ctype-bin.c:308; Linux 86_64, with-max-indexes=128 | ||
|---|---|---|---|
| Submitted: | 16 May 2008 8:23 | Modified: | 13 Apr 2009 19:11 |
| Reporter: | Christian Bolliger | Email Updates: | |
| Status: | Closed | Impact on me: | |
| Category: | MySQL Server: General | Severity: | S2 (Serious) |
| Version: | 5.1.26-rc | OS: | Linux (x86_64, SLES10) |
| Assigned to: | Tatiana Azundris Nuernberg | CPU Architecture: | Any |
| Tags: | ctype-bin, segmentation fault, x86_64 | ||
[16 May 2008 8:23]
Christian Bolliger
[16 May 2008 8:26]
Christian Bolliger
How to repeat addenum: cd <mysql-base> bin/mysql_install_db - chribo
[18 May 2008 6:46]
Valeriy Kravchuk
Thank you for a bug report. Verifed just as described in the following environment: -bash-3.00$ uname -a Linux rh-x86-64.mysql.com 2.6.9-34.0.2.EL #1 Fri Jun 30 10:22:45 EDT 2006 x86_64 x86_64 x86_64 GNU/Linux -bash-3.00$ gcc --version gcc (GCC) 3.4.5 20051201 (Red Hat 3.4.5-2) Copyright (C) 2004 Free Software Foundation, Inc. This is free software; see the source for copying conditions. There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. -bash-3.00$ pwd /users/vkravchuk/dbs/5.1.24 Stack trace was a bit different: -bash-3.00$ bin/mysql_install_db --datadir=`pwd`/var Installing MySQL system tables... 080518 8:40:23 - 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=8388600 read_buffer_size=131072 max_used_connections=0 max_threads=151 threads_connected=1 It is possible that mysqld could use up to key_buffer_size + (read_buffer_size + sort_buffer_size)*max_threads = 338282 K bytes of memory Hope that's ok; if not, decrease some variables in the equation. thd: 0xa43060 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... /users/vkravchuk/dbs/5.1.24/libexec/mysqld(print_stacktrace+0x20) [0x6b2d50] /users/vkravchuk/dbs/5.1.24/libexec/mysqld(handle_segfault+0x317) [0x581b17] /lib64/libpthread.so.0 [0x2a9557b2f8] /lib64/libc.so.6 [0x2a958bc200] /users/vkravchuk/dbs/5.1.24/libexec/mysqld(my_hash_sort_bin+0x13) [0x7623c3] /users/vkravchuk/dbs/5.1.24/libexec/mysqld(my_hash_insert+0x27b) [0x744d0b] /users/vkravchuk/dbs/5.1.24/libexec/mysqld(open_table(THD*, TABLE_LIST*, st_mem_root*, bool*, unsigned int)+0x803) [0x5d2113] /users/vkravchuk/dbs/5.1.24/libexec/mysqld(open_tables(THD*, TABLE_LIST**, unsigned int*, unsigned int)+0x3b8) [0x5d2b28] /users/vkravchuk/dbs/5.1.24/libexec/mysqld(mysql_create_like_table(THD*, TABLE_LIST*, TABLE_LIST*, st_ha_create_information*)+0x64) [0x67a264] /users/vkravchuk/dbs/5.1.24/libexec/mysqld(mysql_execute_command(THD*)+0x1e9e) [0x591fde] /users/vkravchuk/dbs/5.1.24/libexec/mysqld(mysql_parse(THD*, char const*, unsigned int, char const**)+0x143) [0x597c33] /users/vkravchuk/dbs/5.1.24/libexec/mysqld(handle_bootstrap+0x29a) [0x59985a] /lib64/libpthread.so.0 [0x2a95575b6b] /lib64/libc.so.6(__clone+0x43) [0x2a95951463] Trying to get some variables. Some pointers may be invalid and cause the dump to abort... thd->query at 0xa56520 = CREATE TEMPORARY TABLE tmp_db LIKE db 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. Installation of system tables failed! Examine the logs in /users/vkravchuk/dbs/5.1.24/var for more information. ... I had used the following simplified configure command line: ./configure --prefix=/users/vkravchuk/dbs/5.1.24 --enable-community-fetures --with-max-indexes=128 --with-big-tables --with-thread --with-fast-mutexes
[30 Jul 2008 12:42]
Christian Bolliger
The bug still occurs under 5.1.26-rc. Christian
[23 Feb 2009 15:42]
Tatiana Azundris Nuernberg
cf.
#5 0x0000000000a06799 in ha_myisam::info (this=0x10d05b8, flag=26)
at ha_myisam.cc:1751
1751 share->keys_for_keyread.intersect(share->keys_in_use);
(gdb) print share->keys_for_keyread
$5 = {map = {bitmap = 0x0, n_bits = 128, last_word_mask = 0,
last_word_ptr = 0x10c6c54, mutex = 0x0}, buffer = {0, 0, 0, 0}}
That seems to be our 128, notice NULL for bitmap.
(gdb) print share->table_name
$6 = {str = 0x10c6dd0 "tmp_db", length = 6}
#2 0x00007fd35eb8e1e9 in __assert_fail () from /lib64/libc.so.6
#3 0x0000000000b0805e in bitmap_intersect (map=0x10c6c28, map2=0x10c6bf8)
at my_bitmap.c:366
#4 0x00000000005f4de1 in Bitmap<128u>::intersect (this=0x10c6c28,
map2=@0x10c6bf8) at sql_bitmap.h:46
#5 0x0000000000a06799 in ha_myisam::info (this=0x10d05b8, flag=26)
at ha_myisam.cc:1751
#6 0x0000000000a0c293 in ha_myisam::open (this=0x10d05b8, name=0x10c6d88 "/misc/mysql/forest/36751/51-36751/mysql-test/var/tmp/#sql5635_1_0", mode=2, test_if_locked=2) at ha_myisam.cc:686
#7 0x0000000000800615 in handler::ha_open (this=0x10d05b8,
table_arg=0x10c5a28, name=0x10c6d88 "/misc/mysql/forest/36751/51-36751/mysql-test/var/tmp/#sql5635_1_0", mode=2, test_if_locked=2) at handler.cc:2037
#8 0x000000000072a044 in open_table_from_share (thd=0x10aed28,
share=0x10c69a8, alias=0x10c1f88 "tmp_db", db_stat=7, prgflag=44,
ha_open_flags=0, outparam=0x10c5a28, is_create_table=false)
at table.cc:1872
#9 0x0000000000717ab2 in open_temporary_table (thd=0x10aed28, path=0x41509ad0 "/misc/mysql/forest/36751/51-36751/mysql-test/var/tmp/#sql5635_1_0", db=0x10c22f0 "mysql", table_name=0x10c1f88 "tmp_db",
link_in_list=true) at sql_base.cc:5479
#10 0x0000000000827a34 in mysql_create_like_table (thd=0x10aed28,
table=0x10c1fc0, src_table=0x10c2330, create_info=0x4150a2e0)
at sql_table.cc:4981
#11 0x00000000006ca9f1 in mysql_execute_command (thd=0x10aed28)
at sql_parse.cc:2650
#12 0x00000000006d1ed0 in mysql_parse (thd=0x10aed28,
inBuf=0x10c1ec8 "CREATE TEMPORARY TABLE tmp_db LIKE db", length=37,
found_semicolon=0x4150b0f8) at sql_parse.cc:5811
#13 0x00000000006d46eb in handle_bootstrap (arg=0x10aed28) at sql_parse.cc:512
#14 0x00007fd35f988040 in start_thread () from /lib64/libpthread.so.0
#15 0x00007fd35ec360cd in clone () from /lib64/libc.so.6
That's our 128 keys, mind.
-----------------------8<----------------------------
For 97 I drop out elsewhere:
mysqld: my_bitmap.c:431: bitmap_union: Assertion `map->bitmap && map2->bitmap && map->n_bits==map2->n_bits' failed.
/misc/mysql/forest/36751/51-36751/sql/mysqld(bitmap_union+0x69)[0xb081ea]
/misc/mysql/forest/36751/51-36751/sql/mysqld(_ZN6BitmapILj104EE5mergeERS0_+0x1d)[0x722105]
/misc/mysql/forest/36751/51-36751/sql/mysqld(_Z13insert_fieldsP3THDP23Name_resolution_contextPKcS4_P13List_iteratorI4ItemEb+0x5da)[0x712a5a]
/misc/mysql/forest/36751/51-36751/sql/mysqld(_Z10setup_wildP3THDP10TABLE_LISTR4ListI4ItemEPS5_j+0x274)[0x71569a]
/misc/mysql/forest/36751/51-36751/sql/mysqld(_ZN4JOIN7prepareEPPP4ItemP10TABLE_LISTjS1_jP8st_orderS7_S1_S7_P13st_select_lexP18st_select_lex_unit+0x340)[0x758618]
/misc/mysql/forest/36751/51-36751/sql/mysqld(_Z12mysql_selectP3THDPPP4ItemP10TABLE_LISTjR4ListIS1_ES2_jP8st_orderSB_S2_SB_yP13select_resultP18st_select_lex_unitP13st_select_lex+0x286)[0x75964c]
/misc/mysql/forest/36751/51-36751/sql/mysqld(_Z13handle_selectP3THDP6st_lexP13select_resultm+0x1f7)[0x75eef9]
thd->query at 0x10c1f58 = INSERT INTO db SELECT * FROM tmp_db WHERE @had_db_table=0
[11 Mar 2009 6:29]
Tatiana Azundris Nuernberg
I - "WE CRASH HERE"
-- Fill "db" table with default grants for anyone to
-- access database 'test' and 'test_%' if "db" table didn't exist
CREATE TEMPORARY TABLE tmp_db LIKE db;
INSERT INTO tmp_db VALUES ('%','test','','Y','Y','Y','Y','Y','Y','N','Y','Y','Y'
,'Y','Y','Y','Y','Y','N','N','Y','Y');
INSERT INTO tmp_db VALUES ('%','test\_%','','Y','Y','Y','Y','Y','Y','N','Y','Y',
'Y','Y','Y','Y','Y','Y','N','N','Y','Y');
INSERT INTO db SELECT * FROM tmp_db WHERE @had_db_table=0;
DROP TABLE tmp_db;
#3 0x0000000000b081ea in bitmap_union (map=0x10c5580, map2=0x10c7090) at my_bitmap.c:430
#4 0x0000000000722105 in Bitmap<104u>::merge (this=0x10c5580, map2=@0x10c7090) at sql_bitmap.h:62
#5 0x0000000000712a5a in insert_fields (thd=0x10ae888, context=0x10b0758, db_name=0x0, table_name=0x0, it=0x7fe9fab94d00, any_privileges=false) at sql_base.cc:7855
#6 0x000000000071569a in setup_wild (thd=0x10ae888, tables=0x10c1eb0, fields=@0x10b0810, sum_func_list=0x10d7fb8, wild_num=1) at sql_base.cc:7332
#7 0x0000000000758618 in JOIN::prepare (this=0x10d69d8, rref_pointer_array=0x10b08d8, tables_init=0x10c1eb0, wild_num=1, conds_init=0x10c2360, og_num=0, order_init=0x0, group_init=0x0, having_init=0x0, proc_param_init=0x0, select_lex_arg=0x10b0708, unit_arg=0x10b02e0) at sql_select.cc:494
#8 0x000000000075964c in mysql_select (thd=0x10ae888, rref_pointer_array=0x10b08d8, tables=0x10c1eb0, wild_num=1, fields=@0x10b0810, conds=0x10c2360, og_num=0, order=0x0, group=0x0, having=0x0, proc_param=0x0, select_options=3489942016, result=0x10c24e0, unit=0x10b02e0, select_lex=0x10b0708) at sql_select.cc:2356
#9 0x000000000075eef9 in handle_select (thd=0x10ae888, lex=0x10b0240, result=0x10c24e0, setup_tables_done_option=1073741824) at sql_select.cc:268
#10 0x00000000006cc338 in mysql_execute_command (thd=0x10ae888) at sql_parse.cc:3142
#11 0x00000000006d1ed0 in mysql_parse (thd=0x10ae888, inBuf=0x10c1928 "INSERT INTO db SELECT * FROM tmp_db WHERE @had_db_table=0", length=57, found_semicolon=0x7fe9fab960f8) at sql_parse.cc:5811
#12 0x00000000006d46eb in handle_bootstrap (arg=0x10ae888) at sql_parse.cc:512
426 void bitmap_union(MY_BITMAP *map, const MY_BITMAP *map2)
427 {
428 my_bitmap_map *to= map->bitmap, *from= map2->bitmap, *end;
429
430 DBUG_ASSERT(map->bitmap && map2->bitmap &&
431 map->n_bits==map2->n_bits);
432 end= map->last_word_ptr;
433
434 while (to <= end)
435 *to++ |= *from++;
436 }
(gdb) print map->bitmap
$3 = (my_bitmap_map *) 0x0
(gdb) print *map
$5 = {bitmap = 0x0, n_bits = 0, last_word_mask = 0, last_word_ptr = 0x0, mutex = 0x0}
(gdb) print *map2
$6 = {bitmap = 0x10cff78, n_bits = 104, last_word_mask = 4294967040, last_word_ptr = 0x10cff84, mutex = 0xa5a5a5a5a5a5a5a5}
(gdb) print table->merge_keys
$8 = {map = {bitmap = 0x0, n_bits = 0, last_word_mask = 0, last_word_ptr = 0x0, mutex = 0x0}, buffer = {0, 0, 0, 0}}
(gdb) print table->alias
$10 = 0x10bd668 "tmp_db"
void clear_all() { bitmap_clear_all(&map); } in sql_bitmap.h
bitmap_clear_all() is a macro in my_bitmap.h
.merge() { bitmap_union(&map, &map2.map); } in sql_bitmap.h
bitmap_union() is defined in my_bitmap.c
[11 Mar 2009 6:33]
Tatiana Azundris Nuernberg
II - "THE RUB" In sql_bitmap.h, we have separate implementations for template <uint default_width> class Bitmap and template <> class Bitmap<64> bm64 uses a ulonglong for its payload. It's pretty much "set up by default." bm_n uses a MY_BITMAP that has a pointer into a uint32 buffer[...] that lives in the Bitmap class. This point needs setting up. Heck, the whole MY_BITMAP needs setting up.
[11 Mar 2009 6:45]
Tatiana Azundris Nuernberg
III - "PRETTY EXPLOSIONS (I)" The above INSERT...SELECT blows up, but it is my theory, which is mine alone and concerns brontosauruses, that the real culprit here is the CREATE...LIKE, and lo and behold: - in ha_create_table(), we make a beautiful new TABLE, which key-fu set up as it should be - then two lines down, we call open_table_from_share(), which blanks all the key-bitmaps we took such trouble to initialize correctly. It then sets up most keys, but not the administratives for merge_keys. => so, we set up merge_keys along with the other keys. => this works splendidly in that we now explode in a completely new place! :)
[11 Mar 2009 6:47]
Tatiana Azundris Nuernberg
III - "PRETTY EXPLOSIONS (II)" #3 0x0000000000af5a90 in bitmap_union (map=0x1139e50, map2=0x111f400) at my_bitmap.c:430 #4 0x000000000071a5c5 in Bitmap<104u>::merge (this=0x1139e50, map2=@0x111f400) at sql_bitmap.h:62 #5 0x000000000070a748 in insert_fields (thd=0x10c7698, context=0x1126310, db_name=0x0, table_name=0x0, it=0x7ffff7e8b7a0, any_privileges=false) at sql_base.cc:7855 #6 0x000000000070b26a in setup_wild (thd=0x10c7698, tables=0x11211e8, fields=@0x11263c8, sum_func_list=0x11397c0, wild_num=1) at sql_base.cc:7332 #7 0x0000000000750262 in JOIN::prepare (this=0x11381e0, rref_pointer_array=0x1126490, tables_init=0x11211e8, wild_num=1, conds_init=0x1121710, og_num=1, order_init=0x11218b8, group_init=0x0, having_init=0x0, proc_param_init=0x0, select_lex_arg=0x11262c0, unit_arg=0x1125e98) at sql_select.cc:494 #8 0x0000000000751290 in mysql_select (thd=0x10c7698, rref_pointer_array=0x1126490, tables=0x11211e8, wild_num=1, fields=@0x11263c8, conds=0x1121710, og_num=1, order=0x11218b8, group=0x0, having=0x0, proc_param=0x0, select_options=2684636672, result=0x11381c0, unit=0x1125e98, select_lex=0x11262c0) at sql_select.cc:2356 #9 0x00000000007568e1 in handle_select (thd=0x10c7698, lex=0x1125df8, result=0x11381c0, setup_tables_done_option=0) at sql_select.cc:268 #10 0x00000000006c1ec6 in execute_sqlcom_select (thd=0x10c7698, all_tables=0x11211e8) at sql_parse.cc:4911 #11 0x00000000006c3d54 in mysql_execute_command (thd=0x10c7698) at sql_parse.cc:2204 #12 0x00000000008841d5 in sp_instr_stmt::exec_core (this=0x1121900, thd=0x10c7698, nextp=0x7ffff7e8d228) at sp_head.cc:2899 #13 0x000000000088440c in sp_lex_keeper::reset_lex_and_exec_core (this=0x1121940, thd=0x10c7698, nextp=0x7ffff7e8d228, open_tables=false, instr=0x1121900) at sp_head.cc:2728 #14 0x000000000088a539 in sp_instr_stmt::execute (this=0x1121900, thd=0x10c7698, nextp=0x7ffff7e8d228) at sp_head.cc:2842 #15 0x00000000008866d0 in sp_head::execute (this=0x111f988, thd=0x10c7698) at sp_head.cc:1248 #16 0x000000000088744e in sp_head::execute_procedure (this=0x111f988, thd=0x10c7698, args=0x10c99f8) at sp_head.cc:1977 #17 0x00000000006ca394 in mysql_execute_command (thd=0x10c7698) at sql_parse.cc:4252 #18 0x00000000006cc496 in mysql_parse (thd=0x10c7698, inBuf=0x11104e8 "call mtr.check_testcase()", length=25, found_semicolon=0x7ffff7e8ef00) at sql_parse.cc:5811 (gdb) print table->alias $2 = 0x11211d0 "GLOBAL_VARIABLES"
[11 Mar 2009 6:58]
Tatiana Azundris Nuernberg
III - "PRETTY EXPLOSIONS (III)" - adding merge_keys.init() to create_tmp_table() fixes above issue, and lo and behold, a test passes! All tests? Well, we'll see about that. If nothing else, this inits merge_keys in all the places we also init covering_keys. It's a start.
[11 Mar 2009 18:18]
Bugs System
A patch for this bug has been committed. After review, it may be pushed to the relevant source trees for release in the next version. You can access the patch from: http://lists.mysql.com/commits/68943 2813 Tatiana A. Nurnberg 2009-03-11 Bug#36751: Segmentation fault in ctype-bin.c:308; Linux 86_64, with-max-indexes=128 mysqld is optimized for the default case (up to 64-indices); for a greater number of indices it goes through a different code path. As that code-path is a compile-time option and can not easily be covered in standard tests, bitrot occurred. key-fields need an explicit initialization in the non- optimized case; this setup was presumably not added when a new key- vector was added. Changeset adds the necessary initialisations. No test case added due to dependence on compile-time option. @ sql/sql_select.cc Init merge_keys as well. If we don't, things blow up badly outside of the optimized-for-64-keys case! @ sql/table.cc Init merge_keys as well. If we don't, things blow up badly outside of the optimized-for-64-keys case!
[18 Mar 2009 13:39]
Tatiana Azundris Nuernberg
queued for 5.1.34, 6.0.11 in -bugteam
[27 Mar 2009 14:56]
Bugs System
Pushed into 5.1.34 (revid:joro@sun.com-20090327143448-wuuuycetc562ty6o) (version source revid:leonard@mysql.com-20090316090622-sr8lylqvsl1jrcnv) (merge vers: 5.1.34) (pib:6)
[27 Mar 2009 23:13]
Paul DuBois
Noted in 5.1.34 changelog. When MySQL was configured with the --with-max-indexes=128 option, mysqld crashed. Setting report to NDI pending push into 6.0.x.
[13 Apr 2009 9:21]
Bugs System
Pushed into 6.0.11-alpha (revid:alik@sun.com-20090413084402-snnrocwzktcl88ny) (version source revid:joro@sun.com-20090318165614-d6pbac7x3waux3lj) (merge vers: 6.0.11-alpha) (pib:6)
[13 Apr 2009 19:11]
Paul DuBois
Noted in 6.0.11 changelog.
[9 May 2009 16:42]
Bugs System
Pushed into 5.1.34-ndb-6.2.18 (revid:jonas@mysql.com-20090508185236-p9b3as7qyauybefl) (version source revid:jonas@mysql.com-20090508185236-p9b3as7qyauybefl) (merge vers: 5.1.34-ndb-6.2.18) (pib:6)
[9 May 2009 17:39]
Bugs System
Pushed into 5.1.34-ndb-6.3.25 (revid:jonas@mysql.com-20090509063138-1u3q3v09wnn2txyt) (version source revid:jonas@mysql.com-20090509063138-1u3q3v09wnn2txyt) (merge vers: 5.1.34-ndb-6.3.25) (pib:6)
[9 May 2009 18:36]
Bugs System
Pushed into 5.1.34-ndb-7.0.6 (revid:jonas@mysql.com-20090509154927-im9a7g846c6u1hzc) (version source revid:jonas@mysql.com-20090509154927-im9a7g846c6u1hzc) (merge vers: 5.1.34-ndb-7.0.6) (pib:6)
[29 Mar 2010 12:39]
Norbert Tretkowski
Please reopen this bugreport, I'm still (or again) seeing this crash when compiling 5.1.45 with --with-max-indexes-128 on amd64.
