Opened 6 years ago

Closed 5 months ago

#10062 closed bug (not reproducible)

vnode related KDL / Pagefault in qemu

Reported by: kallisti5 Owned by: nobody
Priority: normal Milestone: R1
Component: System/Kernel Version: R1/Development
Keywords: Cc:
Blocked By: Blocking:
Has a Patch: no Platform: All

Description (last modified by kallisti5)

Encountered this KDL / Pagefault in a qemu emulated Haiku machine. Never seen it before pre-PM, so posting screenshot here (pagefault2.png)

Attachments (3)

pagefault.png (57.6 KB ) - added by kallisti5 6 years ago.
pagefault2.png (49.4 KB ) - added by kallisti5 6 years ago.
Got another page fault, similar issue, different backtrace.
pagefault3.png (60.4 KB ) - added by kallisti5 6 years ago.
another page fault, running a sync

Download all attachments as: .zip

Change History (15)

by kallisti5, 6 years ago

Attachment: pagefault.png added

by kallisti5, 6 years ago

Attachment: pagefault2.png added

Got another page fault, similar issue, different backtrace.

comment:1 by bonefish, 6 years ago

I don't see any similarity between the two stack traces. The second one looks like there's an invalid vnode pointer in the vnode hash table. The first lookup_vnode() argument looks incorrect, but maybe that's just a glitch in the stack trace code -- the last kernel_debugger_{loop,internal}() argument doesn't look correct either.

The first stack trace shows a userland page fault. Given that it comes from PyObject_Malloc(), I suppose it just accesses allocated but non-yet-mapped memory. So this is all just fine. Unfortunately the screenshot doesn't contain the panic message. I assume it is an assertion of some inline function vm_soft_fault() calls, since it doesn't call panic() and doesn't contain any assertions itself.

So, please open separate tickets for the issues. And also add the basic information like the Haiku revision, which gcc, details on the (virtual) hardware, and some info on what led up to the crash.

As a general hint, qemu has a -serial option which I would recommend to use always (I find -serial stdio quite convenient).

by kallisti5, 6 years ago

Attachment: pagefault3.png added

another page fault, running a sync

comment:2 by kallisti5, 6 years ago

Feel free to ignore the first screenshot. Didn't have stdio serial going, but the next boot will and I'll grab the output

comment:3 by kallisti5, 6 years ago

EDIT: <unrelated page fault removed and copied to #2539>

Last edited 6 years ago by kallisti5 (previous) (diff)

comment:4 by diver, 6 years ago

Looks like #2539.

comment:5 by bonefish, 6 years ago

Yes the app server crash looks like #2539. pagefault3.png is yet another issue. Please open separate bug reports for the different issues.

comment:6 by kallisti5, 6 years ago

OK, lets focus on the page fault in pagefault2.png. Sorry for mixing them up in this ticket. As they occured within a few hours of each other on the same machine I thought they were all related.

comment:7 by kallisti5, 6 years ago

Description: modified (diff)
Summary: KDL / Pagefaultvnode related KDL / Pagefault in qemu

comment:8 by kallisti5, 6 years ago

Are we sure these panic's aren't related in some way? I just got another one with another random stack strace.. The only relation is they are all memory related.

comment:9 by pulkomandy, 5 years ago

The code in pagefault2.png was partially rewritten to resolve #9552. Does the new code crashes similarly or is the issue gone?

comment:10 by pulkomandy, 4 years ago

Milestone: R1/beta1R1

No answer since 2 years, removing from beta1 for now.

comment:11 by axeld, 3 years ago

Owner: changed from axeld to nobody
Status: newassigned

comment:12 by waddlesplash, 5 months ago

Resolution: not reproducible
Status: assignedclosed
Note: See TracTickets for help on using tickets.