FreeBSD/amd64 port: more progress

[Ian Lynagh]

On Thu, Mar 15, 2007 at 11:13:02AM -0400, Gregory Wright wrote:
> 
> #6  0x000000000159e439 in allocatePinned (n=34359738372) at Storage.c: 
> 593
> #7  0x00000000015a1376 in newPinnedByteArrayzh_fast ()
> #8  0x000000000159d3e2 in StgRun (f=0x15a1330  
> <newPinnedByteArrayzh_fast>,
>     basereg=0x3a2) at StgCRun.c:93
> #9  0x00000000015990f3 in schedule (mainThread=0x2164080,
>     initialCapability=0x3a2) at Schedule.c:932
> 
> 
> Looks like someone is asking for too much memory (n=34359738372)!
> 
> I've taken a cursory look at this, but I wanted to send a note in  
> case you
> know what is wrong off the top of your head.
> 
> I'll be away next week so I won't be able to easily test things on my  
> amd64 box.
> I will be able to look at code, if you can point me to the right  
> places.  (Should I be
> looking at 6.4.2/6.6 differences in Storage.c or Schedule.c?)

Schedule.c doesn't look like the problem. What's happening is the
scheduler (Schedule.c) is running some Haskell code (StgRun, which
calls Haskell code in a loop) and the "Haskell" code it is calling now
is the newPinnedByteArray# primop, defined in PrimOps.cmm.
newPinnedByteArray# is then calling the RTS allocation functions.

OK, this is while running the stage1 GHC, right? So we have the 6.6
Haskell code linked with the 6.4.2 RTS. At first glance it doesn't look
as if the appropriate bits of the RTS have changed significantly,
though.

34359738372 = 2^35 + 4, so it seems likely someone is really trying to
ask for 4 words and something goes wrong somewhere.

I think the first thing to do is to see if newPinnedByteArrayzh_fast is
being passed plausible values. The easiest way is probably to set a
breakpoint in gdb on newPinnedByteArrayzh_fast (Having
"GhcRtsHcOpts += -keep-hc-files" in mk/build.mk will probably help so
you can look at PrimOps.hc; unfortunately we don't seem to set hcsuf -
we probably should. You might also want to check that the RTS wasn't
compiled with optimisation on. Note that this is in the 6.4 tree, not
the 6.6 one!)

If you do make any changes to the RTS code or compilation options then
you'll have to run make and make install in 6.4.2's rts/, then delete
6.6-branch's compiler/stage1/ghc-6.6* and run make stage=1 in compiler/.

If the problem isn't the first time that newPinnedByteArrayzh_fast is
called then see the "Going back in time" section of
http://hackage.haskell.org/trac/ghc/wiki/DebuggingGhcCrashes
for how to get to the right one easily.

If the right value comes in at the start of newPinnedByteArrayzh_fast
then stepping through with gdb and printing all the intermediate values
should show where it goes wrong. If the wrong value goes in then you'll
have to try and work out where it came from. The +RTS -Di flag (I think:
the one for the interpreter) will show you what Haskell functions are
being called, which may help.


Thanks
Ian