This bug was filed from the Socorro interface and is report bp-66ec44d3-6936-46df-91f9-f2f700170820. ============================================================= Seen while looking at Mac crash stats: http://bit.ly/2g2Pp9b. 50% of the crashes happen on 10.9. Although not high volume, it is in the top echelon of Mac specific crashes for release. One comment says "just scrolling on Facebook"
Ted please evaluate priority and scope of impact.
Assignee: nobody → tcampbell
Priority: -- → P1
This is a dupe of Bug 1124397. The signature here is due to diagnostic checks added in that bug. I'll take a look at the state of the investigation but it looks like it has been a very tough problem with no timeline for fix. That bug is still working to narrow down.
Status: NEW → RESOLVED
Last Resolved: 11 months ago
Resolution: --- → DUPLICATE
Duplicate of bug: 1124397
Marcia, should these crash signatures be merged into Bug 1124397? (I'm not familiar with how sigs are managed)
(In reply to Ted Campbell [:tcampbell] from comment #3) > Marcia, should these crash signatures be merged into Bug 1124397? (I'm not > familiar with how sigs are managed) They don't necessarily have to be. As long as the signature is in this bug, it will lead someone in Socorro to the other one on file.
One confusing part is that the FF55 crashes show like https://crash-stats.mozilla.com/report/index/e83253d9-cc4d-4ada-9a62-016630170918, show failure as https://hg.mozilla.org/releases/mozilla-release/annotate/45ab6e362747/js/src/jit/x86-shared/AssemblerBuffer-x86-shared.h#l131, while the FF56/57 crashes show site as https://hg.mozilla.org/releases/mozilla-beta/annotate/6bd183fc6921/js/src/jit/x86-shared/Assembler-x86-shared.cpp#l131. The crash reason for both shows up as MOZ_CRASH(corrupt code buffer) which is Bug 1124397. I think it is just reporting location being funny.
Ah, the crash reporter was confused due to the MOZ_RELEASE_ASSERT and MOZ_CRASH being inlined into same function, but having the same line number in their own source file. In 55 this misidentified the source location, but after line numbers moved in later revisions, this is clearly the same bug as Bug 1124397
(In reply to Ted Campbell [:tcampbell] from comment #2) > This is a dupe of Bug 1124397. The signature here is due to diagnostic > checks added in that bug. I'll take a look at the state of the investigation > but it looks like it has been a very tough problem with no timeline for fix. > That bug is still working to narrow down. To summarize the current situation: 1) The crashes on Windows are almost certainly bad hardware, so beyond detecting hardware failure there's not much we can do. 2) The crashes on OSX look different, but they definitely come from jemalloc itself - there might be some miscompilation on a very rare path, or even something more subtle like a CPU bug that jemalloc happens to hit. The only immediate path forward I can think of is looking at disassembly for jemalloc functions on OSX builds. But now that we've officially forked mozjemalloc and it's being built as C++, there might be more general improvements we can make to make it easier to debug. I've been extremely busy over the last few months, but it's something I'm interested in looking at - hard to say whether we'll be able to fix this crash though.
FWIW, we just hit a crash with this signature on one of the ambient-display machines in the Mountain View office. Crash report: bp-048f5933-0cb8-426d-bfd6-1a0341171025
You need to log in before you can comment on or make changes to this bug.