654707 - Crash [@ nsGlobalWindow::FireDelayedDOMEvents]

Status: RESOLVED FIXED

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

Description

[Honza Bambas (:mayhemer)]

Attachment: 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)]

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]]

without some steep crash trend, I don't think the release drivers are going to track this.

Comment 3

[Johnny Stenback (:jst)]

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)]

http://hg.mozilla.org/mozilla-central/rev/e985b26f23eb

Comment 5

[Robert O'Callahan (:roc) (email my personal email if necessary)]

Thanks!

Comment 6

[chris hofmann]

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)]

Thanks for landing this on my behalf.

Comment 8

[Johnathan Nightingale [:johnath]]

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]]

Comment on attachment 530006 [details] [diff] [review]
v1

Can this land today to make aurora?

Comment 10

[Phil Ringnalda (:philor)]

http://hg.mozilla.org/releases/mozilla-aurora/rev/d3a58d815e2c

Comment 12

[Kami]

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]

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 (Exited; not receiving bugmail, old account, do not use)]

There isn't going to be a 4.0.2, barring some sort of zero day security exploit.

Comment 15

[Kami]

But it is a ugly crasher.

Comment 16

[Robert Kaiser]

(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]

(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)]

(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]

(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]

(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)]

(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 (Exited; not receiving bugmail, old account, do not use)]

That's for fennec.

Comment 23

[Scoobidiver (away)]

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]

(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.