Matthias Kilian wrote:
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.
Nice catch. Looks to me like initAdjustor() can be moved after initStorage().
Please test the fix, if it works for you then send us the patch and we'll
commit. You've been wasting 1Mb in every single executable on OpenBSD!
In fact, I'm not even sure why OpenBSD needs that code, and it isn't commented.
You might like to try removing obscure_ccall_ret_code_dyn and associated cruft
and see what happens (i.e. try the ccall/should_run tests).
Cheers,
Simon
_______________________________________________
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
