Benjamin Smedberg <benja...@smedbergs.us> writes: > Assuming these crashes show up in crash-stats.mozilla.com, are there > particular signatures, metadata, or other patterns that would let us say > "this crash is caused by a sandbox failure"?
They should, and the expected distinguishing feature is a "Crash Reason" of "SIGSYS". I put a certain amount of work into getting the crash reporting integration to work properly back in the B2G era, and on desktop for media plugin processes. (However, there aren't automated tests to ensure it keeps working; "crashing the content process" isn't a use case that the test framework docs were very helpful with.) For additional filtering/faceting, the "crash address" is the syscall number (but note that its meaning depends on architecture). One more thing: it might be a good idea to reconsider the crash-by-default policy for desktop content, at least for release builds. On B2G, the decision to do that was informed by the assumption that builds would be comprehensively tested before being released to end users, that the presence of crashes under test would block release, and that this was all running in a relatively fixed environment. Approximately none of that is true on desktop, especially the last item; it seems to have worked out for media plugins, but they're much more self-contained than content, and I don't know how widely used they are. And there are other options for reporting diagnostic info which trade off detail for hopefully not crashing. It looks like there was never a bug about this, which I guess means I should file one.... --Jed _______________________________________________ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
