Opened 15 years ago
Closed 15 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 )
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 , 15 years ago
Description: | modified (diff) |
---|
comment:2 by , 15 years ago
Description: | modified (diff) |
---|
comment:3 by , 15 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 , 15 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 , 15 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 , 15 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 , 15 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 , 15 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.
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).