ghc-9.4.8: Segfault when enabling -fworker-wrapper-cbv for containers library.
Summary
Enabling this flag for containers causes a build/test failure on the CI for containers: https://github.com/haskell/containers/actions/runs/9205605811/job/25321633577?pr=1003
Steps to reproduce
Please provide a set of concrete steps to reproduce the issue.
Expected behavior
What do you expect the reproducer described above to do?
Environment
- GHC version used:
Optional:
- Operating System:
- System Architecture:
Activity
added needs triage label
assigned to @AndreasK
I reproduced this locally and got the segfault at this point:
Loading unit process-1.6.18.0 ... linking ... done. Loading unit transformers-compat-0.7.2 ... linking ... done. Loading unit optparse-applicative-0.18.1.0 ... linking ... done. Loading unit tagged-0.8.8 ... linking ... done. Loading unit stm-2.5.1.0 ... linking ... done. Loading unit tasty-1.5 ... linking ... done. Loading unit tasty-quickcheck-0.10.3 ... linking ... done. Loading unit call-stack-0.4.0 ... linking ... done. Loading unit tasty-hunit-0.10.1 ... linking ... done. Loading unit ghc-heap-9.10.1 ... linking ... done. Loading unit primitive-0.9.0.0 ... linking ... done. Loading unit vector-stream-0.1.0.1 ... linking ... done. Loading unit vector-0.13.1.0 ... linking ... done. Loading unit wherefrom-compat-0.1.1.0 ... linking ... done. Loading unit nothunks-0.2.1.0 ... linking ... done. Loading unit containers-tests-0 ... linking ... done. Search directories (user): Search directories (gcc): Segmentation fault (core dumped)Seems like this is either right at the start of compilation or related to this invocation of gcc.
-
It's the start of (haskell) compilation. See this snippet for comparison when using 9.6 which works:
Search directories (user): Search directories (gcc): *** Simplify [expr]: !!! Simplify [expr]: finished in 0.25 milliseconds, allocated 0.518 megabytes *** CorePrep [expr]: !!! CorePrep [expr]: finished in 0.03 milliseconds, allocated 0.024 megabytes *** Stg2Stg: added Tbug pointer tagging runtime crash labels and removed needs triage label
added Phigh label
-
I believe this is a similar issue as #22840 (closed) since it seems to happen when running splices.
-
Indeed if I enable -dtag-inference-checks I see:
ghc: internal error: Tag inference failed on:TagCheck failed on entry in Data.Sequence.Internal - value:$dQuote_s1X95 _s1X95::P64 (GHC version 9.4.8 for x86_64_unknown_linux) Please report this as a GHC bug: https://www.haskell.org/ghc/reportabugWhich comes from:
Data.Sequence.Internal.$w$cliftTyped2 [InlPrag=[2]] :: forall {a} {m :: * -> *}. (Language.Haskell.TH.Syntax.Lift a, Language.Haskell.TH.Syntax.Quote m) => Data.Sequence.Internal.Seq a -> m (Language.Haskell.TH.Syntax.TExp (Data.Sequence.Internal.Seq a)) [GblId[StrictWorker([~, !])], Arity=3, Str=<LP(LCL(C1(L)),LCL(C1(L)))><SP(SP(L,SCS(L),L,L),L)><L>, Unf=OtherCon []] = {} \r [$dLift_s1X94 $dQuote_s1X95 t_s1X96] case Language.Haskell.TH.Syntax.$p1Quote $dQuote_s1X95 of { GHC.Base.C:Monad _ [Occ=Dead] ww1_s1X99 [Occ=Once1!] _ [Occ=Dead] ww3_s1X9b [Occ=OnceL1!] -> let { sat_s1X9S [Occ=Once1] :: Language.Haskell.TH.Syntax.Exp -> m_srwK (Language.Haskell.TH.Syntax.TExp (Data.Sequence.Internal.Seq a_srwI)) [LclId] = {ww3_s1X9b} \r [e_s1X9R] ww3_s1X9b e_s1X9R; } in let { sat_s1X9Q [Occ=Once1] :: m_srwK Language.Haskell.TH.Syntax.Exp [LclId] = {t_s1X96, $dLift_s1X94, $dQuote_s1X95} \u [] case $dQuote_s1X95<TagProper> of wild1_s1X9c [Occ=Once1] { Language.Haskell.TH.Syntax.C:Quote ww4_s1X9d [Occ=Once1!] _ [Occ=Dead] -> case ww4_s1X9d of { GHC.Base.C:Monad ww6_s1X9g [Occ=Once1!] ww7_s1X9h _ [Occ=Dead] _ [Occ=Dead] -> case ww6_s1X9g of { GHC.Base.C:Applicative _ [Occ=Dead] ww11_s1X9m _ [Occ=Dead] _ [Occ=Dead] _ [Occ=Dead] _ [Occ=Dead] -> let { y_s1X9r [Occ=OnceL1] :: m_srwK Language.Haskell.TH.Syntax.Exp [LclId] = {t_s1X96, $dLift_s1X94, wild1_s1X9c} \u [] let { sat_s1X9J [Occ=Once1] :: Data.Sequence.Internal.FingerTree a_srwI [LclId] = {t_s1X96} \u [] let-no-escape { $j_s1X9s [Occ=Once3!T[1], Dmd=1C1(L)] :: GHC.Prim.Int# -> Data.Sequence.Internal.FingerTree a_srwI [LclId[JoinId(1)(Nothing)], Arity=1, Str=<L>, Unf=OtherCon []] = {t_s1X96} \r [x_s1X9t] case >=# [x_s1X9t 0#] of { __DEFAULT -> Data.Sequence.Internal.$fApplicativeSeq3; 1# -> case t_s1X96 of wild4_s1X9v [Occ=Once2] { Data.Sequence.Internal.EmptyT -> Data.Sequence.Internal.$fLiftBoxedRepSeq10; Data.Sequence.Internal.Single _ [Occ=Dead] -> case Data.Sequence.Internal.$fLiftBoxedRepSeq8 of $fLiftBoxedRepSeq8_t1Y0v { __DEFAULT -> Data.Sequence.Internal.$wzipWith Data.Sequence.Internal.$fLiftBoxedRepSeq9 $fLiftBoxedRepSeq8_t1Y0v wild4_s1X9v; }; Data.Sequence.Internal.Deep bx_s1X9x _ [Occ=Dead] _ [Occ=Dead] _ [Occ=Dead] -> case >=# [bx_s1X9x 0#] of { __DEFAULT -> Data.Sequence.Internal.$fFunctorSeq1; 1# -> case Data.Sequence.Internal.$w$sapplicativeTree bx_s1X9x 1# GHC.Tuple.() of sat_s1X9C [Occ=Once1] { __DEFAULT -> Data.Sequence.Internal.$wzipWith Data.Sequence.Internal.$fLiftBoxedRepSeq9 sat_s1X9C wild4_s1X9v; }; }; }; }; } in case t_s1X96 of { Data.Sequence.Internal.EmptyT -> $j_s1X9s 0#; Data.Sequence.Internal.Single _ [Occ=Dead] -> $j_s1X9s 1#; Data.Sequence.Internal.Deep bx_s1X9F [Occ=Once1] _ [Occ=Dead] _ [Occ=Dead] _ [Occ=Dead] -> $j_s1X9s bx_s1X9F; }; } in Data.Sequence.Internal.$fLiftBoxedRepFingerTree_$clift $dLift_s1X94 wild1_s1X9c sat_s1X9J; } in let { sat_s1X9P [Occ=Once1] :: Language.Haskell.TH.Syntax.Exp -> m_srwK Language.Haskell.TH.Syntax.Exp [LclId] = {ww11_s1X9m, y_s1X9r, ww7_s1X9h} \r [a1_s1X9L] let { sat_s1X9O [Occ=Once1] :: Language.Haskell.TH.Syntax.Exp -> m_srwK Language.Haskell.TH.Syntax.Exp [LclId] = {a1_s1X9L, ww11_s1X9m} \r [b_s1X9M] let { sat_s1X9N [Occ=Once1] :: Language.Haskell.TH.Syntax.Exp [LclId] = CCCS Language.Haskell.TH.Syntax.AppE! [a1_s1X9L b_s1X9M]; } in ww11_s1X9m sat_s1X9N; } in ww7_s1X9h y_s1X9r sat_s1X9O; } in let { sat_s1X9K [Occ=Once1] :: m_srwK Language.Haskell.TH.Syntax.Exp [LclId] = {ww11_s1X9m} \u [] ww11_s1X9m Data.Sequence.Internal.$fLiftBoxedRepSeq1; } in ww7_s1X9h sat_s1X9K sat_s1X9P; }; }; }; } in ww1_s1X99 sat_s1X9Q sat_s1X9S; };Edited by Andreas Klebinger -
A nice reproducer:
{-# LANGUAGE TemplateHaskell #-} {-# LANGUAGE StandaloneDeriving #-} module SDef where import qualified Language.Haskell.TH.Syntax as TH import Language.Haskell.TH.Syntax as TH import Data.Coerce import GHC.Generics data FingerTree a = EmptyT | Single a deriving instance TH.Lift a => TH.Lift (FingerTree a) newtype Seq a = Seq (FingerTree a) instance TH.Lift (Seq Int) where liftTyped t = [|| coerceFT z ||] where Seq !ft = foo t foo (Seq !_) = (Seq EmptyT :: Seq Int) z :: FingerTree Int z = coerce ft coerceFT :: FingerTree Int -> Seq Int coerceFT = coerce --------------------------------------------------- {-# LANGUAGE TemplateHaskell #-} module SUse where import qualified Language.Haskell.TH.Syntax as TH import SDef foo = $(TH.lift (Single 1 :: FingerTree Int))And compiling with
~/ghc_94/_build/stage1/bin/ghc SUse.hs -O -fworker-wrapper-cbv -
The root cause is this function call:
==================== Initial STG: ==================== BCO_toplevel_E0 :: Language.Haskell.TH.Syntax.Q Language.Haskell.TH.Syntax.Exp [LclId] = \u [] let { sat_s3Ic :: GHC.Types.Int [LclId] = CCCS GHC.Types.I#! [1#]; } in let { sat_s3Id :: SDef.FingerTree GHC.Types.Int [LclId] = CCCS SDef.Single! [sat_s3Ic]; } in SDef.$w$clift Language.Haskell.TH.Syntax.$fLiftBoxedRepInt Language.Haskell.TH.Syntax.$fQuoteQ sat_s3Id;Here
$fQuoteQis a top level type class constructor:Language.Haskell.TH.Syntax.$fQuoteQ [InlPrag=CONLIKE] :: Language.Haskell.TH.Syntax.Quote Language.Haskell.TH.Syntax.Q [GblId[DFunId]] = CCS_DONT_CARE Language.Haskell.TH.Syntax.C:Quote! [Language.Haskell.TH.Syntax.$fMonadQ Language.Haskell.TH.Syntax.$fQuasiQ23];So far so good we expect to be able to tag
$fQuoteQwhen referencing it. However we generate this bytecode:ProtoBCO sat_t3Ig#0 []: { __DEFAULT -> SDef.$w$clift Language.Haskell.TH.Syntax.$fLiftBoxedRepInt Language.Haskell.TH.Syntax.$fQuoteQ sat_t3Ig bitmap: 2 [0] JMP lbl:0 __lbl:0: PUSH_L 0 PUSH_G Language.Haskell.TH.Syntax.$fQuoteQ PUSH_G Language.Haskell.TH.Syntax.$fLiftBoxedRepInt PUSH_APPLY_PPP PUSH_G SDef.$w$clift SLIDE 5 5 ENTERSince PUSH_G doesn't guarantee we get a tagged pointer things to go wrong. Fwiw the code we produce is the same in 9.6+, but it seems we do apply the tags for $QuoteQ in newer versions.
We must grab the properly tagged pointer now instead of a untagged one, but it's very unclear to me at this point what made the difference.
Edited by Andreas Klebinger -
Still not sure why this works on newer versions. Enabling debug info for the interpreter I see the final relevant assembly for 9.4
bcoSize = 24 Sp = 0x4200dd0a60 pc = 0 PUSH_UBX 0x1 Sp = 0x4200dd0a58 pc = 3 PACK 1 words with itbl 0x7fe9eaa18b08 Built Object 0x4200dd0b99 = 0x4200dd0b99: ghc-prim:GHC.Types.I#(0x1#) Sp = 0x4200dd0a58 pc = 6 PUSH_L 0 Sp = 0x4200dd0a50 pc = 8 PACK 1 words with itbl 0x7fe9f433fd48 Built Object 0x4200dd0baa = 0x4200dd0baa: main:SDef.Single(0x4200dd0b99) Sp = 0x4200dd0a50 pc = 11 PUSH_L 0 Sp = 0x4200dd0a48 pc = 13 PUSH_G 0x7fe9ebddbb80 <- the argument we care about - no tag here Sp = 0x4200dd0a40 pc = 15 PUSH_G 0x7fe9ebddba28 Sp = 0x4200dd0a38 pc = 17 PUSH_APPLY_PPP Sp = 0x4200dd0a30 pc = 18 PUSH_G 0x7fe9f43421c8 Sp = 0x4200dd0a28 pc = 20 SLIDE 5 down by 2 Sp = 0x4200dd0a38 pc = 23 ENTERAnd for ghc_head:
bcoSize = 24 Sp = 0x420027f450 pc = 0 PUSH_UBX 0x1 Sp = 0x420027f448 pc = 3 PACK 1 words with itbl 0x7f762ad27ab8 Built Object 0x420027f589 = 0x420027f589: ghc-prim:GHC.Types.I#(0x1#) Sp = 0x420027f448 pc = 6 PUSH_L 0 Sp = 0x420027f440 pc = 8 PACK 1 words with itbl 0x7f7634002080 Built Object 0x420027f59a = 0x420027f59a: main:SDef.Single(0x420027f589) Sp = 0x420027f440 pc = 11 PUSH_L 0 Sp = 0x420027f438 pc = 13 PUSH_G 0x7f762bfc9530 <- the argument we care about - no tag here Sp = 0x420027f430 pc = 15 PUSH_G 0x7f762bfc9400 Sp = 0x420027f428 pc = 17 PUSH_APPLY_PPP Sp = 0x420027f420 pc = 18 PUSH_G 0x7f7634004198 Sp = 0x420027f418 pc = 20 SLIDE 5 down by 2 Sp = 0x420027f428 pc = 23 ENTERSo we seemingly push a untagged address to the stack either way. But somehow this works out fine on master.
-
Alright seems the actual bug is still present in master. It just happens to not cause segfaults on master.
The difference is on master we always end up using the expected-tagged argument as argument to other functions, which are not strict workers themselves.
That is on 9.4 we get something like:
case $dQuote_s3aE<TagProper> of wild2_s3b4 [Occ=Once1] { Language.Haskell.TH.Syntax.C:Quote ww4_s3b5 [Occ=Once1!] _ [Occ=Dead] ->And we blow up on the case as the argument isn't actually tagged.
In contrast on ghc-head we get the same
$dQuoteargument but all the uses look like this:case Language.Haskell.TH.Lib.Syntax.$p1Quote $dQuote_s2Sw of $dMonad_s2SA [Dmd=SP(MP(A,1C(1,L),A,A,A,A),1C(1,C(1,L)),A,LC(S,L))] { __DEFAULT -> let { sat_s2SE [Occ=Once1] :: Language.Haskell.TH.Lib.Syntax.Exp -> m_s2I5 (Language.Haskell.TH.Lib.Syntax.TExp (SDef.FingerTree a_s2I6)) [LclId] = {$dMonad_s2SA} \r [e_s2SD] GHC.Internal.Base.return $dMonad_s2SA e_s2SD; } inWhere
$p1Quoteitself re-evaluates the argument so nothing goes wrong. -
And now that I know how it's broken I can sadly reproduce this on master:
{-# LANGUAGE TemplateHaskell #-} module SDef where {-# NOINLINE aValue #-} aValue = True {-# NOINLINE aStrictFunction #-} aStrictFunction !x = [| x |] ------------------------- {-# LANGUAGE TemplateHaskell #-} module SUse where import qualified Language.Haskell.TH.Syntax as TH import SDef import GHC.Exts bar = $( inline aStrictFunction aValue )Edited by Andreas Klebinger -
There are two ways to fix this:
-
In the interpreter in the case for PUSH_G we could look at the object we are pushing, follow indirections and then tag the closure the indirection ends up pointing to before we actually push to the stack.
-
In the tag analysis we could be more pessimistic when analyzing code for the interpreter, resulting in the rewrite pass inserting an additional eval that would then apply the proper tag once executed.
I think I will give the former a try as it seems like it should improve bytecode performance while also fixing the bug.
-
mentioned in commit 83b90ed7
mentioned in commit 6da2946a
-
Will be fixed by !12773 (closed)
mentioned in commit 3c487956
mentioned in commit 460e65ed
mentioned in commit 379ed573
mentioned in issue #24943 (closed)
mentioned in commit fa968687
marked #24943 (closed) as a duplicate of this issue
marked this issue as related to #24943 (closed)
mentioned in commit 8380ccf6
mentioned in commit c025a98f
mentioned in commit 7bb7e437
closed with commit 1bfa9111
mentioned in commit 1bfa9111
mentioned in commit 28ddc41b
mentioned in commit 51b77722
mentioned in commit 075032b8
mentioned in commit e4b99959
mentioned in commit 43e73dfb
mentioned in commit 6faa8336