Opened 6 years ago

Closed 4 years ago

#9202 closed bug (worksforme)

Strange Closure Type

Reported by: athanclark Owned by:
Priority: normal Milestone:
Component: Compiler Version: 7.8.2
Keywords: strange-closure-type Cc:
Operating System: Linux Architecture: x86_64 (amd64)
Type of failure: Compile-time crash Test Case:
Blocked By: Blocking:
Related Tickets: Differential Rev(s):
Wiki Page:

Description

Hello masters of the universe, I am here with a plea. I have recently installed GHC 7.8.2 and cabal-install 1.20.0.0 (following this guide), and have ran into a fun road block on the way to installing yesod-platform. I have had a few incidents of the 'strange closure type ###' error on this machine before, on the 7.6.x version available in Ubuntu's repository. I believe this failure is occuring when installing text, because that was the error that I got when installing attoparsec alone, but without a sandbox. I know (barely) better now, so when I went to install yesod-platform, I did a cabal unpack $1 && cd $1* && cabal sandbox init && cabal install --only-dependencies && cabal build, but I failed at preventing the error, still :(

I've attached the output as output.txt, and I've also included my lspci and lshw outputs just for giggles :) I hope someone can direct me in the right direction, I would appreciate it tremendously. Thank you!

Attachments (1)

foo.txt (80 bytes) - added by athanclark 6 years ago.
Quick overview of the failure

Download all attachments as: .zip

Change History (10)

comment:1 Changed 6 years ago by athanclark

Resolution: worksforme
Status: newclosed

Wow, somehow I can't find the file I output the logs to. Sorry!!

Changed 6 years ago by athanclark

Attachment: foo.txt added

Quick overview of the failure

comment:2 Changed 6 years ago by athanclark

Resolution: worksforme
Status: closednew

comment:3 Changed 6 years ago by athanclark

I'm sorry to reopen this nuisance case, but I have come across the failure again and can reproduce it. I have a sandbox open for yesod-platform, and have been running into an ExitFailure (-11) when I try to install it normally, with attoparsec-0.12.0.0 being the culprit of failure. So, I install attoparsec-0.12.0.0 in the sandbox without failures, then try to cabal install the whole package, and that's when I ran into the failure. What other information should I be getting? Thank you in advance for all your help :)

comment:4 Changed 6 years ago by athanclark

Here is another log of the same kind of error:

Configuring cereal-0.4.0.1...
Building cereal-0.4.0.1...
Preprocessing library cereal-0.4.0.1...
[1 of 5] Compiling Data.Serialize.Builder ( src/Data/Serialize/Builder.hs, dist$
[2 of 5] Compiling Data.Serialize.Put ( src/Data/Serialize/Put.hs, dist/dist-sa$
[3 of 5] Compiling Data.Serialize.Get ( src/Data/Serialize/Get.hs, dist/dist-sa$
[4 of 5] Compiling Data.Serialize.IEEE754 ( src/Data/Serialize/IEEE754.hs, dist$
[5 of 5] Compiling Data.Serialize   ( src/Data/Serialize.hs, dist/dist-sandbox-$
In-place registering cereal-0.4.0.1...
setup-Simple-Cabal-1.20.0.0-x86_64-linux-ghc-7.8.2: ghc: internal error:
scavenge: unimplemented/strange closure type 1133201408 @ 0x7f9b7c1a1858
(GHC version 7.8.2 for x86_64_unknown_linux)
Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug

comment:5 Changed 6 years ago by carter

could you upload whats in your ~/.cabal/config

comment:6 Changed 6 years ago by athanclark

Yes, here is the whole file: http://lpaste.net/105592 Thank you!

comment:7 Changed 5 years ago by rwbarton

Do you still see this issue with GHC 7.8.3? It will be rather hard to diagnose this without more information, I'm afraid.

comment:8 Changed 5 years ago by Fuuzetsu

At the very least it does seem to still exist with 7.8.3: https://github.com/yi-editor/yi/issues/664

Sorry that I don't have any specific info for you.

comment:9 Changed 4 years ago by thomie

Resolution: worksforme
Status: newclosed

This is an old bug reported against ghc-7.8.2 about "strange closure types" when installing yesod-platform.

A lot has changed since then. I'm assuming this is fixed.

If you do encounter it again, please open a new bug.

Note: See TracTickets for help on using tickets.