Closed Bug 931794 Opened 6 years ago Closed 6 years ago
startup crash in mozilla::dom::Window
Binding::get _content with Twitter Disconnect, Facebook Disconnect, Google Disconnect, Chatzilla
This bug was filed from the Socorro interface and is report bp-4f9b57fa-e48a-4ce4-9f6d-068d82131028. ============================================================= STR: 1. Start latest nightly, with fresh profile to be on the safe side 2. Install Twitter Disconnect from here: https://addons.mozilla.org/en-US/firefox/addon/twdc/ 3. Restart Firefox to complete installation. ACTUAL RESULTS: Startup crash (unable to start firefox, except in safe mode). Sample crash reports: bp-4f9b57fa-e48a-4ce4-9f6d-068d82131028 bp-f55a1398-1f02-4bc4-b3d1-b1b512131028 bp-a6de9a2f-7eac-464d-a4d9-45c982131028 bp-e89a57cd-d7d4-4c2d-ac85-46a772131028 This is with today's nightly [27.0a1 (2013-10-28)] and Twitter Disconnect 2.1.2
I also hit this with Facebook Disconnect: https://addons.mozilla.org/en-us/firefox/addon/fbdc/ bp-97146e4f-a04d-45e2-9b8d-20cd02131028 and Google Disconnect: https://addons.mozilla.org/En-us/firefox/addon/gdc/ bp-d78fdbc7-3a5b-497c-b52c-d8de12131028 (In each case, the add-on in question is the only one enabled)
Summary: startup crash in mozilla::dom::WindowBinding::get_content with Twitter Disconnect on 2013-10-28 nightly → startup crash in mozilla::dom::WindowBinding::get_content with Twitter Disconnect, Facebook Disconnect, or Google Disconnect on 2013-10-28 nightly
I'm going to guess that this is a DOM bindings issue.
This is new in latest nightly, based on my testing. Regression range, given that fact: http://hg.mozilla.org/integration/mozilla-inbound/pushloghtml?fromchange=a80dce1126db&tochange=4646259ab62d Maybe a regression from bug 918345?
Yup, I confirmed that http://hg.mozilla.org/integration/mozilla-inbound/rev/508288a2b62c (for bug 918345) is the first affected cset.
These are all null-derefs in js::GetObjectCompartment. I wonder whether GetContent() is returning null (and failing some asserts on its toObject() calls in the process; presumably this is the case when treeOwner->GetContentWindow() returns null? We should probably mark this nullable in the idl and change that last return to "return val.toObjectOrNull()".
Setting "Tracking" flag, to get this on rel drivers' radar. We absolutely should not ship this startup crash to Aurora users during the train-switch that's happening in the next ~24 hours.
Assignee: nobody → peterv
Status: NEW → ASSIGNED
Tracking as we do not want to enable aurora updates without this bug being resolved.
Comment on attachment 823523 [details] [diff] [review] v1 r=me
Attachment #823523 - Flags: review?(bzbarsky) → review+
Chatzilla is also causes the issue (new profile, only installed Chatzilla). bp-dcd4b72a-b402-42cb-8173-ce3242131029 bp-46bff72e-daea-4719-98ba-515052131029
Comment on attachment 823523 [details] [diff] [review] v1 [Approval Request Comment] Bug caused by (feature/regressing bug #): bug 918345 User impact if declined: crashes Testing completed (on m-c, etc.): landed on mozilla-inboud Risk to taking this patch (and alternatives if risky): low risk, just deals with a null pointer String or IDL/UUID changes made by this patch: none
Attachment #823523 - Flags: approval-mozilla-aurora?
Summary: startup crash in mozilla::dom::WindowBinding::get_content with Twitter Disconnect, Facebook Disconnect, or Google Disconnect on 2013-10-28 nightly → startup crash in mozilla::dom::WindowBinding::get_content with Twitter Disconnect, Facebook Disconnect, Google Disconnect, Chatzilla
Attachment #823523 - Flags: approval-mozilla-aurora? → approval-mozilla-aurora+
Flagging this as a topcrash since it's the #1 on Nightly by far. I'll monitor crashstats over the next couple days to ensure this is fixed. When did this land on mozilla-central?
It hasn't been merged yet - it's held up by the current trunk closure. I set the status flag for firefox28 mainly so it was clear that it didn't need to land on any other branches at this point. Sorry for any confusion that caused.
Yes, having 28 set as fixed when it isn't is indeed confusing. 26 and 27 are marked correctly anyhow, why not leave 28 as "affected" until this lands?
Because I find that often people forget to set it and mcMerge doesn't do it automatically unless it's tracking+.
Status: ASSIGNED → RESOLVED
Closed: 6 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla28
I'm hitting something like this bug in recent nightlies on Windows, too (after this patch landed) - see bug 934203.
There are 2 regressions #1 Crash [@ mozilla::dom::WindowBinding::get_content ] http://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=a80dce1126db&tochange=4646259ab62d Troggered by Bug 918345 #2 Crash [@ JS_WrapValue(JSContext*, JS::MutableHandle<JS::Value>) ] http://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=f0d363d72753&tochange=abe6790a5dd8 Triggered by bug 931794 Regression window(m-c Nightly) Good: http://hg.mozilla.org/mozilla-central/rev/a80dce1126db Mozilla/5.0 (Windows NT 6.1; WOW64; rv:27.0) Gecko/20100101 Firefox/27.0 ID:20131027030205 #1 Bad [@ mozilla::dom::WindowBinding::get_content ]: bp-40b8c650-6ac1-4c7d-b949-62cc12131103 http://hg.mozilla.org/mozilla-central/rev/4646259ab62d Mozilla/5.0 (Windows NT 6.1; WOW64; rv:27.0) Gecko/20100101 Firefox/27.0 ID:20131028030205 bp-663345c9-1ec0-41f1-b208-47de32131103 http://hg.mozilla.org/mozilla-central/rev/518f5bff0ae4 Mozilla/5.0 (Windows NT 6.1; WOW64; rv:28.0) Gecko/20100101 Firefox/28.0 ID:20131029030201 bp-24cd6872-8622-4d2f-b7af-66b872131103 http://hg.mozilla.org/mozilla-central/rev/829d7bef8b0a Mozilla/5.0 (Windows NT 6.1; WOW64; rv:28.0) Gecko/20100101 Firefox/28.0 ID:20131030030201 bp-8b4cd97e-4803-4d2e-bf64-5dcf72131103 http://hg.mozilla.org/mozilla-central/rev/f0d363d72753 Mozilla/5.0 (Windows NT 6.1; WOW64; rv:28.0) Gecko/20100101 Firefox/28.0 ID:20131031030203 #2 Bad [@ JS_WrapValue(JSContext*, JS::MutableHandle<JS::Value>) ]: bp-a0b80ddd-4423-43f9-b113-99ed32131103 http://hg.mozilla.org/mozilla-central/rev/abe6790a5dd8 Mozilla/5.0 (Windows NT 6.1; WOW64; rv:28.0) Gecko/20100101 Firefox/28.0 ID:20131101030205 bp-afa204a4-00be-467e-a998-7d6ff2131103 http://hg.mozilla.org/mozilla-central/rev/2f7593f81351 Mozilla/5.0 (Windows NT 6.1; WOW64; rv:28.0) Gecko/20100101 Firefox/28.0 ID:20131102030205 bp-ad99948d-f32f-4a6d-b6fc-d0d0b2131103 http://hg.mozilla.org/mozilla-central/rev/47c8e9b16918 Mozilla/5.0 (Windows NT 6.1; WOW64; rv:28.0) Gecko/20100101 Firefox/28.0 ID:20131103030204
Mozilla/5.0 (X11; Linux i686; rv:27.0) Gecko/20100101 Firefox/27.0 Mozilla/5.0 (X11; Linux x86_64; rv:27.0) Gecko/20100101 Firefox/27.0 Reproduced this issue with Nightly from 2013-10-28 and on Aurora from 2013-11-05 I've encountered the startup crash from bug 934203. Verified as fixed on latest Aurora (Build ID: 20131106004000): no crash when restarting Firefox to complete the installation for Twitter Disconnect 2.1.2, Facebook Disconnect 2.1.3 and Google Disconnect 2.4.2.
Per crash stats, there are no reports of this crash with recent Nightly builds.
You need to log in before you can comment on or make changes to this bug.