Opened 10 years ago

Last modified 10 years ago

#11399 new bug

[BFS] Panic in BPlusTree::Find()

Reported by: anevilyak Owned by: axeld
Priority: normal Milestone: R1
Component: File Systems/BFS Version: R1/Development
Keywords: Cc:
Blocked By: Blocking:
Platform: All

Description

Yesterday while doing a git commit on hrev48170, I ran into a BFS panic as seen in the attached screenshot. It should be noted that this was shortly after boot, and I had also noticed that one file in my source tree had garbage data in the first few hundred bytes, somewhat like #10765, but StyledEdit was definitely not involved. checkfs both before and after the panic indicated no errors, and I've not been able to reproduce it since.

Attachments (2)

IMG_20141030_205050.jpg (3.7 MB ) - added by anevilyak 10 years ago.
bplustree_find.disasm (9.7 KB ) - added by anevilyak 10 years ago.
Disassembly of BPlusTree::Find()

Change History (4)

by anevilyak, 10 years ago

Attachment: IMG_20141030_205050.jpg added

by anevilyak, 10 years ago

Attachment: bplustree_find.disasm added

Disassembly of BPlusTree::Find()

comment:1 by anevilyak, 10 years ago

Attached disassembly of the corresponding BFS module's BPlusTree::Find() method...if my math is correct, the faulty dereference occurred at:

1200c:	ff 70 34             	pushl  0x34(%eax)

comment:2 by anevilyak, 10 years ago

After digging around a bit further with mmlr, the panic is triggered by this call. The implication is that the BPlusTree in question has fStream set to NULL (the call to ->ID() is what triggers the dereference leading to the panic).

However, up until now, we've been unable to find a code path where that could be the case, since it would more or less imply that either 1) a tree was constructed without ever being assigned an inode, or 2) an attempt was made to set it, but the result not checked prior to calling Find() on it. If it happens again, I'll see if I can dump more of the tree's data members i.e. its status.

Note: See TracTickets for help on using tickets.