GHCi segfault with breakpoint

$ cat test.hs
main = foo 123 
foo n = print n 
$ ghci-9.8.2 test.hs
GHCi, version 9.8.2: https://www.haskell.org/ghc/  :? for help
[1 of 2] Compiling Main             ( test.hs, interpreted )
Ok, one module loaded.
ghci> :b foo
Breakpoint 0 activated at test.hs:2:9-15
ghci> main
Segmentation fault (core dumped)

on x86_64 linux. at least GHC 9.6 and Darwin/aarch64 are also affected

added needs triage label

current master branch also affected (aarch64/darwin here):

% ../ghc.master/_build/stage1/bin/ghc --interactive test.hs
GHCi, version 9.11.20240422: https://www.haskell.org/ghc/  :? for help
[1 of 2] Compiling Main             ( test.hs, interpreted )
Ok, one module loaded.
ghci> :b foo
Breakpoint 0 activated at test.hs:2:9-15
ghci> main
zsh: segmentation fault  ../ghc.master/_build/stage1/bin/ghc --interactive test.hs

In a debug build i get:

Thread 1 "ghc" received signal SIGSEGV, Segmentation fault.
0x00007ffff09f981c in LOOKS_LIKE_INFO_PTR_NOT_NULL (p=5260191916443929928) at rts/include/rts/storage/ClosureMacros.h:308
308	    return info->type != INVALID_OBJECT && info->type < N_CLOSURE_TYPES;
(gdb) bt
#0  0x00007ffff09f981c in LOOKS_LIKE_INFO_PTR_NOT_NULL (p=5260191916443929928) at rts/include/rts/storage/ClosureMacros.h:308
#1  0x00007ffff09f9874 in LOOKS_LIKE_INFO_PTR (p=5260191916443929928) at rts/include/rts/storage/ClosureMacros.h:314
#2  0x00007ffff09f98ce in LOOKS_LIKE_CLOSURE_PTR (p=0x7ffff0a75d30 <stg_ARR_WORDS_info>) at rts/include/rts/storage/ClosureMacros.h:322
#3  0x00007ffff09f797c in heap_view_closureSize (closure=0x7ffff0a75d30 <stg_ARR_WORDS_info>) at rts/Heap.c:18
#4  0x00007ffff0a73d52 in stg_unpackClosurezh ()
   from /home/hsyl20/projects/ghc/master/_build/stage1/bin/../lib/x86_64-linux-ghc-9.11.20240424/libHSrts-1.0.2_thr_debug-ghc9.11.20240424.so
#5  0x00000042004a8578 in ?? ()
#6  0x0000000000000000 in ?? ()

It looks like it's trying to call unpackClosure# on an infotable.

We have the following Core:

-- RHS size: {terms: 6, types: 5, coercions: 0, joins: 0/0}
foo :: forall {a}. Show a => a -> IO ()
[GblId, Arity=2, Unf=OtherCon []]
foo
  = \ (@a_aJg) ($dShow_aJo :: Show a_aJg) (n_az4 :: a_aJg) ->
      break<Main,0>(n_az4) print @a_aJg $dShow_aJo n_az4

-- RHS size: {terms: 6, types: 2, coercions: 0, joins: 0/1}
main :: IO ()
[GblId]
main
  = break<Main,1>()
    let {
      n_az4 :: Integer
      [LclId, Unf=OtherCon []]
      n_az4 = GHC.Num.Integer.IS 123# } in
    break<Main,0>(n_az4)
    print @Integer GHC.Internal.Show.$fShowInteger n_az4

And we try to reconstruct the type of n:

Reconstruct type of n
RTTI started with initial type a_IQe[rt]
instScheme [a_IQe[rt]]
           a_IQe[rt]
           [a_aQh[tau:0]]
check1 passed
add constraint: r_aQj[rutv:0] = a_aQh[tau:0]
go r_aQj[rutv:0]
GHC.Runtime.Interpreter.getClosure
GHC.Exts.Heap.getClosureDataFromHeapObject
[1]    341103 segmentation fault (core dumped)  ~/projects/ghc/master/_build/stage1/bin/ghc --interactive test.hs -ddump-rtti

We try to reconstruct the type of n, but we already know it in main while we don't in foo. I think the CgBreakInfo are wrong in main. Maybe we should filter the free tyvars to only keep those in scope in GHC.Runtime.Eval.bindLocalsAtBreakpoint?

(Note that if we make foo NOINLINE, we don't have the bug.)

If we add some tracing in GHC.StgToByteCode.schemeER_wrk: pprTraceM "schemeER_wrk" (ppr (tick_no, fvs, ty_vars))

We get:

schemeER_wrk (0, [n_sOa], [])
schemeER_wrk (1, [], [])
schemeER_wrk (0, [n_sO9], [a_aJg])

So it confirms that the tick_no isn't enough to identify the right CgBreakInfo.

assigned to @hsyl20

mentioned in merge request !12500 (closed)

Fix in !12500 (closed)

added GHCi Phigh Tbug compiler crash debugger labels and removed needs triage label

mentioned in commit 62eebf29

mentioned in commit b85b1199

Fixed by !12500 (closed)

closed

mentioned in issue #25433 (closed)

mentioned in commit d8a57db8

mentioned in merge request !13736 (merged)

mentioned in commit f1de8643