BKernel::TeamSignalEvent::DoDPC: failed to acquire spinlock for a long time

[jessicah]

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:

• ​GHC
• ​GHC cross compiler
• ​Patches for Haiku

[mmlr]

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:

PANIC: acquire_spinlock: attempt to acquire lock 0xd2e5afec twice on non-SMP sys
tem (last caller: 0x00000000, value -559038737)

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...

[mmlr]

Fixed in hrev48186.