Bug #43958 | Assertion (transState != NULL) failed in Transaction::waitForTransaction | ||
---|---|---|---|
Submitted: | 30 Mar 2009 13:07 | Modified: | 15 May 2009 16:10 |
Reporter: | John Embretsen | Email Updates: | |
Status: | Closed | Impact on me: | |
Category: | MySQL Server: Falcon storage engine | Severity: | S1 (Critical) |
Version: | 6.0.11-bzr | OS: | Solaris (Solaris 10 x64) |
Assigned to: | Olav Sandstå | CPU Architecture: | Any |
Tags: | F_TRANSACTION |
[30 Mar 2009 13:07]
John Embretsen
[30 Mar 2009 13:11]
John Embretsen
Issue was observed against mysql-6.0-falcon-team branch revision christopher.powers@sun.com-20090328181017-hadhr0dt1a389301 (at 2009-03-29 around 01:00 CET).
[30 Mar 2009 14:32]
John Embretsen
I have reproduced this issue and obtained core file. Let me know if you need more information. In the error log the assertion was preceeded by: 090330 16:25:47 [ERROR] Got error 123 when reading table './test/t1' $SRC_BRANCH/extra/perror tells me what this error means: MySQL error code 123: Someone has changed the row since it was read (while the table was locked to prevent it)
[30 Mar 2009 15:09]
Ann Harrison
I think this is less a Falcon issue than a Falcon/handler issue. We don't do transactional table locking.
[30 Mar 2009 20:16]
Olav Sandstå
This crash is caused by an wrong assert added first in Transaction::waitForTransaction() as part of the implementation of the new Transaction State object (see bug#41357).
[31 Mar 2009 9:16]
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/70867 3086 Olav Sandstaa 2009-03-31 Fix for Bug #43958 Assertion (transState != NULL) failed in Transaction::waitForTransaction Remove too strict assert on the in parameter to Transaction::waitForTransaction. @ storage/falcon/Transaction.cpp Remove too strict assert on the in parameter to Transaction::waitForTransaction.
[31 Mar 2009 9:52]
Lars-Erik Bjørk
Given your explanation and from looking at the code, I say OK to push from me
[1 Apr 2009 6:39]
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/71002 3093 Kevin Lewis 2009-04-01 Bug#43958 - An alternative solution to deleting the assert for the existence of the TransState object is to re-organize the calls to Transaction::waitForTransaction so that they ALWAYS use a TransactionState pointer. This can be done because the only place where the transId is sent in by itself is in Table::validateAndInsert(). This function calls waitForTransaction when a new base record is found superceding the record that was known as the prior. This new base record MUST be a RecordVersion, so it MUST have a TransactionState pointer. So instead of sending the TransId, the patch now sends the TransactionState pointer. This also allows us to eliminate a costly and obnoxious search for a Transaction based on a TransId. Note that Table::validateAndInsert() holds its own useCount on the TransactionState that it gets from the new pending base record, just in case that record is rolledBack. Although, with the new CycleManager, that rolledBack record will not be deleted until validateAndInsert() is done.
[1 Apr 2009 19:39]
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/71138 3093 Kevin Lewis 2009-04-01 Bug#43958 - An alternative solution to deleting the assert for the existence of the TransState object is to re-organize the calls to Transaction::waitForTransaction so that they ALWAYS use a TransactionState pointer. This can be done because the only place where the transId is sent in by itself is in Table::validateAndInsert(). This function calls waitForTransaction when a new base record is found superceding the record that was known as the prior. This new base record MUST be a RecordVersion, so it MUST have a TransactionState pointer. So instead of sending the TransId, the patch now sends the TransactionState pointer. This also allows us to eliminate a costly and obnoxious search for a Transaction based on a TransId. Note that Table::validateAndInsert() holds its own useCount on the TransactionState that it gets from the new pending base record, just in case that record is rolledBack. Although, with the new CycleManager, that rolledBack record will not be deleted until validateAndInsert() is done. In addition to waitForTransaction, the various calls to getRelativeState are also changed to use TransactionState and not use TransId. waitForTransaction does not need to increment its own useCount on the TransactionState object sent in. It either comes from validateAndInsert or getRelativeState. Table::validateAndInsert holds a useCount itself. Most of the getRelativeState calls hold a useCount on the record associated with the TransactionState, which by extention, holds the useCount on the TransactionState. An addRef is added to getrelativeState(Record*) so that waitForTransaction does not need to.
[2 Apr 2009 17:39]
Bugs System
Pushed into 6.0.11-alpha (revid:hky@sun.com-20090402144811-yc5kp8g0rjnhz7vy) (version source revid:olav@sun.com-20090331091553-21i60f3ser2slzf0) (merge vers: 6.0.11-alpha) (pib:6)
[15 Apr 2009 16:59]
Bugs System
Pushed into 6.0.11-alpha (revid:hky@sun.com-20090415164923-9arx29ye5pzxd4zf) (version source revid:kevin.lewis@sun.com-20090401193845-97k8cnd4d0zlzyll) (merge vers: 6.0.11-alpha) (pib:6)
[15 May 2009 16:10]
MC Brown
Internal/test fix. No changelog entry required.