Opened 11 years ago

Closed 11 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:
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 11 years ago.

Download all attachments as: .zip

Change History (9)

by maxime.simon, 11 years ago

Attachment: Inode.h ASSERT FAILED.png added

comment:1 by maxime.simon, 11 years ago

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 by axeld, 11 years ago

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 by maxime.simon, 11 years ago

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 by axeld, 11 years ago

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 by axeld, 11 years ago

Milestone: R1R1/alpha1
Priority: normalblocker

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

comment:6 by axeld, 11 years ago

Resolution: fixed
Status: newclosed

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

comment:7 by axeld, 11 years ago

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 by axeld, 11 years ago

Resolution: fixed
Status: reopenedclosed

Finally fixed in hrev33883.

Note: See TracTickets for help on using tickets.