traverse print [1..] overflows the stack

[Gurkenglas]

This ought to take constant space, as it does in Haskell.

Exception in thread "main" java.lang.StackOverflowError
    at java.util.concurrent.ConcurrentSkipListMap.cpr(ConcurrentSkipListMap.java:655)
    at java.util.concurrent.ConcurrentSkipListMap.findPredecessor(ConcurrentSkipListMap.java:682)
    at java.util.concurrent.ConcurrentSkipListMap.findNear(ConcurrentSkipListMap.java:1234)
    at java.util.concurrent.ConcurrentSkipListMap.getNear(ConcurrentSkipListMap.java:1268)
    at java.util.concurrent.ConcurrentSkipListMap.floorEntry(ConcurrentSkipListMap.java:2153)
    at eta.runtime.io.MemoryManager.findLowerAllocatedAddress(MemoryManager.java:600)
    at eta.runtime.io.MemoryManager.findAllocatedAddress(MemoryManager.java:611)
    at eta.runtime.io.MemoryManager.getBoundedBuffer(MemoryManager.java:627)
    at eta.base.Utils.c_write(Utils.java:112)
    at base.ghc.io.FD$a8_sFIVL.applyV(FD.hs:468)
    at base.foreign.c.Error$throwErrnoIfMinus1RetryMayBlock2.enter(Error.hs:342)
    at base.ghc.io.FD$$wa1.enter(FD.hs:464)
    at base.ghc.io.FD$$fBufferedIO_FD_$s$wa.enter(FD.hs:373)
    at base.ghc.io.FD$$fBufferedIO_FD5.apply2V(FD.hs:91)
    at base.ghc.io.handle.Text$sat_sGI4P.apply1V(Text.hs:605)
    at base.ghc.io.handle.Internals$sat_sFZZ8G.apply1V(Internals.hs:255)
    at eta.runtime.apply.PAP1_1.applyV(PAP1_1.java:16)
    at eta.runtime.thunk.Thunk.applyV(Thunk.java:125)
    at eta.runtime.exception.Exception.catch_(Exception.java:129)
    at base.ghc.io.handle.Internals$$wa2.enter(Internals.hs:166)
    at base.ghc.io.handle.Internals$a3_sFYZZI.applyV(Internals.hs:132)
    at eta.runtime.exception.Exception.maskAsyncExceptions(Exception.java:42)
    at base.ghc.io.handle.Internals$$wa4.enter(Internals.hs:130)
    at base.ghc.io.handle.Internals$$wa3.enter(Internals.hs:236)
    at base.ghc.io.handle.Internals$wantWritableHandle1.apply3V(Internals.hs:226)
    at base.ghc.io.handle.Text$$wa7.enter(Text.hs:630)
    at base.ghc.io.handle.Text$hPutStr2.apply3V(Text.hs:553)
    at main.Main$main2.apply2V(Main.hs:6)
    at eta.runtime.apply.PAPSlow.apply(PAPSlow.java:62)
    at eta.runtime.apply.PAPSlow.applyV(PAPSlow.java:110)
    at eta.runtime.thunk.Thunk.applyV(Thunk.java:125)
        [...]
    at main.Main$main2.apply2V(Main.hs:6)
    at eta.runtime.apply.PAPSlow.apply(PAPSlow.java:62)
    at eta.runtime.apply.PAPSlow.applyV(PAPSlow.java:110)
    at eta.runtime.thunk.Thunk.applyV(Thunk.java:125)

[rahulmutt]

Yes, indeed. This stack trace pattern looks like something that can be optimized with #442. That should be implemented within the next couple of weeks.

Closing because that issue can solve this. I'll verify that this problem is fixed once I implement #442 and re-open it if it isn't.

[Gurkenglas]

The referenced issue is closed, any updates?

[rahulmutt]

This needs to be checked out. We now have a function called trampolineIO :: IO a -> IO a which avoids stack blowouts. In this case it did not help and we need to look into why.