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




DOM: Core & HTML
8 years ago
6 years ago


(Reporter: wsmwk, Assigned: timeless)


({crash, topcrash-})

1.9.1 Branch
Windows Vista
crash, topcrash-

Firefox Tracking Flags

(status1.9.2 .2-fixed, status1.9.1 .9-fixed)


(crash signature)


(1 attachment)

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

8 years ago 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.
Flags: blocking-seamonkey2.0.2?

Comment 2

8 years ago 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

8 years ago
Related to bug 424027 perhaps?
(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

8 years ago
(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

8 years ago
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...
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
Component: General → DOM: Core & HTML
Flags: blocking-seamonkey2.0.3?
Keywords: topcrash → topcrash-
Product: SeaMonkey → Core
QA Contact: general → general
Version: SeaMonkey 2.0 Branch → 1.9.1 Branch

Comment 8

8 years ago
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.
Assignee: nobody → timeless

Comment 9

8 years ago
Created attachment 425015 [details] [diff] [review]

attachment 424981 [details] [diff] [review] reviewed by smaug in bug 540953 comment 5
Attachment #425015 - Flags: review+
Attachment #425015 - Flags: approval1.9.2.1?
Attachment #425015 - Flags: approval1.9.1.9?
Uh... how can GetCurrentDoc() return null if IsInDoc() is true?  Is the owner doc null while IsInDoc() is true or something?

Comment 11

8 years ago
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.
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

8 years ago
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.
Bug reference in the comments sounds good to me.
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.
Attachment #425015 - Flags: approval1.9.2.2?
Attachment #425015 - Flags: approval1.9.2.2+
Attachment #425015 - Flags: approval1.9.1.9?
Attachment #425015 - Flags: approval1.9.1.9+

Comment 16

8 years ago
Last Resolved: 8 years ago
status1.9.1: --- → .9-fixed
status1.9.2: --- → .2-fixed
Resolution: --- → FIXED
Nothing for QA to do here as there is no way to verify this fix directly.
Crash Signature: [@ nsHTMLAreaElement::UnbindFromTree(int, int)]
You need to log in before you can comment on or make changes to this bug.