#9858: Ripping CDs -> page fault panic
-----------------------------+----------------------------
Reporter: ttcoder | Owner: nobody
Type: bug | Status: assigned
Priority: high | Milestone: R1/beta1
Component: System/Kernel | Version: R1/Development
Resolution: | Keywords: slab
Blocked By: | Blocking:
Has a Patch: 0 | Platform: All
-----------------------------+----------------------------
Comment (by ttcoder):
Possible breakthrough warning (if we're lucky). Please take a look and
tell me if my expectations are inflated or not :-)
I enrolled dsuden in the test with a recent nightly, he had a much easier
time than me reproducing the KDL. First two backtraces/message are
similar, "unhandled page fault in kernel space". The third one made me
fall off my chair though. Here it is typed to text for emphasis:
{{{
PANIC: page fault, but interrupts were disabled. Touching address
0xadbeefe2 from ip 0x8010287f
}}}
If it gets the spidey sense tickling in a userland guy like me, maybe it
will ''really'' interest kernel-savvy people :-)
So why is there a shifted/mangled deadbeef in there.. Seems related for
sure to the ecx register, with an almost "clean" deadbeef value. Seems
like there were two 0xdeadbeef values back to back, and list_remove_link()
tried to access an address across the two.
IIRC 0xdeadbeef is written when a pointer is free()d (or whatever the
kernel-land equivalent of free() is), is that right ? That should get us
closer to finding the problem, with some luck ?
Also gotta note that the KDL message is similar to #7889 rather than to
this ticket.. But that latter ticket's backtrace is very different, so for
now I'm filing this .jpeg here. I could even file a third ticket.. Might
make sense since this KDL smells of a different problem than the others,
possibly related to heap/malloc corruption instead of plain old memory
corruption ?
Feedback eagerly anticipated, crossing fingers to not be like "actually
that deadbeef thing does not tell us much useful stuff at all, continue
testing some more". *g*
--
Ticket URL: <http://dev.haiku-os.org/ticket/9858#comment:19>
Haiku <http://dev.haiku-os.org>
Haiku - the operating system.
