[Haskell-cafe] Diagnose stack space overflow

[Daniel Fischer]

On Friday 08 July 2011, 11:29:40, Ketil Malde wrote:
> Max Bolingbroke <batterseapower at hotmail.com> writes:
> >> Stack space overflow: current size 8388608 bytes.
> >> Use `+RTS -Ksize -RTS' to increase it.
> >> 
> >> I want to find out the culprit function and rewrite it
> >> tail-recursively. Is there a way to find out which function is
> >> causing this error other than reviewing the code manually?
> > 
> > It's possible that building your program with profiling and then
> > running with "+RTS -xc" will print a useful call stack.
> 
> Does this help, really?  I've tried that occasionally, but can't really
> say it's ever helped pinpoint the problem.  (Not complaining, stack
> traces are hard in Haskell.)

It can help. I recently had a stack overflow in some code with ghc-7 (which 
worked fine in ghc-6) which was a pain to locate.
I had forgotten about the -xc way and when (after the fact) I read Max' 
post, I reverted the fix and tried that.
And, hey presto, the printed call stack, although not incredibly 
informative, revealed the function in which the overflow occurred.
It would have been faster to pinpoint with -xc.

> 
> I generally heap-profile (often with the -hd option), most stack
> overflows will also retain heap data (i.e. a stack of (+) operations
> will point to all the numbers as well), which should give you an idea of
> where to look.

The abovementioned didn't reveal anything in the heap profiles, apart from 
the data that should have been there (in the correct amounts), there were 
only TSOs and BLACKHOLE in the profiles, not attributed to anything 
(despite ample SCC pragmas).


I have little experience with stack overflows, so I can't tell whether heap 
profiling is generally more informative than the stack trace to find them 
or not, it's certainly reasonable to expect that often retained data will 
show you where to look, but it doesn't always do it.
One should be aware of both ways, where the first one tried doesn't help, 
the other one may.

Cheers,
Daniel