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:
None 
Category:MySQL Server: General Severity:S2 (Serious)
Version:5.1.26-rc OS:Linux (x86_64, SLES10)
Assigned to: Tatiana Azundris Nuernberg
Tags: ctype-bin, segmentation fault, x86_64
Triage: Triaged: D1 (Critical)

[16 May 2008 8:23] Christian Bolliger
Description:
For all tests mysql has been compiled with: "--with-max-indexes=128"

Start of mysqld crashes, usual installation procedure is not possible.

Debugger output (compiled with -g):
(gdb) set args --user=mysql
(gdb) run
[Thread debugging using libthread_db enabled]
[New Thread 47952998253856 (LWP 27608)]
[New Thread 1082132800 (LWP 27611)]
[Thread 1082132800 (LWP 27611) exited]
[New Thread 1082399040 (LWP 27612)]

Program received signal SIGSEGV, Segmentation fault.
[Switching to Thread 47952998253856 (LWP 27608)]
0x00000000008020b8 in my_hash_sort_bin (cs=0xab5220, key=0x15 <Address 0x15 out of bounds>, len=21, nr1=0x7fffbe0fd808, nr2=0x7fffbe0fd800) at ctype-bin.c:308
/lustre/scratch/chribo/mysql-5.1.24-rc/strings/ctype-bin.c:308:8968:beg:0x8020b8
Current language:  auto; currently c

Using the src rpm has the same effect, log output (compiled without -g):
bootstrap log:
thd: 0xb23f40
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...
/home/user/id/chribo/rpm/BUILD/mysql-5.1.24-rc/sql/mysqld(print_stacktrace+0x1e)[0x6a63ee]
/home/user/id/chribo/rpm/BUILD/mysql-5.1.24-rc/sql/mysqld(handle_segfault+0x322)[0x58c112]
/lib64/libpthread.so.0[0x2aabbe3c4c10]
/home/user/id/chribo/rpm/BUILD/mysql-5.1.24-rc/sql/mysqld(_Z21tablename_to_filenamePKcPcj+0x16)[0x669cd6]
/home/user/id/chribo/rpm/BUILD/mysql-5.1.24-rc/sql/mysqld(_Z20build_table_filenamePcmPKcS1_S1_j+0x104)[0x669e74]
/home/user/id/chribo/rpm/BUILD/mysql-5.1.24-rc/sql/mysqld(_ZN19Table_triggers_list12check_n_loadEP3THDPKcS3_P8st_tableb+0x60)[0x6c58c0]
/home/user/id/chribo/rpm/BUILD/mysql-5.1.24-rc/sql/mysqld[0x5d04ed]
/home/user/id/chribo/rpm/BUILD/mysql-5.1.24-rc/sql/mysqld(_Z10open_tableP3THDP10TABLE_LISTP11st_mem_rootPbj+0x61b)[0x5d345b]
/home/user/id/chribo/rpm/BUILD/mysql-5.1.24-rc/sql/mysqld(_Z11open_tablesP3THDPP10TABLE_LISTPjj+0x3a0)[0x5d3f20]
/home/user/id/chribo/rpm/BUILD/mysql-5.1.24-rc/sql/mysqld(_Z23mysql_create_like_tableP3THDP10TABLE_LISTS2_P24st_ha_create_information+0x6a)[0x66f84a]
/home/user/id/chribo/rpm/BUILD/mysql-5.1.24-rc/sql/mysqld(_Z21mysql_execute_commandP3THD+0x4547)[0x59c8c7]
/home/user/id/chribo/rpm/BUILD/mysql-5.1.24-rc/sql/mysqld(_Z11mysql_parseP3THDPKcjPS2_+0x1b4)[0x59d864]
/home/user/id/chribo/rpm/BUILD/mysql-5.1.24-rc/sql/mysqld(handle_bootstrap+0x308)[0x59db88]
/lib64/libpthread.so.0[0x2aabbe3bd143]
/lib64/libc.so.6(__clone+0x6d)[0x2aabbea3674d]

How to repeat:
compile 5.1.24-rc on x86_64 with:
./configure --prefix=/lustre/prog/mysql5.1 \
 --enable-assembler \
 --enable-community-features \
 --with-comment \
 --with-max-indexes=128 \
 --with-big-tables \
 --with-thread \
 --with-fast-mutexes \
 --enable-large-files \
 --with-mysqld-user-mysql \
 --with-isam \
 --with-extra-charsets=utf8 \
 --with-libwrap \

#Lustre FS has no influence, using a local disk has the same effekt

make
make install

A test with --with-max-indexes=64 run successfully (bug does not appear).
[16 May 2008 8:26] Christian Bolliger
How to repeat addenum:

cd <mysql-base>
bin/mysql_install_db

- chribo
[18 May 2008 6:46] Valerii 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.