Last Comment Bug 533061 - crash [@ nsHTMLAreaElement::UnbindFromTree(int, int)]
: crash [@ nsHTMLAreaElement::UnbindFromTree(int, int)]
: crash, topcrash-
Product: Core
Classification: Components
Component: DOM: Core & HTML (show other bugs)
: 1.9.1 Branch
: x86 Windows Vista
: -- critical (vote)
: ---
Assigned To: timeless
Depends on:
  Show dependency treegraph
Reported: 2009-12-05 02:28 PST by Wayne Mery (:wsmwk, NI for questions)
Modified: 2011-06-09 14:58 PDT (History)
8 users (show)
See Also:
Crash Signature:
QA Whiteboard:
Iteration: ---
Points: ---
Has Regression Range: ---
Has STR: ---

patch (736 bytes, patch)
2010-02-03 09:43 PST, timeless
timeless: review+
mbeltzner: approval1.9.2.2+
mbeltzner: approval1.9.1.9+
Details | Diff | Review

Description Wayne Mery (:wsmwk, NI for questions) 2009-12-05 02:28:05 PST
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...

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 

switching out of composer

tried to close a tab
Comment 1 Robert Kaiser (not working on stability any more) 2009-12-10 16:55:23 PST still has this ranked very high, see for more signatures. Putting up on 2.0.2 radar, we really should get an idea about this.
Comment 2 Robert Kaiser (not working on stability any more) 2009-12-10 17:03:38 PST 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 2009-12-11 02:18:07 PST
Related to bug 424027 perhaps?
Comment 4 Serge Gautherie (:sgautherie) 2010-01-11 09:13:00 PST
(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 (not working on stability any more) 2010-01-26 12:58:58 PST
(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 (not working on stability any more) 2010-02-03 05:34:24 PST
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, NI for questions) 2010-02-03 06:53:32 PST
In fact, I don't find any SM crashes other than 2.0.

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 2010-02-03 09:41:26 PST
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 2010-02-03 09:43:29 PST
Created attachment 425015 [details] [diff] [review]

attachment 424981 [details] [diff] [review] reviewed by smaug in bug 540953 comment 5
Comment 10 Boris Zbarsky [:bz] 2010-02-03 09:54:30 PST
Uh... how can GetCurrentDoc() return null if IsInDoc() is true?  Is the owner doc null while IsInDoc() is true or something?
Comment 11 timeless 2010-02-06 11:00:19 PST
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 [:bz] 2010-02-06 11:27:21 PST
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 2010-02-06 11:53:02 PST
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 [:bz] 2010-02-06 12:49:36 PST
Bug reference in the comments sounds good to me.
Comment 15 Mike Beltzner [:beltzner, not reading bugmail] 2010-02-22 10:39:04 PST
Comment on attachment 425015 [details] [diff] [review]

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 17 Al Billings [:abillings] 2010-03-12 17:03:15 PST
Nothing for QA to do here as there is no way to verify this fix directly.

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