HEAD ghci crash on ppc OS X

[Thorkil Naur]

Hello,

I get a similar reaction starting ghci built from a ghc-HEAD pulled 
2007-Jan-12 on a PPC Mac OS X 10.4.

Best regards
Thorkil
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:
> 
> ---start
> [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:  
> ocAllocateJumpIslands
> ---end
> 
> 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:
> 
> --start
> 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
> (gdb)
> --end
> 
> 
> 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) *  
> count,
>                                   "ocAllocateJumpIslands" );
>      oc->image += misalignment;
> --end
> 
> 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,  
> "loadObj(image)");
> #  else
> ---end
> 
> 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
> oc->image.
> 
> 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
> http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
>