1392649 - Crash in js::jit::AssemblerX86Shared::executableCopy

Status: RESOLVED DUPLICATE of bug 1124397

(Core :: JavaScript Engine, defect, P1)

Description

[Marcia Knous [:marcia]]

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"

Comment 1

[Naveed Ihsanullah [:naveed]]

Ted please evaluate priority and scope of impact.

Comment 2

[Ted Campbell [:tcampbell]]

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.

Comment 3

[Ted Campbell [:tcampbell]]

Marcia, should these crash signatures be merged into Bug 1124397? (I'm not familiar with how sigs are managed)

Comment 4

[Marcia Knous [:marcia]]

(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.

Comment 5

[Ted Campbell [:tcampbell]]

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.

Comment 6

[Ted Campbell [:tcampbell]]

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

Comment 7

[Emanuel Hoogeveen [:ehoogeveen]]

(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.

Comment 8

[Daniel Holbert [:dholbert]]

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