impossible internal bug while building darcs

[quick]

[ghc] src/Exec.o
ghc: panic! (the 'impossible' happened)
  (GHC version 6.10.1 for i386-unknown-linux):
        applyTypeToArgs
    unix-2.3.1.0:System.Posix.Signals.a38{v r8P} [gid]
      (unix-2.3.1.0:System.Posix.Signals.a5{v r8O} [gid]
       `cast` (ghc-prim:GHC.Prim.sym{(w) tc 34v}
                 base:Foreign.C.Types.:CoCInt{tc r4P}
               :: <pred>base:GHC.Int.Int32{tc 3V}
                          ~
                        <nt>base:Foreign.C.Types.CInt{tc r4S}))
      unix-2.3.1.0:System.Posix.Signals.Ignore{v r8N} [gid]
      (base:Data.Maybe.Nothing{v r4K} [gid]
         @ <nt>unix-2.3.1.0:System.Posix.Signals.SignalSet{tc r8M})
      eta{v a1Vy} [lid]
    (# ghc-prim:GHC.Prim.State#{(w) tc 32q}
         ghc-prim:GHC.Prim.RealWorld{(w) tc 31E},
       <nt>unix-2.3.1.0:System.Posix.Signals.SignalSet{tc r8M} #)

Please report this as a GHC bug:  http://www.haskell.org/ghc/reportabug

While building darcs 2.2.0.

[simonpj]

This looks very similar to #2763 and #2878.

But we closed #2878 because we couldn't reproduce it; and we've just compiled Darcs 2.2.0 (using configure/make, not cabal) with GHC 6.10.1 without a problem. So we can't reproduce your problem.

Suggestion: start with a fresh tree. And add -dcore-lint. Let us know. Perhaps it's due to some leftover droppings from a previous compilation (although that would still be a bug).

Simon

[quick]

This is a clean directory using the config/make build.

It appears to be related to optimization:

$ rm src/Exec.o $ ghc -dcore-lint -I. -I./src -I./src -i./src -c src/Exec.hs $ rm src/Exec.o $ ghc -dcore-lint -I. -I./src -I./src -i./src -c -O2 src/Exec.hs ghc: panic! (the 'impossible' happened)

(GHC version 6.10.1 for i386-unknown-linux):

applyTypeToArgs

unix-2.3.1.0:System.Posix.Signals.a38{v reS} [gid]

(unix-2.3.1.0:System.Posix.Signals.a5{v reR} [gid]

cast (ghc-prim:GHC.Prim.sym{(w) tc 34v}

base:Foreign.C.Types.:CoCInt{tc ra3}

<pred>base:GHC.Int.Int32{tc 3V} ~ <nt>base:Foreign.C.Types.CInt{tc ra6})) unix-2.3.1.0:System.Posix.Signals.Ignore{v reQ} [gid] (base:Data.Maybe.Nothing{v r5F} [gid] @ <nt>unix-2.3.1.0:System.Posix.Signals.SignalSet{tc reP}) eta{v a1UC} [lid] (# ghc-prim:GHC.Prim.State#{(w) tc 32q} ghc-prim:GHC.Prim.RealWorld{(w) tc 31E}, <nt>unix-2.3.1.0:System.Posix.Signals.SignalSet{tc reP} #)

Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug

The actual full make-generated line (from $ make VERBOSE=true):

$ ghc -hide-all-packages -package haskell98 -package base-3.0.3.0 -threaded -package regex-compat -package network -package HTTP -package filepath -package bytestring -package random -package directory -package old-time -package process -package array -package old-locale -package mtl -package parsec -package html -package containers -package unix -O2 -funbox-strict-fields -D_REENTRANT -DHAVE_CURL -DCURL_MULTI_TIMEOUT -DHAVE_CURSES -DPACKAGE_NAME=\"darcs\" -DPACKAGE_TARNAME=\"darcs\" -DPACKAGE_VERSION=\"2.2.0\" -DPACKAGE_STRING=\"darcs\ 2.2.0\" -DPACKAGE_BUGREPORT=\"bugs@…\" -DSTDC_HEADERS=1 -DHAVE_SYS_TYPES_H=1 -DHAVE_SYS_STAT_H=1 -DHAVE_STDLIB_H=1 -DHAVE_STRING_H=1 -DHAVE_MEMORY_H=1 -DHAVE_STRINGS_H=1 -DHAVE_INTTYPES_H=1 -DHAVE_STDINT_H=1 -DHAVE_UNISTD_H=1 -DHAVE_HTTP=1 -DHAVE_SIGNALS=1 -DHAVE_LIBCURL=1 -Wall -I. -I./src -i./src -dcore-lint -c src/Exec.hs

Also note that the -dcore-lint doesn't seem to have any effect.

Let me know if there's anything else I can provide.

-Kevin

[quick]

Also note that the same error is reported for src/Darcs/External.hs and--as above--dropping the -O2 flag allows it to compile successfully.

[simonpj]

I downloaded  http://darcs.net/darcs-2.2.0.tar.gz, and ran your command line. Complained about lack of HTTP library. So I installed HTTP-4000.0.4. Tried again, with --make -O2:

bash-3.2$ ghc -hide-all-packages -package haskell98 -package base-3.0.3.0 -threaded -package regex-compat -package network -package HTTP -package filepath -package bytestring -package random -package directory -package old-time -package process -package array -package old-locale -package mtl -package parsec -package html -package containers -package unix -O2 -funbox-strict-fields -D_REENTRANT -DHAVE_CURL -DCURL_MULTI_TIMEOUT -DHAVE_CURSES -DPACKAGE_NAME=\"darcs\" -DPACKAGE_TARNAME=\"darcs\" -DPACKAGE_VERSION=\"2.2.0\" -DPACKAGE_STRING=\"darcs\ 2.2.0\" -DPACKAGE_BUGREPORT=\"bugs@darcs.net\" -DSTDC_HEADERS=1 -DHAVE_SYS_TYPES_H=1 -DHAVE_SYS_STAT_H=1 -DHAVE_STDLIB_H=1 -DHAVE_STRING_H=1 -DHAVE_MEMORY_H=1 -DHAVE_STRINGS_H=1 -DHAVE_INTTYPES_H=1 -DHAVE_STDINT_H=1 -DHAVE_UNISTD_H=1 -DHAVE_HTTP=1 -DHAVE_SIGNALS=1 -DHAVE_LIBCURL=1 -Wall -I. -I./src -i./src -dcore-lint --make src/Exec.hs -O2
[1 of 3] Compiling Darcs.Global     ( src/Darcs/Global.hs, src/Darcs/Global.o )
[2 of 3] Compiling Progress         ( src/Progress.hs, src/Progress.o )
[3 of 3] Compiling Exec             ( src/Exec.hs, src/Exec.o )
bash-3.2$ ghc --version
The Glorious Glasgow Haskell Compilation System, version 6.10.1

Worked fine. So I still can't reproduce your problem.

Can you start from scratch and show a log of every single step?

BTW, don't forget the {{{ ... }}} brackets, else your code gets "typeset" by the wiki.

Simon

[quick]

I have a tentative solution. Tentative because it did resolve the problem for me, but I don't know if this would help the similar reported errors.

When I started, I was upgrading from GHC 6.8.3 to GHC 6.10.1, which created a new ghc-pkg database, so I had then attempted to re-install all the library packages I had previously installed.

It seems that the problems start occurring when I installed the unix-2.3.1.0 package. This package is (no longer) necessary for my environment because the functionality is now builtin to GHC 6.10.1; actually installing and registring unix-2.3.1.0 introduced the failures described here.

Another clue was that directory started causing problems:

[ghc] src/Darcs/Commands/Apply.o
/Programs/GHC/6.10.1/lib/ghc-6.10.1/directory-1.0.0.2/System/Directory.hi
Declaration for removeFile
Unfolding of System.Directory.removeFile:
  Can't find interface-file declaration for variable System.Posix.Files.a52
    Probable cause: bug in .hi-boot file, or inconsistent .hi file
    Use -ddump-if-trace to get an idea of which file caused the error

and

[ghc] darcs
/Programs/GHC/6.10.1/lib/ghc-6.10.1/directory-1.0.0.2/libHSdirectory-1.0.0.2.a(Directory__71.o):(.text+0x29): undefined reference to `unixzm2zi3zi1zi0_SystemziPosixziDirectory_a12_info'
/Programs/GHC/6.10.1/lib/ghc-6.10.1/directory-1.0.0.2/libHSdirectory-1.0.0.2.a(Directory__71.o): In function `directoryzm1zi0zi0zi2_SystemziDirectory_a27_srt':
(.data+0x0): undefined reference to `unixzm2zi3zi1zi0_SystemziPosixziDirectory_a12_closure'
/Programs/GHC/6.10.1/lib/ghc-6.10.1/directory-1.0.0.2/libHSdirectory-1.0.0.2.a(Directory__73.o): In function `s6CP_info':
(.text+0x19d): undefined reference to `unixzm2zi3zi1zi0_SystemziPosixziFiles_a55_info'
/Programs/GHC/6.10.1/lib/ghc-6.10.1/directory-1.0.0.2/libHSdirectory-1.0.0.2.a(Directory__73.o): In function `directoryzm1zi0zi0zi2_SystemziDirectory_a28_srt':
(.data+0x4): undefined reference to `unixzm2zi3zi1zi0_SystemziPosixziFiles_a55_closure'
/Programs/GHC/6.10.1/lib/ghc-6.10.1/directory-1.0.0.2/libHSdirectory-1.0.0.2.a(Directory__77.o): In function `s6PY_info':
(.text+0x40): undefined reference to `unixzm2zi3zi1zi0_SystemziPosixziFiles_a55_info'
/Programs/GHC/6.10.1/lib/ghc-6.10.1/directory-1.0.0.2/libHSdirectory-1.0.0.2.a(Directory__77.o): In function `directoryzm1zi0zi0zi2_SystemziDirectory_a32_srt':
(.data+0x4): undefined reference to `unixzm2zi3zi1zi0_SystemziPosixziFiles_a55_closure'
...

I rebuilt and re-installed GHC 6.10.1 and did *not* install unix-2.3.1.0. I am now successfully able to build darcs.

As a side note, I cannot build QuickCheck?-2.1.0.1 with GHC 6.10.1; I don't know if this is a known issue or not:

Building QuickCheck-2.1.0.1...
[ 1 of 11] Compiling Test.QuickCheck.Exception ( Test/QuickCheck/Exception.hs, dist/build/Test/QuickCheck/Exception.o )

Test/QuickCheck/Exception.hs:12:31:
    Class `Exception' used as a type
    In the type `Exception'
    In the type `Either Exception a'
    In the type `IO (Either Exception a)'

Test/QuickCheck/Exception.hs:15:36:
    Class `Exception' used as a type
    In the type `Exception'
    In the type `Either Exception a'
    In the type `IO (Either Exception a)'

Anyhow, root cause was PEBKAC... sorry to have wasted your time.

-Kevin

[simonpj]

I'm glad you're rolling again, but I'm still mystified. That "Can't find interface-file declaration" message sounds just like a stale interface file, which can give all sorts of trouble.

What happens if you now install unix-2.3.1.0 in your fresh GHC 6.10? (When I say "install" I mean "using Cabal or something" so that you compile it from scratch; a binary download won't do.) If installing the unix package breaks the build, something is still wrong.

Re Quickcheck, GHC 6.10 has a new implementation of exceptions. I think you can get the old one back with some package incantation like -package base-3, but I'm not certain. Ask the libraries list.

Simon

[quick]

Sorry for the delay...

I can confirm that a cabal-based installation of unix-2.3.1.0 causes the darcs-build error to re-occur. The build of unix-2.3.1.0 proceeded without problems, but the result is fatal.

A ghc-pkg hide unix-2.3.1.0 is successful and a list confirms that unix is hidden (surrounded by parentheses) but the error persists.

I cannot ghc-pkg unregister unix because:

ghc-pkg: unregistering unix would break the following packages: haddock-2.3.0 ghc-6.10.1 directory-1.0.0.2 process-1.0.1.0 hpc-0.5.0.2 Cabal-1.6.0.1 haskell98-1.0.1.0 (use --force to override)

The only solution apparent at this point is to remove GHC-6.10.1 and fallback to GHC-6.8.3, then use GHC-6.8.3 to rebuild and re-install GHC-6.10.1. I cannot simply rebuild GHC-6.10.1 because it has a similar failure attempting to build itself.

So... I'm going to re-open this bug, but with lower severity (because there are workarounds). The unix package is definitely problematic post-install.

[duncan]

GHC-6.10.1 bundles unix-2.3.1.0. There are several other installed packages that come with ghc-6.10.1 that depend on unix-2.3.1.0. You cannot in general substitute an installed package without also rebuilding all the other packages that depend on it. There is no guarantee that you can rebuild the package and get the same ABI as previously.

In this case you are fortunate that you get errors at compile time due to mismatches in .hi files rather than linker errors or segfaults.

At the moment we do not track ABIs so Cabal and ghc-pkg do not prevent you from doing unwise things. The short term solution is to "not do that". The medium term solution is to track the ABI and use it as a check. The longer term solution is to allow installing multiple instances based on their ABI.

[simonpj]

Simon and I have just discussed this, and agreed that we'll change ghc-pkg so that it won't let you update (overwrite) a package on which other installed packages depend. That's the inconsistency that led to this bug.

I'm leaving this ticket open just to remind us to complete this change.

Simon

[quick]

Thanks, that third-rail protection will be useful.

[As background, I had done the GHC upgrade and was just iterating through the list of packages I'd previously installed to re-install for the upgrade. I suspect this isn't an uncommon practice.]

Just a few small concerns about your intended fix (probably mostly based on my ghc-pkg ignorance):

- If a new version of a valid package comes out, how can I upgrade if the old version has dependencies? Will ghc-pkg allow multiple installations with separate versions? Do I have to uninstall all the dependent versions before upgrading?

- Is there a differentiation between user-added packages and packages that are part of the GHC distribution? For example, if I had "uninstalled" the unix package (and its deps?) before trying to install my own-built version, would I have had the same problem? Should it be that ghc-pkg never allows one to uninstall or otherwise modify a package that is part of the distribution?

Thanks again,

Kevin

[simonmar]

Replying to simonpj:

Simon and I have just discussed this, and agreed that we'll change ghc-pkg so that it won't let you update (overwrite) a package on which other installed packages depend. That's the inconsistency that led to this bug. I'm leaving this ticket open just to remind us to complete this change.

New ticket opened for fixing ghc-pkg: #3090