#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
[email protected]
http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
