This bug was filed from the Socorro interface and is report bp-aac279b5-63b1-4bab-9549-31df22140517. ============================================================= Recent signature for nightly 32a1, currently in the top 50. The first appearance of this on nightly 32 was around 5/17. Most of these happen in Windows XP. There are no comments in the reports yet. There's a ~20% correlation to Greasemonkey. More reports can be found here: https://crash-stats.mozilla.com/report/list?product=Firefox&signature=js%3A%3Airregexp%3A%3AExecuteCode%28JSContext%2A%2C+js%3A%3Ajit%3A%3AJitCode%2A%2C+wchar_t+const%2A%2C+unsigned+int%2C+unsigned+int%2C+js%3A%3AMatchPairs%2A%29 0 @0x46ef765 1 mozjs.dll js::irregexp::ExecuteCode(JSContext *,js::jit::JitCode *,wchar_t const *,unsigned int,unsigned int,js::MatchPairs *) js/src/irregexp/RegExpEngine.cpp 2 mozjs.dll js::RegExpShared::execute(JSContext *,wchar_t const *,unsigned int,unsigned int *,js::MatchPairs &) js/src/vm/RegExpObject.cpp 3 mozjs.dll js::ExecuteRegExp(JSContext *,JS::Handle<JSObject *>,JS::Handle<JSString *>,js::MatchConduit &,js::RegExpStaticsUpdate)

bhackett landed bug 976446 on 5/16, which switched our regexp engine from Yarr to irregexp, and this is a crash in irregexp appearing with the first nightly this was enabled in. Brian, can you take a look?

I think this is the same issue as bug 1013586, they're both crashing in similar ways in jitcode.

(In reply to Brian Hackett (:bhackett) from comment #2) > I think this is the same issue as bug 1013586, they're both crashing in > similar ways in jitcode. Interestingly, unlike bug 1013586, the signature here has a number of different values in the "crash reason" field, some even being this: EXCEPTION_ACCESS_VIOLATION_READ 0x5a5a5a5a Which sounds like we tried to read previously freed, poisoned memory.

I think this was fixed by bug 1024678, there haven't been any crashes in 33.0 since that bug landed (though that bug isn't on 32.0 yet).

(In reply to Brian Hackett (:bhackett) from comment #4) > I think this was fixed by bug 1024678, there haven't been any crashes in > 33.0 since that bug landed (though that bug isn't on 32.0 yet). I can confirm this. Can we mark this bug fixed based on that?

We still have cases with similar signatures but we already track that in bug 1013996.