Last Comment Bug 654707 - Crash [@ nsGlobalWindow::FireDelayedDOMEvents]
: Crash [@ nsGlobalWindow::FireDelayedDOMEvents]
Status: RESOLVED FIXED
:
Product: Core
Classification: Components
Component: DOM: Core & HTML (show other bugs)
: 2.0 Branch
: All All
: -- critical (vote)
: mozilla5
Assigned To: Honza Bambas (:mayhemer)
:
Mentors:
: 637279 (view as bug list)
Depends on:
Blocks: 630193 637279
  Show dependency treegraph
 
Reported: 2011-05-04 07:49 PDT by Honza Bambas (:mayhemer)
Modified: 2013-12-27 14:36 PST (History)
10 users (show)
See Also:
Crash Signature:
(edit)
QA Whiteboard:
Iteration: ---
Points: ---
Has Regression Range: ---
Has STR: ---
+
fixed
-
?


Attachments
v1 (848 bytes, patch)
2011-05-04 07:49 PDT, Honza Bambas (:mayhemer)
jst: review+
bugzilla: approval‑mozilla‑aurora+
Details | Diff | Review

Description Honza Bambas (:mayhemer) 2011-05-04 07:49:24 PDT
Created attachment 530006 [details] [diff] [review]
v1

This is leftover after bug 630193 fix.  We double delete nsAutoPtr value here:
http://hg.mozilla.org/mozilla-central/annotate/3fd770ef6a65/dom/base/nsGlobalWindow.cpp#l8451:

honzab@37608 8451 delete mPendingStorageEventsObsolete;
honzab@37608 8452 mPendingStorageEventsObsolete = nsnull;

mPendingStorageEventsObsolete is nsAutoPtr.

delete here is redundant.

Crash reports here, very low, so no rush to fix this:
https://crash-stats.mozilla.com/report/list?product=Firefox&query_search=signature&query_type=contains&query=nsGlobalWindow%3A%3AFireDelayedDOMEvents&reason_type=contains&date=05%2F04%2F2011%2007%3A37%3A58&range_value=4&range_unit=weeks&hang_type=any&process_type=any&do_query=1&signature=nsGlobalWindow%3A%3AFireDelayedDOMEvents%28%29
Comment 1 Honza Bambas (:mayhemer) 2011-05-04 07:53:33 PDT
BTW:

I was able to reproduce this while browsing pages referred in bug 637279 (http://www.hasznaltauto.hu/), a mysterious crash in the html5 parser.

As we double delete here, we might have a corrupted memory that affects later the parser.

But this is only a wild theory!
Comment 2 Asa Dotzler [:asa] 2011-05-06 13:58:00 PDT
without some steep crash trend, I don't think the release drivers are going to track this.
Comment 3 Johnny Stenback (:jst, jst@mozilla.com) 2011-05-10 09:00:58 PDT
Comment on attachment 530006 [details] [diff] [review]
v1

Agreed, but if this tests out well I'd be fine approving this trivial crash fix for aurora etc.
Comment 4 Phil Ringnalda (:philor) 2011-05-15 19:10:12 PDT
http://hg.mozilla.org/mozilla-central/rev/e985b26f23eb
Comment 5 Robert O'Callahan (:roc) (Exited; email my personal email if necessary) 2011-05-15 19:11:38 PDT
Thanks!
Comment 6 chris hofmann 2011-05-16 08:05:08 PDT
if this fix seems to work for fixing Bug 637279, and the patch appears to be low risk I think its a candidate for trying to take in 5.0 beta.   the reward for hungarian users would definitely be high.   

let's see what the feedback on trunk testing is in a few days.
Comment 7 Honza Bambas (:mayhemer) 2011-05-16 10:30:52 PDT
Thanks for landing this on my behalf.
Comment 8 Johnathan Nightingale [:johnath] 2011-05-16 14:35:49 PDT
This is really more of an approval request than a tracking request afaict, but whatever - land it for 5 please!
Comment 9 Johnathan Nightingale [:johnath] 2011-05-16 14:36:12 PDT
Comment on attachment 530006 [details] [diff] [review]
v1

Can this land today to make aurora?
Comment 10 Phil Ringnalda (:philor) 2011-05-16 15:12:34 PDT
http://hg.mozilla.org/releases/mozilla-aurora/rev/d3a58d815e2c
Comment 11 Robert O'Callahan (:roc) (Exited; email my personal email if necessary) 2011-05-16 16:49:54 PDT
*** Bug 637279 has been marked as a duplicate of this bug. ***
Comment 12 Kami 2011-05-17 00:33:12 PDT
Could you also put in 4.0.2, after we tested in Aurora?
Will 2011-05-17 Aurora build contain the fix?
Comment 13 Kami 2011-05-17 00:38:00 PDT
Ok, I tested 2011-05-16 version of Aurora and it was easy to crash. Crashreport tagged with:
"Testing fix of https://bugzilla.mozilla.org/show_bug.cgi?id=654707 on Aurora
THIS IS THE TEST BEFORE FIX (20110516)"

I will test with fresh release as soon as available.
Comment 14 Kyle Huey [:khuey] (khuey@mozilla.com) (Away until 6/13) 2011-05-17 06:14:24 PDT
There isn't going to be a 4.0.2, barring some sort of zero day security exploit.
Comment 15 Kami 2011-05-17 08:25:27 PDT
But it is a ugly crasher.
Comment 16 Robert Kaiser (not working on stability any more) 2011-05-17 08:44:12 PDT
(In reply to comment #15)
> But it is a ugly crasher.

Sure, but Firefox 5 is coming in about 5-6 weeks hopefully and will have it fixed. :)
Comment 17 Kami 2011-05-18 00:38:27 PDT
(In reply to comment #16)
> Sure, but Firefox 5 is coming in about 5-6 weeks hopefully and will have it
> fixed. :)

I don't think so, It means all of us have no stable version of Firefox for more than a month that I can recommend to use for production scene. You must understand this top 10 crasher hurts the browsing experience mainly Hungary. Plenty of Hungarian sites can crash the current version of Firefox 4.0.x. So I still want to propose this bug to put in to next bugfix release.
Comment 18 Scoobidiver (away) 2011-05-18 01:53:11 PDT
(In reply to comment #16)
> Sure, but Firefox 5 is coming in about 5-6 weeks hopefully and will have it
> fixed. :)
Normally, each minor update releases every 5 weeks, for instance, 4.0.1 was released on April 28th, 5 weeks after 4.0. So if you continue with this schedule, a could-be 4.0.2 would be expected at the beginning of June, before 5.0 that is scheduled on June, 21th. So there is a hole of 3 weeks in the release schedule.
Comment 19 Kami 2011-05-18 03:45:40 PDT
(In reply to comment #18)
> Normally, each minor update releases every 5 weeks, for instance, 4.0.1 was
> released on April 28th, 5 weeks after 4.0. So if you continue with this
> schedule, a could-be 4.0.2 would be expected at the beginning of June,
> before 5.0 that is scheduled on June, 21th. So there is a hole of 3 weeks in
> the release schedule.

So we have at least one week to get one liner (trivial?) crash fix to final version?
Comment 20 Robert Kaiser (not working on stability any more) 2011-05-18 04:27:29 PDT
(In reply to comment #17)
> So
> I still want to propose this bug to put in to next bugfix release.

There is no more 4.0.* planned. The "next bugfix release" is Firefox 5.
Comment 21 Scoobidiver (away) 2011-05-18 04:39:19 PDT
(In reply to comment #20)
> There is no more 4.0.* planned. The "next bugfix release" is Firefox 5.
Why bug 640968 and bug 617298 are marked as 4.0.2+?
Comment 22 Kyle Huey [:khuey] (khuey@mozilla.com) (Away until 6/13) 2011-05-18 05:52:14 PDT
That's for fennec.
Comment 23 Scoobidiver (away) 2011-05-22 01:37:31 PDT
It seems that there is going to be a desktop Firefox 4.0.2 (see bug 639303 comment 51). Can it be land in 4.0.2?
Comment 24 Robert Kaiser (not working on stability any more) 2011-05-22 02:48:58 PDT
(In reply to comment #23)
> It seems that there is going to be a desktop Firefox 4.0.2 (see bug 639303
> comment 51).

From all I know, there will be a TenFourFox 4.0.2 from mozilla-2.0, but no normal desktop release is planned.

Note You need to log in before you can comment on or make changes to this bug.