Bug #37362 Crash in do_field_eq
Submitted: 12 Jun 2008 11:30 Modified: 3 Aug 2009 23:05
Reporter: Philip Stoev Email Updates:
Status: Closed Impact on me:
None 
Category:MySQL Server: Optimizer Severity:S1 (Critical)
Version:6.0-falcon, 5.0, 5.1, 6.0 bzr OS:Any
Assigned to: Gleb Shchepa CPU Architecture:Any
Tags: regression
Triage: Triaged: D1 (Critical)

[12 Jun 2008 11:30] Philip Stoev
Description:
When running EXPLAIN EXTENDED, mysql crashed as follows:

#0  0x00110416 in __kernel_vsyscall ()
#1  0x00581c78 in pthread_kill () from /lib/libpthread.so.0
#2  0x0843eda3 in write_core (sig=11) at stacktrace.c:302
#3  0x0829b228 in handle_segfault (sig=11) at mysqld.cc:2626
#4  <signal handler called>
#5  0x00432f61 in memcpy () from /lib/libc.so.6
#6  0x083f851d in do_field_eq (copy=0xae80d44) at field_conv.cc:32
#7  0x0830e542 in copy_fields (param=0xaf5fbbc) at sql_select.cc:17642
#8  0x083103c6 in end_send_group (join=0xaf5e968, join_tab=0x0, end_of_records=false) at sql_select.cc:14563
#9  0x08322c1c in do_select (join=0xaf5e968, fields=0xaf5fcc4, table=0x0, procedure=0x0) at sql_select.cc:13069
#10 0x08335655 in JOIN::exec (this=0xaf5e968) at sql_select.cc:2740
#11 0x0824f73b in subselect_single_select_engine::exec (this=0xaf73830) at item_subselect.cc:2277
#12 0x0824c10e in Item_subselect::exec (this=0xaf73790) at item_subselect.cc:280
#13 0x0824cf8b in Item_singlerow_subselect::val_int (this=0xaf73790) at item_subselect.cc:629
#14 0x081ddb06 in Item::save_in_field (this=0xaf73790, field=0xaf233a0, no_conversions=false) at item.cc:4886
#15 0x082e7765 in fill_record (thd=0xa9c09c90, ptr=0xae49dec, values=@0xae800fc, ignore_errors=true) at sql_base.cc:8061
#16 0x0843e1e9 in select_union::send_data (this=0xaf74728, values=@0xae800fc) at sql_union.cc:60
#17 0x08309a48 in end_send (join=0xafcc100, join_tab=0xaf5ff0c, end_of_records=false) at sql_select.cc:14406
#18 0x08315b79 in evaluate_join_record (join=0xafcc100, join_tab=0xaf5fd58, error=0) at sql_select.cc:13568
#19 0x08315da5 in sub_select (join=0xafcc100, join_tab=0xaf5fd58, end_of_records=false) at sql_select.cc:13342
#20 0x08322d70 in do_select (join=0xafcc100, fields=0xae800fc, table=0x0, procedure=0x0) at sql_select.cc:13092
#21 0x08335655 in JOIN::exec (this=0xae7edb8) at sql_select.cc:2740
#22 0x083308f2 in mysql_select (thd=0xa9c09c90, rref_pointer_array=0xaf1437c, tables=0xaf73990, wild_num=0, fields=@0xaf1430c, conds=0xaf73ca0, og_num=1,
    order=0x0, group=0xaf73e38, having=0x0, proc_param=0x0, select_options=2417773056, result=0xaf74728, unit=0xaf14410, select_lex=0xaf14278)
    at sql_select.cc:2929
#23 0x0843e6f8 in mysql_derived_filling (thd=0xa9c09c90, lex=0xa9c0ad60, orig_table_list=0xaf74138) at sql_derived.cc:264
#24 0x0843e4a3 in mysql_handle_derived (lex=0xa9c0ad60, processor=0x843e528 <mysql_derived_filling(THD*, st_lex*, TABLE_LIST*)>) at sql_derived.cc:56
#25 0x082f890f in open_and_lock_tables_derived (thd=0xa9c09c90, tables=0xaf74138, derived=true) at sql_base.cc:4929
#26 0x082b7921 in open_and_lock_tables (thd=0xa9c09c90, tables=0xaf74138) at mysql_priv.h:1606
#27 0x082aa403 in execute_sqlcom_select (thd=0xa9c09c90, all_tables=0xaf74138) at sql_parse.cc:4789
#28 0x082ac0c9 in mysql_execute_command (thd=0xa9c09c90) at sql_parse.cc:2018
#29 0x082b4ec6 in mysql_parse (thd=0xa9c09c90,
    inBuf=0xaf13cc0 "EXPLAIN EXTENDED SELECT int_key FROM ( SELECT ( SELECT COUNT( pk ) FROM ( SELECT AVG( int_nokey ) FROM D AS X WHERE X . int_key < 76 ORDER BY int_nokey  LIMIT 20 ) AS X WHERE X . int_nokey < 83  GROUP"..., length=317, found_semicolon=0xa9bff260) at sql_parse.cc:5782
#30 0x082b590f in dispatch_command (command=COM_QUERY, thd=0xa9c09c90,
    packet=0xa9c0b689 "EXPLAIN EXTENDED SELECT int_key FROM ( SELECT ( SELECT COUNT( pk ) FROM ( SELECT AVG( int_nokey ) FROM D AS X WHERE X . int_key < 76 ORDER BY int_nokey  LIMIT 20 ) AS X WHERE X . int_nokey < 83  GROUP"..., packet_length=319) at sql_parse.cc:1059
#31 0x082b6b75 in do_command (thd=0xa9c09c90) at sql_parse.cc:732
#32 0x082a4385 in handle_one_connection (arg=0xa9c09c90) at sql_connect.cc:1134
#33 0x0057d32f in start_thread () from /lib/libpthread.so.0
#34 0x0049a27e in clone () from /lib/libc.so.6

The query in question was:

 EXPLAIN EXTENDED SELECT int_key FROM ( SELECT ( SELECT COUNT( pk ) FROM ( SELECT AVG( int_nokey ) FROM D AS X WHERE X . int_key < 76 ORDER BY int_nokey  LIMIT 20 ) AS X WHERE X . int_nokey < 83  GROUP BY int_key LIMIT 1 ) FROM D AS X WHERE X . int_key < 11  GROUP BY int_nokey LIMIT 20 ) AS X WHERE X . int_nokey < 75

How to repeat:
A simplifed test case and data will follow shortly.
[2 Sep 2008 13:37] Philip Stoev
Setting to open so that the bug verification team can take over.
[23 Mar 2009 21:38] Sveta Smirnova
Thank you for the report.

Verified as described.

Backtrace from 5.1:
Thread 1 (process 4827):
#0  0x002ce402 in __kernel_vsyscall ()
#1  0x0046264f in pthread_kill () from /lib/libpthread.so.0
#2  0x085a46c5 in my_write_core (sig=11) at stacktrace.c:310
#3  0x0824c685 in handle_segfault (sig=11) at mysqld.cc:2513
#4  <signal handler called>
#5  0x08190d80 in Item_field::print (this=0xa295ae0, str=0xb2b0c3f4, query_type=QT_ORDINARY) at item.cc:5434
#6  0x0816f657 in st_select_lex::print_order (str=0xb2b0c3f4, order=0xa28ac58, query_type=QT_ORDINARY) at sql_lex.cc:1985
#7  0x082eef48 in st_select_lex::print (this=0xa289638, thd=0xa230c78, str=0xb2b0c3f4, query_type=QT_ORDINARY) at sql_select.cc:16634
#8  0x08207766 in subselect_single_select_engine::print (this=0xa2854a8, str=0xb2b0c3f4, query_type=QT_ORDINARY) at item_subselect.cc:2438
#9  0x0820153f in Item_subselect::print (this=0xa285420, str=0xb2b0c3f4, query_type=QT_ORDINARY) at item_subselect.cc:317
#10 0x081842c1 in Item::print_item_w_name (this=0xa285420, str=0xb2b0c3f4, query_type=QT_ORDINARY) at item.cc:451
#11 0x082eedbe in st_select_lex::print (this=0xa289238, thd=0xa230c78, str=0xb2b0c3f4, query_type=QT_ORDINARY) at sql_select.cc:16595
#12 0x0816f786 in st_select_lex_unit::print (this=0xa2893c8, str=0xb2b0c3f4, query_type=QT_ORDINARY) at sql_lex.cc:1953
#13 0x082ee6ab in TABLE_LIST::print (this=0xa285d48, thd=0xa230c78, str=0xb2b0c3f4, query_type=QT_ORDINARY) at sql_select.cc:16487
#14 0x082ee9f6 in print_join (thd=0xa230c78, str=0xb2b0c3f4, tables=0xa2320d4, query_type=QT_ORDINARY) at sql_select.cc:16390
#15 0x082eee2a in st_select_lex::print (this=0xa232010, thd=0xa230c78, str=0xb2b0c3f4, query_type=QT_ORDINARY) at sql_select.cc:16606
#16 0x0816f786 in st_select_lex_unit::print (this=0xa231da0, str=0xb2b0c3f4, query_type=QT_ORDINARY) at sql_lex.cc:1953
#17 0x0825b7d0 in execute_sqlcom_select (thd=0xa230c78, all_tables=0xa285d48) at sql_parse.cc:4895
#18 0x08261be1 in mysql_execute_command (thd=0xa230c78) at sql_parse.cc:2204
#19 0x0826af74 in mysql_parse (thd=0xa230c78, 
    inBuf=0xa288cc0 "EXPLAIN EXTENDED SELECT int_key FROM ( SELECT ( SELECT COUNT( pk ) FROM ( SELECT AVG(\nint_nokey ) FROM D AS X WHERE X . int_key < 76 ORDER BY int_nokey  LIMIT 20 ) AS X WHERE X\n. int_nokey < 83  GROUP"..., length=317, found_semicolon=0xb2b0d2fc) at sql_parse.cc:5831
#20 0x0826bbb0 in dispatch_command (command=COM_QUERY, thd=0xa230c78, packet=0xb2a7d021 "", packet_length=317) at sql_parse.cc:1216
#21 0x0826cdce in do_command (thd=0xa230c78) at sql_parse.cc:857
#22 0x08259a05 in handle_one_connection (arg=0xa230c78) at sql_connect.cc:1115
#23 0x0045fbd4 in start_thread () from /lib/libpthread.so.0
#24 0x003b74fe in clone () from /lib/libc.so.6
[23 Mar 2009 21:40] Sveta Smirnova
6.0 backtrace like 5.1 in my case:

#0  0x002ce402 in __kernel_vsyscall ()
#0  0x002ce402 in __kernel_vsyscall ()
#1  0x0046264f in pthread_kill () from /lib/libpthread.so.0
#2  0x088240fb in my_write_core (sig=11) at stacktrace.c:309
#3  0x082bf3a0 in handle_segfault (sig=11) at mysqld.cc:2689
#4  <signal handler called>
#5  0x082004c4 in Item_field::print (this=0xa7990f8, str=0xa7f0d084, query_type=QT_ORDINARY) at item.cc:5624
#6  0x081df05b in st_select_lex::print_order (str=0xa7f0d084, order=0xa5f4128, query_type=QT_ORDINARY) at sql_lex.cc:2055
#7  0x083702e8 in st_select_lex::print (this=0xa5b72d8, thd=0xa5ba5b8, str=0xa7f0d084, query_type=QT_ORDINARY) at sql_select.cc:22125
#8  0x08277b50 in subselect_single_select_engine::print (this=0xa5f4258, str=0xa7f0d084, query_type=QT_ORDINARY) at item_subselect.cc:2783
#9  0x08271a51 in Item_subselect::print (this=0xa5f41b8, str=0xa7f0d084, query_type=QT_ORDINARY) at item_subselect.cc:383
#10 0x081f34a7 in Item::print_item_w_name (this=0xa5f41b8, str=0xa7f0d084, query_type=QT_ORDINARY) at item.cc:450
#11 0x0837015e in st_select_lex::print (this=0xa5b6ea8, thd=0xa5ba5b8, str=0xa7f0d084, query_type=QT_ORDINARY) at sql_select.cc:22086
#12 0x081df18a in st_select_lex_unit::print (this=0xa5b7040, str=0xa7f0d084, query_type=QT_ORDINARY) at sql_lex.cc:2023
#13 0x0836f999 in TABLE_LIST::print (this=0xa5f4d90, thd=0xa5ba5b8, str=0xa7f0d084, query_type=QT_ORDINARY) at sql_select.cc:21978
#14 0x0836fc48 in print_table_array (thd=0xa5ba5b8, str=0xa7f0d084, table=0xa7996c8, end=0xa7996cc) at sql_select.cc:21834
#15 0x0836febe in print_join (thd=0xa5ba5b8, str=0xa7f0d084, tables=0xa5bb8b0, query_type=QT_ORDINARY) at sql_select.cc:21903
#16 0x083701ca in st_select_lex::print (this=0xa5bb7ec, thd=0xa5ba5b8, str=0xa7f0d084, query_type=QT_ORDINARY) at sql_select.cc:22097
#17 0x081df18a in st_select_lex_unit::print (this=0xa5bb554, str=0xa7f0d084, query_type=QT_ORDINARY) at sql_lex.cc:2023
#18 0x082ce382 in execute_sqlcom_select (thd=0xa5ba5b8, all_tables=0xa5f4d90) at sql_parse.cc:4752
#19 0x082d4017 in mysql_execute_command (thd=0xa5ba5b8) at sql_parse.cc:2069
#20 0x082dced3 in mysql_parse (thd=0xa5ba5b8, 
    inBuf=0xa5b66c8 "EXPLAIN EXTENDED SELECT int_key FROM ( SELECT ( SELECT COUNT( pk ) FROM ( SELECT AVG(\nint_nokey ) FROM D AS X WHERE X . int_key < 76 ORDER BY int_nokey  LIMIT 20 ) AS X WHERE X\n. int_nokey < 83  GROUP"..., length=317, found_semicolon=0xa7f0df20) at sql_parse.cc:5783
#21 0x082dd915 in dispatch_command (command=COM_QUERY, thd=0xa5ba5b8, packet=0xa7e7e021 "", packet_length=317) at sql_parse.cc:1009
#22 0x082dec79 in do_command (thd=0xa5ba5b8) at sql_parse.cc:691
#23 0x082cca67 in handle_one_connection (arg=0xa5ba5b8) at sql_connect.cc:1146
#24 0x0045fbd4 in start_thread () from /lib/libpthread.so.0
#25 0x003b74fe in clone () from /lib/libc.so.6
[23 Mar 2009 21:42] Sveta Smirnova
shorter test

Attachment: bug37362.test (application/octet-stream, text), 379.17 KiB.

[24 Mar 2009 6:50] Sveta Smirnova
Bug was repeatable with version 5.1.23, then not repeatable with versions 5.1.30-5.1.32 (didn't check when it was reintroduced though) and 6.0.8, then repeatable again with current development sources.
[24 Mar 2009 17:12] Sveta Smirnova
Bug is repeatable with current 5.0, 5.1 and 6.0 sources.
[1 Apr 2009 21:56] 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/71146

2722 Gleb Shchepa	2009-04-02
      Bug #37362: Crash in do_field_eq
      
      EXPLAIN EXTENDED of nested query containing a error:
      
         1054 Unknown column '...' in 'field list'
         
      may cause a server crash.
      
      
      Parse error like described above forces a call to
      JOIN::destroy() on malformed subquery.
      That JOIN::destroy function closes and frees temporary
      tables. However, temporary fields of these tables
      may be listed in st_select_lex::group_list of outer
      query, and that st_select_lex may not cleanup them
      properly. So, after the JOIN::destroy call that
      st_select_lex::group_list may have Item_field
      objects with dangling pointers to freed temporary
      table Field objects. That caused a crash.
      
      To prevent dangling pointers,
      1) a list of temporary table fields has been added
      to JOIN class;
      2) JOIN::destroy has been modified to cleanup
      temporary table fields.
      modified:
        mysql-test/r/subselect3.result
        mysql-test/t/subselect3.test
        sql/sql_select.cc
        sql/sql_select.h
[3 Apr 2009 15:44] 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/71332

2722 Gleb Shchepa	2009-04-03
      Bug #37362: Crash in do_field_eq
      
      EXPLAIN EXTENDED of nested query containing a error:
      
         1054 Unknown column '...' in 'field list'
      
      may cause a server crash.
      
      
      Parse error like described above forces a call to
      JOIN::destroy() on malformed subquery.
      That JOIN::destroy function closes and frees temporary
      tables. However, temporary fields of these tables
      may be listed in st_select_lex::group_list of outer
      query, and that st_select_lex may not cleanup them
      properly. So, after the JOIN::destroy call that
      st_select_lex::group_list may have Item_field
      objects with dangling pointers to freed temporary
      table Field objects. That caused a crash.
      modified:
        mysql-test/r/subselect3.result
        mysql-test/t/subselect3.test
        sql/sql_select.cc
[29 Apr 2009 18:15] Timour Katchaounov
Review discussion with Gleb:
<timour> gleb, quick question
<timour> in
<timour> JOIN::destroy()
<timour> you added:
<timour> +  { /* Cleanup items referencing temporary table columns */
<timour> +    List_iterator_fast<Item> it(tmp_all_fields3);
<timour> +    Item *item;
<timour> +    while ((item= it++))
<timour> +      item->cleanup();
<timour> +  }
<timour> gleb, this is unconditional, however
<timour> looking at how tmp_all_fields3 is used,
<timour> one case that it is initialized inside an IF statement:
<timour> inside
<timour> JOIN::exec()
<timour> {
<timour> ....
<timour>   if (curr_join->group || curr_join->tmp_table_param.sum_func_count ||
<timour>       (procedure && (procedure->flags & PROC_GROUP)))
<timour>   {
<timour> ...
<gleb> timour: looking
<timour> initalize and modify tmp_all_fields3
<timour> ...
<timour>   }
<timour> }
<timour> gleb, thus, it makes sense to change your patch as:
<timour> if (tmp_all_fields3 is non-empty)
<timour> {
<timour>   cleanup all items in tmp_all_fields3
<timour> }
<timour> gleb, then another question -
<gleb> timour: agree (OTOH isn't this change equivalent to my patch? ;-)
<timour> gleb, not exactly, as with this change we allocate an iterator only if really needed.
<timour> gleb, and it is clearer, otherwise why cleanup something that shouldn't be cleaned up.
<timour> gleb, then naturally, I would like you to investigate how do we cleanup the contents of
<timour> tmp_all_fields[1,2]
<gleb> timour: FYI: cleanup of tmp_all_fields2 like tmp_all_fields3 is probably ok, but tmp_all_fields1 is not (I'm just running tests and looking at gdb traces)
<timour> gleb, could be - my point was that we should not wait for the next similar bug if there are other similar cases.
<timour> gleb, also, please add a comment why tmp_all_fields[2,3] can be cleaned up, but tmp_all_fields1 cannot.
<gleb> timour: I see. but additional investigation is not trivial (need some more time)
<gleb> timour: ok
<timour> gleb, if  tmp_all_fields2 needs cleanup, could you add a test.
<gleb> timour: I think I can
[30 Apr 2009 8:36] 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/73090

2722 Gleb Shchepa	2009-04-30
      Bug #37362: Crash in do_field_eq
      
      EXPLAIN EXTENDED of nested query containing a error:
      
         1054 Unknown column '...' in 'field list'
      
      may cause a server crash.
      
      
      Parse error like described above forces a call to
      JOIN::destroy() on malformed subquery.
      That JOIN::destroy function closes and frees temporary
      tables. However, temporary fields of these tables
      may be listed in st_select_lex::group_list of outer
      query, and that st_select_lex may not cleanup them
      properly. So, after the JOIN::destroy call that
      st_select_lex::group_list may have Item_field
      objects with dangling pointers to freed temporary
      table Field objects. That caused a crash.
     @ mysql-test/r/subselect3.result
        Added test case for bug #37362.
     @ mysql-test/t/subselect3.test
        Added test case for bug #37362.
     @ sql/sql_select.cc
        Bug #37362: Crash in do_field_eq
        
        The JOIN::destroy function has been modified to
        cleanup temporary table column items.
[28 May 2009 7:40] Bugs System
Pushed into 5.0.83 (revid:joro@sun.com-20090528073529-q9b8s60vlpu28fny) (version source revid:gshchepa@mysql.com-20090430192037-9p1etcynkglte2j3) (merge vers: 5.0.82) (pib:6)
[28 May 2009 8:13] Bugs System
Pushed into 5.1.36 (revid:joro@sun.com-20090528073639-yohsb4q1jzg7ycws) (version source revid:mats@sun.com-20090511132802-nnkiyb2huih1tklz) (merge vers: 5.1.35) (pib:6)
[30 May 2009 2:35] Paul Dubois
Noted in 5.0.83, 5.1.36 changelogs.

If a query was such as to produce the error "1054 Unknown column '...'
in 'field list'," using EXPLAIN EXTENDED with the query could cause a
server crash. 

Setting report to NDI pending push into 6.0.x.
[3 Aug 2009 23:05] Paul Dubois
Noted in 5.4.4 changelog.
[10 Aug 2009 17:53] Paul Dubois
Noted in 5.0.82sp1 changelog.
[10 Aug 2009 18:59] Bugs System
Pushed into 5.0.85 (revid:build@mysql.com-20090810185326-yr4orhpwq09e3y50) (version source revid:build@mysql.com-20090810185326-yr4orhpwq09e3y50) (merge vers: 5.0.85) (pib:11)
[12 Aug 2009 22:54] Paul Dubois
Noted in 5.4.2 changelog because next 5.4 version will be 5.4.2 and not 5.4.4.
[15 Aug 2009 2:11] Paul Dubois
Ignore previous comment about 5.4.2.
[25 Aug 2009 9:23] Bugs System
Pushed into 5.1.39 (revid:jperkin@sun.com-20090824091334-6ktgrhq218vl7zq1) (version source revid:joerg@mysql.com-20090813203300-nnskc3aofxydzi85) (merge vers: 5.1.39) (pib:11)
[26 Aug 2009 13:45] Bugs System
Pushed into 5.1.37-ndb-7.0.8 (revid:jonas@mysql.com-20090826132541-yablppc59e3yb54l) (version source revid:jonas@mysql.com-20090826132541-yablppc59e3yb54l) (merge vers: 5.1.37-ndb-7.0.8) (pib:11)
[26 Aug 2009 13:46] Bugs System
Pushed into 5.1.37-ndb-6.3.27 (revid:jonas@mysql.com-20090826105955-bkj027t47gfbamnc) (version source revid:jonas@mysql.com-20090826105955-bkj027t47gfbamnc) (merge vers: 5.1.37-ndb-6.3.27) (pib:11)
[26 Aug 2009 13:48] Bugs System
Pushed into 5.1.37-ndb-6.2.19 (revid:jonas@mysql.com-20090825194404-37rtosk049t9koc4) (version source revid:jonas@mysql.com-20090825194404-37rtosk049t9koc4) (merge vers: 5.1.37-ndb-6.2.19) (pib:11)
[27 Aug 2009 16:32] Bugs System
Pushed into 5.1.35-ndb-7.1.0 (revid:magnus.blaudd@sun.com-20090827163030-6o3kk6r2oua159hr) (version source revid:jonas@mysql.com-20090826132541-yablppc59e3yb54l) (merge vers: 5.1.37-ndb-7.0.8) (pib:11)
[14 Sep 2009 16:02] Bugs System
Pushed into 5.4.4-alpha (revid:alik@sun.com-20090914155317-m1g9wodmndzdj4l1) (version source revid:alik@sun.com-20090914155317-m1g9wodmndzdj4l1) (merge vers: 5.4.4-alpha) (pib:11)
[1 Oct 2009 5:58] Bugs System
Pushed into 5.1.39-ndb-6.3.28 (revid:jonas@mysql.com-20091001055605-ap2kiaarr7p40mmv) (version source revid:jonas@mysql.com-20091001055605-ap2kiaarr7p40mmv) (merge vers: 5.1.39-ndb-6.3.28) (pib:11)
[1 Oct 2009 7:25] Bugs System
Pushed into 5.1.39-ndb-7.0.9 (revid:jonas@mysql.com-20091001072547-kv17uu06hfjhgjay) (version source revid:jonas@mysql.com-20091001071652-irejtnumzbpsbgk2) (merge vers: 5.1.39-ndb-7.0.9) (pib:11)
[1 Oct 2009 13:25] Bugs System
Pushed into 5.1.39-ndb-7.1.0 (revid:jonas@mysql.com-20091001123013-g9ob2tsyctpw6zs0) (version source revid:jonas@mysql.com-20091001123013-g9ob2tsyctpw6zs0) (merge vers: 5.1.39-ndb-7.1.0) (pib:11)
[5 Oct 2009 10:50] Bugs System
Pushed into 5.1.39-ndb-6.2.19 (revid:jonas@mysql.com-20091005103850-dwij2dojwpvf5hi6) (version source revid:jonas@mysql.com-20090930185117-bhud4ek1y0hsj1nv) (merge vers: 5.1.39-ndb-6.2.19) (pib:11)
[8 Oct 2009 20:13] Paul Dubois
The 5.4 fix has been pushed to 5.4.2.