I just built ghc from HEAD on OS X (ppc), and get the following error
when starting ghci:
---start
[15:15:[EMAIL PROTECTED] 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@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
