[Mono-dev] Logging profiler timings are way off

[Paul Melis]

While looking at the GC statistics after a profiler run which used
--profile=logging:c I noticed the following times that seem to be the
result of overflow/uninitialized vars:

Reporting GC statistics for 85 collections (total 6164298204850.500ms,
18737439181.81% of total time, mark  0.00%, sweep  0.00%)
[1] Collection starting at 0.000s (generation 0): duration 0.048ms, mark
0.021ms, sweep 0.019ms
[2] Heap resized to 131072 bytes
[3] Heap resized to 196608 bytes
[4] Heap resized to 266240 bytes
[5] Collection starting at 0.123s (generation 0): duration 0.294ms, mark
0.175ms, sweep 0.080ms
[6] Heap resized to 360448 bytes
[7] Collection starting at 0.174s
...
[94] Collection starting at 30.075s (generation 0): duration 1.614ms,
mark 1.327ms, sweep 0.166ms
[95] Collection starting at 30.792s (generation 0): duration 1.831ms,
mark 1.567ms, sweep 0.134ms
[96] Collection starting at 31.253s (generation 0): duration 1.108ms,
mark 0.791ms, sweep 0.184ms
[97] Collection starting at 31.659s (generation 0): duration 0.592ms,
mark 0.327ms, sweep 0.160ms
[98] Collection starting at 32.895s (generation 0): duration 0.421ms,
mark 0.288ms, sweep 0.079ms
[99] Collection starting at 32.897s (generation 0): duration
6164298204746.200ms, mark 0.222ms, sweep 0.046ms

The program run itself was just a few seconds. I have a .mprof file that
generates this output with mprof-decoder, but it's over 450 megs and I
haven't been able to reproduce the faulty timings with a smaller file.
Nor do I know if the strange values come from a failing decoding of the
.mprof file or if the values in the file are corrupted. I can probably
put the .mprof file somewhere on a web server if needed?

What's a good way to move forward on this?
Paul