Switching to Cabal 2.2 makes ghc unusable

When bumping Cabal to 2.2 as done here, we end up with a stage 1 GHC that seemingly cannot build a non-segfaulting program.

For instance, if one builds the following trivial program with a stage 1 built from the ghc-8.4 branch + the patch above...

import System.Exit
main = exitSuccess

Then...

$ ./foo
Segmentation fault

So of course, when we proceed and build stage 2, and then build things with stage 2, all the stage2 commands crash.

Trac metadata

Trac field	Value
Version	8.4.1-alpha3
Type	Bug
TypeOfFailure	OtherFailure
Priority	high
Resolution	Unresolved
Component	None
Test case
Differential revisions
BlockedBy
Related
Blocking
CC	bgamari
Operating system
Architecture

changed weight to 7

added Tbug Trac import labels

Can you try bisecting to find the offending Cabal commit?

Additional infos: It's unrelated to integer-gmp (I was able to reproduce this with an integer-simple-based GHC build as well); so this leaves rts, ghc-prim or base being possibly miscompiled (wrong/missing compile settings or include headers) due to something that wasn't accounted for in phab:D4453.

assigned to @alp

refold: most of us suspect the "basedir" PR, I'm trying all sorts of things from gdb/rr to figure out how even that trivial program ends up crashing.

Alright, so gdb hasn't been all that helpful as it seems that single-stepping somehow makes me follow a codepath that just loops between the scheduler and the top of the haskell stack without really ever making progress. I have not managed to find a breakpoint that's "far enough" so that single-stepping would just lead me right to the crash.

However, in the meantime hvr saw that:

import Data.Typeable

data Foo = Foo deriving Eq
data Bar = Bar deriving Eq
main = print (Just Foo == cast Bar)

prints True, while it should obviously print False.

What's more:

*Main Data.Typeable λ> typeRepFingerprint (typeRep (Proxy :: Proxy Foo))
00000000000000000000000000000000
*Main Data.Typeable λ> typeRepFingerprint (typeRep (Proxy :: Proxy Bar))
00000000000000000000000000000000

hvr and I then looked at the code that generates those fingerprints. After digging some more for a while, we ended up realizing that SIZEOF_STRUCT_MD5CONTEXT is detected to be... 0! Which cause the md5 context & the digest to overlap in memory, and since we memset the md5 context to 0 at the end of the md5 computation in the C code, we end up with an all-0 digest, whatever the inputs!

hvr has reported a fix in the aforementionned diff.

Let's add the case in ticket:14862#comment:149773 as a testcase if there isn't already something similar; it seems like a very reasonable sanity-check.

assigned to @angerman and unassigned @alp

Moritz is looking into the few small quirks left to handle for D4453 to be mergeable.

closed

D4453 has been merged. Thanks hvr/angerman!

Trac metadata

Trac field	Value
Resolution	Unresolved → ResolvedFixed

added Phigh label