My validate has a few perf failures (below). Now I know that sampling heap size is inaccurate, but the evidence here is pretty strong. Also validate fell over completely in my 2GB VM when Haddock ran out of memory, I had to give it more memory to complete. Something has got worse recently - this wasn't happening a couple of weeks ago. Does anyone have any idea what might have caused this? Going back in time is difficult. Are these failures happening for other people? Let me suggest something that might help with these perf tests: running the program with +RTS -h -i0.01 will give a more accurate indication of peak residency, by running major GCs much more often. Also you get a heap profile. Cheers, Simon =====> haddock.base(normal) 2474 of 3806 [0, 1, 0] max_bytes_used value is too high: Expected max_bytes_used: 96022312 +/-10% Lower bound max_bytes_used: 86420080 Upper bound max_bytes_used: 105624544 Actual max_bytes_used: 113537216 peak_megabytes_allocated value is too high: Expected peak_megabytes_allocated: 274 +/-10% Lower bound peak_megabytes_allocated: 246 Upper bound peak_megabytes_allocated: 302 Actual peak_megabytes_allocated: 323 *** unexpected failure for haddock.base(normal) =====> haddock.Cabal(normal) 2475 of 3806 [0, 2, 0] =====> haddock.compiler(normal) 2476 of 3806 [0, 2, 0] peak_megabytes_allocated value is too high: Expected peak_megabytes_allocated: 1250 +/-10% Lower bound peak_megabytes_allocated: 1125 Upper bound peak_megabytes_allocated: 1375 Actual peak_megabytes_allocated: 1397 bytes allocated value is too high: Expected bytes allocated: 25990254632 +/-10% Lower bound bytes allocated: 23391229168 Upper bound bytes allocated: 28589280096 Actual bytes allocated: 28680445952 *** unexpected failure for haddock.compiler(normal) =====> T3064(normal) 2480 of 3806 [0, 3, 0] cd ./perf/compiler && '/home/smarlow/ghc/bindisttest/install dir/bin/ghc' -fforce-recomp -dno-debug-output -no-user-package-db -rtsopts -fno-ghci-history -c T3064.hs +RTS -V0 -tT3064.comp.stats --machine-readable -RTS >T3064.comp.stderr 2>&1 max_bytes_used value is too high: Expected max_bytes_used: 12000480 +/-20% Lower bound max_bytes_used: 9600384 Upper bound max_bytes_used: 14400576 Actual max_bytes_used: 15258696 peak_megabytes_allocated value is too high: Expected peak_megabytes_allocated: 30 +/-20% Lower bound peak_megabytes_allocated: 24 Upper bound peak_megabytes_allocated: 36 Actual peak_megabytes_allocated: 37 *** unexpected failure for T3064(normal)
It would be very helpful if someone felt able to do some space profiles of GHC itself, using 7.4, 7.6 and the new HEAD, to see whether residency (the amount of head in use at any moment) has increased. And if so, why. Any takers? Simon From: ghc-devs [mailto:ghc-devs-bounces@haskell.org] On Behalf Of Simon Marlow Sent: 01 October 2013 10:01 To: ghc-devs@haskell.org Subject: New space leak? My validate has a few perf failures (below). Now I know that sampling heap size is inaccurate, but the evidence here is pretty strong. Also validate fell over completely in my 2GB VM when Haddock ran out of memory, I had to give it more memory to complete. Something has got worse recently - this wasn't happening a couple of weeks ago. Does anyone have any idea what might have caused this? Going back in time is difficult. Are these failures happening for other people? Let me suggest something that might help with these perf tests: running the program with +RTS -h -i0.01 will give a more accurate indication of peak residency, by running major GCs much more often. Also you get a heap profile. Cheers, Simon =====> haddock.base(normal) 2474 of 3806 [0, 1, 0] max_bytes_used value is too high: Expected max_bytes_used: 96022312 +/-10% Lower bound max_bytes_used: 86420080 Upper bound max_bytes_used: 105624544 Actual max_bytes_used: 113537216 peak_megabytes_allocated value is too high: Expected peak_megabytes_allocated: 274 +/-10% Lower bound peak_megabytes_allocated: 246 Upper bound peak_megabytes_allocated: 302 Actual peak_megabytes_allocated: 323 *** unexpected failure for haddock.base(normal) =====> haddock.Cabal(normal) 2475 of 3806 [0, 2, 0] =====> haddock.compiler(normal) 2476 of 3806 [0, 2, 0] peak_megabytes_allocated value is too high: Expected peak_megabytes_allocated: 1250 +/-10% Lower bound peak_megabytes_allocated: 1125 Upper bound peak_megabytes_allocated: 1375 Actual peak_megabytes_allocated: 1397 bytes allocated value is too high: Expected bytes allocated: 25990254632 +/-10% Lower bound bytes allocated: 23391229168 Upper bound bytes allocated: 28589280096 Actual bytes allocated: 28680445952 *** unexpected failure for haddock.compiler(normal) =====> T3064(normal) 2480 of 3806 [0, 3, 0] cd ./perf/compiler && '/home/smarlow/ghc/bindisttest/install dir/bin/ghc' -fforce-recomp -dno-debug-output -no-user-package-db -rtsopts -fno-ghci-history -c T3064.hs +RTS -V0 -tT3064.comp.stats --machine-readable -RTS >T3064.comp.stderr 2>&1 max_bytes_used value is too high: Expected max_bytes_used: 12000480 +/-20% Lower bound max_bytes_used: 9600384 Upper bound max_bytes_used: 14400576 Actual max_bytes_used: 15258696 peak_megabytes_allocated value is too high: Expected peak_megabytes_allocated: 30 +/-20% Lower bound peak_megabytes_allocated: 24 Upper bound peak_megabytes_allocated: 36 Actual peak_megabytes_allocated: 37 *** unexpected failure for T3064(normal)
That would help, but since this regression is quite recent I'm hoping that someone will know what caused it. Did anyone notice when these failures first appeared? It is certainly not the patches I'm working on, because I see the same failures on two separate machines. Cheers, Simon On 01/10/13 11:05, Simon Peyton-Jones wrote:
It would be very helpful if someone felt able to do some space profiles of GHC itself, using 7.4, 7.6 and the new HEAD, to see whether residency (the amount of head in use at any moment) has increased. And if so, why.
Any takers?
Simon
*From:*ghc-devs [mailto:ghc-devs-bounces@haskell.org] *On Behalf Of *Simon Marlow *Sent:* 01 October 2013 10:01 *To:* ghc-devs@haskell.org *Subject:* New space leak?
My validate has a few perf failures (below). Now I know that sampling heap size is inaccurate, but the evidence here is pretty strong. Also validate fell over completely in my 2GB VM when Haddock ran out of memory, I had to give it more memory to complete. Something has got worse recently - this wasn't happening a couple of weeks ago.
Does anyone have any idea what might have caused this? Going back in time is difficult. Are these failures happening for other people?
Let me suggest something that might help with these perf tests: running the program with +RTS -h -i0.01 will give a more accurate indication of peak residency, by running major GCs much more often. Also you get a heap profile.
Cheers, Simon
=====> haddock.base(normal) 2474 of 3806 [0, 1, 0] max_bytes_used value is too high: Expected max_bytes_used: 96022312 +/-10% Lower bound max_bytes_used: 86420080 Upper bound max_bytes_used: 105624544 Actual max_bytes_used: 113537216 peak_megabytes_allocated value is too high: Expected peak_megabytes_allocated: 274 +/-10% Lower bound peak_megabytes_allocated: 246 Upper bound peak_megabytes_allocated: 302 Actual peak_megabytes_allocated: 323 *** unexpected failure for haddock.base(normal) =====> haddock.Cabal(normal) 2475 of 3806 [0, 2, 0] =====> haddock.compiler(normal) 2476 of 3806 [0, 2, 0] peak_megabytes_allocated value is too high: Expected peak_megabytes_allocated: 1250 +/-10% Lower bound peak_megabytes_allocated: 1125 Upper bound peak_megabytes_allocated: 1375 Actual peak_megabytes_allocated: 1397 bytes allocated value is too high: Expected bytes allocated: 25990254632 +/-10% Lower bound bytes allocated: 23391229168 Upper bound bytes allocated: 28589280096 Actual bytes allocated: 28680445952 *** unexpected failure for haddock.compiler(normal) =====> T3064(normal) 2480 of 3806 [0, 3, 0] cd ./perf/compiler && '/home/smarlow/ghc/bindisttest/install dir/bin/ghc' -fforce-recomp -dno-debug-output -no-user-package-db -rtsopts -fno-ghci-history -c T3064.hs +RTS -V0 -tT3064.comp.stats --machine-readable -RTS >T3064.comp.stderr 2>&1 max_bytes_used value is too high: Expected max_bytes_used: 12000480 +/-20% Lower bound max_bytes_used: 9600384 Upper bound max_bytes_used: 14400576 Actual max_bytes_used: 15258696 peak_megabytes_allocated value is too high: Expected peak_megabytes_allocated: 30 +/-20% Lower bound peak_megabytes_allocated: 24 Upper bound peak_megabytes_allocated: 36 Actual peak_megabytes_allocated: 37 *** unexpected failure for T3064(normal)
I know that the roles stuff made T3064 worse -- I adjusted the numbers then and it worked on the systems I tested (Linux and Mac, both 64-bit). It looks like other wibbles have happened since then, though. On Oct 1, 2013, at 6:19 AM, Simon Marlow wrote:
That would help, but since this regression is quite recent I'm hoping that someone will know what caused it. Did anyone notice when these failures first appeared? It is certainly not the patches I'm working on, because I see the same failures on two separate machines.
Cheers, Simon
On 01/10/13 11:05, Simon Peyton-Jones wrote:
It would be very helpful if someone felt able to do some space profiles of GHC itself, using 7.4, 7.6 and the new HEAD, to see whether residency (the amount of head in use at any moment) has increased. And if so, why.
Any takers?
Simon
*From:*ghc-devs [mailto:ghc-devs-bounces@haskell.org] *On Behalf Of *Simon Marlow *Sent:* 01 October 2013 10:01 *To:* ghc-devs@haskell.org *Subject:* New space leak?
My validate has a few perf failures (below). Now I know that sampling heap size is inaccurate, but the evidence here is pretty strong. Also validate fell over completely in my 2GB VM when Haddock ran out of memory, I had to give it more memory to complete. Something has got worse recently - this wasn't happening a couple of weeks ago.
Does anyone have any idea what might have caused this? Going back in time is difficult. Are these failures happening for other people?
Let me suggest something that might help with these perf tests: running the program with +RTS -h -i0.01 will give a more accurate indication of peak residency, by running major GCs much more often. Also you get a heap profile.
Cheers, Simon
=====> haddock.base(normal) 2474 of 3806 [0, 1, 0] max_bytes_used value is too high: Expected max_bytes_used: 96022312 +/-10% Lower bound max_bytes_used: 86420080 Upper bound max_bytes_used: 105624544 Actual max_bytes_used: 113537216 peak_megabytes_allocated value is too high: Expected peak_megabytes_allocated: 274 +/-10% Lower bound peak_megabytes_allocated: 246 Upper bound peak_megabytes_allocated: 302 Actual peak_megabytes_allocated: 323 *** unexpected failure for haddock.base(normal) =====> haddock.Cabal(normal) 2475 of 3806 [0, 2, 0] =====> haddock.compiler(normal) 2476 of 3806 [0, 2, 0] peak_megabytes_allocated value is too high: Expected peak_megabytes_allocated: 1250 +/-10% Lower bound peak_megabytes_allocated: 1125 Upper bound peak_megabytes_allocated: 1375 Actual peak_megabytes_allocated: 1397 bytes allocated value is too high: Expected bytes allocated: 25990254632 +/-10% Lower bound bytes allocated: 23391229168 Upper bound bytes allocated: 28589280096 Actual bytes allocated: 28680445952 *** unexpected failure for haddock.compiler(normal) =====> T3064(normal) 2480 of 3806 [0, 3, 0] cd ./perf/compiler && '/home/smarlow/ghc/bindisttest/install dir/bin/ghc' -fforce-recomp -dno-debug-output -no-user-package-db -rtsopts -fno-ghci-history -c T3064.hs +RTS -V0 -tT3064.comp.stats --machine-readable -RTS >T3064.comp.stderr 2>&1 max_bytes_used value is too high: Expected max_bytes_used: 12000480 +/-20% Lower bound max_bytes_used: 9600384 Upper bound max_bytes_used: 14400576 Actual max_bytes_used: 15258696 peak_megabytes_allocated value is too high: Expected peak_megabytes_allocated: 30 +/-20% Lower bound peak_megabytes_allocated: 24 Upper bound peak_megabytes_allocated: 36 Actual peak_megabytes_allocated: 37 *** unexpected failure for T3064(normal)
_______________________________________________ ghc-devs mailing list ghc-devs@haskell.org http://www.haskell.org/mailman/listinfo/ghc-devs
On 2013-10-01 at 12:19:16 +0200, Simon Marlow wrote:
That would help, but since this regression is quite recent I'm hoping that someone will know what caused it. Did anyone notice when these failures first appeared? It is certainly not the patches I'm working on, because I see the same failures on two separate machines.
fwiw, I started seeing "haddock.base" failures with ghc.git commit 680441de191145dd874bd453e09e4ee906d87bbb (which merged the SIMD branch) the commit 6e6e6f5bfdfc3996603064523af6e2be2c5131fa right before the wip/simd branch merge didn't have this failure in its testlog; hth, hvr
participants (4)
-
Herbert Valerio Riedel -
Richard Eisenberg -
Simon Marlow -
Simon Peyton-Jones