KDL: page fault at 0x8 (NULL dereference) in heap_allocate_from_bin

[humdinger]

This is hrev42858, gcc2hybrid

I can't really remember what exactly was going on when this crash occured, but I took a picture... It starts with:

PANIC: vm_page_fault: unhandled page fault in kernel space at 0x8, ip 0x80054bbb

I hope it's no duplicate, couldn't find an existing ticket after just a short search.
Are these kinds of reports helpful at all?

[humdinger]

KDL: vm_page_fault

[humdinger]

Attached another KDL photo that seems to show the same issue. This time it's:

PANIC: vm_page_fault: unhandled page fault in kernel space at 0x8, ip 0x8005683f

[humdinger]

another one of that sort

[humdinger]

And another one. Attached kdl-3.jpg. This time I left the computer after 3 hours uptime for 30 minutes while it was building a Haiku image (jam -qj2, 2gb ram). Came back to KDL.

[humdinger]

another one of that sort

[mmlr]

That last one isn't related, it has a different stack trace not pointing to the port heap. It'd probably warrant it's own ticket.

[bonefish]

Replying to mmlr:

That last one isn't related, it has a different stack trace not pointing to the port heap. It'd probably warrant it's own ticket.

Clemens reverted the code in hrev43739, so no point in creating a new ticket.

[humdinger]

I found that last, kdl-3, being reproducible. I'm trying to build a current Haiku image from Haiku hrev43696 with "AddOptionalHaikuImagePackages DemoPackage_Data ;" in the UserBuildProfile. The KDL appears always while extracting the demo package into the image. The 50mb package extracts to about 75mb. I made sure the image is large enough...

When extracting the demo package with Expander, there's no problem. The email seen in the KDL looks OK too...

[bonefish]

Replying to humdinger:

I found that last, kdl-3, being reproducible.

My previous comment might have been a bit to concise. :-) The crash is in the FD path info code Clemens introduced a while ago. It has a few issues which I commented on on the commit list. Since Clemens didn't have the time to address them, he removed the code for the time being (in hrev43739). So no need to track that KDL.

[anevilyak]

(In #9641) Thought I'd seen it before...duplicate of #8028.

[ttcoder]

For what it's worth, this page fault in the port-heap code can sometimes follow immediately after the "got an in use page 0x.... from the free pages list" port heap panic of #5474 (as noted in the duplicate ticket #10498).

[waddlesplash]

Is this still reproducible?

[waddlesplash]

Glancing at this again: It seems the heap in question is the "debug heap", not the "object cache heap" as we use normally. So this is probably low-priority at this point, if it's reproducible at all.