Hi Don, I find this answer confusing. The SO question you're linking to is about heap size, not stack overflow. The stack size in this example is 8M. The whole heap size may be much bigger (and increasing the stack size may actually remove the overflow). It would be interesting to learn about success stories of investigation of a stack overflow using heap profiling. * Don Stewart [2011-07-04 12:08:05-0400]

Profile!!

E.g.

http://stackoverflow.com/questions/6429085/haskell-heap-issues-with-paramete...

On Mon, Jul 4, 2011 at 11:44 AM, Logo Logo wrote:

...

Hi,

For the following error:

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?

-- Roman I. Cheplyaka :: http://ro-che.info/

On Friday 08 July 2011, 11:29:40, Ketil Malde wrote:

Max Bolingbroke 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