Opened 13 years ago

Closed 2 months ago

#8028 closed bug (not reproducible)

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

Reported by: humdinger Owned by: mmlr
Priority: low Milestone: R1
Component: System/Kernel Version: R1/Development
Keywords: Cc:
Blocked By: Blocking: #9641
Platform: All

Description

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?

Attachments (3)

KDL.JPG (127.4 KB ) - added by humdinger 13 years ago.
KDL: vm_page_fault
kdl-2.JPG (106.9 KB ) - added by humdinger 13 years ago.
another one of that sort
kdl-3.JPG (245.9 KB ) - added by humdinger 13 years ago.
another one of that sort

Download all attachments as: .zip

Change History (20)

by humdinger, 13 years ago

Attachment: KDL.JPG added

KDL: vm_page_fault

comment:1 by bonefish, 13 years ago

Keywords: port heap added
Owner: changed from axeld to mmlr
Status: newassigned

comment:2 by humdinger, 13 years ago

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

ETA: Haiku revision is hrev43696.

Last edited 13 years ago by humdinger (previous) (diff)

by humdinger, 13 years ago

Attachment: kdl-2.JPG added

another one of that sort

comment:3 by mmadia, 13 years ago

Milestone: R1R1/alpha4
Priority: normalhigh

comment:4 by humdinger, 13 years ago

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.

by humdinger, 13 years ago

Attachment: kdl-3.JPG added

another one of that sort

comment:5 by mmlr, 13 years ago

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.

in reply to:  5 comment:6 by bonefish, 13 years ago

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.

comment:7 by humdinger, 13 years ago

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

in reply to:  7 comment:8 by bonefish, 13 years ago

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.

comment:9 by scottmc, 12 years ago

Milestone: R1/alpha4R1

comment:10 by anevilyak, 12 years ago

Blocking: 9641 added

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

comment:11 by ttcoder, 11 years ago

Cc: degea@… added

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

comment:12 by waddlesplash, 6 years ago

Summary: PANIC: vm_page_fault: unhandled page fault in kernel space at 0x8, ip 0x80054bbbKDL: page fault at 0x8 (NULL dereference) in heap_allocate_from_bin

comment:13 by waddlesplash, 6 years ago

Is this still reproducible?

comment:14 by ttcoder, 6 years ago

Cc: degea@… removed

comment:15 by waddlesplash, 5 years ago

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.

comment:16 by waddlesplash, 5 years ago

Priority: highlow

comment:17 by waddlesplash, 2 months ago

Keywords: port heap removed
Resolution: not reproducible
Status: assignedclosed
Note: See TracTickets for help on using tickets.