On 18 November 2005 10:48, Joel Reymont wrote:
> On Nov 18, 2005, at 10:17 AM, Simon Peyton-Jones wrote:
>
>> I hope you don't abandon Haskell altogether. Without steady,
>> friendly pressure from applications-end folk like you, things won't
>> improve.
>
> Nah, I'm just having a very frustrating Friday. I think I need some
> direction in which to dig and a bit of patience over the weekend. For
> example,
>
> What does this mean precisely? My take is that the GHC runtime is
> trying to call a C function. this much I gathered from the source
> code. It also seems that since I do not see another library at #0
> then the issue is within GHC. Is that the right take on it?
The stack trace doesn't mean much at all I'm afraid - GHC doesn't use
the C stack, so any stack trace generated for a crash inside the Haskell
code is mostly useless. It does tell you the block in which the crash
happened (s8j1_info), and it tells you that the crash was in Haskell and
not C. The rest of the frames on the stack are from the GHC runtime,
and you'll pretty much always see these same frames on the stack for any
crash inside Haskell code.
How we normally proceed for a crash like this is as follows: examine
where the crash happened and determine whether it is a result of heap or
stack corruption, and then attempt to trace backwards to find out where
the corruption originated from. Tracing backwards means running the
program from the beginning again, so it's essential to have a
reproducible example. Without reproducibility, we have to use a
combination of debugging printfs and staring really hard at the code,
which is much more time consuming (and still requires being able to run
the program to make it crash with debugging output turned on).
You can get debugging output by compiling your program with -debug, and
then running it with some of the -D<something> options (use +RTS -? for
a list, +RTS -Ds is a good one to start with).
Cheers,
Simon
