Bug #41831 | Error: assertion (record->state != recLock) failed at line 1999 in file Table.cp | ||
---|---|---|---|
Submitted: | 2 Jan 2009 20:44 | Modified: | 15 May 2009 12:56 |
Reporter: | Philip Stoev | Email Updates: | |
Status: | Closed | Impact on me: | |
Category: | MySQL Server: Falcon storage engine | Severity: | S1 (Critical) |
Version: | 6.0-falcon-team | OS: | Any |
Assigned to: | Kevin Lewis | CPU Architecture: | Any |
Tags: | F_SCAVENGER |
[2 Jan 2009 20:44]
Philip Stoev
[7 Jan 2009 18:35]
Kevin Lewis
Philip, Please be aware that the new scavenger code will move this assert to; +void RecordLeaf::pruneRecords (Table *table, int base, RecordScavenge *recordScavenge) { . . . + ASSERT(oldestVisible->state != recLock); Since the algorithm is different, it is possible that the conditions that lead to this strange bug are no longer around. Those changes will be pushed to falcon-team shortly. See Bug#34893, Bug#36700, Bug#40342, Bug#40801
[8 Jan 2009 5:31]
Kevin Lewis
I was able to reproduce this bug with RQG and the new assert mentioned previously with the new scavenger code. The records being pruned are in a strange state. The base record is state=recDeleted, next prior is recLocked in the same transaction, next prior is a record version from a previous transaction. The delete should have used the lock record instead of creating its own record version. + data {record=0x00000000} useCount 1 recordNumber 5091 size 88 generation 1 highWater -13108 encoding 0 state 1 {recDeleted} active 1 - [RecordVersion] virtualOffset 2422945 + transaction 0x00000000 + nextInTrans 0x00000000 + prevInTrans 0x00000000 transactionId 8327 savePointId 4 superceded false - priorVersion + data {record=0x00000000 } useCount 2 recordNumber 5091 size 88 generation 1 highWater -13108 encoding 0 state 4 {recLocked} active 0 - [RecordVersion] virtualOffset 0 + transaction 0x00000000 + nextInTrans 0x00000000 + prevInTrans 0x00000000 transactionId 8327 savePointId 0 superceded true - priorVersion 0x068333a0 + data {record=0x06833778 } useCount 1 + format 0x0418ebc8 recordNumber 5091 size 101 generation 1 highWater 2 encoding 4 state 0 active 0 - [RecordVersion] + priorVersion 0x00000000 virtualOffset 2420023 + transaction 0x00000000 + nextInTrans 0x00000000 + prevInTrans 0x00000000 transactionId 8321 savePointId 0 int superceded false
[15 Jan 2009 4:33]
Kevin Lewis
Move to patch pending. I tested this code quite a bit. falcon_record_cache_memory_leak2 ran 25 times straight. The trigger somehow failed to send a message to commits@lists.mysql.com today, so here is the changeset info revno: 2959 revision-id: klewis@mysql.com-20090114223344-og8t9pw03ckyexdw committer: Kevin Lewis <klewis@mysql.com> branch nick: mysql-6.0-falcon-team timestamp: Wed 2009-01-14 16:33:44 -0600 message: Bug#42080, Bug#41831 In both of these bugs, the scavenger was pruning records that it should not have. The record version chosen to start pruning is returned from RecordScavenge::inventoryRecord(). This function is improved so that only the oldest visible record is returned. In addition, Recordversion::committedbefore() is added to simplify the code and read RecordVersion::transaction only once since it can be set to null at any time.
[15 Jan 2009 4:36]
Kevin Lewis
Found this message in Bug#42080; 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/63294 2959 Kevin Lewis 2009-01-14 Bug#42080, Bug#41831 In both of these bugs, the scavenger was pruning records that it should not have. The record version chosen to start pruning is returned from RecordScavenge::inventoryRecord(). This function is improved so that only the oldest visible record is returned. In addition, Recordversion::committedbefore() is added to simplify the code and read RecordVersion::transaction only once since it can be set to null at any time.
[28 Jan 2009 7:24]
Vladislav Vaintroub
Assertion has been seen again with the latest Falcon-team, yet on another location (RecordLeaf, line 143) Following RQG command was used to crash: perl runall.pl --mysqld=--falcon-page-size=8K --rows=100 --threads=16 --mask=59 --queries=1000000 --duration=300 --basedir=G:\bzr\mysql-6.0-falcon-team --engine=Falcon --grammar=conf/combinations.yy --gendata=conf/combinations.zz --reporter=Deadlock,ErrorLog,Backtrace,Recovery --mysqld=--loose-falcon-lock-wait-timeout=1 --mysqld=--log-output=none Callstack: mysqld.exe!Error::error(const char * string=0x0000000140afd238, ...) Line 73 C++ mysqld.exe!Error::assertionFailed(const char * text=0x0000000140b28440, const char * fileName=0x0000000140b28428, int line=0x0000008f) Line 79 C++ > mysqld.exe!RecordLeaf::pruneRecords(Table * table=0x0000000004dbeb08, int base=0x00000001, RecordScavenge * recordScavenge=0x0000000005d9f7c0) Line 143 + 0x2a bytes C++ mysqld.exe!RecordGroup::pruneRecords(Table * table=0x0000000004dbeb08, int base=0x00000000, RecordScavenge * recordScavenge=0x0000000005d9f7c0) Line 123 C++ mysqld.exe!Table::pruneRecords(RecordScavenge * recordScavenge=0x0000000005d9f7c0) Line 1907 + 0x37 bytes C++ mysqld.exe!Database::pruneRecords(RecordScavenge * recordScavenge=0x0000000005d9f7c0) Line 1855 + 0x12 bytes C++ mysqld.exe!Database::scavengeRecords() Line 1806 C++ mysqld.exe!Database::scavenge() Line 1771 C++ mysqld.exe!Database::scavengerThreadMain() Line 1932 C++ mysqld.exe!Database::scavengerThreadMain(void * database=0x0000000004c10c28) Line 1920 C++ mysqld.exe!Thread::thread() Line 168 C++ mysqld.exe!Thread::thread(void * parameter=0x0000000004e2b0e8) Line 146 C++
[30 Jan 2009 5:35]
Kevin Lewis
Putting this bug back to patch queued because the other assert was fixed. The current assert is still happenning and is tracked by Bug#42340 : Falcon assertion (oldestVisible->state != recLock) in RecordLeaf::pruneRecords, line 143
[13 Feb 2009 7:24]
Bugs System
Pushed into 6.0.10-alpha (revid:alik@sun.com-20090211182317-uagkyj01fk30p1f8) (version source revid:klewis@mysql.com-20090114223344-og8t9pw03ckyexdw) (merge vers: 6.0.10-alpha) (pib:6)
[15 May 2009 12:56]
MC Brown
An entry has been added to the 6.0.10 changelog: The Falcon storage engine has been updated to incorporate new code for the built-in scavenger service, which handles the caching of records in memory. This fixes a number of different issues related to the visibility of different records during certain operations and improves the memory usage.