MySQL Bugs: #48245: crash in Bitmap<64u>::merge called by add_key

Bug #48245	crash in Bitmap<64u>::merge called by add_key_field
Submitted:	22 Oct 2009 20:25	Modified:	23 Oct 2009 19:29
Reporter:	Matthias Leich	Email Updates:
Status:	Verified	Impact on me:	None
Category:	MySQL Server: Optimizer	Severity:	S3 (Non-critical)
Version:	5.1,mysql-6.0-codebase-bugfixing	OS:	Any
Assigned to:		CPU Architecture:	Any

Description:
The crash happens in sql_bitmap.h:216 :
   void merge(Bitmap<64>& map2) { map|= map2.map; }

mysql-6.0-codebase-bugfixing 
revno: 3654 2009-10-15
-------------------------------------------
Thread 1 (process 9124):
#0  0x00007f200bbec1f6 in pthread_kill () from /lib/libpthread.so.0
#1  0x0000000000b8f05c in my_write_core (sig=11) at stacktrace.c:309
#2  0x00000000006f6f17 in handle_segfault (sig=11) at mysqld.cc:2754
#3  <signal handler called>
#4  0x0000000000769dcc in Bitmap<64u>::merge (this=0x160, map2=@0x7f20082a7f90) at sql_bitmap.h:216
#5  0x000000000077cd2d in add_key_field (key_fields=0x7f20082a8378, and_level=0, cond=0x7f2004049168, field=0x4409e00, eq_func=true, value=0x7f20082a80b0, num_values=1, usable_tables=18446744073709551615, sargables=0x7f20082a86f8) at sql_select.cc:4896
#6  0x00000000007a25b4 in add_key_fields (join=0x7f2004100cd0, key_fields=0x7f20082a8378, and_level=0x7f20082a839c, cond=0x7f2004049168, usable_tables=18446744073709551615, sargables=0x7f20082a86f8) at sql_select.cc:5268
#7  0x00000000007a1b1f in add_key_fields (join=0x7f2004100cd0, key_fields=0x7f20082a8378, and_level=0x7f20082a839c, cond=0x7f2004048138, usable_tables=18446744073709551615, sargables=0x7f20082a86f8) at sql_select.cc:5102
#8  0x00000000007a2a08 in update_ref_and_keys (thd=0x436ba88, keyuse=0x7f2004106868, join_tab=0x7f20040494e0, tables=2, cond=0x7f2004048138, cond_equal=0x7f2004048210, normal_tables=18446744073709551615, select_lex=0x7f20041ad8c0,
    sargables=0x7f20082a86f8) at sql_select.cc:5567
#9  0x00000000007a452e in make_join_statistics (join=0x7f2004100cd0, tables_arg=0x7f200413a0b8, conds=0x7f2004048138, keyuse_array=0x7f2004106868) at sql_select.cc:4182
#10 0x00000000007a8ccc in JOIN::optimize (this=0x7f2004100cd0) at sql_select.cc:1608
#11 0x00000000007ad8e8 in mysql_select (thd=0x436ba88, rref_pointer_array=0x7f20041adaa8, tables=0x7f200413a0b8, wild_num=0, fields=@0x7f20082a8bc0, conds=0x0, og_num=0, order=0x0, group=0x0, having=0x0, proc_param=0x0, select_options=1342177408,
    result=0x7f2004048058, unit=0x7f20041ad230, select_lex=0x7f20041ad8c0) at sql_select.cc:3083
#12 0x00000000007d41e1 in mysql_multi_update (thd=0x436ba88, table_list=0x7f200413a0b8, fields=0x7f20041ad9c8, values=0x7f20041addd8, conds=0x0, options=0, handle_duplicates=DUP_ERROR, ignore=false, unit=0x7f20041ad230, select_lex=0x7f20041ad8c0,
    result=0x7f20082a9650) at sql_update.cc:1246
#13 0x000000000070cfcb in mysql_execute_command (thd=0x436ba88) at sql_parse.cc:3196
#14 0x0000000000907279 in sp_instr_stmt::exec_core (this=0x7f200413aab8, thd=0x436ba88, nextp=0x7f20082aa668) at sp_head.cc:2921
#15 0x00000000009074a9 in sp_lex_keeper::reset_lex_and_exec_core (this=0x7f200413aaf8, thd=0x436ba88, nextp=0x7f20082aa668, open_tables=false, instr=0x7f200413aab8) at sp_head.cc:2746
#16 0x000000000090da7e in sp_instr_stmt::execute (this=0x7f200413aab8, thd=0x436ba88, nextp=0x7f20082aa668) at sp_head.cc:2859
#17 0x00000000009098b4 in sp_head::execute (this=0x7f2004136c60, thd=0x436ba88) at sp_head.cc:1243
#18 0x000000000090a767 in sp_head::execute_procedure (this=0x7f2004136c60, thd=0x436ba88, args=0x436dfa0) at sp_head.cc:1983
#19 0x000000000071107f in mysql_execute_command (thd=0x436ba88) at sql_parse.cc:4430
#20 0x0000000000712b87 in mysql_parse (thd=0x436ba88, inBuf=0x436e8a0 "CALL testdb_S . p1_2_N", length=22, found_semicolon=0x7f20082ac900) at sql_parse.cc:5991
#21 0x00000000007137d2 in dispatch_command (command=COM_QUERY, thd=0x436ba88, packet=0x43d9389 "CALL testdb_S . p1_2_N ", packet_length=23) at sql_parse.cc:1074
#22 0x0000000000714d3d in do_command (thd=0x436ba88) at sql_parse.cc:756
#23 0x0000000000701784 in handle_one_connection (arg=0x436ba88) at sql_connect.cc:1164
#24 0x00007f200bbe73ba in start_thread () from /lib/libpthread.so.0
#25 0x00007f200ab53fcd in clone () from /lib/libc.so.6
#26 0x0000000000000000 in ?? ()

The crash was found when running a RQG test with 30 threads
on an derivate of the grammar WL5004_sql.yy.

I will come up with a simplified testcase soon.

How to repeat:
See above

For a simplified replay testcase see
Bug#48157 crash in Item_field::used_tables

Attempts to replay this bug on mysql-5.1-bugteam Nov 2009
with the RQG grammar were not successfull.
I got either no crash/assert or crashes/assertions with
different backtraces.

Sorry, this bug could be replayed with
mysql-5.1-bugteam. But the likelihood
that we get this and not something else
is very low. And the backtrace is a tiny
bit different. Bitmap<64u>::merge gets called
by update_const_equal_items
---------------------------------------
Thread 1 (process 15200):
#0  0x00007f172226ace6 in pthread_kill () from /lib64/libpthread.so.0
#1  0x0000000000b16093 in my_write_core (sig=11) at stacktrace.c:310
#2  0x00000000006baca7 in handle_segfault (sig=11) at mysqld.cc:2570
#3  <signal handler called>
#4  0x00000000007242a8 in Bitmap<64u>::merge (this=0x138, map2=@0x41d4c430) at sql_bitmap.h:129
#5  0x000000000074c72b in update_const_equal_items (cond=0x7f17140185a0, tab=0x7f171402a028) at sql_select.cc:8302
#6  0x000000000074c5e8 in update_const_equal_items (cond=0x7f1714018280, tab=0x7f171402a028) at sql_select.cc:8283
#7  0x000000000074cb7b in join_read_const_table (tab=0x7f171402a028, pos=0x7f171402bba8) at sql_select.cc:11652
#8  0x0000000000756436 in make_join_statistics (join=0x7f171402bae0, tables_arg=0x1a2e300, conds=0x7f1714018280, keyuse_array=0x7f171402d0c8) at sql_select.cc:2693
#9  0x0000000000758768 in JOIN::optimize (this=0x7f171402bae0) at sql_select.cc:978
#10 0x000000000075cb9c in mysql_select (thd=0x7f171c0fd3f0, rref_pointer_array=0x1a2c890, tables=0x1a2e300, wild_num=0, fields=@0x41d4ce00, conds=0x0, og_num=0, order=0x0, group=0x0, having=0x0, proc_param=0x0, select_options=1342177408,
    result=0x7f1714018190, unit=0x1a2c260, select_lex=0x1a2c698) at sql_select.cc:2430
#11 0x000000000077eea2 in mysql_multi_update (thd=0x7f171c0fd3f0, table_list=0x1a2e300, fields=0x1a2c7a8, values=0x1a2cbf0, conds=0x0, options=0, handle_duplicates=DUP_ERROR, ignore=false, unit=0x1a2c260, select_lex=0x1a2c698) at sql_update.cc:1229
#12 0x00000000006cf74d in mysql_execute_command (thd=0x7f171c0fd3f0) at sql_parse.cc:3130
#13 0x000000000089e771 in sp_instr_stmt::exec_core (this=0x1a3f260, thd=0x7f171c0fd3f0, nextp=0x41d4e188) at sp_head.cc:2912
#14 0x000000000089e9b3 in sp_lex_keeper::reset_lex_and_exec_core (this=0x1a3f2a8, thd=0x7f171c0fd3f0, nextp=0x41d4e188, open_tables=false, instr=0x1a3f260) at sp_head.cc:2740
#15 0x00000000008a4f90 in sp_instr_stmt::execute (this=0x1a3f260, thd=0x7f171c0fd3f0, nextp=0x41d4e188) at sp_head.cc:2855
#16 0x00000000008a0ed2 in sp_head::execute (this=0x1a55fa0, thd=0x7f171c0fd3f0) at sp_head.cc:1255
#17 0x00000000008a1c9f in sp_head::execute_procedure (this=0x1a55fa0, thd=0x7f171c0fd3f0, args=0x7f171c0ff7f0) at sp_head.cc:1988
#18 0x00000000006d3a4d in mysql_execute_command (thd=0x7f171c0fd3f0) at sql_parse.cc:4392
#19 0x00000000006d5ba6 in mysql_parse (thd=0x7f171c0fd3f0, inBuf=0x7f171c103f30 "CALL testdb_S . p1", length=18, found_semicolon=0x41d4fef0) at sql_parse.cc:5970
#20 0x00000000006d69ea in dispatch_command (command=COM_QUERY, thd=0x7f171c0fd3f0, packet=0x7f171c0ffe01 "CALL testdb_S . p1", packet_length=18) at sql_parse.cc:1231
#21 0x00000000006d7ddc in do_command (thd=0x7f171c0fd3f0) at sql_parse.cc:872
#22 0x00000000006c4269 in handle_one_connection (arg=0x7f171c0fd3f0) at sql_connect.cc:1127
#23 0x00007f1722266040 in start_thread () from /lib64/libpthread.so.0
#24 0x00007f172151408d in clone () from /lib64/libc.so.6
#25 0x0000000000000000 in ?? ()

Matthias,
Can we close this bug as a duplicate of Bug#48157?