Bug #42475 | Falcon can crash in Sync::findLocks after a timeout. | ||
---|---|---|---|
Submitted: | 30 Jan 2009 12:51 | Modified: | 15 May 2009 13:02 |
Reporter: | Vladislav Vaintroub | Email Updates: | |
Status: | Closed | Impact on me: | |
Category: | MySQL Server: Falcon storage engine | Severity: | S3 (Non-critical) |
Version: | 6.0.9 | OS: | Any |
Assigned to: | Vladislav Vaintroub | CPU Architecture: | Any |
Tags: | F_SYNCHRONIZATION |
[30 Jan 2009 12:51]
Vladislav Vaintroub
[30 Jan 2009 13:11]
Bugs System
A patch for this bug has been committed. After review, it may be pushed to the relevant source trees for release in the next version. You can access the patch from: http://lists.mysql.com/commits/64626 2990 Vladislav Vaintroub 2009-01-30 Bug#42475 crash in Sync::findLocks. Falcon would sporadically crash in high concurrency situations,when some threads are stalled waiting for a lock. The crash comes from lock analysis function Sync::stalled(), that prints list of locks and wait queue. Problem: SyncObject::wait() does not reset thread->lockPending is not NULL in timeout situations. So it can happen that lockPending points to invalid memory for some Thread object. When Sync::stalled() is trying to analyze the locks, it will access lockPending and crash. Fix: Set thread->lockPending b NULL before SyncObject::wait() throws exception in timedout().
[30 Jan 2009 13:13]
Bugs System
A patch for this bug has been committed. After review, it may be pushed to the relevant source trees for release in the next version. You can access the patch from: http://lists.mysql.com/commits/64628 2990 Vladislav Vaintroub 2009-01-30 Bug#42475 crash in Sync::findLocks. Falcon would sporadically crash in high concurrency situations,when some threads are stalled waiting for a lock. The crash comes from lock analysis function Sync::stalled(), that prints list of locks and wait queue. Problem: SyncObject::wait() does not reset thread->lockPending to NULL in timeout situations. So it can happen that lockPending points to invalid memory for some Thread object. When Sync::stalled() is trying to analyze the locks, it will access lockPending and crash. Fix: Set thread->lockPending b NULL before SyncObject::wait() throws exception in timedout().
[30 Jan 2009 18:53]
Kevin Lewis
The change looks correct. OK to push
[1 Feb 2009 20:55]
Bugs System
A patch for this bug has been committed. After review, it may be pushed to the relevant source trees for release in the next version. You can access the patch from: http://lists.mysql.com/commits/64804 2990 Vladislav Vaintroub 2009-02-01 Bug#42475 crash in Sync::findLocks. Falcon would sporadically crash in high concurrency situations,when some threads are stalled waiting for a lock. The crash comes from lock analysis function Sync::stalled(), that prints list of locks and wait queue. Problem: SyncObject::wait() does not reset thread->lockPending to NULL in timeout situations. So it can happen that lockPending points to invalid memory for some Thread object. When Sync::stalled() is trying to analyze the locks, it will access lockPending and crash. Fix: Set thread->lockPending to NULL before SyncObject::wait() throws exception in timedout().
[2 Feb 2009 18:42]
Kevin Lewis
The second patch, setting thread->lockPending to NULL before SyncObject::wait() throws an exception in timedout(), is also approved.
[13 Feb 2009 7:25]
Bugs System
Pushed into 6.0.10-alpha (revid:alik@sun.com-20090211182317-uagkyj01fk30p1f8) (version source revid:vvaintroub@mysql.com-20090201205427-yzedgslc2jqiu626) (merge vers: 6.0.10-alpha) (pib:6)
[15 May 2009 13:02]
MC Brown
An entry has been added to the 6.0.10 changelog: When running Falcon during a very high concurrency workload, mysqld could fail.