1147215 - crash in mozilla::dom::WarningOnlyErrorReporter(JSContext*, char const*, JSErrorReport*)

Status: RESOLVED FIXED

(Core :: DOM: Core & HTML, defect)

Description

[u279076]

This bug was filed from the Socorro interface and is 
report bp-1a10ab1a-384d-4f38-b826-baa952150317.
=============================================================
0 	xul.dll 	mozilla::dom::WarningOnlyErrorReporter(JSContext*, char const*, JSErrorReport*) 	dom/base/ScriptSettings.cpp
1 	xul.dll 	js_ReportOutOfMemory(js::ThreadSafeContext*) 	js/src/jscntxt.cpp
2 	xul.dll 	js::frontend::TokenStream::getStringOrTemplateToken(int, js::frontend::Token**) 	js/src/frontend/TokenStream.cpp
3 	xul.dll 	js::HashSet<js::AtomStateEntry, js::AtomHasher, js::SystemAllocPolicy>::lookupForAdd(js::AtomHasher::Lookup const&) 	js/public/HashTable.h
4 	xul.dll 	js::frontend::TokenStream::getTokenInternal(js::frontend::TokenKind*, js::frontend::TokenStream::Modifier) 	js/src/frontend/TokenStream.cpp
5 	xul.dll 	js::frontend::Parser<js::frontend::FullParseHandler>::memberExpr(js::frontend::TokenKind, bool) 	js/src/frontend/Parser.cpp
6 	xul.dll 	js::frontend::Parser<js::frontend::FullParseHandler>::unaryExpr() 	js/src/frontend/Parser.cpp
=============================================================
More reports: https://crash-stats.mozilla.com/report/list?product=Firefox&signature=mozilla%3A%3Adom%3A%3AWarningOnlyErrorReporter%28JSContext%2A%2C+char+const%2A%2C+JSErrorReport%2A%29

Volume: 
678 crashes in the last week (#12 DOM crash @ 1.01%)

Platforms: 
All crashes on Windows with 77% on Windows 7 32-bit

Products: 
64% on Firefox 36
35% on Firefox 37
1% on Firefox 38
0% on Firefox 39

I'm marking this as a regression in Firefox 36 based on crash-stats but I don't have any solid leads as to how to reproduce this or what might have caused it.

Comment 1

[Olli Pettay [:smaug]]

Looks like a null pointer crash, but what exactly is null... perhaps CurrentGlobalOrNull returns null
since WindowGlobalOrNull can't deal with that?
But anyhow, probably a regression from bug 1070842

Comment 2

[u279076]

Bobby, since you were the developer involved with bug 1070842, would you be able to look into this?

Comment 3

[Bobby Holley (:bholley)]

Smaug's theory sounds reasonable - I don't think we're in a compartment when tokenizing. Waldo, can you confirm?

Comment 4

[Bobby Holley (:bholley)]

Attachment: Add a helper to get the current window with a null check. v1

Comment 5

[Bobby Holley (:bholley)]

https://hg.mozilla.org/integration/mozilla-inbound/rev/00121d84932a

Comment 6

[Ryan VanderMeulen [:RyanVM]]

https://hg.mozilla.org/mozilla-central/rev/00121d84932a

Comment 7

[Bobby Holley (:bholley)]

Comment on attachment 8583242 [details] [diff] [review]
Add a helper to get the current window with a null check. v1

Approval Request Comment
[Feature/regressing bug #]: bug 1070842
[User impact if declined]: Possible crashes
[Describe test coverage new/current, TreeHerder]: None
[Risks and why]: extremely low risk. Null-check.
[String/UUID change made/needed]: None

Comment 8

[Ryan VanderMeulen [:RyanVM]]

https://hg.mozilla.org/releases/mozilla-aurora/rev/7049015f9ce3

Comment 9

[Jeff Walden [:Waldo]]

I think we're in a compartment when tokenizing.  There's pretty little you can do when you're *not* in a compartment, and not being in one would make it very, very difficult (probably impossible) to do things like create template objects.  So I rather doubt that's the explanation, but I could be wrong.

Comment 10

[Bobby Holley (:bholley)]

Ok - hopefully anthony can tell us if the signature goes away.

Comment 11

[u279076]

We have a few crashes for Aurora 38 and Nightly 39 in the last few days but they're with builds before the fix landed. I see no crashes with "fixed" builds. That said, volume was initially low with 38 and 39 so I'm not confident that I'll be able to 100% confirm this is fixed without a reproducible testcase. 

We should know more when Firefox 38 moves further into the Beta cycle. I can put a reminder in my calendar to loop back in a couple weeks.