On 2/27/2014 11:57 AM, Bill McCloskey wrote:
We poison the GC heap with 0xda on nightly and aurora [1]. Lots of our
processMarkStackTop are at this address [2]. It looks like we only poison Ion
code in debug builds [3]. That should be easy to fix by removing the #ifdef
DEBUG.
bug#?
I don't think we've found GC heap poisoning to be all that helpful for
debugging in crashstats. The stacks are almost always really generic.
Are there ways we can make the stacks less generic without killing perf?
For example check for poison values when tracing, so that we might know
which pointer was potentially broken? Or even extra-checking modes which
are built into release builds but aren't on by default; people who are
seeing intermittent GC crashes ca turn on the extra checking with prefs
or environment variables to give us better data.
Or, when tracing can we store an extra pointer describing the traced
variable that got us to the object? Then we can store/annotate the trace
path if we end up crashing later marking that object, and we're not
touching pages out of order.
One thing I've noticed in the past is that certain add-ons seem to increase the
frequency of GC crashes (not necessarily though any misbehavior on their part).
The correlations that show up in crashstats aren't very helpful here since so
many different crashes are lumped together. I wonder if we could do a more
sophisticated analysis to try to find the problematic add-ons. Then we could
try to do some manual (or automatic) testing with those add-ons and hopefully
get some full crashdumps, which would be more useful than what we have now.
I'm certainly open to suggestions, though I don't know what kind of
analysis would help ;-)
--BDS
_______________________________________________
dev-tech-js-engine-internals mailing list
[email protected]
https://lists.mozilla.org/listinfo/dev-tech-js-engine-internals
