[GHC] #13970: Segmentation fault inside threadPaused

[GHC]

#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:2 bgamari]:
 > What might also help is if you could compile your program with `-debug`
 and paste the output of `x/64a tso->stackobj->sp` after the program
 crashes. It seems like we are getting confused walking the stack, so it
 would be interesting to know what the stack looks like.

 I finally managed to get debugging symbols. I had to pass {{{dontStrip =
 true}}} to the Nix derivation that builds ghc from git. Anyway, it crashed
 again at the same point and here's what gdb says:

 {{{
 (gdb) x/64a tso->stackobj->sp
 0x421cdbfea8:   0x7f9b3d2cc5c8 <stg_enter_info> 0x420c746c00
 0x421cdbfeb8:   0x100   0x4204442df9
 0x421cdbfec8:   0xf4    0xfffffffffffffff4
 0x421cdbfed8:   0x7f9b3d2cce88 <stg_upd_frame_info>     0x420c746c00
 0x421cdbfee8:   0x7f9b4367b308
 <sigym4zmpropagzmenginezm0zi1zi0zi0zmFERo4wFJ8F465LTBnpBC6B_Sigym4ziPropagziEngine_zdwpolyzugo3_info+64>
 0x6465c88fdad5932f
 0x421cdbfef8:   0xffffffffffffffff      0x6
 0x421cdbff08:   0x0     0x7f9b4367be08
 0x421cdbff18:   0x42042655c8    0x42042655e0
 0x421cdbff28:   0x4202361568    0x7f9b3d2cce88 <stg_upd_frame_info>
 0x421cdbff38:   0x4204442dc8    0x7f9b436ac7b0
 0x421cdbff48:   0x63b   0xffffffffffffffe4
 0x421cdbff58:   0x420447bb61    0x7f9b441837a0
 0x421cdbff68:   0x42187a9841    0x420447bb71
 0x421cdbff78:   0xfffffffffffffff4      0x4204265518
 0x421cdbff88:   0x42183d5c09    0x42183f1523
 0x421cdbff98:   0x626   0x42187a0119
 0x421cdbffa8:   0x7f9b3d2c8588 <stg_maskAsyncExceptionszh_ret_info>
 0x7f9b3dbf2cc0
 0x421cdbffb8:   0x7f9b3d2c8ae8 <stg_catch_frame_info>   0xc
 0x421cdbffc8:   0x7f9b3e119592  0x7f9b3dbf2d80
 0x421cdbffd8:   0x42183f155a    0x7f9b3d2c8ae8 <stg_catch_frame_info>
 0x421cdbffe8:   0xc     0x7f9b3e14ee2a
 0x421cdbfff8:   0x7f9b3d2c8088 <stg_stop_thread_info>   0x7f9b41aa3340
 <linearzm1zi20zi6zm10zzIy9OH0MgIRAfBAdsUHU_LinearziV2_V2_con_info>
 0x421cdc0008:   0x421cdc00d1    0x421cdc00c1
 0x421cdc0018:   0x7f9b41aa3340
 <linearzm1zi20zi6zm10zzIy9OH0MgIRAfBAdsUHU_LinearziV2_V2_con_info>
 0x421cdc00f1
 0x421cdc0028:   0x421cdc00e1    0x7f9b41aa3340
 <linearzm1zi20zi6zm10zzIy9OH0MgIRAfBAdsUHU_LinearziV2_V2_con_info>
 0x421cdc0038:   0x421cdc0111    0x421cdc0101
 0x421cdc0048:   0x7f9b41aa3340
 <linearzm1zi20zi6zm10zzIy9OH0MgIRAfBAdsUHU_LinearziV2_V2_con_info>
 0x421cdc0131
 0x421cdc0058:   0x421cdc0121    0x7f9b41aa3340
 <linearzm1zi20zi6zm10zzIy9OH0MgIRAfBAdsUHU_LinearziV2_V2_con_info>
 0x421cdc0068:   0x421cdc0151    0x421cdc0141
 0x421cdc0078:   0x7f9b41aa3340
 <linearzm1zi20zi6zm10zzIy9OH0MgIRAfBAdsUHU_LinearziV2_V2_con_info>
 0x421cdc0171
 0x421cdc0088:   0x421cdc0161    0x7f9b41aa3340
 <linearzm1zi20zi6zm10zzIy9OH0MgIRAfBAdsUHU_LinearziV2_V2_con_info>
 0x421cdc0098:   0x421cdc0191    0x421cdc0181

 }}}

 BTW, I've got an approval to factor out the spread algorithm from our
 program as an opensource library so I'll begin working on that tomorrow.
 Hopefully the bug still manifests itself.

-- 
Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/13970#comment:7>
GHC <http://www.haskell.org/ghc/>
The Glasgow Haskell Compiler