| Bug #53510 | Potential deadlock | ||
|---|---|---|---|
| Submitted: | 8 May 2010 0:02 | Modified: | 17 Jul 2010 12:29 |
| Reporter: | Weiwei Xiong | Email Updates: | |
| Status: | No Feedback | Impact on me: | |
| Category: | MySQL Server: Locking | Severity: | S2 (Serious) |
| Version: | 5.0+ | OS: | Linux |
| Assigned to: | CPU Architecture: | Any | |
| Tags: | deadlock, performance issue | ||
[7 Jun 2010 15:43]
Konstantin Osipov
Please check out 5.5, this call chain is not there.
[17 Jul 2010 23:00]
Bugs System
No feedback was provided for this bug for over a month, so it is being suspended automatically. If you are able to provide the information that was originally requested, please do so and change the status of the bug back to "Open".
Description: I think there's a potential deadlock here: In sql_base.cc: Thread 1 wait_for_table() { Lock(&LOCK_open); ==> 3 level call chain while(global_read_lock_blocks_commit) && !thd->killed) { waiting ... } } This may potentially cause a performance issue. And further more, In sql/lock.cc: Thread 2 make_global_read_lock_block_commit(){ global_read_lock_blocks_commit ++; while(protect_against_global_read_lock && !thd_killed) { wait... } global_read_lock_blocks_commit--; } In sql_trigger.cc: Thread 3 mysql_create_or_drop_trigger(...) { wait_if_global_read_lock() => protect_against_global_read_lock ++; LOCK(&LOCK_open); -- protect_against_global_read_lock; } Thread 1 grabbed the LOCK_open mutex, and could be blocked in the waiting loop by thread 2's global_read_lock_blocks_commit ++; Thread 2 may be blocked by thread 3's protect_against_global_read_lock ++; While thread 3 is trying to grab the LOCK_open, which is already held by thread 1, it can't execute -- protect_against_global_read_lock. This may cause the situation Thread 1 waiting for thread 2, thread 2 waiting for thread 3, and thread 3 waiting for thread 1, thus a cyclic deadlock. How to repeat: Detected by our tool. Trying to repeat...