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

[maxime.simon]

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.

[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.

[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.

[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.

[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.

[axeld]

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

[axeld]

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

[axeld]

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

[axeld]

Finally fixed in hrev33883.