Bug #4810 deadlock with KILL when the victim was in a wait state

• Submitted: 29 Jul 2004 17:41
• Modified: 31 Jul 2004 22:39
• Reporter: Guilhem Bichot
• Status: Closed
• Category: MySQL Server
• Severity: S2 (Serious)
• Version: 3.23
• Assigned to: Guilhem Bichot
• CPU Architecture: Any

[29 Jul 2004 17:41] Guilhem Bichot

Description:
This deadlock happens only if timings are fine for it. If you modify lock_global_read_lock() like this:
    waiting_for_read_lock--;
    fprintf(stderr, "now I (lock_global_read_lock()) sleep for 10 seconds,"
            "please kill me\n");
    sleep(10);
    sleep(5);
    thd->exit_cond(old_message);
and then you issue FLUSH TABLES WITH READ LOCK, and you kill this thread (from another thread), then the 2 threads will deadlock and mysqld will also suffer (as LOCK_open is a very commonly used mutex).
This can happen whenever the victim calls exit_cond() before releasing its mysys_var->current_mutex (only a handful of places in code).

How to repeat:
You need to modify code. See above.

Suggested fix:
release current_mutex before calling exit_cond(), as said in a comment in log.cc

[29 Jul 2004 17:42] Guilhem Bichot

Possibly affected places:
- replication
- mysql_admin_table() (OPTIMIZE TABLE, REPAIR TABLE etc)
- FLUSH TABLES WITH READ LOCK
- wait_if_global_read_lock() so much of the lock.cc code and CREATE/DROP DATABASE.
keeping in mind that the time window for the deadlock to happen is quite narrow.

[31 Jul 2004 22:39] Guilhem Bichot

Thank you for your bug report. This issue has been committed to our
source repository of that product and will be incorporated into the
next release.

If necessary, you can access the source repository and build the latest
available version, including the bugfix, yourself. More information 
about accessing the source trees is available at
    http://www.mysql.com/doc/en/Installing_source_tree.html

Additional info:

Fixed in 4.0:
ChangeSet@1.1936, 2004-07-31 22:33:20+02:00, [e-mail]