On Thu, May 26, 2016, at 02:41 PM, Benoit Girard wrote: > - Crash address can give you a hint as to what's going on: 0x0 -> null > crash, 0x8 -> null offset accessing a member like this->mFoo,
N.B.: due to the way addressing works on x86-64, if the crash address is "0x0" for a Linux/OS X crash report, or "0xffffffffffffffff" for a Windows crash report, it's highly likely that the value is incorrect[1]. This is due to how these faults are reported from the CPU. (I have an in-progress Breakpad patch[2] to detect this and attempt to find the actual faulting address, but it needs some more work to land upstream. The commit message also describes the root cause more thoroughly, if you're interested.) You can sanity check these crashes by clicking the "Raw Dump" tab. The top frame of the crashing stack in that JSON data will contain the registers from the crash context. If you see a suspicious value in one of them (like a poison pattern) more thorough analysis may be warranted. -Ted 1. https://bugzilla.mozilla.org/show_bug.cgi?id=974420 2. https://github.com/luser/breakpad/commit/c8c0bbcdba178b74db171c21d2c6f4a59efd0131 _______________________________________________ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
