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
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.
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).
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?
(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.
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
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.
Created attachment 425015 [details] [diff] [review]
attachment 424981 [details] [diff] [review] reviewed by smaug in bug 540953 comment 5
Uh... how can GetCurrentDoc() return null if IsInDoc() is true? Is the owner doc null while IsInDoc() is true or something?
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.
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.
Nothing for QA to do here as there is no way to verify this fix directly.