Christian Maeder writes:

I've tried your code with ghc-6.6.1 under x86 linux with binary-0.3: http://hackage.haskell.org/cgi-bin/hackage-scripts/package/binary-0.3

It does terminate for me with and without profiling and/or optimization, when I pass in the source file itself as input:

$ ./foo < foo.hs

Is this a confirmation of your observation or am I (are we) doing something wrong?

I don't know what's supposed to happen if you pass it invalid input (such as the source file); for me it it seems to just eat up all available memory. However, I observed the stack overflow when actually passing in *valid* input,that is a tuple of two IntMaps previously serialized using Binary. If that helps I copied the input file I used here: http://computing.dcu.ie/~gchrupala/okok I'm running ghc-6.6.1 on linux fedora 6 on x86, binary-0.3 Best, -- Grzegorz

Christian Maeder schrieb:

$ ./foo < okok 58386 $ ghc --make -O2 -prof -auto-all foo.hs [1 of 1] Compiling Main ( foo.hs, foo.o ) Linking foo ... $ ./foo < okok Stack space overflow: current size 8388608 bytes. Use `+RTS -Ksize' to increase it.

But it goes through with increased stack space! $ ./foo < okok +RTS -K100m 58386 So this is quite normal behaviour. Profiling may need more stack space. C.

Grzegorz schrieb:

On 6/4/07, Christian Maeder wrote:

...

But it goes through with increased stack space!

$ ./foo < okok +RTS -K100m 58386

So this is quite normal behaviour. Profiling may need more stack space.

The question is why this simple program would need so much stack space. I thought that that mostly happend in Haskell with badly written recursive functions?

The file "okok" has 3816117 bytes and "-K11m" is sufficient ("-K10m" is not). That's just above the amount of stack size used without complaining (8388608 bytes) when profiling is switched off. C.

On Tue, Jun 05, 2007 at 12:13:46PM +0000, Grzegorz wrote:

I thought stack was for function frames and such...

Yes, but with lazy evaluation, even normal data are functions (closures). You probably have too much laziness somewhere; I'm sorry but I don't have the energy to go digging around in the code. -- Antti-Juhani Kaijanaho, Jyväskylä http://antti-juhani.kaijanaho.fi/newblog/

grzegorz.chrupala:

Antti-Juhani Kaijanaho writes:

...

On Tue, Jun 05, 2007 at 12:13:46PM +0000, Grzegorz wrote:

...

I thought stack was for function frames and such...

Yes, but with lazy evaluation, even normal data are functions (closures). You probably have too much laziness somewhere; I'm sorry but I don't have the energy to go digging around in the code.

I think so too, but it can't be in the three lines of code I posted so it's probably somewhere in one of the three libraries used, and hopefully someone familiar with the library code has the energy to dig and fix it ;-)

Can you submit a bug report -- if you believe it is a stack overflow issue in the Data.Binary source -- to the binary maintainers? If its a bug introduce by profiling, that's a known issue with profiling, and would qualify as a GHC bug. -- Don