On Tue, May 29, 2007 at 04:15:29PM +0100, Simon Marlow wrote:
> >What puzzles me a little bit is the fact that this does *not* happen
> >on amd64 (aka x86_64) but only on i386 so far.
> >
> >So does this ring a bell for anyone? I didn't find anything similar
> >in the archives or in the bug tracker.
>
> No ringing bells here I'm afraid. What you're seeing is a failure from
> the code that checks for memory leaks, which is only enabled by -debug
> (the threaded1 test way uses -threaded -debug). It reckons you have 508
> blocks allocated from the OS, but can only account for 255 of them. You
> could try enabling some more debugging options, e.g. +RTS -DSb will enable
> sanity-checking and debugging messages from the block allocator.
This, and with some more debugging output and gdb sessions, helped.
The problem is that in hs_init(), initAdjustor() is called *before*
initStorage(). initAdjustor() is a NOOP everywhere except for
OpenBSD/i386, where it calls allocateExec(). Later in hs_init(),
when initStorage() is invoked, the free_list is reset, but
mblocks_allocated is still 1 => bummer.
Now my GHC knowledge is still very rusty (I didn't look at it for
years), so I really don't know wether that initAdjustor() is still
needed nor what it's good for, or if its invocation can be moved
after initStorage().
Any hint appreciated.
Ciao,
Kili
_______________________________________________
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
