Opened 5 weeks ago
Last modified 4 weeks ago
#19252 new bug
[ramfs] PANIC: vm_page_fault: unhandled page fault in kernel space
| Reported by: | bipolar | Owned by: | nobody |
|---|---|---|---|
| Priority: | normal | Milestone: | Unscheduled |
| Component: | File Systems/RAMFS | Version: | R1/beta5 |
| Keywords: | Cc: | ||
| Blocked By: | Blocking: | ||
| Platform: | All |
Description
While using haikuporter to build the mozc recipe (with OUTPUT_DIRECTORY pointing to a RAMFS mount), on beta5+125, 64 bits, bare-metal, I got the attached KDL (syslog didn't retained the info upon reboot).
The build had almost ended, but haikuporter was unable to unmount the system volume from the chroot, so I did it manually, removed a boot/system dir that remained on the chroot, tried to run hp -F mozc, and that is where I got the KDL.
Attachments (1)
Change History (4)
by , 5 weeks ago
| Attachment: | kdl-ramfs-vm_page_fault.jpg added |
|---|
comment:1 by , 5 weeks ago
comment:2 by , 5 weeks ago
FWIW, I have 8 GB of RAM on that machine, and while building the recipe, RAM usage topped at 3.2 GB. The largest I've seen for that particular work dir during build, was about 1 GB. Even doubling that... should still have a couple of GBs left. But I have no idea how accurate those numbers are (of if there are other "hidden" uses of RAM).
comment:3 by , 4 weeks ago
Hmm, then maybe not.
Did "hp -F mozc" on a RAMFS twice now, didn't get this KDL so far. I looked at the codepath here and it acquires a write lock, as it should, and does NULL checks in the relevant places. So I'm not sure how this could happen.
I have a few refactors I'll push, though.
Looks like a NULL dereference after OOM.