[GHC] #2411: RaiseAsync and STM segfault with
stop_at_atomically in some circumstances.
GHC
trac at galois.com
Tue Jul 8 11:58:26 EDT 2008
#2411: RaiseAsync and STM segfault with stop_at_atomically in some circumstances.
----------------------------+-----------------------------------------------
Reporter: sclv | Owner:
Type: bug | Status: new
Priority: normal | Milestone: 6.10.1
Component: Runtime System | Version: 6.8.3
Severity: normal | Resolution:
Keywords: | Difficulty: Unknown
Testcase: | Architecture: Unknown
Os: Unknown |
----------------------------+-----------------------------------------------
Comment (by sclv):
Ok. So I've narrowed down a relatively simple test case. It crashes even
at -N1 but crashes much more immediately at -N4. The backtrace is the same
as above.
From this test case its pretty clear that there's an issue either with
catchSTM or directly with RaiseAsync.c or with their interaction, and in
fact unsafePerformIO and unsafeIOToSTM are nowhere to be found in this
code.
This test case can probably be distilled down to something even simpler
that doesn't use any of the typeclass toys I was playing with that ended
up here in the first place. But I've taken it about as far as I can today.
As far as I know though, this is only triggered during validation during
GC, which is the only time stop_at_atomically is set. So one question I
have is why a thread which is already hit by an asynchronous exception
should *then* be treated as invalid as well and subject to an attempt to
roll back during scheduleDoGC. So it may be that there are two different
mechanisms (one for exception handling via catchSTM and one for
validation) that end up stepping on one another's toes. Just spinning a
theory though.
I should note this bug occurs in 6.8.3 up through HEAD as far as I know.
--
Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/2411#comment:3>
GHC <http://www.haskell.org/ghc/>
The Glasgow Haskell Compiler
More information about the Glasgow-haskell-bugs
mailing list