#8611: nofib’s cacheprof’s allocations nondeterminisitic -------------------------------------+------------------------------------- Reporter: nomeata | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: NoFib benchmark | Version: 8.5 suite | Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #4450 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by sgraf): * related: => #4450 Comment: Just a few notes while it's still fresh in my head. I always compared two traces via `rr`. - Based on my observation that bytes copied was the first metric to diverge, I did some printf debugging in the RTS. - I noticed that the first divergence comes from copying additional blackholes. After evacuating the blackhole in trace B, it resumes 'normal' operation, e.g. does the same thing trace A would do instead of evacuating the black hole. - The black holes are evacuated when the stack is scavenged. They're pointed to by update frames, all of which originally pointed to `stg_sel_0_upd` selector thunks. - I also noticed that the `mut_list_size` output of `+RTS -Dg` varies between the two traces, and it's never because of any mutable primitives (e.g., arrays, MVars, etc.). I'm not sure what pushes (or fails to push) the update frames. Maybe it has to do with `ThreadPaused.c:stackSqueeze()`? Maybe this is related to #4450? -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/8611#comment:10 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler