Bug #33518 Server hangs, no new connections are accepted
Submitted: 26 Dec 2007 18:56 Modified: 30 Dec 2007 4:22
Reporter: Philip Stoev Email Updates:
Status: Duplicate Impact on me:
Category:MySQL Server: Falcon storage engine Severity:S1 (Critical)
Version: OS:Any
Assigned to: Assigned Account CPU Architecture:Any
Triage: D2 (Serious)

[26 Dec 2007 18:56] Philip Stoev
Running the iuds6 test with all known workarounds (falcon memory = 2GB, falcon deadlock timeout = 50 msec, all tables Falcon-only) still results in a server which is:

* 0% cpu uage;
* No queries are processed, all threads hang;
* No new connections are accepted - server completes handshake, writes new connection establishment to log, then server hangs;
* Killing server is only possible with kill -9;
* After restart, bug #33517 is present, no recovery possible.

I will work on producing a repeatable test case. Please hang on.

How to repeat:
* ./run_systest --scenario=iuds6.tst --threads=50 --duration=86400 &
* All CREATE TABLE set to create a falcon table Falcon
* mysql-test-run options:
--vardir=$VAR_DIR --suite=systems --do-test=load_engines \
       --mysqld="--default-storage-engine=falcon" --mysqld="--falcon_record_memory_max=2GB" \
       --mysqld="--max_connections=500" --mysqld="--falcon-lock-timeout=20"
[27 Dec 2007 8:33] Philip Stoev
Falcon debug log for bug #33518

Attachment: bug33518.log (application/octet-stream, text), 24.67 KiB.

[27 Dec 2007 8:44] Philip Stoev
This bug occured again and I am attaching the output produced using falcon_debug_log = 65535.
[27 Dec 2007 14:24] Kevin Lewis
Chris,  This sounds like another undetected deadlock.  However, it may not be waitForTransaction since the timeout does not seem to help.
[30 Dec 2007 4:22] Christopher Powers
Reproduced locally. Same call stack as that detailed in Bug#33480.

Mutex in ha_partition::write_row() causes a deadlock Falcon, Transaction::waitForTransaction().