Hi Ian,
I have made some more progress on understanding the build
failure on FreeBSD/amd64. I could use a check on my understanding
of the problem, though.
The setup: I have an unregisterized ghc-6.4.2 successfully built
on FreeBSD/amd64. It was bootstrapped from .hc files compiled
on FreeBSD/i386. I am attempting to use this compiler (the ghc-inplace
from the unregisterized build, not a fully installed compiler) to
build a recent ghc-6.6 branch from darcs (20070314).
The build of ghc-6.6-20070314 fails when compiling rts/Linker.c.
The failure is mostly reproducible (more about that below).
It's also worth remembering that when I tried to build an unregisterized
ghc-6.6 on FreeBSD/amd64 using .hc files from ghc-6.6 built on
FreeBSD/i386,
I had a crash at the same place, while trying to build rts/Linker.c
The failure comes from trying to allocate a huge amount of memory.
newPinnedByteArrayzh_fast is called with a giant argument, 0x4000000010.
So it looks like we're after 16 bytes, but the upper 32 bits has some
junk in it.
The above was the state of things just over a week ago. Since then,
I've worked to track down whether the bug is in the ghc-6.4.2 runtime
or in the ghc-6.6 code. The compiler that fails is the 6.6 stage1
compiler, which is a 6.6 compiler linked with the runtime from the
unregisterized 6.4.2 (let me know if I'm wrong about that).
I have rebuilt the unregisterized 6.4.2 with optimization turned off.
I haven't got any more information this way; it seems the problem is
really on the 6.6 side. Here is my reasoning:
I run the 6.6 compiler under the debugger:
greenhouse-george> gdb /tmp/ghc/compiler/stage1/ghc-6.6.20070314
GNU gdb 6.1.1 [FreeBSD]
Copyright 2004 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public License, and
you are
welcome to change it and/or distribute copies of it under certain
conditions.
Type "show copying" to see the conditions.
There is absolutely no warranty for GDB. Type "show warranty" for
details.
This GDB was configured as "amd64-marcel-freebsd"...
(gdb) dir /tmp/ghc-6.4.2/ghc/rts
Source directories searched: /tmp/ghc-6.4.2/ghc/rts:$cdir:$cwd
(gdb) b newPinnedByteArrayzh_fast
Breakpoint 1 at 0x163cbb4
(gdb) run -B/tmp/ghc -v -optc-O -optc-Wall -optc-W -optc-Wstrict-
prototypes -optc-Wmissing-prototypes -optc-Wmissing-declarations -
optc-Winline -optc-Waggregate-return -optc-Wbad-function-cast -optc-
I../includes -optc-I. -optc-Iparallel -optc-DCOMPILING_RTS -optc-
fomit-frame-pointer -optc-I/usr/local/include -optc-fno-strict-
aliasing -H16m -O -optc-O2 -static -I/usr/local/include -I. -#include
HCIncludes.h -fvia-C -dcmm-lint -c Linker.c -o Linker.o
Starting program: /tmp/ghc/compiler/stage1/ghc-6.6.20070314 -B/tmp/
ghc -v -optc-O -optc-Wall -optc-W -optc-Wstrict-prototypes -optc-
Wmissing-prototypes -optc-Wmissing-declarations -optc-Winline -optc-
Waggregate-return -optc-Wbad-function-cast -optc-I../includes -optc-
I. -optc-Iparallel -optc-DCOMPILING_RTS -optc-fomit-frame-pointer -
optc-I/usr/local/include -optc-fno-strict-aliasing -H16m -O -optc-O2 -
static -I/usr/local/include -I. -#include HCIncludes.h -fvia-C -dcmm-
lint -c Linker.c -o Linker.o
Breakpoint 1, 0x000000000163cbb4 in newPinnedByteArrayzh_fast ()
By playing around with it, I have isolated --- more or less --- when the
failure occurs. In this run, it was after 973 calls to
newPinnedByteArrayzh_fast.
If I quit gdb and re-run it, the number of calls is consistently the
same.
However, from one system boot to the next, it varies a bit.
Yesterday morning,
I had to skip 976 calls.
(gdb) c 973
Will ignore next 972 crossings of breakpoint 1. Continuing.
Glasgow Haskell Compiler, Version 6.6.20070314, for Haskell 98,
compiled by GHC version 6.4.2
Using package config file: /tmp/ghc/driver/package.conf.inplace
wired-in package base not found.
wired-in package rts mapped to rts-1.0
wired-in package haskell98 not found.
wired-in package template-haskell not found.
Hsc static flags: -static -static
Created temporary directory: /tmp/ghc1073_0
*** C Compiler:
gcc -x c Linker.c -o /tmp/ghc1073_0/ghc1073_0.s -v -S -Wimplicit -O -
D__GLASGOW_HASKELL__=606 -O -Wall -W -Wstrict-prototypes -Wmissing-
prototypes -Wmissing-declarations -Winline -Waggregate-return -Wbad-
function-cast -I../includes -I. -Iparallel -DCOMPILING_RTS -fomit-
frame-pointer -I/usr/local/include -fno-strict-aliasing -O2 -I /usr/
local/include -I . -I /tmp/ghc/includes -fwrapv
Breakpoint 1, 0x000000000163cbb4 in newPinnedByteArrayzh_fast ()
OK, I should be at the call which is going to blow up:
(gdb) bt
#0 0x000000000163cbb4 in newPinnedByteArrayzh_fast ()
#1 0x00000000016377ea in StgRun (f=0x163cbb0
<newPinnedByteArrayzh_fast>,
basereg=0x260fcd0) at StgCRun.c:93
#2 0x0000000001631f48 in schedule (mainThread=0x2611080,
initialCapability=0x0) at Schedule.c:932
#3 0x0000000001633190 in waitThread_ (m=0x2611080,
initialCapability=0x0)
at Schedule.c:2156
#4 0x0000000001633085 in scheduleWaitThread (tso=0x8021c0000, ret=0x0,
initialCapability=0x0) at Schedule.c:2050
#5 0x000000000162d60f in rts_evalLazyIO (p=0x1d409d0, ret=0x0) at
RtsAPI.c:459
#6 0x000000000162ca24 in main (argc=33, argv=0x7fffffffe960) at
Main.c:104
(gdb) f 1
#1 0x00000000016377ea in StgRun (f=0x163cbb0
<newPinnedByteArrayzh_fast>,
basereg=0x260fcd0) at StgCRun.c:93
93 f = (StgFunPtr) (f)();
Since the 6.4.2 runtime is unregisterized, the parameter are passed
through the virtual, not actual registers (is this correct?). The
code for newPinnedByteArrayzh_fast says that the requested number of
bytes
is passed in through R1, so take a look:
(gdb) p basereg->rR1
$1 = {w = 274877906960, a = 0x4000000010, c = 16, i8 = 16 '\020',
f = 2.24207754e-44, i = 274877906960, p = 0x4000000010, cl =
0x4000000010,
offset = 274877906960,
b = 0x4000000010 <Error reading address 0x4000000010: Bad address>,
t = 0x4000000010}
This request should certainly wedge the system by gobbling up all of the
memory. The question now is what put the bad value into R1? It seems
as if newPinnedByteArrayzh_fast is just getting too big a request. I
looked
at the assembly code for newPinnedByteArrayzh_fast, and the arguments
passed down to the functions it calls are calculated correctly, but are
just too big.
I also tried setting the breakpoint one call earlier (972 instead of
973),
and then stepping through until I reached the next breakpoint.
newPinnedByteArrayzh_fast calls allocatePinned successfully and control
come back to StgCRun.c at line 87. This is the miniinterpreter loop.
If I keep stepping control just stays in the miniinterpreter loop until
newPinnedByteArrayzh_fast is called again. (I used the gdb "until"
command
to run the loop until it either finished or hit a breakpoint. It hit
the
breakpoint.)
This leads me to believe that the problem is in the haskell code, not
the
C code of the runtime system.
Looking at the RTS stack,
(gdb) pmem basereg->rSp 32
0x802dfe808: 0x0
0x802dfe800: 0x0
0x802dfe7f8: 0x2216f80 <stg_stop_thread_info>
0x802dfe7f0: 0x2217000 <stg_noforceIO_info>
0x802dfe7e8: 0x2149b90 <GHCziConc_childHandler_closure>
0x802dfe7e0: 0x0
0x802dfe7d8: 0x2214b60 <stg_catch_frame_info>
0x802dfe7d0: 0x2214b20 <stg_unblockAsyncExceptionszh_ret_info>
0x802dfe7c8: 0x802a121b0
0x802dfe7c0: 0x1d61f60 <s99O_info>
0x802dfe7b8: 0x802a15848
0x802dfe7b0: 0x1
0x802dfe7a8: 0x2214b60 <stg_catch_frame_info>
0x802dfe7a0: 0x2214b40 <stg_blockAsyncExceptionszh_ret_info>
0x802dfe798: 0x22179e0 <stg_ap_v_info>
0x802dfe790: 0x802a17af0
0x802dfe788: 0x802a17b08
0x802dfe780: 0x802a121b0
0x802dfe778: 0x802a15870
0x802dfe770: 0x1d61a40 <s99v_info>
0x802dfe768: 0x217aef0 <s6Z8_info>
0x802dfe760: 0x802a17b88
0x802dfe758: 0x802d04e98
0x802dfe750: 0x2125f40 <s3eo_info>
0x802dfe748: 0x802a18970
0x802dfe740: 0x802a17b08
0x802dfe738: 0x802a17b78
0x802dfe730: 0x1d61620 <r37t_closure>
0x802dfe728: 0x400000000
0x802dfe720: 0x802d04ed0
0x802dfe718: 0x400000000
0x802dfe710: 0x220db80 <s31b_info>
(gdb)
I'm guessing that the culpable module defines the symbol "s31b". I
added -ddump-stg
to the options for the 6.6 build. (In fact, deleted everything,
added the -ddump-stg option,
rebuilt and did the run under the debugger shown above, to make
certain that everything
was consistent.) The symbol "s31b" is from the module
GHC.Compat.Unicode.
This may be getting somewhere. Compat.Unicode does not exist in
6.4.2, which
may explain why the unregisterized 6.4.2 is quite reliable --- I used
it to build alex
and happy with no trouble. Also, the Unicode module makes foreign
calls to C library
functions. FreeBSD has its own implementation of libc, not the same
as linux, which
may explain why FreeBSD/amd64 chokes and Linux/amd64 works.
So. I am asking if this argument makes sense, especially my
interpretation of
the RTS stack dump. Any suggestions are appreciated.
Best Wishes,
Greg
