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