1312110 - nsCSSRuleProcessor::CascadeSheet() allocates a JS regexp object during InterruptCallback

Status: RESOLVED DUPLICATE of bug 1310335

(Core :: CSS Parsing and Computation, defect)

Description

[(inactive) Jim Chen [:jchen] [:darchons]]

This bug was filed from the Socorro interface and is 
report bp-0bb229d2-8612-46ce-9100-1233a2161021.
=============================================================

Low volume crash that's been happening in several recent nightlies, but I'm not sure when it started. It does appear across several installations/machines so it's unlikely to be a bogus crash.

Comment 1

[Andrew McCreight [:mccr8]]

This is another regression from bug 1308039 (though we've been marking these blocking bug 1279086 so I'll continue that).

Painting during interrupt callback ends up in nsCSSRuleProcessor::CascadeSheet(), which calls into DocumentRule::UseForPresentation(), which calls nsContentUtils::IsPatternMatching(), which attempts to allocate a new JS engine regular expression object.

It looks like bug 398962 added support for regular expressions to a moz-document CSS rule, or something like that, and it was implemented by calling into the JS engine.

One side note, I'm not sure why these crashes are not annotated with the same release assert as the other crashes. We're crashing inside a JS engine allocation. There may be more release asserts to be added here.

Comment 2

[(no longer active)]

Sadly it seems hard to call into irregexp without the SpiderMonkey machinery wrapped around it.  Based on a quick look at that code, it seems fairly intertwined with SpiderMonkey.  For example, NativeRegExpMacroAssembler uses SpiderMonkey's macro assembler machinery...

I wonder if we can bypass resolving such moz-document rules when painting in this mode?  That seems like a questionable thing to do for example for users who are using such rules in their user stylesheet to customize a website...

Comment 3

[Andrew McCreight [:mccr8]]

This is still present on Nightly.