Opened 10 years ago
Closed 10 years ago
#11390 closed bug (fixed)
BKernel::TeamSignalEvent::DoDPC: failed to acquire spinlock for a long time
Reported by: | jessicah | Owned by: | axeld |
---|---|---|---|
Priority: | normal | Milestone: | R1 |
Component: | System/Kernel | Version: | R1/Development |
Keywords: | spinlock | Cc: | |
Blocked By: | Blocking: | ||
Platform: | All |
Description
Compiling native GHC triggers this panic all the time. However, the spinlock command in KDL always says it's not locked, and only one core is running (other three are in idle).
I don't really know how to reduce to a test case, nor know which threads to look at.
However, to reproduce using GHC (it'll continually trigger the KDL when resuming), can use the following steps:
wget https://www.haskell.org/ghc/dist/7.8.3/ghc-7.8.3-src.tar.xz wget http://haiku.jessicah.org/working-ghc-cross-install.zip wget https://raw.githubusercontent.com/nick8325/haiku-ghc/master/ghc-patches/0001-Haiku-patches.patch tar xJQf ghc-7.8.3-src.tar.xz extract working-ghc-cross-install.zip into /system/non-packaged cd ghc-7.8.3 patch -Np1 < ../0001-Haiku-patches.patch setarch x86 ./configure --prefix=/boot/home/test-ghc make -jN # multiple jobs seems to trigger it more often than without
You'll also need updated binutils/gcc4 packages (I've just uploaded, and available in hrev48162 for gcc2h).
Links:
Attachments (6)
Change History (8)
by , 10 years ago
Attachment: | IMG_0162.JPG added |
---|
by , 10 years ago
Attachment: | IMG_0163.JPG added |
---|
by , 10 years ago
Attachment: | IMG_0164.JPG added |
---|
by , 10 years ago
Attachment: | IMG_0166.JPG added |
---|
by , 10 years ago
Attachment: | IMG_0168.JPG added |
---|
by , 10 years ago
Attachment: | IMG_0170.JPG added |
---|
comment:1 by , 10 years ago
Note:
See TracTickets
for help on using tickets.
OK, I was able to reproduce this under KVM. Since I've ran with a single virtual core I got the double lock panic instead:
The interesting part being the printed value of -559038737, which translates nicely to 0xdeadbeef. When continuing out of the panic, the next KDL immediately hits with a page fault accessing 0xdeadbeff in BKernel::PendingSignals::AddSignal(). So this is definitely caused by using a freed kernel structure and an already freed spinlock. Investigating...