[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