Bug #29981 Falcon: crash with 64 threads
Submitted: 23 Jul 2007 16:25 Modified: 5 Dec 2007 17:04
Reporter: Calvin Sun Email Updates:
Status: Can't repeat Impact on me:
Category:MySQL Server: Falcon storage engine Severity:S1 (Critical)
Version:6.0.1 OS:Linux
Assigned to: Jim Starkey CPU Architecture:Any

[23 Jul 2007 16:25] Calvin Sun
from Ranger:

Just checked with the latest Jim's fix on qa-bench-emt64 box. It sometimes hangs during run with 4 threads on 'COMMIT' and it crashes during run with 64 threads:


Program terminated with signal 4, Illegal instruction.
#0  0x00002b85ac5ce3d3 in pthread_kill () from /lib64/libpthread.so.0
(gdb) bt
#0  0x00002b85ac5ce3d3 in pthread_kill () from /lib64/libpthread.so.0
#1  0x00000000005e5776 in handle_segfault (sig=4) at mysqld.cc:2250
#2  <signal handler called>
#3  0x00002b85ac5d0fdd in raise () from /lib64/libpthread.so.0
#4  0x000000000079275c in Error::error (string=<value optimized out>) at Error.cpp:92
#5  0x000000000076c6c3 in ~Transaction (this=0x2b85af775d78) at Transaction.cpp:187
#6  0x000000000076c03f in Transaction::commitNoUpdates (this=0x2b85af775d78) at Transaction.cpp:923
#7  0x000000000076c557 in Transaction::commit (this=0x2b85af775d78) at Transaction.cpp:229
#8  0x000000000077e0f1 in Connection::commit (this=0x2b85af7a2a30) at Connection.cpp:269
#9  0x00000000007551bb in StorageConnection::commit (this=0x2b85af7a2998) at StorageConnection.cpp:153
#10 0x0000000000749fcd in StorageInterface::commit (hton=<value optimized out>, thd=0x2aaab40aacf0, all=true)
    at ha_falcon.cpp:998
#11 0x00000000006beba7 in ha_commit_one_phase (thd=0x2aaab40aacf0, all=true) at handler.cc:779
#12 0x00000000006bf5c2 in ha_commit_trans (thd=0x2aaab40aacf0, all=true) at handler.cc:749
#13 0x00000000005f35e1 in end_trans (thd=0x5d6f, completion=COMMIT) at sql_parse.cc:555
#14 0x00000000005f4f45 in mysql_execute_command (thd=0x2aaab40aacf0) at sql_parse.cc:3557
#15 0x00000000005fa9b0 in mysql_parse (thd=0x2aaab40aacf0, inBuf=0x2aaac0032cf0 "COMMIT", length=6,
    found_semicolon=0x407bb068) at sql_parse.cc:5381
#16 0x00000000005fae3d in dispatch_command (command=COM_QUERY, thd=0x2aaab40aacf0,
    packet=0x2aaab40ada01 "COMMIT", packet_length=<value optimized out>) at sql_parse.cc:907
#17 0x00000000005fc163 in do_command (thd=0x2aaab40aacf0) at sql_parse.cc:669
#18 0x00000000005eddb6 in handle_one_connection (arg=0x2aaab40aacf0) at sql_connect.cc:1091
#19 0x00002b85ac5c909e in start_thread () from /lib64/libpthread.so.0
#20 0x00002b85ad35e4cd in clone () from /lib64/libc.so.6
#21 0x0000000000000000 in ?? ()
(gdb) frame 6
#6  0x000000000076c03f in Transaction::commitNoUpdates (this=0x2b85af775d78) at Transaction.cpp:923
923                     delete this;
(gdb) l
918     {
919             //ASSERT(useCount > dependencies);
920             int count = INTERLOCKED_DECREMENT(useCount);
922             if (count == 0)
923                     delete this;
925             return count;
926     }

How to repeat:
Ranger will have details later

Suggested fix:
no crash.
[24 Jul 2007 16:36] Kevin Lewis
Holding the locks in Transaction::commitNoUpdate for until the end cleared up the conflict which was caused by another thread using an available transaction before it was fully available.
[5 Dec 2007 17:04] Alexey Stroganov
Rechecked and confirming that this issue doesn't exist in 6.0.4pre anymore.