#16067: Profiled GHCi segfaults under Windows. -------------------------------------+------------------------------------- Reporter: AndreasK | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Runtime System | Version: 8.7 Resolution: | Keywords: Operating System: Windows | Architecture: | Unknown/Multiple Type of failure: GHCi crash | Test Case: Blocked By: | Blocking: Related Tickets: #15808 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by AndreasK): * related: => #15808 Comment: Pretty sure the underlying issue is similar to #15808. We get the following call stack: {{{ #0 0x0000000005e599bd in registerCcsList (cc_list=0xc2f3020) at rts\Profiling.c:326 #1 0x0000000005e42db9 in ocRunInit_PEi386 (oc=0x76a58c0) at rts\linker\PEi386.c:2031 #2 0x0000000005e42efd in ocTryLoad (oc=0x76a58c0) at rts\Linker.c:1615 #3 0x0000000005e5d9af in resolveObjs_ () at rts\Linker.c:1643 #4 0x0000000005e5d969 in resolveObjs () at rts\Linker.c:1662 #5 0x0000000005d5d0c4 in ghcizm8zi7_GHCiziObjLink_resolveObjs1_info () #6 0x00000000066f73e0 in MULTI_CHUNK_SLOW_CALL_ctr () #7 0x000000000a34d000 in ?? () }}} We call registerCcsList in the initializer functions of modules with profiling. Which then calls the rts code. The RTS and the initializer end up being farther than 2GB from each other so if any offset is limited to 32bit that will do. It seems the first pointer in cc_list is what causes the segfault (pointing to 0xfffffff225ff). But I haven't dug into it enough to find out where the overflow comes from. Likely a relocation overflow somewhere (as in #15808) but could also be some ghc internal offset. -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/16067#comment:1 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler