Cabal-install assertion failed

[ksqsf]

Describe the bug

❯ cabal v2-build         
Build profile: -w ghc-8.10.7 -O1
In order, the following will be built (use -v for more details):
 - OpenGLRaw-3.3.4.0 (lib) (requires build)
 - connection-0.3.1 (lib:connection) (requires build)
Assertion failed
CallStack (from HasCallStack):
  assert, called at src/Distribution/Client/ProjectPlanning.hs:238:5 in main:Distribution.Client.ProjectPlanning

To Reproduce

1. create a project with build dependency monomer
2. cabal v2-build

Expected behavior
cabal v2-build should work.

System information

• macOS 12
• cabal 3.6.1.0, cabal-install 3.6.0.0, ghc 8.10.7

Additional context
cabal v2-build will report this assertion failure very early, even before actual building happens. But cabal build --verbose=0 seems to defer this error later, and finally I arrived at:

Resolving dependencies...
Build profile: -w ghc-8.10.7 -O1
In order, the following will be built (use -v for more details):
Assertion failed
CallStack (from HasCallStack):
  assert, called at src/Distribution/Client/ProjectPlanning.hs:238:5 in main:Distribution.Client.ProjectPlanning

edit: cabal 3.4 works fine.

[ksqsf]

Suggestion: make cabal-install error messages more helpful. A bare Assertion failed almost tells me nothing at all.

[gbaz]

I just tried and failed to reproduce. macOS Big Sur (11 -- 12 isn't out yet!). Cabal-install 3.6, ghc 8.10.4.

Have you tried running cabal clean first? it could be some mismatch in how 3.6 vs 3.4 handle some details of install plans. Cached info in dist-newstyle might not match up between the two versions if so.

[gbaz]

(this does remind me of another issue that confuses me though -- why/how do we even have asserts on it our distribution builds? I thought they were supposed to be compiled out -- is it possible ghc doesn't handle compiling out asserts in general the way the docs promise -- or are we doing something wrong in our building process? or... is this intended behaviour and i'm just terribly confused about asserts?)

[gbaz]

Also, if that fails, please try passing an explicit new store dir with cabal --store-dir /some/new/storedir -- this assert I think relates to hashes, and its possible there's a hash computation change hiding somewhere as well? Just a shot in the dark.

[Mikolaj]

(this does remind me of another issue that confuses me though -- why/how do we even have asserts on it our distribution builds? I thought they were supposed to be compiled out -- is it possible ghc doesn't handle compiling out asserts in general the way the docs promise -- or are we doing something wrong in our building process? or... is this intended behaviour and i'm just terribly confused about asserts?)

I guess it's intended. Better to have the exe crash than to wipe out user's data or compile a program that is subtly wrong and not provide any feedback to us that things are broken.

However, assertion failures should provide more info to devs (of particular importance is info that helps to reproduce the failure) and a more understandable message to user (though, the message is essentially going to be "the program broke in a way we haven't forseen so please report a bug"). I have a tiny package that helps printing extra debug info, but it requires adding stuff at each assert.

[ksqsf]

I tried again with ghc 8.10.4 + cabal 3.6 and/or --with-store x, no luck.

.. but I moved my old ~/.cabal away and it compiled successfully. Then, I moved back the previous ~/.cabal and now I can't reproduce this anymore!

I still have no clues, but I will close this for now, as I can no longer provide any useful evidence. Sorry :(

[Mikolaj]

@ksqsf: thank you for the report. Indeed, the program may be sloppy in dealing with data from old versions that no longer match its changed assumptions (expressed in assertions, among others). So perhaps it was just that. We don't have the resources to track down and fix such issues and wiping out all old data would presumable inconvenience people too much, given how rarely it breaks (probably randomly corrupted data is a bigger problem, so people need to learn to wipe out their data anyway). Please do reopen if it occurs again.

[Mikolaj]

This may be related to #6006.