Closed Bug 654707 Opened 9 years ago Closed 9 years ago

Crash [@ nsGlobalWindow::FireDelayedDOMEvents]

Categories

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

2.0 Branch
defect
Not set
critical

Tracking

()

RESOLVED FIXED
mozilla5
Tracking Status
firefox5 + fixed
firefox6 - ---
blocking2.0 --- ?

People

(Reporter: mayhemer, Assigned: mayhemer)

References

Details

Attachments

(1 file)

Attached patch v1Splinter Review
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
Attachment #530006 - Flags: review?(jst)
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!
without some steep crash trend, I don't think the release drivers are going to track this.
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.
Attachment #530006 - Flags: review?(jst) → review+
http://hg.mozilla.org/mozilla-central/rev/e985b26f23eb
Assignee: nobody → honzab.moz
Status: NEW → RESOLVED
Closed: 9 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla6
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.
Thanks for landing this on my behalf.
This is really more of an approval request than a tracking request afaict, but whatever - land it for 5 please!
Comment on attachment 530006 [details] [diff] [review]
v1

Can this land today to make aurora?
Attachment #530006 - Flags: approval-mozilla-aurora+
Could you also put in 4.0.2, after we tested in Aurora?
Will 2011-05-17 Aurora build contain the fix?
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.
blocking2.0: --- → ?
There isn't going to be a 4.0.2, barring some sort of zero day security exploit.
But it is a ugly crasher.
(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. :)
(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.
(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.
(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?
(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.
(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+?
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?
(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.
Target Milestone: mozilla6 → mozilla5
You need to log in before you can comment on or make changes to this bug.