Re: [GHC] #5899: RTS crash w/ strange closure type 603975781 on OS X 10.8
#5899: RTS crash w/ strange closure type 603975781 on OS X 10.8 -+-- Reporter: dylukes | Owner: Type: bug | Status: closed Priority: high| Milestone: 7.4.2 Component: Runtime System |Version: 7.4.1 Resolution: worksforme | Keywords: rts, strange closure, internal error, os x Os: MacOS X | Architecture: x86_64 (amd64) Failure: Runtime crash | Difficulty: Unknown Testcase: | Blockedby: Blocking: |Related: -+-- Comment(by chak): For what it is worth, I just validated the HEAD with GHC 7.4.1 on ML DP4 with Xcode 4.5 DP. Seems to be fine. -- Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/5899#comment:34 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler ___ Glasgow-haskell-bugs mailing list Glasgow-haskell-bugs@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
Re: [GHC] #5899: RTS crash w/ strange closure type 603975781 on OS X 10.8
#5899: RTS crash w/ strange closure type 603975781 on OS X 10.8 -+-- Reporter: dylukes | Owner: Type: bug | Status: closed Priority: high| Milestone: 7.4.2 Component: Runtime System |Version: 7.4.1 Resolution: worksforme | Keywords: rts, strange closure, internal error, os x Os: MacOS X | Architecture: x86_64 (amd64) Failure: Runtime crash | Difficulty: Unknown Testcase: | Blockedby: Blocking: |Related: -+-- Changes (by simonmar): * status: new = closed * resolution: = worksforme Comment: I just did a validate using an existing installation of GHC 7.0.3 on OS X 10.8 DP3 with XCode 4.4 DP5. There are a few test failures that need to be cleaned up, but the crashes now seem to be gone. So I presume this was a bug in the linker after all, and Apple fixed it. -- Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/5899#comment:33 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler ___ Glasgow-haskell-bugs mailing list Glasgow-haskell-bugs@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
Re: [GHC] #5899: RTS crash w/ strange closure type 603975781 on OS X 10.8
#5899: RTS crash w/ strange closure type 603975781 on OS X 10.8 ---+ Reporter: dylukes | Owner: Type: bug | Status: new Priority: high| Milestone: 7.4.2 Component: Runtime System | Version: 7.4.1 Keywords: rts, strange closure, internal error, os x | Os: MacOS X Architecture: x86_64 (amd64) | Failure: Runtime crash Difficulty: Unknown |Testcase: Blockedby: |Blocking: Related: | ---+ Comment(by simonmar): That's good news. However we don't know what made the problem go away, so it's possible it might re-emerge. Let's keep the ticket open until we can verify whether our 7.4.2 distributions work on 10.8. -- Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/5899#comment:30 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler ___ Glasgow-haskell-bugs mailing list Glasgow-haskell-bugs@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
Re: [GHC] #5899: RTS crash w/ strange closure type 603975781 on OS X 10.8
#5899: RTS crash w/ strange closure type 603975781 on OS X 10.8 ---+ Reporter: dylukes | Owner: Type: bug | Status: new Priority: high| Milestone: 7.4.2 Component: Runtime System | Version: 7.4.1 Keywords: rts, strange closure, internal error, os x | Os: MacOS X Architecture: x86_64 (amd64) | Failure: Runtime crash Difficulty: Unknown |Testcase: Blockedby: |Blocking: Related: | ---+ Comment(by igloo): But the HP contains exactly the same GHC that didn't work, doesn't it? Isn't it more likely that the newer versions of OS X stuff fixed the linker? -- Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/5899#comment:31 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler ___ Glasgow-haskell-bugs mailing list Glasgow-haskell-bugs@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
Re: [GHC] #5899: RTS crash w/ strange closure type 603975781 on OS X 10.8
#5899: RTS crash w/ strange closure type 603975781 on OS X 10.8 ---+ Reporter: dylukes | Owner: Type: bug | Status: new Priority: high| Milestone: 7.4.2 Component: Runtime System | Version: 7.4.1 Keywords: rts, strange closure, internal error, os x | Os: MacOS X Architecture: x86_64 (amd64) | Failure: Runtime crash Difficulty: Unknown |Testcase: Blockedby: |Blocking: Related: | ---+ Comment(by simonmar): I've been updating my Mac to the latest 10.8 and XCode, so hopefully I'll be able to answer that soon. -- Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/5899#comment:32 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler ___ Glasgow-haskell-bugs mailing list Glasgow-haskell-bugs@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
Re: [GHC] #5899: RTS crash w/ strange closure type 603975781 on OS X 10.8
#5899: RTS crash w/ strange closure type 603975781 on OS X 10.8
---+
Reporter: dylukes | Owner:
Type: bug | Status: new
Priority: high| Milestone:
7.4.2
Component: Runtime System | Version:
7.4.1
Keywords: rts, strange closure, internal error, os x | Os:
MacOS X
Architecture: x86_64 (amd64) | Failure:
Runtime crash
Difficulty: Unknown |Testcase:
Blockedby: |Blocking:
Related: |
---+
Comment(by lukexi):
Hi guys,
I'm very happy to report that this seems to be fixed using the new Haskell
Platform release 2012.2.0.0!
The test program above runs perfectly, and my multithreaded server I
originally ran into the 'strange closure type' issue with runs wonderfully
as well. Hurray!
I'm on ML DP3 (Build 12A206j), with Xcode 4.4 DP4.
{{{
lukexi@Luke-Ianninis-MacBook-Air:~/ghctest2$ echo 'main = print $ reverse
[1,2,3]' Main.hs
lukexi@Luke-Ianninis-MacBook-Air:~/ghctest2$ ghc Main
[1 of 1] Compiling Main ( Main.hs, Main.o )
Linking Main ...
lukexi@Luke-Ianninis-MacBook-Air:~/ghctest2$ ./Main
[3,2,1]
lukexi@Luke-Ianninis-MacBook-Air:~/ghctest2$
}}}
{{{
lukexi@Luke-Ianninis-MacBook-Air:~/ghctest2$ ghc --version
The Glorious Glasgow Haskell Compilation System, version 7.4.1
lukexi@Luke-Ianninis-MacBook-Air:~/ghctest2$ ld -v
@(#)PROGRAM:ld PROJECT:ld64-132.11
configured to support archs: armv6 armv7 i386 x86_64
LTO support using: LLVM version 3.1svn, from Apple Clang 4.0 (build
421.0.31)
lukexi@Luke-Ianninis-MacBook-Air:~/ghctest2$ gcc --version
i686-apple-darwin11-llvm-gcc-4.2 (GCC) 4.2.1 (Based on Apple Inc. build
5658) (LLVM build 2336.11.00)
Copyright (C) 2007 Free Software Foundation, Inc.
This is free software; see the source for copying conditions. There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR
PURPOSE.
}}}
--
Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/5899#comment:29
GHC http://www.haskell.org/ghc/
The Glasgow Haskell Compiler
___
Glasgow-haskell-bugs mailing list
Glasgow-haskell-bugs@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
Re: [GHC] #5899: RTS crash w/ strange closure type 603975781 on OS X 10.8
#5899: RTS crash w/ strange closure type 603975781 on OS X 10.8 ---+ Reporter: dylukes | Owner: Type: bug | Status: new Priority: high| Milestone: 7.4.2 Component: Runtime System | Version: 7.4.1 Keywords: rts, strange closure, internal error, os x | Os: MacOS X Architecture: x86_64 (amd64) | Failure: Runtime crash Difficulty: Unknown |Testcase: Blockedby: |Blocking: Related: | ---+ Changes (by simonpj): * cc: gdr@… (added) Comment: We seem stuck here. Mabye it's even a linker bug. * It is documented not to do this * Surely other systems also rely on the linker not randomly re-laying out code We could do with help from a linker expert. Gaby dos Reis perhaps? Simon -- Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/5899#comment:28 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler ___ Glasgow-haskell-bugs mailing list Glasgow-haskell-bugs@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
Re: [GHC] #5899: RTS crash w/ strange closure type 603975781 on OS X 10.8
#5899: RTS crash w/ strange closure type 603975781 on OS X 10.8 ---+ Reporter: dylukes | Owner: Type: bug | Status: new Priority: high| Milestone: 7.4.2 Component: Runtime System | Version: 7.4.1 Keywords: rts, strange closure, internal error, os x | Os: MacOS X Architecture: x86_64 (amd64) | Failure: Runtime crash Difficulty: Unknown |Testcase: Blockedby: |Blocking: Related: | ---+ Comment(by simonmar): Regarding the documentation, the documentation for `-no_order_inits` says When the -order_file option is not used, the linker lays out functions in object file order and it moves all initializer routines to the start of the __text section and terminator routines to the end. Use this option to disable the automatic rearrangement of initializers and terminators. So this explicitly says that functions are laid out in object file order when `-order_file` is ''not'' used. Either the documentation is wrong, or the implementation has a bug. In principle we could use `-order_file`, but as Irene says it is difficult to arrange. We don't know the list of symbols before linking because they come from libraries, so we would have to link the program twice: once to find the list of object files, then construct the symbol list by looking up the object files in the libraries, and then link again with `-order_file` and the constructed list of symbols. This could all be quite slow. Irene: I don't think reordering is gaining us anything. The linker doesn't have any locality information that it could use to do a sensible reordering. I suspect that all it is doing is filling in gaps caused by alignment with small symbols to reduce the size of the linked binary a tiny bit. -- Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/5899#comment:27 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler ___ Glasgow-haskell-bugs mailing list Glasgow-haskell-bugs@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
Re: [GHC] #5899: RTS crash w/ strange closure type 603975781 on OS X 10.8
#5899: RTS crash w/ strange closure type 603975781 on OS X 10.8 ---+ Reporter: dylukes | Owner: Type: bug | Status: new Priority: high| Milestone: 7.4.2 Component: Runtime System | Version: 7.4.1 Keywords: rts, strange closure, internal error, os x | Os: MacOS X Architecture: x86_64 (amd64) | Failure: Runtime crash Difficulty: Unknown |Testcase: Blockedby: |Blocking: Related: | ---+ Comment(by simonmar): One thought occurred to me: maybe if we set the size of the `_dsp` symbol to be the size of the info table plus the size of the code, that would prevent `ld` from separating them. But, as far as I can tell, symbols do not have sizes in Mach-O. I'm a bit bemused at how the linker can get away with reordering code within an object file. The behaviour seems to be inconsistent with the man page for ld, which says The object files are loaded in the order in which they are specified on the command line. The segments and the sections in those segments will appear in the output file in the order they are encountered in the object files being linked. [...] The use of the -order_file option will alter the layout rules above, and move the symbols specified to start of their section. which doesn't explicitly say that code within a section will not be reordered, but it strongly implies that. -- Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/5899#comment:24 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler ___ Glasgow-haskell-bugs mailing list Glasgow-haskell-bugs@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
Re: [GHC] #5899: RTS crash w/ strange closure type 603975781 on OS X 10.8
#5899: RTS crash w/ strange closure type 603975781 on OS X 10.8 ---+ Reporter: dylukes | Owner: Type: bug | Status: new Priority: high| Milestone: 7.4.2 Component: Runtime System | Version: 7.4.1 Keywords: rts, strange closure, internal error, os x | Os: MacOS X Architecture: x86_64 (amd64) | Failure: Runtime crash Difficulty: Unknown |Testcase: Blockedby: |Blocking: Related: | ---+ Comment(by chak): Replying to [comment:24 simonmar]: I'm a bit bemused at how the linker can get away with reordering code within an object file. The behaviour seems to be inconsistent with the man page for ld, which says The object files are loaded in the order in which they are specified on the command line. The segments and the sections in those segments will appear in the output file in the order they are encountered in the object files being linked. [...] The use of the -order_file option will alter the layout rules above, and move the symbols specified to start of their section. which doesn't explicitly say that code within a section will not be reordered, but it strongly implies that. But don't the `-no_order_inits` and `-no_order_data` options make it clear that reordering within sections is happening? In fact, can't we use `-order_file` to solve this problem once and for all? -order_file file Alters the order in which functions and data are laid out. For each section in the output file, any symbol in that sec- tion that are specified in the order file file is moved to the start of its section and laid out in the same order as in the order file file. Order files are text files with one symbol name per line. Lines starting with a # are comments. A symbol name may be optionally preceded with its object file leaf name and a colon (e.g. foo.o:_foo). This is useful for static functions/data that occur in multiple files. A symbol name may also be optionally preceded with the architecture (e.g. ppc:_foo or ppc:foo.o:_foo). This enables you to have one order file that works for multiple architectures. Lit- eral c-strings may be ordered by by quoting the string (e.g. Hello, world\n) in the order file. In fact, the man page makes it sound as if we can achieve TNTC without any hacks using an order file on OS X. Or am I missing something? -- Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/5899#comment:25 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler ___ Glasgow-haskell-bugs mailing list Glasgow-haskell-bugs@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
Re: [GHC] #5899: RTS crash w/ strange closure type 603975781 on OS X 10.8
#5899: RTS crash w/ strange closure type 603975781 on OS X 10.8 ---+ Reporter: dylukes | Owner: Type: bug | Status: new Priority: high| Milestone: 7.4.2 Component: Runtime System | Version: 7.4.1 Keywords: rts, strange closure, internal error, os x | Os: MacOS X Architecture: x86_64 (amd64) | Failure: Runtime crash Difficulty: Unknown |Testcase: Blockedby: |Blocking: Related: | ---+ Comment(by Irene): Well, we can indeed do it with an order file, but it's unwieldy to have to construct one that encompasses every single module being linked, and then it breaks again if linked again, as for example happens if we build a Haskell library that an innocent and well-meaning author tries to link into a C program without GHC's involvement. Actually, I'm not sure how we can make that scenario work even with some sort of way to tell LLVM explicitly about TNTC, since the Mach-O format doesn't have any way to express that constraint, so it will never survive to a second linking. But the main reason to not use an order file is that the reordering probably actually does provide a good benefit, since (I assume but nobody's actually explained it that I've seen) it does things such as providing additional code locality so as to keep things within the processor's instruction cache more often. It can also do whole-program dead-code removal. This sort of feature, which the LLVM people call link- time optimization (LTO), is defeated if we tell it it can't actually do anything. -- Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/5899#comment:26 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler ___ Glasgow-haskell-bugs mailing list Glasgow-haskell-bugs@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
Re: [GHC] #5899: RTS crash w/ strange closure type 603975781 on OS X 10.8
#5899: RTS crash w/ strange closure type 603975781 on OS X 10.8 ---+ Reporter: dylukes | Owner: Type: bug | Status: new Priority: high| Milestone: 7.4.2 Component: Runtime System | Version: 7.4.1 Keywords: rts, strange closure, internal error, os x | Os: MacOS X Architecture: x86_64 (amd64) | Failure: Runtime crash Difficulty: Unknown |Testcase: Blockedby: |Blocking: Related: | ---+ Comment(by simonmar): I think you only forced ordering for the `Main.o` module, and not the libraries or the RTS, correct? I observed the ordering being mangled for one object file in the `base` package, so you would need to force the correct order for all the symbols in the libraries too. -- Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/5899#comment:21 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler ___ Glasgow-haskell-bugs mailing list Glasgow-haskell-bugs@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
Re: [GHC] #5899: RTS crash w/ strange closure type 603975781 on OS X 10.8
#5899: RTS crash w/ strange closure type 603975781 on OS X 10.8 ---+ Reporter: dylukes | Owner: Type: bug | Status: new Priority: high| Milestone: 7.4.2 Component: Runtime System | Version: 7.4.1 Keywords: rts, strange closure, internal error, os x | Os: MacOS X Architecture: x86_64 (amd64) | Failure: Runtime crash Difficulty: Unknown |Testcase: Blockedby: |Blocking: Related: | ---+ Comment(by Irene): Yes, that is correct - I didn't think of doing it for libraries and the RTS. I'll put together another test that does, and report back. Good catch! -- Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/5899#comment:22 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler ___ Glasgow-haskell-bugs mailing list Glasgow-haskell-bugs@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
Re: [GHC] #5899: RTS crash w/ strange closure type 603975781 on OS X 10.8
#5899: RTS crash w/ strange closure type 603975781 on OS X 10.8 ---+ Reporter: dylukes | Owner: Type: bug | Status: new Priority: high| Milestone: 7.4.2 Component: Runtime System | Version: 7.4.1 Keywords: rts, strange closure, internal error, os x | Os: MacOS X Architecture: x86_64 (amd64) | Failure: Runtime crash Difficulty: Unknown |Testcase: Blockedby: |Blocking: Related: | ---+ Comment(by Irene): I did the more thorough test, and the trivial program runs without a crash, producing correct output. Excellent! This means that the problem does indeed consist only of the TNTC thing, which is what I was trying to verify. -- Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/5899#comment:23 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler ___ Glasgow-haskell-bugs mailing list Glasgow-haskell-bugs@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
Re: [GHC] #5899: RTS crash w/ strange closure type 603975781 on OS X 10.8
#5899: RTS crash w/ strange closure type 603975781 on OS X 10.8
---+
Reporter: dylukes | Owner:
Type: bug | Status: new
Priority: high| Milestone:
7.4.2
Component: Runtime System | Version:
7.4.1
Keywords: rts, strange closure, internal error, os x | Os:
MacOS X
Architecture: x86_64 (amd64) | Failure:
Runtime crash
Difficulty: Unknown |Testcase:
Blockedby: |Blocking:
Related: |
---+
Comment(by Irene):
I did more digging - I wanted to verify that this was the only issue
breaking us on Mountain Lion, and possibly also find a short-term kludge
so that those of us who are using it can continue to develop our Haskell
projects while we wait for the release. :) It's important that we know
whether there are any other issues hidden by this one, to avoid a
situation where this one gets fixed just in time but then something else
breaks us and we aren't able to release.
I used the test program
{{{
main = print $ f 1 where f = (+1)
}}}
and passed the linker an option that forces it to keep the symbols in the
same order (which the LLVM people have no interest in supporting as a
long-term solution, since it makes various stuff impossible):
{{{
$ nm -n Main.o | grep -v '^ \+U ' | sed -e 's/^[0-9a-f]* [a-zA-Z] //'
order.txt
$ ld Main.o rtsopts.o
/Library/Frameworks/GHC.framework/Versions/7.0.4-x86_64/usr/lib/ghc-7.0.4/base-4.3.1.0/libHSbase-4.3.1.0.a
/usr/lib/libiconv.dylib
/Library/Frameworks/GHC.framework/Versions/7.0.4-x86_64/usr/lib/ghc-7.0.4
/integer-gmp-0.2.0.3/libHSinteger-gmp-0.2.0.3.a
/Library/Frameworks/GHC.framework/Versions/7.0.4-x86_64/usr/lib/ghc-7.0.4
/ghc-prim-0.2.0.0/libHSghc-prim-0.2.0.0.a
/Library/Frameworks/GHC.framework/Versions/7.0.4-x86_64/usr/lib/ghc-7.0.4/directory-1.1.0.0/libHSdirectory-1.1.0.0.a
/Library/Frameworks/GHC.framework/Versions/7.0.4-x86_64/usr/lib/ghc-7.0.4/filepath-1.2.0.0/libHSfilepath-1.2.0.0.a
/Library/Frameworks/GHC.framework/Versions/7.0.4-x86_64/usr/lib/ghc-7.0.4/unix-2.4.2.0/libHSunix-2.4.2.0.a
/Library/Frameworks/GHC.framework/Versions/7.0.4-x86_64/usr/lib/ghc-7.0.4
/old-time-1.0.0.6/libHSold-time-1.0.0.6.a
/Library/Frameworks/GHC.framework/Versions/7.0.4-x86_64/usr/lib/ghc-7.0.4
/old-locale-1.0.0.2/libHSold-locale-1.0.0.2.a /usr/lib/libSystem.dylib
/usr/lib/crt1.10.6.o
/Library/Frameworks/GHC.framework/Versions/7.0.4-x86_64/usr/lib/ghc-7.0.4/libHSffi.a
/Library/Frameworks/GHC.framework/Versions/7.0.4-x86_64/usr/lib/ghc-7.0.4/libHSrts_debug.a
/Library/Frameworks/GHC.framework/Versions/7.0.4-x86_64/usr/lib/ghc-7.0.4/libHSrtsmain.a
}}}
You'll note that I'm using GHC 7.0.4 for this test. That's because I
couldn't find where _main was defined under 7.4.1 and thus couldn't do the
manual linking step. (I presume it's generated dynamically...) This has
no ramifications for the eventual fix, since of course GHC devs know how
to modify GHC to be certain it really is issuing the desired ld command -
but I don't. So I had to do it this way.
Anyway, attached, please find three long dumps of information. They are
the complete symbol table of the a.out produced by the above command; the
complete output of the test program with all the RTS debugging flags
turned on; and the crash report produced by the OS. It looks like we
still have a problem, even with the symbol order fixed - or did I mess
something up?
--
Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/5899#comment:19
GHC http://www.haskell.org/ghc/
The Glasgow Haskell Compiler
___
Glasgow-haskell-bugs mailing list
Glasgow-haskell-bugs@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
Re: [GHC] #5899: RTS crash w/ strange closure type 603975781 on OS X 10.8
#5899: RTS crash w/ strange closure type 603975781 on OS X 10.8 ---+ Reporter: dylukes | Owner: Type: bug | Status: new Priority: high| Milestone: 7.4.2 Component: Runtime System | Version: 7.4.1 Keywords: rts, strange closure, internal error, os x | Os: MacOS X Architecture: x86_64 (amd64) | Failure: Runtime crash Difficulty: Unknown |Testcase: Blockedby: |Blocking: Related: | ---+ Comment(by Irene): Hm, not sure how to attach a file. See [http://ireneknapp.com/himitsu/still-a-problem.tar.bz2] for the aforementioned dumps. -- Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/5899#comment:20 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler ___ Glasgow-haskell-bugs mailing list Glasgow-haskell-bugs@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
Re: [GHC] #5899: RTS crash w/ strange closure type 603975781 on OS X 10.8
#5899: RTS crash w/ strange closure type 603975781 on OS X 10.8
---+
Reporter: dylukes | Owner:
Type: bug | Status: new
Priority: high| Milestone:
7.4.2
Component: Runtime System | Version:
7.4.1
Keywords: rts, strange closure, internal error, os x | Os:
MacOS X
Architecture: x86_64 (amd64) | Failure:
Runtime crash
Difficulty: Unknown |Testcase:
Blockedby: |Blocking:
Related: |
---+
Comment(by simonmar):
I managed to reproduce the problem. I know what's going on, but I don't
know how to fix it yet. So the problem is that in the binary, the linker
has re-ordered some of the contents so that one particular info table is
not next to its code any more:
{{{
00010002cb88 t
_base_GHCziIOziHandleziInternals_augmentIOError_info_dsp
00010002cba0 T _base_GHCziIOziHandleziInternals_augmentIOError_info
00010002cbe8 t _base_GHCziEventziInternal_evtNothing_info_dsp
00010002cbf8 T _base_GHCziEventziInternal_evtNothing_info
00010002cc88 t _base_GHCziBase_zd_info_dsp
00010002cca0 t _base_GHCziIOziHandleziInternals_zdLr3Qxlvl8_info_dsp
00010002ccb0 T _base_GHCziIOziHandleziInternals_zdLr3Qxlvl8_info
00010002cd38 T _base_GHCziBase_zd_info
}}}
Note the symbol `_base_GHCziBase_zd_info_dsp` should be adjacent to
`_base_GHCziBase_zd_info`, but the linker has placed some other stuff in
between. These _dsp symbols are already special OS X magic that we insert
to prevent the linker dropping things on the floor (IIRC, and this is
horrible because it means the libraries on OS X have twice as many symbols
as other platforms).
These symbols are adjacent in the original object file:
{{{
libHSbase-4.5.0.0.a(Base__45.o):
0028 D _base_GHCziBase_zd_closure
0018 T _base_GHCziBase_zd_info
t _base_GHCziBase_zd_info_dsp
U _stg_ap_p_fast
}}}
it seems like there ought to be a way to disable this behaviour with a
linker flag, but I can't find one that works. I've tried
`-no_order_inits` and `-no_order_data`.
Help from OS X experts greatly appreciated...
--
Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/5899#comment:17
GHC http://www.haskell.org/ghc/
The Glasgow Haskell Compiler
___
Glasgow-haskell-bugs mailing list
Glasgow-haskell-bugs@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
Re: [GHC] #5899: RTS crash w/ strange closure type 603975781 on OS X 10.8
#5899: RTS crash w/ strange closure type 603975781 on OS X 10.8 ---+ Reporter: dylukes | Owner: Type: bug | Status: new Priority: high| Milestone: 7.4.2 Component: Runtime System | Version: 7.4.1 Keywords: rts, strange closure, internal error, os x | Os: MacOS X Architecture: x86_64 (amd64) | Failure: Runtime crash Difficulty: Unknown |Testcase: Blockedby: |Blocking: Related: | ---+ Comment(by dylukes): When I went to the LLVM folks to talk about this, they referred me to a recent mailing list discussion last week. As long as there's support for moving forward with proper TNTC support in LLVM, this should get solved as a byproduct. http://lists.cs.uiuc.edu/pipermail/llvmdev/2012-March/048195.html -- Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/5899#comment:18 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler ___ Glasgow-haskell-bugs mailing list Glasgow-haskell-bugs@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
Re: [GHC] #5899: RTS crash w/ strange closure type 603975781 on OS X 10.8
#5899: RTS crash w/ strange closure type 603975781 on OS X 10.8
---+
Reporter: dylukes | Owner:
Type: bug | Status: new
Priority: high| Milestone:
7.4.2
Component: Runtime System | Version:
7.4.1
Keywords: rts, strange closure, internal error, os x | Os:
MacOS X
Architecture: x86_64 (amd64) | Failure:
Runtime crash
Difficulty: Unknown |Testcase:
Blockedby: |Blocking:
Related: |
---+
Changes (by Irene):
* cc: ireney.knapp@… (added)
Comment:
I tried the sample program above:
{{{
main = print $ reverse [1,2,3]
}}}
GHC 7.4.1 (from the .pkg version of the prebuilt binaries, but it's
probably identical to the tarball version?) compiled successfully but the
output crashed; here is the OS X crash report:
{{{
Process: Main [37094]
Path:/Users/USER/*/Main
Identifier: Main
Version: 0
Code Type: X86-64 (Native)
Parent Process: bash [29186]
User ID: 501
Date/Time: 2012-03-22 20:24:06.768 -0400
OS Version: Mac OS X 10.8 (12A154q)
Report Version: 10
Interval Since Last Report: 166904 sec
Crashes Since Last Report: 12
Per-App Crashes Since Last Report: 1
Anonymous UUID: 15C338D1-9CE8-40B1-8287-60D878AF6A68
Crashed Thread: 0 Dispatch queue: com.apple.main-thread
Exception Type: EXC_BAD_ACCESS (SIGSEGV)
Exception Codes: KERN_INVALID_ADDRESS at 0x00022bbe8a30
VM Regions Near 0x22bbe8a30:
VM_ALLOCATE00010bd0-00010be0 [ 1024K]
rw-/rwx SM=PRV
--
MALLOC_TINY7fc3d840-7fc3d8411000 [ 68K]
rw-/rwx SM=COW
Application Specific Information:
objc[37094]: garbage collection is OFF
Thread 0 Crashed:: Dispatch queue: com.apple.main-thread
0 Main0x00010bbf0617 stg_ap_pp_fast
+ 31
Thread 0 crashed with X86 Thread State (64-bit):
rax: 0x23fff065 rbx: 0x00010bc0ad58 rcx:
0x00010bbf0708 rdx: 0x00010bd041d8
rdi: 0x00010bc21e98 rsi: 0x00010bc087c0 rbp:
0x00010bd05358 rsp: 0x7fff540c8ab8
r8: 0x0001 r9: 0x0017 r10:
0x0001 r11: 0x0246
r12: 0x00010bd041e0 r13: 0x00010bc21e98 r14:
0x00010bc087e0 r15: 0x00010bd050c0
rip: 0x00010bbf0617 rfl: 0x00010202 cr2:
0x00022bbe8a30
Logical CPU: 6
Binary Images:
0x10bb33000 -0x10bc07fef +Main (0)
F8E9D66A-B502-3555-B942-53E07F336457 /Users/USER/*/Main
0x7fff6b733000 - 0x7fff6b7678e7 dyld (209.1) 7F330FEF-C9C5-38D8
-9C3D-FBDCC0C28BDA /usr/lib/dyld
0x7fff868d6000 - 0x7fff869ed827 libobjc.A.dylib (526)
C3BAF7E1-9924-3714-9001-C1A97AF7448E /usr/lib/libobjc.A.dylib
0x7fff869fa000 - 0x7fff86a46ff7 libauto.dylib (185)
EC749301-51DA-3413-97DF-5481A75F974C /usr/lib/libauto.dylib
0x7fff86b6b000 - 0x7fff86b70fff libcompiler_rt.dylib (30)
C865130E-E5D7-33E3-8131-2591703C67EB
/usr/lib/system/libcompiler_rt.dylib
0x7fff8717a000 - 0x7fff871e2ff7 libc++.1.dylib (61) 5C289258
-570C-3D3E-ACAB-88CB1C01804B /usr/lib/libc++.1.dylib
0x7fff87b24000 - 0x7fff87b27ff7 libdyld.dylib (209.1)
94E58E38-AC20-36DB-A84E-DAFA8D4E41E2 /usr/lib/system/libdyld.dylib
0x7fff890e7000 - 0x7fff890e8fff libremovefile.dylib (23)
D5F8B6CB-1EE1-3A71-858A-F98362786CD9 /usr/lib/system/libremovefile.dylib
0x7fff89148000 - 0x7fff8914afff libquarantine.dylib (48)
CC311F4D-83E1-3A88-9328-9FB095DACF32 /usr/lib/system/libquarantine.dylib
0x7fff898b8000 - 0x7fff898b9fff libsystem_blocks.dylib (57.2)
7014BC27-D424-3E9B-9535-3CAA6C956337
/usr/lib/system/libsystem_blocks.dylib
0x7fff89934000 - 0x7fff8994fff7 libsystem_kernel.dylib
(2050.2.33) D93B6B58-F16D-377C-BE81-C4A87BDDF359
/usr/lib/system/libsystem_kernel.dylib
0x7fff8995 - 0x7fff89951ff7 libsystem_sandbox.dylib (206)
A1AB71A9-6E45-3C2A-A890-046185233396
/usr/lib/system/libsystem_sandbox.dylib
0x7fff8a3e6000 - 0x7fff8a3e7ff7 libSystem.B.dylib (169.1)
A1FA6BD6-4F77-38E5-891E-9EB347229419 /usr/lib/libSystem.B.dylib
0x7fff8a52a000 - 0x7fff8a558ff7 libsystem_m.dylib (3022.4)
C2BB2EF1-B11D-37DE-AF67-50720171F3A0 /usr/lib/system/libsystem_m.dylib
0x7fff8a559000 - 0x7fff8a5c0fff libcommonCrypto.dylib (60007)
Re: [GHC] #5899: RTS crash w/ strange closure type 603975781 on OS X 10.8
#5899: RTS crash w/ strange closure type 603975781 on OS X 10.8 ---+ Reporter: dylukes | Owner: Type: bug | Status: new Priority: high| Milestone: 7.4.2 Component: Runtime System | Version: 7.4.1 Keywords: rts, strange closure, internal error, os x | Os: MacOS X Architecture: x86_64 (amd64) | Failure: Runtime crash Difficulty: Unknown |Testcase: Blockedby: |Blocking: Related: | ---+ Changes (by simonmar): * priority: highest = high Comment: Current status on this: we're not treating it as a blocking issue for 7.4.2, as 10.8 is not released yet and we expect to have time for another GHC release before it is. We are currently blocked on a diagnosis. That means either someone diagnosing it for us, or either Ian or me installing 10.8 on our respective Macs. Can this be done non-destructively? -- Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/5899#comment:13 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler ___ Glasgow-haskell-bugs mailing list Glasgow-haskell-bugs@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
Re: [GHC] #5899: RTS crash w/ strange closure type 603975781 on OS X 10.8
#5899: RTS crash w/ strange closure type 603975781 on OS X 10.8 ---+ Reporter: dylukes | Owner: Type: bug | Status: new Priority: high| Milestone: 7.4.2 Component: Runtime System | Version: 7.4.1 Keywords: rts, strange closure, internal error, os x | Os: MacOS X Architecture: x86_64 (amd64) | Failure: Runtime crash Difficulty: Unknown |Testcase: Blockedby: |Blocking: Related: | ---+ Comment(by dylukes): 10.8 cannot be installed non-destructively over an existing 10.7, but... you could install 10.8 to a new partition (temporarily). I would volunteer to do diagnosis, but I am utterly ignorant of how to do so. -- Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/5899#comment:14 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler ___ Glasgow-haskell-bugs mailing list Glasgow-haskell-bugs@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
Re: [GHC] #5899: RTS crash w/ strange closure type 603975781 on OS X 10.8
#5899: RTS crash w/ strange closure type 603975781 on OS X 10.8
---+
Reporter: dylukes | Owner:
Type: bug | Status: new
Priority: high| Milestone:
7.4.2
Component: Runtime System | Version:
7.4.1
Keywords: rts, strange closure, internal error, os x | Os:
MacOS X
Architecture: x86_64 (amd64) | Failure:
Runtime crash
Difficulty: Unknown |Testcase:
Blockedby: |Blocking:
Related: |
---+
Comment(by dr.gigabit):
I have the same symptom while trying to cabal install syb
{{{
Resolving dependencies...
[1 of 1] Compiling Main (
/var/folders/gh/3w2hyrhs649b13txtmn7j5wcgn/T/syb-0.3.6-18301/syb-0.3.6/Setup.hs,
/var/folders/gh/3w2hyrhs649b13txtmn7j5wcgn/T/syb-0.3.6-18301/syb-0.3.6/dist/setup/Main.o
)
/var/folders/gh/3w2hyrhs649b13txtmn7j5wcgn/T/syb-0.3.6-18301/syb-0.3.6/Setup.hs:4:30:
Warning: In the use of `runTests'
(imported from Distribution.Simple, but defined in
Distribution.Simple.UserHooks):
Deprecated: Please use the new testing interface instead!
Linking
/var/folders/gh/3w2hyrhs649b13txtmn7j5wcgn/T/syb-0.3.6-18301/syb-0.3.6/dist/setup/setup
...
setup: internal error: evacuate(static): strange closure type 603975781
(GHC version 7.4.1 for x86_64_apple_darwin)
Please report this as a GHC bug:
http://www.haskell.org/ghc/reportabug
cabal: Error: some packages failed to install:
syb-0.3.6 failed during the configure step. The exception was:
ExitFailure 6
}}}
--
Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/5899#comment:15
GHC http://www.haskell.org/ghc/
The Glasgow Haskell Compiler
___
Glasgow-haskell-bugs mailing list
Glasgow-haskell-bugs@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
Re: [GHC] #5899: RTS crash w/ strange closure type 603975781 on OS X 10.8 (was: GHC RTS crash w/ strange closure type 603975781 on OS X 10.8)
#5899: RTS crash w/ strange closure type 603975781 on OS X 10.8 ---+ Reporter: dylukes | Owner: Type: bug | Status: new Priority: highest | Milestone: 7.4.2 Component: Runtime System | Version: 7.4.1 Keywords: rts, strange closure, internal error, os x | Os: MacOS X Architecture: x86_64 (amd64) | Failure: Runtime crash Difficulty: Unknown |Testcase: Blockedby: |Blocking: Related: | ---+ Comment(by dylukes): More information and some clarifications: - I can confirm updating to 10.8 DP2, or Xcode 4.4 DP2 do not fix it. Individually or together. - This manifests in the x86_64 AND i386 architectures. - There is an existing issue with binaries compiled on 10.8 not running on 10.7 or previous. This has been reported to Apple, and is mirrored here: http://openradar.appspot.com/11022559 -- Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/5899#comment:12 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler ___ Glasgow-haskell-bugs mailing list Glasgow-haskell-bugs@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
