Bug #42341 | Falcon assertion (key - (UCHAR*) indexNode < 14) in IndexNode::parseNode | ||
---|---|---|---|
Submitted: | 26 Jan 2009 9:37 | Modified: | 15 May 2009 16:15 |
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: | Lars-Erik Bjørk | CPU Architecture: | Any |
Tags: | F_LIMIT |
[26 Jan 2009 9:37]
Philip Stoev
[26 Jan 2009 16:05]
Kevin Lewis
Sorry, Vlad is busy with recovery bugs. Chris, please take a look at this index issue.
[27 Jan 2009 17:00]
Hakan Küçükyılmaz
Philip, does the assertion also happens with 4k page size?
[27 Jan 2009 18:14]
Philip Stoev
Hakan this was only seen with falcon-page-size=16K however so far I do not think we have had a LIMIT bug that is specific to a certain page size. I think that any page size will be affected given the right index sizes and workload.
[30 Jan 2009 15:46]
Philip Stoev
In PB2 this is seen frequently with the default page cashe size.
[27 Feb 2009 9:36]
Lars-Erik Bjørk
This crash seems to happen because we are trying to use the data behind the last record in the bucket. The reason for this is that the node with the special record number -1, which indicates END_BUCKET, is the only node in the page. WalkIndex::getNextNode has the following piece of code: int32 WalkIndex::getNextNode(void) { for (;; first = true) { if (first) { first = false; recordNumber = node.getNumber(); if (recordNumber >= 0) return recordNumber; else if (recordNumber == END_LEVEL) return -1; } node.getNext(endNodes); It seems like we fail to check if the recordNumber == END_BUCKET, and further down the call stack from node.getNext(endNodes) in IndexNode::parseNode() we try to parse some garbage data and assert on a consistency check. Changing the if from else if (recordNumber == END_LEVEL) to else if (recordNumber == END_LEVEL || recordNumber == END_BUCKET) prevents the crash. According to Ann, this check ought to be there as we should expect that pages may only contain the END_BUCKET node, and that this should not slip through WalkIndex::getNextNode()
[2 Mar 2009 8:17]
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/67956 3043 lars-erik.bjork@sun.com 2009-03-02 This is a patch for bug#42341 Falcon assertion (key - (UCHAR*) indexNode < 14) in IndexNode::parseNode and bug#38130 Falcon assertion in IndexNode::expandKey offset + length <= MAX_PHYSICAL_KEY_LENGTH These crashes happen because we are trying to use the data behind the last node in the bucket, when we are walking the index. The reason for this is that the node with the special record number -1 (which indicates END_BUCKET) is the only node in the page. WalkIndex::getNextNode has the following piece of code: int32 WalkIndex::getNextNode(void) { for (;; first = true) { if (first) { first = false; recordNumber = node.getNumber(); if (recordNumber >= 0) return recordNumber; else if (recordNumber == END_LEVEL) return -1; } node.getNext(endNodes); We fail to check if recordNumber == END_BUCKET. In the case of bug#42341, we try to parse some garbage data in IndexNode::parseNode and assert on a consistency check. In the case of bug#38130, we slip through this consistency check, but assert on a second check in IndexNode::expandKey Changing the if from else if (recordNumber == END_LEVEL) to else if (recordNumber == END_LEVEL || recordNumber == END_BUCKET) prevents both crashes. modified file 'storage/falcon/WalkIndex.cpp' ----------------------------------------------- Changed the if to prevent reading behind the END_BUCKET node.
[2 Mar 2009 14:38]
Kevin Lewis
Patch approved
[2 Apr 2009 17:39]
Bugs System
Pushed into 6.0.11-alpha (revid:hky@sun.com-20090402144811-yc5kp8g0rjnhz7vy) (version source revid:christopher.powers@sun.com-20090304040340-b4zoglfws0iswqm1) (merge vers: 6.0.11-alpha) (pib:6)
[15 May 2009 16:15]
MC Brown
Internal/test fix. No changelog entry required.