#5282: Bizarre results from -P profiler on OS X
---------------------------------+------------------------------------------
Reporter: bos | Owner:
Type: bug | Status: new
Priority: high | Milestone: 7.2.1
Component: Runtime System | Version: 7.0.3
Keywords: | Testcase:
Blockedby: | Difficulty:
Os: Unknown/Multiple | Blocking:
Architecture: x86_64 (amd64) | Failure: Incorrect result at runtime
---------------------------------+------------------------------------------
Comment(by dmp):
Replying to [comment:9 simonmar]:
> I can't imagine why the threaded and non-threaded runtimes would differ
in this way. You could try `gdb` and set a watchpoint on the `CCCS`
variable ("Current Cost Centre Stack"), and see if you can see what
differs between the two runtimes.
I spent some time with gdb and could not find anything obviously wrong. In
the single-threaded runtime, if I put a break point on the timer callback
the backtrace shows it is in the scheduler getting ready to do a GC so the
CCCS is set correctly.
In the threaded version, I'm seeing some odd things in the debugger but it
seems fine if I run it outside the debugger. In the debugger it looks like
the timer interrupt is delivered to each thread in the rts, including two
worker threads waiting on pthread condition variables. Its probably just
an odd interaction with the debugger, because running normally seems to
work fine.
The simple benchmark I'm using does do a large number of GCs. It has 5208
collections in about 2.5 seconds, which is a collection about every half
millisecond. Even though the collections are fast (98% productivity
reported by -s), we could be just getting unlucky with the timer signal.
If I set a larger heap with -A100M, then there is only 26 collections and
the profile data looks good. I don't know why the threaded runtime
wouldn't have the same problem though.
--
Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/5282#comment:13>
GHC <http://www.haskell.org/ghc/>
The Glasgow Haskell Compiler
_______________________________________________
Glasgow-haskell-bugs mailing list
[email protected]
http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
