HEAD ghci crash on ppc OS X
naur at post11.tele.dk
Tue Jan 16 00:57:43 EST 2007
I get a similar reaction starting ghci built from a ghc-HEAD pulled
2007-Jan-12 on a PPC Mac OS X 10.4.
On Tuesday 16 January 2007 03:03, David Kirkman wrote:
> I just built ghc from HEAD on OS X (ppc), and get the following error
> when starting ghci:
> [15:15:15][david at isengard]$ compiler/stage2/ghc-inplace --interactive
> ___ ___ _
> / _ \ /\ /\/ __(_)
> / /_\// /_/ / / | | GHC Interactive, version 6.7, for Haskell 98.
> / /_\\/ __ / /___| | http://www.haskell.org/ghc/
> \____/\/ /_/\____/|_| Type :? for help.
> ghc-6.7(9972,0xa000ed88) malloc: *** error for object 0x3807ff8:
> pointer being reallocated was not allocated
> ghc-6.7(9972,0xa000ed88) malloc: *** set a breakpoint in szone_error
> to debug
> malloc: failed on request for 11359964 bytes; message:
> despite the suggestion, a breakpoint in szone_error catches nothing.
> But a breakpoint in malloc_printf (both szone_error and malloc_printf
> in the OS, not ghc) gives the following backtrace for an rts compiled
> with the -g flag:
> Breakpoint 1, 0x9012bb94 in malloc_printf ()
> (gdb) bt
> #0 0x9012bb94 in malloc_printf ()
> #1 0x90018388 in szone_realloc ()
> #2 0x90018098 in realloc ()
> #3 0x00e6f5c4 in stgReallocBytes (p=0x901a4df4, n=11359964,
> msg=0xfd9704 "ocAllocateJumpIslands") at RtsUtils.c:209
> #4 0x00e97cbc in ocAllocateJumpIslands (oc=0x2b005d0, count=372,
> first=14502) at Linker.c:1598
> #5 0x00e98954 in loadObj (path=0x2e63268 "/Network/Sid/Users/david/
> ghc-crap/ghc/libraries/base/HSbase.o") at Linker.c:3743
> #6 0x005b660c in s1wt_info ()
> #7 0x00e8a220 in schedule (initialCapability=0x901a4df4,
> task=0x2e63268) at Schedule.c:608
> #8 0x00c60e18 in main (argc=-1877324300, argv=0x3807ff8) at Main.c:105
> The call to failing call to stgReallocBytes occurs at line 1598 of
> Linker.c, in the following context:
> --start Linker.c, lines 1597 --> 1602
> oc->image -= misalignment;
> oc->image = stgReallocBytes( oc->image,
> misalignment +
> aligned + sizeof (ppcJumpIsland) *
> "ocAllocateJumpIslands" );
> oc->image += misalignment;
> oc->image is allocated at line 1326 of Linker.c (listing below), and
> then never modified until misalignment is subtracted from it at line
> 1598. Both the comment in the code fragment below, and the actual
> code in the fragment above seem to indicate that oc->image should be
> offset by misalignment.
> --start Linker.c, lines 1315 --> 1327
> # elif defined(darwin_HOST_OS)
> // In a Mach-O .o file, all sections can and will be misaligned
> // if the total size of the headers is not a multiple of the
> // desired alignment. This is fine for .o files that only serve
> // as input for the static linker, but it's not fine for us,
> // as SSE (used by gcc for floating point) and Altivec require
> // 16-byte alignment.
> // We calculate the correct alignment from the header before
> // reading the file, and then we misalign oc->image on purpose so
> // that the actual sections end up aligned again.
> oc->misalignment = machoGetMisalignment(f);
> oc->image = stgMallocBytes(oc->fileSize + oc->misalignment,
> # else
> The comment above seems to be begging for a
> oc->image += oc->misalignment;
> statement right after the call to stgMallocBytes. But I'm assuming it
> must normally be done someplace else -- I just can't figure out where.
> Anyway, I've verified that os->image is still pointing to the value
> returned from stgMallocBytes when misalignment (non-zero) is
> subtracted from it just before the call to stgReallocBytes. So in
> my build at least, the execution path is not hitting whatever part
> of the code that should be applying the misalignment offset to
> Let me know if there is any more information I can give.
> -david k.
> Glasgow-haskell-users mailing list
> Glasgow-haskell-users at haskell.org
More information about the Glasgow-haskell-users