crash nsDeviceMotion::DeviceMotionChanged

VERIFIED FIXED in Firefox 7

Status

()

Core
DOM
--
critical
VERIFIED FIXED
6 years ago
3 years ago

People

(Reporter: djc, Assigned: jdm)

Tracking

(5 keywords)

8 Branch
mozilla9
x86
Mac OS X
crash, regression, testcase, verified-aurora, verified-beta
Points:
---
Bug Flags:
in-testsuite ?

Firefox Tracking Flags

(firefox7+ fixed, firefox8+ fixed)

Details

(Whiteboard: [qa!], crash signature)

Attachments

(1 attachment)

(Reporter)

Description

6 years ago
This bug was filed from the Socorro interface and is 
report bp-e3071077-b38d-4f2a-a7d4-a9dbe2110904 .
============================================================= 

I've had this crash 4 times over two days; this is the first time I've had it. It seems to be related to scrolling events. I'm running OS X Lion 10.7.1 and latest Aurora.

https://crash-stats.mozilla.com/report/index/bp-6062067e-13e5-41d0-b33d-8f29c2110903
https://crash-stats.mozilla.com/report/index/bp-1a4c29fb-dad6-48e3-8872-a956b2110904
http://crash-stats.mozilla.com/report/index/bp-a9bee1df-4d98-4315-8b27-4b5242110903

(The associated bug states that everything after that fix should be considered separate, so here I am.)
Status: NEW → RESOLVED
Last Resolved: 6 years ago
Resolution: --- → DUPLICATE
Duplicate of bug: 673472
(Reporter)

Comment 2

6 years ago
kbrosnan, did you have a particular reason to ignore bug 673472 comment 15?

https://bugzilla.mozilla.org/show_bug.cgi?id=673472#c15
(Assignee)

Comment 3

6 years ago
The buildid says it's from a Sept 2nd build, so this looks like a crash that needs addressing. Dirkjan, any further details about when this reproduces?
Status: RESOLVED → REOPENED
Resolution: DUPLICATE → ---
(Reporter)

Comment 4

6 years ago
I had a scenario to reproduce after each crash:

1. Restore session (with 4 app tabs and 4 normal tabs)
2. Open new tab
3. In new tab, google for simplejson
4. Click link to http://undefined.org/python/
5. Try to hit the github link under simplejson
6. Crash before getting to click the link

However, at some point, instead of restoring the session, I started clean, opened up all my (app + normal) tabs again, and now it seems to work without crashing.

My previous instance of this had a similar way of reoccurring after the crash, when I tried to do the exact same thing. Ah, see the comment I left on the 606* crash, that also had something to do with github (though in this case I didn't even get to github before crashing). So I guess the first time I had it was not yesterday but this morning; should be a recent regression.
(Assignee)

Comment 5

6 years ago
Thanks for the hint. I was able to reproduce it by opening up two tabs to the github 404 page, refreshing them both, and closing them.
Assignee: nobody → josh
(Assignee)

Comment 6

6 years ago
This is a regression from bug 678818.
(Assignee)

Comment 7

6 years ago
Created attachment 558176 [details] [diff] [review]
Avoid null dereference when chacking if a window's in the background.

This code just keeps on giving, doesn't it?
(Assignee)

Updated

6 years ago
Attachment #558176 - Flags: review?(Olli.Pettay)

Updated

6 years ago
Attachment #558176 - Flags: review?(Olli.Pettay) → review+

Updated

6 years ago
Component: General → General
Product: Firefox → Core
QA Contact: general → general
(Assignee)

Comment 8

6 years ago
http://hg.mozilla.org/integration/mozilla-inbound/rev/81ebc148aad3
(Reporter)

Comment 9

6 years ago
Should there be some flag set to make sure this goes into Aurora, or does that only happen after landing onto mozilla-central?

Updated

6 years ago
Attachment #558176 - Flags: approval-mozilla-beta?
Attachment #558176 - Flags: approval-mozilla-aurora?
smaug, how can the outer window ever be null here?  I thought inners always have outers?

jdm - yes, giving and giving and giving.
I hit this today, and interesting it didn't trigger breakpad (I got the MS dialog and dropped into the debugger).
http://hg.mozilla.org/mozilla-central/rev/81ebc148aad3
Status: REOPENED → RESOLVED
Last Resolved: 6 years ago6 years ago
Flags: in-testsuite?
Resolution: --- → FIXED
Target Milestone: --- → mozilla9

Updated

6 years ago
Duplicate of this bug: 673472

Comment 14

6 years ago
Flagging for 8 as it appears in crash stats there. I know approval has been requested already, I just don't want to lose track of it. :)
tracking-firefox8: --- → ?
Attachment #558176 - Flags: approval-mozilla-beta?
Attachment #558176 - Flags: approval-mozilla-beta+
Attachment #558176 - Flags: approval-mozilla-aurora?
Attachment #558176 - Flags: approval-mozilla-aurora+
tracking-firefox7: --- → +
tracking-firefox8: ? → +
Keywords: regression
(Assignee)

Comment 15

6 years ago
Can someone push this to aurora and beta for me, please?
(In reply to Josh Matthews [:jdm] from comment #15)
> Can someone push this to aurora and beta for me, please?

Pushing
We'll need to verify this on aurora and beta when it lands. Use the information in comment #4 and #5 to verify.
Keywords: testcase
Whiteboard: [qa+]

Updated

6 years ago
status-firefox7: --- → fixed
status-firefox8: --- → fixed

Comment 18

6 years ago
This looks to have landed everywhere, marking as fixed everywhere.

Comment 19

6 years ago
Setting resolution to Verified Fixed on:
Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:7.0) Gecko/20100101 Firefox/7.0
Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:8.0a2) Gecko/20110921 Firefox/8.0a2
Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:9.0a1) Gecko/20110922 Firefox/9.0a1

I've verified this following the steps from comment4 and I forced quit firefox from the Activity Monitor to get the Retore Tab. On all three channels I got no crash.
Status: RESOLVED → VERIFIED
Keywords: verified-aurora, verified-beta
Whiteboard: [qa+] → [qa!]

Updated

3 years ago
Component: General → DOM
You need to log in before you can comment on or make changes to this bug.