I just built ghc from HEAD on OS X (ppc), and get the following error when starting ghci: ---start [15:15:15][david@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.
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@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@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
On 1/15/07, David Kirkman
The comment above seems to be begging for a
oc->image += oc->misalignment;
statement right after the call to stgMallocBytes.
This did in fact work (patch for rts/Linker.c below). And it *was* in the 6.6 sources, so it was removed in the last few months. Putting the line back in seems to fix everything on ppc darwin: my code which uses "ghc as a library" to do a bunch of dynamic compilation and loading works again, and the test suite looks pretty much like the results from the latest linux builds (http://www.haskell.org/ghc/dist/current/logs/x86_64-unknown-linux-test-summa...) I can only get a partial darcs repository, so I can't figure out why the line was removed -- presumably to fix something that my patch will proceed to rebreak :) Cheers, -david k. The is the testsuite summary after applying the Linker.c patch, followed by the patch. Before the patch, *every* ghci test is a failure. OVERALL SUMMARY for test run started at Mon Jan 15 14:44:24 PST 2007 1606 total tests, which gave rise to 6403 test cases, of which 0 caused framework failures 1068 were skipped 5089 expected passes 67 expected failures 2 unexpected passes 177 unexpected failures Unexpected passes: barton-mangler-bug(optasm) cholewo-eval(optasm) Unexpected failures: GMapAssoc(hpc) GMapTop(hpc) TH_dataD1(normal) TH_spliceE5_prof(normal) ThreadDelay001(ghci,threaded1,threaded2) arith005(opt,hpc,optasm,threaded2) arith011(normal,opt,hpc,optasm,ghci,threaded1,threaded2) arrowrun004(normal,opt,hpc,optasm,ghci,threaded1,threaded2) break001(ghci) break004(ghci) break005(ghci) break007(ghci) break008(ghci) break010(ghci) cabal01(normal) cabal02(normal) cg047(normal) conc019(opt) conc023(threaded2) conc037(threaded2) conc056(threaded1,threaded2) conc059(threaded1) conc063(normal,opt,hpc,optasm,ghci,threaded1,threaded2) conc064(normal,opt,hpc,optasm,ghci,threaded1,threaded2) conc065(ghci) conc066(ghci) concprog001(ghci) concprog002(threaded2) driver011(normal) driver012(normal) driver013(normal) driver014(normal) driver015(normal) driver016(normal) driver017(normal) driver018(normal) driver021(normal) driver022(normal) driver023(normal) driver024(normal) driver024a(normal) driver025(normal) driver026(normal) driver027(normal) driver028(normal) driver031(normal) driver032(normal) driver033(normal) driver034(normal) driver035(normal) driver041(normal) driver042(normal) driver043(normal) driver044(normal) driver045(normal) driver051(normal) driver052(normal) driver053(normal) driver060(normal) driver061(normal) driver062.1(normal) driver062.2(normal) driver062.3(normal) driver064(normal) driver065(normal) driver066(normal) driver067(normal) driver068(normal) driver069(normal) driver070(normal) driver071(normal) driver080(normal) driver200(normal) drvfail011(normal) dynbk002(ghci) dynbk008(ghci) ffi-deriv1(normal,opt,hpc,optasm) ffi009(ghci) forkprocess01(ghci) gadt17(normal) getC(normal,opt,hpc,optasm,ghci,threaded1,threaded2) ghci008(ghci) ghciprog004(normal) ghcpkg01(normal) ghcpkg02(normal) ghcpkg03(normal) ghcpkg04(normal) maessen_hashtab(normal,opt,hpc,optasm,ghci,threaded1,threaded2) mod56(normal) newtype(opt) num012(normal,opt,hpc,optasm,ghci,threaded1,threaded2) print001(ghci) print004(ghci) print005(ghci) print006(ghci) print007(ghci) print012(ghci) print016(ghci) read040(normal,opt,hpc,optasm) rnfail028(normal) signals002(ghci) tc049(normal,opt,hpc,optasm) tc173(normal) tcfail004(normal) tcfail005(normal) tcfail072(normal) tcfail105(normal,opt,hpc,optasm) tcfail140(normal) tcfail169(normal) tcfail172(normal) tcrun032(normal,opt,hpc,optasm,ghci,threaded1,threaded2) --- Linker-old-c 2007-01-15 12:46:29.000000000 -0800 +++ Linker.c 2007-01-15 20:06:37.000000000 -0800 @@ -1324,6 +1324,7 @@ // that the actual sections end up aligned again. oc->misalignment = machoGetMisalignment(f); oc->image = stgMallocBytes(oc->fileSize + oc->misalignment, "loadObj(image)"); + oc->image += oc->misalignment; # else oc->image = stgMallocBytes(oc->fileSize, "loadObj(image)"); # endif
Argh ... gmail totally mangled that patch. (The line that starts with "loadObj(image)" needs to be part of the previous line). I've put an unmangled version online at http://cass166.ucsd.edu/~david/link-patch
On Tue, Jan 16, 2007 at 02:19:46PM -0800, David Kirkman wrote:
Applied, thanks! Ian
participants (3)
-
David Kirkman -
Ian Lynagh -
Thorkil Naur