Opened 14 years ago

Closed 14 years ago

#5352 closed bug (fixed)

hang on entering KDL while strace:ing CDPlayer

Reported by: jonas.kirilla Owned by: bonefish
Priority: normal Milestone: R1
Component: System/Kernel Version: R1/Development
Keywords: Cc:
Blocked By: Blocking:
Platform: All

Description (last modified by bonefish)

I was doing a "strace -s CDPlayer" in Terminal and pressed the keys to enter KDL. The white ribbon appeared but no text, and input wasn't possible. I also had ActivityMonitor running. Revision should be around hrev35383. This is on a quad core.

Change History (9)

comment:1 by jonas.kirilla, 14 years ago

Description: modified (diff)

comment:2 by bonefish, 14 years ago

Description: modified (diff)

I've seen the problem, too. Though not on voluntarily entering KDL, but on a panic() (at least I think it was a panic() -- I had no serial port at that time). Can you reproduce the bug with the described method or was that a one time thing?

Regarding _kern_port_buffer_size_etc(): That's a blocking call (it waits for new messages).

comment:3 by jonas.kirilla, 14 years ago

Seems like I can easily reproduce the hung white ribbon by entering KDL, continuing and then entering KDL again. I.e. manually entering KDL twice in a row.

No strace:ing or certain apps running necessary for it to happen.

comment:4 by bonefish, 14 years ago

Nice. Unfortunately this method doesn't work here. Do you have have a way to capture the serial output? Would be interesting what is printed when it hangs.

comment:5 by jonas.kirilla, 14 years ago

PANIC: Keyboard Requested Halt.
Welcome to Kernel Debugging Land...
Thread 4 "idle thread 4" running on CPU 0
kdebug> co
PANIC: Keyboard Requested Halt.
Welcome to Kernel Debugging Land...
list: 0x80159020, element: 0x801598b8
list: 0x80159020, element: 0x80159868
Last message repeated 27 times.
list: 0x80159020, element: 0x00159868
list: 0x80159020, element: 0x80159868

comment:6 by bonefish, 14 years ago

Please look up the symbol the list address printed above (0x80159020) belongs to (if you have rebuilt the kernel in the meantime, the address may have changed). You can do so via "objdump --syms /system/kernel_x86 | grep <address>" (the gcc2 Haiku objdump may have issues -- objdump under Linux or FreeBSD should work fine, though) or in the kernel debugger via "ls <address>".

My guess is that the result will be "sTemporaryVariablesLRUQueue", as that seems to be the only DoublyLinkedList used in the kernel debugger. But before running off in the wrong direction a verification would be nice. :-)

comment:7 by jonas.kirilla, 14 years ago

KDL:
0x80159020 = sInitialHeap + 0x280
0x801598b8 = sInitialHeap + 0xb18
0x80159868 = sInitialHeap + 0xac8
$ objdump --syms kernel_x86 | grep sInitialHeap
80158da0 l     O .bss	00001000              sInitialHeap
$ objdump --syms kernel_x86 | grep 80158
80158d84 l     O .bss	00000004              sCurrentPipeSegment
80158d80 l     O .bss	00000004              sCurrentPipe
80158da0 l     O .bss	00001000              sInitialHeap
$ objdump --syms kernel_x86 | grep 80159
80159da0 l     O .bss	00000004              sCurrentPool
80159da4 l     O .bss	00000018              sInitialPool
80159f00 l     O .bss	00000080              sExceptionMessage
80159f80 l     O .bss	00000004              sExceptionPosition
80159dc0 l     O .bss	00000140              sJumpBuffers
80159fa0 l     O .bss	00000080              sTempBuffer

comment:8 by bonefish, 14 years ago

Are you sure you haven't rebuilt the kernel in the meantime? The results don't make any sense. sInitialHeap is a buffer for a mini heap only used when entering KDL in the early boot process. At some point an area is created and this buffer isn't used anymore. Besides, none of the code using the KDL heap does anything with DoublyLinkedLists.

comment:9 by bonefish, 14 years ago

Resolution: fixed
Status: newclosed

Fixed in hrev35534.

Note: See TracTickets for help on using tickets.