Stack overflow weirdness
While tuning some code, the test programme suddenly started producing stack overflows. Reverting the code to a previous version did not revert that behaviour, code that previously produced a well-behaved binary now produced stack overflowing ones. But only with ghc-7.0.1, not with ghc-6.12.3 and ghc-6.12.1, and when compiled with optimisations (both, -O and -O2) and without profiling. A HEAD from October and a freshly darcs pulled HEAD displayed the same behaviour as 7.0.1. At some point I tried compiling with -fno-strictness (+ -O or -O2) which again produced well-behaved albeit somewhat slower binaries. An hour or so later, I again compile with -O2 without -fno-strictness to see whether the Core revealed something and, as suddenly as the stack overflows started, they disappeared, for the time being, I consistently get well-behaved binaries. A run of an overflowing binary with -hT -K32M produced a triangular graph with > 10MB Blackhole allocation and > 30MB TSO allocation in the peak. Obviously the behaviour is not reproducible, nevertheless, perhaps somebody has an idea what went on. Or should I attribute it to cosmic rays? Cheers, Daniel
On 27/01/2011 11:45, Daniel Fischer wrote:
While tuning some code, the test programme suddenly started producing stack overflows. Reverting the code to a previous version did not revert that behaviour, code that previously produced a well-behaved binary now produced stack overflowing ones. But only with ghc-7.0.1, not with ghc-6.12.3 and ghc-6.12.1, and when compiled with optimisations (both, -O and -O2) and without profiling. A HEAD from October and a freshly darcs pulled HEAD displayed the same behaviour as 7.0.1. At some point I tried compiling with -fno-strictness (+ -O or -O2) which again produced well-behaved albeit somewhat slower binaries. An hour or so later, I again compile with -O2 without -fno-strictness to see whether the Core revealed something and, as suddenly as the stack overflows started, they disappeared, for the time being, I consistently get well-behaved binaries.
A run of an overflowing binary with -hT -K32M produced a triangular graph with> 10MB Blackhole allocation and> 30MB TSO allocation in the peak.
Obviously the behaviour is not reproducible, nevertheless, perhaps somebody has an idea what went on. Or should I attribute it to cosmic rays?
I think you may have had an encounter with this bug: http://hackage.haskell.org/trac/ghc/ticket/4924 I reported it yesterday, and Simon has already fixed it. The fix will be in 7.0.2. Cheers, Simon
On Friday 28 January 2011 11:40:33, Simon Marlow wrote:
I think you may have had an encounter with this bug:
That seems not unlikely. the offending Main contained a couple of near- identical loops, and that bug doesn't reliably occur (I compiled your example Test module a few times with -O2 [ghc-7.0.1] and always got Str=DmdType U(L)U(L)m, for both, f and g).
I reported it yesterday, and Simon has already fixed it. The fix will be in 7.0.2.
Great. Cheers, Daniel
participants (2)
-
Daniel Fischer -
Simon Marlow