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)
Change History (4)
by , 10 years ago
Attachment: | IMG_20141030_205050.jpg added |
---|
by , 10 years ago
Attachment: | bplustree_find.disasm added |
---|
comment:1 by , 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 , 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.
Disassembly of BPlusTree::Find()