Bug #30365 Falcon: running falcon_concurrent_blob_updates leads to crash
Submitted: 10 Aug 2007 19:09 Modified: 29 Aug 2007 11:26
Reporter: Hakan Küçükyılmaz Email Updates:
Status: Closed Impact on me:
None 
Category:MySQL Server: Falcon storage engine Severity:S1 (Critical)
Version:6.0.2 OS:Linux
Assigned to: Kevin Lewis CPU Architecture:Any

[10 Aug 2007 19:09] Hakan Küçükyılmaz
Description:
Running falcon_concurrent_blob_updates leads to crash.

How to repeat:
I ran the test in a loop with increasing SEED value like

SEED=1
while ( [ $? -eq 0 ] );
     do
     ./falcon_concurrent_blob_updates -r540 -s$SEED;
     SEED=$(($SEED + 3));
done

Completed spawning new database worker threads.
Runtime is 540.
Seed value is 25.
Isolation level is READ-COMMITTED.
Testcase is now running, so watch for error output.
Waiting for worker threads to finish ...
Running initializations ...
Pre-generating 16777216 bytes of random data.
About to spawn 2 threads
1 2
Completed spawning new database worker threads.
Runtime is 540.
Seed value is 28.
Isolation level is READ-COMMITTED.
Testcase is now running, so watch for error output.
Waiting for worker threads to finish ...

--> crash

Program received signal SIGSEGV, Segmentation fault.
[Switching to Thread 1074272592 (LWP 935)]
0x0000000000924010 in RecordVersion::fetchVersion (this=0x0, trans=0x2aaab2758a80) at
RecordVersion.cpp:89
89              Transaction *recTransaction = transaction;
(gdb) bt
#0  0x0000000000924010 in RecordVersion::fetchVersion (this=0x0, trans=0x2aaab2758a80) at
RecordVersion.cpp:89
#1  0x000000000092414d in RecordVersion::fetchVersion (this=0x2aaab2749cc8,
trans=0x2aaab2758a80) at RecordVersion.cpp:111
#2  0x000000000092414d in RecordVersion::fetchVersion (this=0x2aaab23b1e08,
trans=0x2aaab2758a80) at RecordVersion.cpp:111
#3  0x000000000089e06c in StorageDatabase::nextRow (this=0x2b051364c1c8,
storageTable=0x2b051349c750, recordNumber=8099, 
    lockForUpdate=false) at StorageDatabase.cpp:250
#4  0x00000000008a3939 in StorageTable::next (this=0x2b051349c750, recordNumber=0,
lockForUpdate=false) at StorageTable.cpp:126
#5  0x000000000088c64a in StorageInterface::rnd_next (this=0x11bd118, buf=0x11bd358
"�\005N\206X") at ha_falcon.cpp:480
#6  0x00000000007b16d9 in rr_sequential (info=0x11c2a58) at records.cc:363
#7  0x000000000070dcd5 in join_init_read_record (tab=0x11c29d8) at sql_select.cc:11480
#8  0x000000000070d3b3 in sub_select (join=0x11bd6f8, join_tab=0x11c29d8,
end_of_records=false) at sql_select.cc:10830
#9  0x0000000000715ecd in do_select (join=0x11bd6f8, fields=0x11bc770, table=0x0,
procedure=0x0) at sql_select.cc:10594
#10 0x000000000072ebd6 in JOIN::exec (this=0x11bd6f8) at sql_select.cc:2099
#11 0x000000000072a3d8 in mysql_select (thd=0x11bac68, rref_pointer_array=0x11bc850,
tables=0x11c1a30, wild_num=0, 
    fields=@0x11bc770, conds=0x11c2060, og_num=0, order=0x0, group=0x0, having=0x0,
proc_param=0x0, select_options=2148813312, 
    result=0x11c2298, unit=0x11bc2a0, select_lex=0x11bc668) at sql_select.cc:2275
#12 0x000000000072eeef in handle_select (thd=0x11bac68, lex=0x11bc200, result=0x11c2298,
setup_tables_done_option=0)
    at sql_select.cc:258
#13 0x00000000006a950a in execute_sqlcom_select (thd=0x11bac68, all_tables=0x11c1a30) at
sql_parse.cc:4485
#14 0x00000000006aad7c in mysql_execute_command (thd=0x11bac68) at sql_parse.cc:1835
#15 0x00000000006b3103 in mysql_parse (thd=0x11bac68, 
    inBuf=0x11c1738 "SELECT c1 FROM t1 WHERE c2 =
'pucuufjgxbdxdyxbcymbtcelwtxboqfrnfqefjlhrgddslbgsbbpjjyeylnntylxanfaobrnnczrsqtnjiaqitzfq
xjgspejyzigkqjusdbrthvenfbtirymqaomyrxzinssowylbngxjtgjnqvojpquyaceapsawhrsusiivz"...,
length=256, 
    found_semicolon=0x40080f00) at sql_parse.cc:5381
#16 0x00000000006b3e3d in dispatch_command (command=COM_QUERY, thd=0x11bac68,
packet=0x11d8849 "", packet_length=257)
    at sql_parse.cc:907
#17 0x00000000006b51e4 in do_command (thd=0x11bac68) at sql_parse.cc:669
#18 0x00000000006a3392 in handle_one_connection (arg=0x118ea68) at sql_connect.cc:1091
#19 0x00002b0511dd9225 in start_thread () from /lib/libpthread.so.0
#20 0x00002b0512ba733d in clone () from /lib/libc.so.6
[13 Aug 2007 11:24] MySQL Verification Team
Thank you for the bug report.
[13 Aug 2007 11:27] MySQL Verification Team
See bug: http://bugs.mysql.com/bug.php?id=30032 to get falcon_concurrent_blob_updates code application.
[16 Aug 2007 18:26] Kevin Lewis
I have not reproduced this bug since fixing Bug#30364.  The could easily have been caused by the same bug.  That bug was caused by a disapearing Record object.  This seems have the same symptom, in that RecordVersion::fetchVersion()  is called from StorageDatabase::nextRow(), and all of a sudden a priorRecord pointer within the Record object is set to zero, as if the Record was freed on a non-debug Falcon, so that the next call to fetchVersion has this=0x0.  Unless this call stack shows up again, we should consider it fixed with Bug#30364.
[27 Aug 2007 7:33] Hakan Küçükyılmaz
I cannot reproduce this crash anymore.
[29 Aug 2007 11:26] MC Brown
Internal change only; no documentation required.