[GHC] #13970: Segmentation fault inside threadPaused
GHC
ghc-devs at haskell.org
Fri Jul 14 15:52:15 UTC 2017
#13970: Segmentation fault inside threadPaused
-------------------------------------+-------------------------------------
Reporter: albertov | Owner: (none)
Type: bug | Status: new
Priority: normal | Milestone:
Component: Runtime System | Version: 8.2.1-rc3
Resolution: | Keywords:
Operating System: Unknown/Multiple | Architecture:
| Unknown/Multiple
Type of failure: None/Unknown | Test Case:
Blocked By: | Blocking:
Related Tickets: | Differential Rev(s):
Wiki Page: |
-------------------------------------+-------------------------------------
Comment (by albertov):
Replying to [comment:14 albertov]:
> Replying to [comment:13 hsyl20]:
> > GHC uses
[https://ghc.haskell.org/trac/ghc/wiki/Commentary/Compiler/SymbolNames
z-encoding], hence "zd" is "$" and "zu" is "_" . You can remove the `$w`
prefix probably introduced by the worker/wrapper transformation, leaving
you with `poly_go13` or maybe `poly_go` in the Haskell source.
>
> There's no function by those names in that module, however, I could
manage to find "poly_go13" it's header (.hi) file. It's in a binary format
which gives me no hints regarding where it might come from. Is there any
way to inspect it in a more amicable way? Thanks!
I've found out by compiling with {{{-ddump-simpl}}} that {{{poly_go13}}}
seems to be a specialization of {{{Data.Map.lookup}}}:
{{{
$wpoly_go13 [InlPrag=[0], Occ=LoopBreaker]
:: forall a. Int# -> Int# -> Map BlockIndex a -> Maybe a
[GblId, Arity=3, Caf=NoCafRefs, Str=<L,U><L,U><S,1*U>]
$wpoly_go13
= \ (@ a) (ww :: Int#) (ww1 :: Int#) (w :: Map BlockIndex a) ->
case w of {
Bin ipv ipv1 ipv2 ipv3 ipv4 ->
case ipv1 of { V2 b1 b2 ->
case b1 of { I# y# ->
case b2 of { I# y#1 ->
case tagToEnum# @ Bool (<# ww y#) of {
False ->
case tagToEnum# @ Bool (==# ww y#) of {
False -> $wpoly_go13 @ a ww ww1 ipv4;
True ->
case tagToEnum# @ Bool (<# ww1 y#1) of {
False ->
case tagToEnum# @ Bool (==# ww1 y#1) of {
False -> $wpoly_go13 @ a ww ww1 ipv4;
True -> Just @ a ipv2
};
True -> $wpoly_go13 @ a ww ww1 ipv3
}
};
True -> $wpoly_go13 @ a ww ww1 ipv3
}
}
}
};
Tip -> Nothing @ a
}
end Rec }
}}}
where
{{{
type BlockIndex = Linear.V2.V2 Int
}}}
I can relate to the part of my program where this comes from and,
interestingly, this was originally a {{{Data.HashMap.Strict.HashMap}}}
which I changed to a {{{Data.Map.Strict.Map}}} to see if it made a
difference (see comment:10). For some reason, segfaults are much more
frequent with the Data.Map (so I've left it like this to help debug).
This Map is stored in a TMVar which threads regularly {{{M.lookup blockIx
<$> readTMVar}}} neighboring Blocks to send them "work". When the lookup
fails they take the lock, create a new Block and a new thread to process
it, put the Block back in the Map and put the Map back in the TMVar. So,
although the BlockIndex is strict, the value isn't so perhaps this is
where shared un-evaluated thunks are created which manifests the bug? (if
my intuition about the problem is correct).
Anyway, now I have some ideas on how to attempt to reproduce this bug
outside of my program, which might be quicker than factoring out the whole
engine out of the propietary parts.
--
Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/13970#comment:17>
GHC <http://www.haskell.org/ghc/>
The Glasgow Haskell Compiler
More information about the ghc-tickets
mailing list