Opened 10 years ago

Closed 9 years ago

#4155 closed bug (fixed)

ASSERT FAILED in bfs/Inode.h:178 when building source code.

Reported by: maxime.simon Owned by: axeld
Priority: blocker Milestone: R1/alpha2
Component: File Systems/BFS Version: R1/Development
Keywords: Cc:
Blocked By: Blocking:
Has a Patch: no Platform: All


In Haiku, I got this issue when compiling DumpRenderTree. ( a tool to test the rendering of our WebKit port ). The command was

jam -j2 DumpRenderTree

The ASSERT which failed and the backtrace are in the screenshot as attachment.

Note: I made a checkfs of my two drives, but I still got the problem.

Attachments (1)

Inode.h ASSERT FAILED.png (60.4 KB) - added by maxime.simon 10 years ago.

Download all attachments as: .zip

Change History (9)

Changed 10 years ago by maxime.simon

Attachment: Inode.h ASSERT FAILED.png added

comment:1 Changed 10 years ago by maxime.simon

I tried with other targets (still in WebKit), and using jam -j2 foobar . It failed again. So I tried with jam -q foobar and I didn't get any PANIC: ASSERT FAILED.

comment:2 Changed 10 years ago by axeld

Are you building Haiku yourself and recently changed some kernel debug settings? Or only updated parts of Haiku?

The code in question looks perfectly fine, and if this would be an actual bug, everyone should run into it all the time.

comment:3 Changed 10 years ago by maxime.simon

I'm building Haiku myself, but I didn't hit anything in the kernel debug settings.
In fact I got the issue on Haiku, when using jam -j2 .

If the issue was from my file system, when making a checkfs I should get some warnings about corrupted data, isn't it?
I restarted the compilation 3 times, with different targets (but in the same directory) and 3 times I got the issue.

But the last building using the same flag didn't send me to the KDL.

comment:4 Changed 10 years ago by axeld

Nah, I suspected a build problem, but I just ran into this thing, too.

I don't really understand how this problem can occur, but hrev31944 fixes a recently introduced bug that should be responsible for it. I'll do some more testing tonight, and if I can't reproduce it anymore, I'll close it as fixed for now.

comment:5 Changed 10 years ago by axeld

Milestone: R1R1/alpha1
Priority: normalblocker

Just ran into it again, this one must be new.

comment:6 Changed 10 years ago by axeld

Resolution: fixed
Status: newclosed

Fixed in hrev31952 - this caused another bug, though, which was fixed in hrev31954.

comment:7 Changed 9 years ago by axeld

Milestone: R1/alpha1R1/alpha2
Resolution: fixed
Status: closedreopened
Version: R1/pre-alpha1R1/Development

Just ran into it again, there must be another problematic code path (using hrev33823).

comment:8 Changed 9 years ago by axeld

Resolution: fixed
Status: reopenedclosed

Finally fixed in hrev33883.

Note: See TracTickets for help on using tickets.