533061 - crash [@ nsHTMLAreaElement::UnbindFromTree(int, int)]

Status: RESOLVED FIXED

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

Description

[Wayne Mery (:wsmwk)]

crash [@ nsHTMLAreaElement::UnbindFromTree(int, int)]
#3 crash for SM 2.0.1

signature also present in FF but I didn't check for stack matches.
many mention checking mail/gmail eg bg-de6b447e-31e6-41ad-8d06-15eec2091130

crashes with comments...

bp-6f08c7c3-4b21-46ee-b79a-b96de2091203
updating our school site
0	seamonkey.exe	nsHTMLAreaElement::UnbindFromTree	 content/html/content/src/nsHTMLAnchorElement.cpp:228
1	seamonkey.exe	nsElementDeletionObserver::NodeWillBeDestroyed	editor/libeditor/html/nsHTMLAnonymousUtils.cpp:130
2	seamonkey.exe	nsNodeUtils::LastRelease	content/base/src/nsNodeUtils.cpp:196
3	seamonkey.exe	nsGenericDOMDataNode::Release	content/base/src/nsGenericElement.cpp:4124
4	seamonkey.exe	nsAttrAndChildArray::Clear	content/base/src/nsAttrAndChildArray.cpp:662
5	seamonkey.exe	nsAttrAndChildArray::~nsAttrAndChildArray	content/base/src/nsAttrAndChildArray.cpp:133 

bp-9aa0545d-c5b4-4339-a70d-c957b2091123
switching out of composer

bp-0612e0d7-1a99-4457-bcef-6f97d2091111
tried to close a tab

Comment 1

[Robert Kaiser]

http://crash-stats.mozilla.com/topcrasher/byversion/SeaMonkey/2.0 still has this ranked very high, see http://crash-stats.mozilla.com/report/list?range_value=2&range_unit=weeks&signature=nsHTMLAreaElement%3A%3AUnbindFromTree%28int%2C%20int%29&version=SeaMonkey%3A2.0 for more signatures. Putting up on 2.0.2 radar, we really should get an idea about this.

Comment 2

[Robert Kaiser]

https://crash-stats.mozilla.com/report/list?version=Firefox%3A3.5.5&query_search=signature&query_type=exact&query=&date=&range_value=2&range_unit=weeks&do_query=&signature=nsHTMLAreaElement%3A%3AUnbindFromTree(int%2C says it also happens in Firefox often enough to make it onto a list - but SeaMonkey seems to hit it more often compared to the mass of users - 1024 reports on FF 3.5.5 in the last week (#246 in their topcrash list), but 218 on SeaMonkey 2.0 (#2).

Comment 3

[[e-mail]]

Related to bug 424027 perhaps?

Comment 4

[Serge Gautherie (:sgautherie)]

(In reply to comment #0)
> signature also present in FF but I didn't check for stack matches.

(Maybe depending on the stack,)
Should this bug be moved to Core then?
Or is there a Firefox bug already filed to depend on?

Comment 5

[Robert Kaiser]

(In reply to comment #4)
> Should this bug be moved to Core then?
> Or is there a Firefox bug already filed to depend on?

If you can figure out from the stack that this is really a cross-application crash and not just something that does something wrong in our code and that bubbles up to crash at a place where other things also cause a crash, then sure.

Else it would be good to investigate this.

Comment 6

[Robert Kaiser]

I don't see this in the SeaMonkey 2.0.2 topcrash list right now, but bug 540953 is there, which look similar.

This crash is #46 on the Thunderbird 3.0.1 topcrash list now, though, which implies it at least happens on both our products...

Comment 7

[Wayne Mery (:wsmwk)]

In fact, I don't find any SM crashes other than 2.0.

Thunderbird
bp-17e5ff86-fbfa-4e0f-ab9b-302cf2100112
0	thunderbird.exe	nsHTMLAreaElement::UnbindFromTree	 content/html/content/src/nsHTMLAnchorElement.cpp:228
1	thunderbird.exe	nsElementDeletionObserver::NodeWillBeDestroyed	editor/libeditor/html/nsHTMLAnonymousUtils.cpp:130
2	thunderbird.exe	nsNodeUtils::LastRelease	content/base/src/nsNodeUtils.cpp:196
3	thunderbird.exe	nsGenericDOMDataNode::Release	content/base/src/nsGenericElement.cpp:4124
4	xpcom_core.dll	nsXPCOMCycleCollectionParticipant::Unroot	objdir-tb/mozilla/xpcom/build/nsCycleCollectionParticipant.cpp:74
5	xpcom_core.dll	nsCycleCollector::CollectWhite	xpcom/base/nsCycleCollector.cpp:1734
6	xpcom_core.dll	nsCycleCollector::FinishCollection	xpcom/base/nsCycleCollector.cpp:2570
7	thunderbird.exe	XPCCycleCollectGCCallback	js/src/xpconnect/src/nsXPConnect.cpp:403
8	js3250.dll	js_GC	js/src/jsgc.cpp:3788
9	js3250.dll	JS_GC	js/src/jsapi.cpp:2458
10	thunderbird.exe	nsXPConnect::Collect	js/src/xpconnect/src/nsXPConnect.cpp:477
11	xpcom_core.dll	nsCycleCollector::Collect	xpcom/base/nsCycleCollector.cpp:2386
12	xpcom_core.dll	nsCycleCollector_collect	xpcom/base/nsCycleCollector.cpp:3045
13	thunderbird.exe	nsJSContext::CC	dom/src/base/nsJSEnvironment.cpp:3512
14	thunderbird.exe	nsUserActivityObserver::Observe	dom/src/base/nsJSEnvironment.cpp:266
15	xpcom_core.dll	nsObserverList::NotifyObservers	xpcom/ds/nsObserverList.cpp:128
16	xpcom_core.dll	nsObserverService::NotifyObservers	xpcom/ds/nsObserverService.cpp:181
17	thunderbird.exe	nsUITimerCallback::Notify	content/events/src/nsEventStateManager.cpp:355
18	xpcom_core.dll	nsTimerImpl::Fire	xpcom/threads/nsTimerImpl.cpp:423
19	xpcom_core.dll	nsTimerEvent::Run	xpcom/threads/nsTimerImpl.cpp:512
20	xpcom_core.dll	nsThread::ProcessNextEvent	xpcom/threads/nsThread.cpp:521

Comment 8

[timeless]

so this is the same crash as bug 540953, and the patch I posted there actually belongs here.

The reason that it was posted there is because the compiler folded the code since it's identical :).

This crash applies to 1.9.1 and 1.9.2.

Comment 9

[timeless]

Attachment: patch

attachment 424981 [details] [diff] [review] reviewed by smaug in bug 540953 comment 5

Comment 10

[Boris Zbarsky [:bzbarsky]]

Uh... how can GetCurrentDoc() return null if IsInDoc() is true?  Is the owner doc null while IsInDoc() is true or something?

Comment 11

[timeless]

bz: wsmwk's bug 540953 comment 7 points to bug 480300 comment 21
 --- by you @ 2009-03-04 11:01:25 PST
> Created an attachment 365482 [details] [diff] [review] -- Wallpaper I [bz] just pushed
> I [bz] just checked this in.  This is Mats' suggestion, basically. 
> It's wallpaper, but with any luck it'll at least stop the test oranges...

So, respectfully, I'd request that you allow me the same right that you had in pushing uninvestigated wallpaper, certainly if you couldn't figure out why your change worked, I don't see how you can ask me to figure it out :/. That bug does indicate the problem went away with your wallpaper.

If you'd prefer that we use your bug to back port this wallpaper instead of claiming that I wrote the patch, that's fine with me.

Comment 12

[Boris Zbarsky [:bzbarsky]]

To be clear, I have no problem with wallpaper as long as:

1) We're clear that it's wallpaper
2) We don't plan to just close the bug and walk away after pushing it

I'm also fine with an answer like "I don't know, but we get here somehow" to comment 10; I just want us to be clear on the fact that if we get into this situation then there's something really broken going on that needs to be fixed, regardless of whether we wallpaper this immediate crash.

Comment 13

[timeless]

I fully intend to walk away from this pair of crashes on branches once spackle is applied (with about the same effort that you did for trunk 10 months ago).

However we can leave a note in bug 480300 such that if peterv ever steps up to that bug and finds a fix, you and the rest of the layout team can choose whether you wish to backport it. Until then, it's incredibly unfair to normal end users that we have spackle for trunk but not our releases (which they might never be able to run because we discriminate against their platform...).

If you'd like there to be a bug reference in the sources pointing to bug 480300, that can certainly be arranged.

Comment 14

[Boris Zbarsky [:bzbarsky]]

Bug reference in the comments sounds good to me.

Comment 15

[Mike Beltzner [:beltzner, not reading bugmail]]

Comment on attachment 425015 [details] [diff] [review]
patch

a=beltzner for 1.9.2 and 1.9.1, but instead of leaving this bug open, please file a followup with the remaining problem. We'll need this to be marked FIXED.

Comment 16

[timeless]

http://hg.mozilla.org/releases/mozilla-1.9.2/rev/d2b5d6c67f6a
http://hg.mozilla.org/releases/mozilla-1.9.1/rev/76cccd53bd7e

Comment 17

[Al Billings [:abillings - ex-MoCo]]

Nothing for QA to do here as there is no way to verify this fix directly.