[slightly OT] ghc-6.6.1 on OpenBSD/i386: internal error (Storage.c)

[Simon Marlow]

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