[slightly OT] ghc-6.6.1 on OpenBSD/i386: internal error (Storage.c)
Hi, I'm currently working on updating the GHC port to 6.6.1 for OpenBSD, and when I run the testsuite (ghc-regress), all test cases for the way "threaded1", i.e. debug + threaded bail out with an assertion failure: Blocks: 132 live + 123 free = 255 total (508 around) conc010: internal error: ASSERTION FAILED: file Storage.c, line 1174 The numbers vary slightly, but there's always a total of 255 and 508 blocks around, except for one test case (con012), where there are a total of 763 blocks (1016 around). 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. Ciao, Kili -- CRM114 isn't ugly like PERL. It's a whole different kind of ugly. -- John Bowker
Matthias Kilian wrote:
I'm currently working on updating the GHC port to 6.6.1 for OpenBSD, and when I run the testsuite (ghc-regress), all test cases for the way "threaded1", i.e. debug + threaded bail out with an assertion failure:
Blocks: 132 live + 123 free = 255 total (508 around) conc010: internal error: ASSERTION FAILED: file Storage.c, line 1174
The numbers vary slightly, but there's always a total of 255 and 508 blocks around, except for one test case (con012), where there are a total of 763 blocks (1016 around).
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. Cheers, Simon
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
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
participants (2)
-
Matthias Kilian -
Simon Marlow