## Summary When decoding the stack of a simple thread I get an exception "Invalid large bitmap size 0". ## Steps to reproduce ``` -- Main.hs module Main where main = pure () ``` ``` $ ghci Main.hs ghci> :break 3 Breakpoint 0 activated at Main.hs:3:8-14 ghci> main Stopped in Main.main, Main.hs:3:8-14 _result :: IO () = _ [Main.hs:3:8-14] ghci> import GHC.Conc [Main.hs:3:8-14] ghci> import GHC.Stack.CloneStack [Main.hs:3:8-14] ghci> mapM (\ix -> print ix >> (decode =<< cloneThreadStack ix)) =<< listThreads ThreadId 109 ThreadId 108 ThreadId 58 *** Exception: Invalid large bitmap size 0. HasCallStack backtrace: error, called at libraries/ghc-internal/src/GHC/Internal/Stack/Decode.hs:272:25 in ghc-internal:GHC.Internal.Stack.Decode [Main.hs:3:8-14] ghci> ``` Decoding the stack of the main thread (the `main = pure ()` one) results in this failure ## Expected behavior Here's the stack of that thread printed out in lldb: ``` (lldb) p printStackChunk(cap->r.rCurrentTSO->stackobj->sp, cap->r.rCurrentTSO->stackobj->stack + cap->r.rCurrentTSO->stackobj->stack_size) stg_apply_interp_info (0x70002d2790) 0x70002d27a0: NORMAL_UPDATE_FRAME(0x105f3c348,0x70002e46e8) 0x70002d27b0: NORMAL_UPDATE_FRAME(0x105f3c348,0x70002f2018) stg_ap_v_info RET_SMALL (0x10c503aa8) stk[29] (0x70002d27d0) = 0x70002f2000 -- Object 0x70002f2000 = 0x70002f2000: PAP/1(0x70002edc20) RET_SMALL (0x105f31c88) 0x70002d27e0: CATCH_FRAME(0x105f32498,0x70002f6d1a) RET_SMALL (0x10c2d5610) stk[24] (0x70002d27f8) = 0x70002f696a -- Object 0x70002f696a = 0x70002f696a: FUN/2(0x10c970a30, 0x70002f6942) stk[23] (0x70002d2800) = 0x10ccff6c1 -- Object 0x10ccff6c1 = 0x10ccff6c1: ghc-internal:GHC.Internal.Tuple.()(0x10ca33ce8#) 0x70002d2808: CATCH_FRAME(0x105f32498,0x70002f473a) RET_SMALL (0x10c2d5610) stk[19] (0x70002d2820) = 0x70002f3a32 -- Object 0x70002f3a32 = 0x70002f3a32: FUN/2(0x10c970a30, 0x70002f3a0a) stk[18] (0x70002d2828) = 0x10ccff6c1 -- Object 0x10ccff6c1 = 0x10ccff6c1: ghc-internal:GHC.Internal.Tuple.()(0x10ca33ce8#) RET_SMALL (0x105f31a98) RET_SMALL (0x104dc6494) 0x70002d2840: CATCH_FRAME(0x105f32498,0x70002f0ce2) RET_SMALL (0x104dc4994) 0x70002d2858: CATCH_FRAME(0x105f32498,0x106d2f672) RET_SMALL (0x104dc4ae8) RET_SMALL (0x104dc4c8c) RET_SMALL (0x105f31a98) RET_SMALL (0x104dc4df0) stk[6] (0x70002d2888) = 0x70002f0a68 -- Object 0x70002f0a68 = 0x70002f0a68: MVAR(head=0x70002f0c90, tail=0x70002f0c90, value=END_TSO_QUEUE) stk[5] (0x70002d2890) = Word# 481039420361 stk[4] (0x70002d2898) = Word# 481039296696 0x70002d28a0: CATCH_FRAME(0x105f32498,0x106e8674a) 0x70002d28b0: STOP_FRAME(0x105f3ab58) ``` The large bitmap which fails to decode is from ``` stg_apply_interp_info ``` which is a `RET_BCO` with a large bitmap of size 0. The question is whether * The panic is incorrect, and we can indeed have large bitmaps of size 0 (as we do here) * The generated bytecode should never have large bitmaps of size 0 ## Environment * GHC version used: 9.14.0.20251104, HEAD