Opened 5 years ago

Closed 5 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:
Has a Patch: no 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)

IMG_0162.JPG (1.7 MB ) - added by jessicah 5 years ago.
IMG_0163.JPG (1.3 MB ) - added by jessicah 5 years ago.
IMG_0164.JPG (1.8 MB ) - added by jessicah 5 years ago.
IMG_0166.JPG (2.3 MB ) - added by jessicah 5 years ago.
IMG_0168.JPG (2.3 MB ) - added by jessicah 5 years ago.
IMG_0170.JPG (2.2 MB ) - added by jessicah 5 years ago.

Change History (8)

by jessicah, 5 years ago

Attachment: IMG_0162.JPG added

by jessicah, 5 years ago

Attachment: IMG_0163.JPG added

by jessicah, 5 years ago

Attachment: IMG_0164.JPG added

by jessicah, 5 years ago

Attachment: IMG_0166.JPG added

by jessicah, 5 years ago

Attachment: IMG_0168.JPG added

by jessicah, 5 years ago

Attachment: IMG_0170.JPG added

comment:1 by mmlr, 5 years ago

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

comment:2 by mmlr, 5 years ago

Resolution: fixed
Status: newclosed

Fixed in hrev48186.

Note: See TracTickets for help on using tickets.