Closed Bug 976181 Opened 7 years ago Closed 7 years ago

startup crash in nsContentUtils::IsCallerChrome()

Categories

(Core :: DOM: Workers, defect)

29 Branch
defect
Not set
critical

Tracking

()

RESOLVED DUPLICATE of bug 913138
Tracking Status
firefox29 + verified
firefox30 --- affected

People

(Reporter: kairo, Assigned: bholley)

References

Details

(Keywords: crash, topcrash-win, Whiteboard: [startupcrash])

Crash Data

This bug was filed from the Socorro interface and is 
report bp-381e68ac-4adf-476a-9624-1d51d2140223.
=============================================================

This is the #2 crash on 29.0a2 Aurora at this time, and though it lists many dupes, the 260 crashes over the last week happened on 101 different installations (different install times), so it seems pretty legitimate.

Top frames:
0 	xul.dll 	nsContentUtils::IsCallerChrome() 	content/base/src/nsContentUtils.cpp
1 	xul.dll 	mozilla::dom::workers::WorkerPrivate::GetLoadInfo(JSContext *,nsPIDOMWindow *,mozilla::dom::workers::WorkerPrivate *,nsAString_internal const &,bool,mozilla::dom::workers::WorkerPrivateParent<mozilla::dom::workers::WorkerPrivate>::LoadInfo *) 	dom/workers/WorkerPrivate.cpp
2 	xul.dll 	mozilla::dom::workers::WorkerPrivate::Constructor(mozilla::dom::GlobalObject const &,nsAString_internal const &,bool,mozilla::dom::workers::WorkerPrivateParent<mozilla::dom::workers::WorkerPrivate>::WorkerType,nsACString_internal const &,mozilla::dom::workers::WorkerPrivateParent<mozilla::dom::workers::WorkerPrivate>::LoadInfo *,mozilla::ErrorResult &) 	dom/workers/WorkerPrivate.cpp
3 	xul.dll 	mozilla::dom::workers::ChromeWorkerPrivate::Constructor(mozilla::dom::GlobalObject const &,nsAString_internal const &,mozilla::ErrorResult &) 	dom/workers/WorkerPrivate.cpp
4 	xul.dll 	mozilla::dom::ChromeWorkerBinding::_constructor 	obj-firefox/dom/bindings/WorkerBinding.cpp
5 	mozjs.dll 	js::InvokeConstructor(JSContext *,JS::CallArgs) 	js/src/vm/Interpreter.cpp
6 	mozjs.dll 	Interpret 	js/src/vm/Interpreter.cpp
7 	mozjs.dll 	js::RunScript(JSContext *,js::RunState &) 	js/src/vm/Interpreter.cpp
8 	mozjs.dll 	js::Invoke(JSContext *,JS::CallArgs,js::MaybeConstruct) 	js/src/vm/Interpreter.cpp
9 	mozjs.dll 	js::Invoke(JSContext *,JS::Value const &,JS::Value const &,unsigned int,JS::Value *,JS::MutableHandle<JS::Value>) 	js/src/vm/Interpreter.cpp
10 	mozjs.dll 	GetPropertyOperation 	js/src/vm/Interpreter.cpp
11 	mozjs.dll 	Interpret 	js/src/vm/Interpreter.cpp


Find more crashes like this at https://crash-stats.mozilla.com/report/list?signature=nsContentUtils%3A%3AIsCallerChrome%28%29
This isn't really a startup crash per-se since ShutdownXPCOM is at the bottom of the stack. It looks like someone is constructing a ChromeWorker after the script security manager has already been torn down.
Well, I called it "startup" because the uptime of the browser process is far under 1 minute for all those crashes.
Right, I knew what you meant :)
I wonder why we seem to be at/after ShutdownXPCOM with uptimes of 0 or very few seconds on the process, though.
Kairo, do you see it also on nightly or just 29?
Flags: needinfo?(kairo)
Version: 26 Branch → 29 Branch
(In reply to Sylvestre Ledru [:sylvestre] from comment #6)
> Kairo, do you see it also on nightly or just 29?

Volume is much higher on Aurora 29 than on Nightly 30, but it's there as well. Also, current Aurora builds are still affected.
Flags: needinfo?(kairo)
jst, this is a steady top-10 crash on Aurora 29 and a "startup" crash at that, can we have someone assigned to look at how we can fix it?
Ben already took a look at the cause in comment #1, FWIW.
Flags: needinfo?(jst)
See Also: → 981639
This is the same as bug 913138, I think, which I tried to fix a while ago.
This is still in the top 10 in the list of top crashers for Firefox 29 in beta. I'm looking at the correlations reports, but nothing is jumping right me at the moment.
We know how to fix this crash - see bug 913138. It's just tricky, and requires someone with deep Gecko expertise to sink some time into untangling everything. Some potential candidates:

* glandium
* ehsan
* bsmedberg
* nathan froyd
* bz
* bholley
* smaug
* khuey
Given comment #11, jst not replying to my ni? here and besmedberg leading stability engineering, ni? on him to find someone to actually do the work on this.
Flags: needinfo?(benjamin)
Sorry this one got lost on my end, looking for resources now.
Flags: needinfo?(jst)
Taking.
Assignee: nobody → bobbyholley
Depends on: 913138
Flags: needinfo?(benjamin)
Bobby, any news on this bug? Sorry for the pressure but we are going to release beta 5 tomorrow and it would be nice to see that bug fixed in beta6 (next monday) or 7 (next thursday). Thanks
Flags: needinfo?(bobbyholley)
(In reply to Sylvestre Ledru [:sylvestre] from comment #15)
> Bobby, any news on this bug? Sorry for the pressure but we are going to
> release beta 5 tomorrow and it would be nice to see that bug fixed in beta6
> (next monday) or 7 (next thursday). Thanks

The patches (in bug 913138) have been ready for the past week, waiting on Benjamin's review.
Flags: needinfo?(bobbyholley)
Bobby, if bug 913138 is fixed, is it going to fix also this one? Thanks
(In reply to Sylvestre Ledru [:sylvestre] from comment #17)
> Bobby, if bug 913138 is fixed, is it going to fix also this one? Thanks

If comment 1 is accurate, then I believe they are the same issue, yes.
Kairo, once bug 913138 bakes a bit, can you confirm that it fixes the crash here? If so, we can go ahead and get it uplifted.
Flags: needinfo?(kairo)
I'm marking this as a dupe of bug 913138 as it's on the same signature and the fix there made this disappear completely for 29.0b7 (haven't checked in detail for trunk and aurora but expect the same there).
Status: NEW → RESOLVED
Closed: 7 years ago
Flags: needinfo?(kairo)
Resolution: --- → DUPLICATE
Duplicate of bug: 913138
You need to log in before you can comment on or make changes to this bug.