349463 - Crash on quit in AtomImpl::~AtomImpl @ PL_DHashTableOperate

Status: RESOLVED INCOMPLETE

(Core :: XPCOM, defect)

Description

[Mark Newland]

User-Agent:       Mozilla/5.0 (Macintosh; U; Intel Mac OS X; en-US; rv:1.8.1b1) Gecko/20060817 Camino/1.0+
Build Identifier: Mozilla/5.0 (Macintosh; U; Intel Mac OS X; en-US; rv:1.8.1b1) Gecko/20060817 Camino/1.0+

Camino crashed on quit with a few windows open.

Reproducible: Always

Steps to Reproduce:
1.Select File Quit
2.
3.

Actual Results:  
Camino crashes.

Expected Results:  
Application should quit.

Comment 1

[Mark Newland]

Attachment: Camino crashlog

Comment 2

[Smokey Ardisson (offline for a while; not following bugs - do not email)]

We're seeing this a bit on Talkback in recent builds (but the stack is different than the one ispiked reported in July)....

I don't see any similar crashes in Core in my searching.

Comment 3

[Adam Guthrie]

Yeah, I'm pretty sure this crash is different from the other PL_DHashTableOperate and SearchTable crashes on shutdown.

Here's an example talkback report:

Incident ID: 22879816
Stack Signature	PL_DHashTableOperate() 23437c87
Product ID	Camino11
Build ID	2006083001
Trigger Time	2006-09-04 07:32:54.0
Platform	MacOSX
Operating System	Darwin 8.7.0
Module	libxpcom_core.dylib.1.0.0 + (00001ed8)
URL visited	
User Comments	
Since Last Crash	140109 sec
Total Uptime	140109 sec
Trigger Reason	SIGBUS: Bus Error: (signal 10)
Source File, Line No.	N/A
Stack Trace 	
PL_DHashTableOperate()
AtomImpl::~AtomImpl()
AtomImpl::Release()
nsAtomList::~nsAtomList()  [mozilla/extensions/transformiix/source/xslt/txXSLTNumberCounters.cpp, line 750]
nsCSSSelector::Reset()  [mozilla/extensions/transformiix/source/xslt/txXSLTNumberCounters.cpp, line 323]
nsCSSSelector::~nsCSSSelector()  [mozilla/extensions/transformiix/source/xslt/txXSLTNumberCounters.cpp, li]
nsCSSSelectorList::~nsCSSSelectorList()  [mozilla/extensions/transformiix/source/xslt/txXSLTNumberCounters]
nsCSSSelectorList::~nsCSSSelectorList()  [mozilla/extensions/transformiix/source/xslt/txXSLTNumberCounters]
CSSStyleRuleImpl::~CSSStyleRuleImpl()  [mozilla/extensions/transformiix/source/xslt/txXSLTNumberCounters.c]
nsCSSRule::Release()  [mozilla/layout/style/nsCSSRule.cpp, line 61]
nsSupportsArray::Clear()
nsSupportsArray::DeleteArray()
nsSupportsArray::Release()
nsCSSStyleSheetInner::~nsCSSStyleSheetInner()  [mozilla/layout/style/nsCSSStyleSheet.cpp, line 1195]
nsCSSStyleSheet::~nsCSSStyleSheet()  [mozilla/layout/style/nsCSSStyleSheet.cpp, line 1386]
nsCSSStyleSheet::Release()  [mozilla/layout/style/nsCSSStyleSheet.cpp, line 1406]
nsBaseHashtableET<nsURIHashKey, nsCOMPtr<nsICSSStyleSheet> >::~nsBaseHashtableET<nsURIHashKey, nsCOMPtr<nsICSSStyleSheet> >()
PL_DHashTableFinish()
CSSLoaderImpl::~CSSLoaderImpl()  [mozilla/extensions/transformiix/source/xslt/txXSLTNumberCounters.cpp, li]
CSSLoaderImpl::Release()  [mozilla/extensions/transformiix/source/xslt/txXSLTNumberCounters.cpp, line 259]
nsDocument::~nsDocument()  [mozilla/content/base/src/nsDocument.cpp, line 892]
nsHTMLDocument::~nsHTMLDocument()  [mozilla/content/html/document/src/nsHTMLDocument.cpp, line 299]
nsDocument::Release()  [mozilla/content/base/src/nsDocument.cpp, line 974]
nsEventStateManager::~nsEventStateManager()  [mozilla/content/events/src/nsEventStateManager.cpp, line 262]
nsEventStateManager::Release()  [mozilla/content/events/src/nsEventStateManager.cpp, line 459]
nsPresContext::~nsPresContext()  [mozilla/extensions/transformiix/source/xslt/txXSLTNumberCounters.cpp, li]
nsPresContext::Release()  [mozilla/extensions/transformiix/source/xslt/txXSLTNumberCounters.cpp, line 132]
nsDOMEvent::~nsDOMEvent()  [mozilla/content/events/src/nsDOMEvent.cpp, line 145]
nsDOMPopupBlockedEvent::~nsDOMPopupBlockedEvent()  [mozilla/extensions/transformiix/source/xslt/txXSLTNumb]
nsDOMEvent::Release()  [mozilla/content/events/src/nsDOMEvent.cpp, line 148]
ReleaseObjects()
nsVoidArray::EnumerateForwards()
nsCOMArray_base::Clear()
nsArray::Clear()
nsArray::~nsArray()
nsArray::Release()
...

Comment 4

[Smokey Ardisson (offline for a while; not following bugs - do not email)]

This is the #2 topcrasher for Camino on the 1.8branch.

Comment 5

[Reinout van Schouwen]

The stack trace looks a bit similar to the one from bug 236688.

Comment 6

[Smokey Ardisson (offline for a while; not following bugs - do not email)]

This vanished from our branch topcrashers for a while, but it's back again with a vengeance recently.  Who can we get to look into this?

Comment 7

[Mike Pinkerton (not reading bugmail)]

here's what darin suggested:

"maybe the atom table (gAtomTable) has already been shutdown?  or maybe the AtomImpl is invalid (e.g., perhaps the nsCSSSelector object has an invalid nsIAtom reference?"

Comment 8

[timeless]

darin's right

Breakpoint 1, NS_ShutdownXPCOM_P (servMgr=0x0) at
/home/romaxa/microbcomponent/maemo-browser-mozilla-engine/build-tree/mozilla/xpcom/build/nsXPComInit.cpp:691
warning: Source file is more recent than executable.
691         NS_ENSURE_STATE(NS_IsMainThread());
Current language:  auto; currently c++
(gdb) where
#0  NS_ShutdownXPCOM_P (servMgr=0x0) at
/home/romaxa/microbcomponent/maemo-browser-mozilla-engine/build-tree/mozilla/xpcom/build/nsXPComInit.cpp:691
#1  0xa645518a in XRE_TermEmbedding () at
/home/romaxa/microbcomponent/maemo-browser-mozilla-engine/build-tree/mozilla/toolkit/xre/nsEmbedFunctions.cpp:160
#2  0xa62ca038 in EmbedPrivate::PopStartup () at
/home/romaxa/microbcomponent/maemo-browser-mozilla-engine/build-tree/mozilla/embedding/browser/gtk/branchsrc/EmbedPrivate.cpp:918
#3  0xa62c8d15 in ~EmbedPrivate (this=0x81b0fc8) at
/home/romaxa/microbcomponent/maemo-browser-mozilla-engine/build-tree/mozilla/embedding/browser/gtk/branchsrc/EmbedPrivate.cpp:451
#4  0xa62c49d3 in gtk_moz_embed_destroy (object=0x81b0fc8) at
/home/romaxa/microbcomponent/maemo-browser-mozilla-engine/build-tree/mozilla/embedding/browser/gtk/branchsrc/gtkmozembed2.cpp:680
#5  0xa7b57a38 in g_cclosure_marshal_VOID__VOID () from
/usr/lib/libgobject-2.0.so.0
#6  0xa7b415d9 in g_cclosure_new_swap () from /usr/lib/libgobject-2.0.so.0
#7  0xa7b4129b in g_closure_invoke () from /usr/lib/libgobject-2.0.so.0
#8  0xa7b561df in g_signal_has_handler_pending () from
/usr/lib/libgobject-2.0.so.0
#9  0xa7b57358 in g_signal_emit_valist () from /usr/lib/libgobject-2.0.so.0
#10 0xa7b57646 in g_signal_emit () from /usr/lib/libgobject-2.0.so.0
#11 0xa7de5635 in gtk_object_destroy () from /usr/lib/libgtk-x11-2.0.so.0
#12 0xa7ec8644 in gtk_widget_get_default_direction () from
/usr/lib/libgtk-x11-2.0.so.0
#13 0xa7b474a7 in g_object_run_dispose () from /usr/lib/libgobject-2.0.so.0
#14 0xa7de55c8 in gtk_object_destroy () from /usr/lib/libgtk-x11-2.0.so.0
#15 0xa7ec2b81 in gtk_widget_destroy () from /usr/lib/libgtk-x11-2.0.so.0
#16 0xa790b111 in browser_engine_close_en_window (self=0x8197000,
en_win=0x81ac920) at browserengine.c:750
#17 0xa790b67b in browser_engine_close_by_window (self=0x8197000,
widget=0x80c9810) at browserengine.c:868
#18 0x08059c3d in view_close_by_win_cb (widget=0x80c9000,
win_child=0x80c9810, real_close=0xafda8154, self=0x808b808) at
browsercontroller_app_cb.c:77
#19 0x08066ae4 in browser_view_marshal_VOID__OBJECT_POINTER
(closure=0x8144000, return_value=0x0, n_param_values=3,
param_values=0xafda7fb0, invocation_hint=0xafda7e88, marshal_data=0x0)
   at browserviewmarshal.c:81
#20 0xa7b4129b in g_closure_invoke () from /usr/lib/libgobject-2.0.so.0
#21 0xa7b56408 in g_signal_has_handler_pending () from
/usr/lib/libgobject-2.0.so.0
#22 0xa7b57358 in g_signal_emit_valist () from /usr/lib/libgobject-2.0.so.0
#23 0xa7b57646 in g_signal_emit () from /usr/lib/libgobject-2.0.so.0
#24 0x08051e55 in browser_win_child_event_delete (widget=0x80c9810,
event=0x8902c18, self=0x80c9000) at browserview.c:250
#25 0xa7dc50d0 in gtk_marshal_VOID__UINT_STRING () from
/usr/lib/libgtk-x11-2.0.so.0
#26 0xa7b4129b in g_closure_invoke () from /usr/lib/libgobject-2.0.so.0
#27 0xa7b56408 in g_signal_has_handler_pending () from
/usr/lib/libgobject-2.0.so.0
#28 0xa7b570ad in g_signal_emit_valist () from /usr/lib/libgobject-2.0.so.0
---Type <return> to continue, or q <return> to quit---
#29 0xa7b57646 in g_signal_emit () from /usr/lib/libgobject-2.0.so.0
#30 0xa7ec4d94 in gtk_widget_activate () from /usr/lib/libgtk-x11-2.0.so.0
#31 0xa7dc3aae in gtk_main_do_event () from /usr/lib/libgtk-x11-2.0.so.0
#32 0xa7c5e0e1 in gdk_event_get_graphics_expose () from
/usr/lib/libgdk-x11-2.0.so.0
#33 0xa7ad28e7 in g_main_context_dispatch () from /usr/lib/libglib-2.0.so.0
#34 0xa7ad4285 in g_main_context_acquire () from /usr/lib/libglib-2.0.so.0
#35 0xa7ad45aa in g_main_loop_run () from /usr/lib/libglib-2.0.so.0
#36 0xa7dc2ad3 in gtk_main () from /usr/lib/libgtk-x11-2.0.so.0
#37 0x08051228 in main (argc=1, argv=0xafda87d4) at main.c:201
(gdb) /dev/dsp: Device or resource busy

(gdb) c
Continuing.

Program received signal SIGSEGV, Segmentation fault.
0xafda73f8 in ?? ()
(gdb) bt
#0  0xafda73f8 in ?? ()
#1  0xa6c7d7f6 in PL_DHashTableOperate (table=0xa6ebb760,
key=0xafda7470, op=PL_DHASH_LOOKUP) at pldhash.c:456
#2  0xa6c8ba46 in AtomImpl::Release (this=0x84cc508) at
/home/romaxa/microbcomponent/maemo-browser-mozilla-engine/build-tree/mozilla/xpcom/ds/nsAtomTable.cpp:402
#3  0xa6c7e199 in ~nsCOMPtr_base (this=0x84cc558) at nsCOMPtr.cpp:81
#4  0xa6747845 in nsCSSSelector::Reset (this=0x84cc530) at nsINodeInfo.h:87
#5  0xa674775c in ~nsCSSSelector (this=0x84cc530) at
/home/romaxa/microbcomponent/maemo-browser-mozilla-engine/build-tree/mozilla/layout/style/nsCSSStyleRule.cpp:306
#6  0xa6748cd6 in ~nsCSSSelectorList (this=0x84cc520) at
/home/romaxa/microbcomponent/maemo-browser-mozilla-engine/build-tree/mozilla/layout/style/nsCSSStyleRule.cpp:309
#7  0xa674a5fb in ~CSSStyleRuleImpl (this=0x84cc5b8) at
/home/romaxa/microbcomponent/maemo-browser-mozilla-engine/build-tree/mozilla/layout/style/nsCSSStyleRule.cpp:1230
#8  0xa673111e in nsCSSRule::Release (this=0x84cc5b8) at
/home/romaxa/microbcomponent/maemo-browser-mozilla-engine/build-tree/mozilla/layout/style/nsCSSRule.cpp:64
#9  0xa674a7ff in CSSStyleRuleImpl::Release (this=0xa6ebb760) at
/home/romaxa/microbcomponent/maemo-browser-mozilla-engine/build-tree/mozilla/layout/style/nsCSSStyleRule.cpp:1256
#10 0xa6c7e6e4 in ~nsCOMArray_base (this=0x84e21d0) at nsCOMArray.cpp:61
#11 0xa673b96d in ~nsCOMArray (this=0xa6ebb760) at nsCOMArray.h:156
#12 0xa674d2e4 in ~nsCSSStyleSheetInner (this=0x84e2198) at
/home/romaxa/microbcomponent/maemo-browser-mozilla-engine/build-tree/mozilla/layout/style/nsCSSStyleSheet.cpp:533
#13 0xa674d3e7 in nsCSSStyleSheetInner::RemoveSheet (this=0x84e2198,
aParentSheet=0x84e2148)
   at /home/romaxa/microbcomponent/maemo-browser-mozilla-engine/build-tree/mozilla/layout/style/nsCSSStyleSheet.cpp:553
#14 0xa674e026 in ~nsCSSStyleSheet (this=0x84e2148) at
/home/romaxa/microbcomponent/maemo-browser-mozilla-engine/build-tree/mozilla/layout/style/nsCSSStyleSheet.cpp:712
#15 0xa674e323 in nsCSSStyleSheet::Release (this=0x84e2148) at
/home/romaxa/microbcomponent/maemo-browser-mozilla-engine/build-tree/mozilla/layout/style/nsCSSStyleSheet.cpp:736
#16 0xa6c7e6e4 in ~nsCOMArray_base (this=0x82cbfb0) at nsCOMArray.cpp:61
#17 0xa663a223 in ~nsCOMArray (this=0xa6ebb760) at nsCOMArray.h:156
#18 0xa664903f in ~PresShell (this=0x82cc090) at
/home/romaxa/microbcomponent/maemo-browser-mozilla-engine/build-tree/mozilla/layout/base/nsPresShell.cpp:1699
#19 0xa66489f1 in PresShell::Release (this=0x82cc090) at
/home/romaxa/microbcomponent/maemo-browser-mozilla-engine/build-tree/mozilla/layout/base/nsPresShell.cpp:1677
#20 0xa6c7e199 in ~nsCOMPtr_base (this=0x836387c) at nsCOMPtr.cpp:81
#21 0xa62d1e93 in ~EmbedEventListener (this=0x8363858) at
/home/romaxa/microbcomponent/maemo-browser-mozilla-engine/build-tree/mozilla/embedding/browser/gtk/branchsrc/EmbedEventListener.cpp:61
#22 0xa62d1f3e in EmbedEventListener::Release (this=0x8363858)
   at /home/romaxa/microbcomponent/maemo-browser-mozilla-engine/build-tree/mozilla/embedding/browser/gtk/branchsrc/EmbedEventListener.cpp:70
#23 0xa6c7e199 in ~nsCOMPtr_base (this=0x81b0fe8) at nsCOMPtr.cpp:81
#24 0xa62c8d45 in ~EmbedPrivate (this=0x81b0fc8) at nsCOMPtr.h:1650
#25 0xa62c49d3 in gtk_moz_embed_destroy (object=0x81b0fc8) at
/home/romaxa/microbcomponent/maemo-browser-mozilla-engine/build-tree/mozilla/embedding/browser/gtk/branchsrc/gtkmozembed2.cpp:680
#26 0xa7b57a38 in g_cclosure_marshal_VOID__VOID () from
/usr/lib/libgobject-2.0.so.0
#27 0xa7b415d9 in g_cclosure_new_swap () from /usr/lib/libgobject-2.0.so.0
---Type <return> to continue, or q <return> to quit---
#28 0xa7b4129b in g_closure_invoke () from /usr/lib/libgobject-2.0.so.0
#29 0xa7b561df in g_signal_has_handler_pending () from
/usr/lib/libgobject-2.0.so.0
#30 0xa7b57358 in g_signal_emit_valist () from /usr/lib/libgobject-2.0.so.0
#31 0xa7b57646 in g_signal_emit () from /usr/lib/libgobject-2.0.so.0
#32 0xa7de5635 in gtk_object_destroy () from /usr/lib/libgtk-x11-2.0.so.0
#33 0xa7ec8644 in gtk_widget_get_default_direction () from
/usr/lib/libgtk-x11-2.0.so.0
#34 0xa7b474a7 in g_object_run_dispose () from /usr/lib/libgobject-2.0.so.0
#35 0xa7de55c8 in gtk_object_destroy () from /usr/lib/libgtk-x11-2.0.so.0
#36 0xa7ec2b81 in gtk_widget_destroy () from /usr/lib/libgtk-x11-2.0.so.0
#37 0xa790b111 in browser_engine_close_en_window (self=0x8197000,
en_win=0x81ac920) at browserengine.c:750
#38 0xa790b67b in browser_engine_close_by_window (self=0x8197000,
widget=0x80c9810) at browserengine.c:868
#39 0x08059c3d in view_close_by_win_cb (widget=0x80c9000,
win_child=0x80c9810, real_close=0xafda8154, self=0x808b808) at
browsercontroller_app_cb.c:77
#40 0x08066ae4 in browser_view_marshal_VOID__OBJECT_POINTER
(closure=0x8144000, return_value=0x0, n_param_values=3,
param_values=0xafda7fb0, invocation_hint=0xafda7e88, marshal_data=0x0)
   at browserviewmarshal.c:81
#41 0xa7b4129b in g_closure_invoke () from /usr/lib/libgobject-2.0.so.0
#42 0xa7b56408 in g_signal_has_handler_pending () from
/usr/lib/libgobject-2.0.so.0
#43 0xa7b57358 in g_signal_emit_valist () from /usr/lib/libgobject-2.0.so.0
#44 0xa7b57646 in g_signal_emit () from /usr/lib/libgobject-2.0.so.0
#45 0x08051e55 in browser_win_child_event_delete (widget=0x80c9810,
event=0x8902c18, self=0x80c9000) at browserview.c:250
#46 0xa7dc50d0 in gtk_marshal_VOID__UINT_STRING () from
/usr/lib/libgtk-x11-2.0.so.0
#47 0xa7b4129b in g_closure_invoke () from /usr/lib/libgobject-2.0.so.0
#48 0xa7b56408 in g_signal_has_handler_pending () from
/usr/lib/libgobject-2.0.so.0
#49 0xa7b570ad in g_signal_emit_valist () from /usr/lib/libgobject-2.0.so.0
#50 0xa7b57646 in g_signal_emit () from /usr/lib/libgobject-2.0.so.0
#51 0xa7ec4d94 in gtk_widget_activate () from /usr/lib/libgtk-x11-2.0.so.0
#52 0xa7dc3aae in gtk_main_do_event () from /usr/lib/libgtk-x11-2.0.so.0
#53 0xa7c5e0e1 in gdk_event_get_graphics_expose () from
/usr/lib/libgdk-x11-2.0.so.0
#54 0xa7ad28e7 in g_main_context_dispatch () from /usr/lib/libglib-2.0.so.0
#55 0xa7ad4285 in g_main_context_acquire () from /usr/lib/libglib-2.0.so.0
#56 0xa7ad45aa in g_main_loop_run () from /usr/lib/libglib-2.0.so.0
---Type <return> to continue, or q <return> to quit---
#57 0xa7dc2ad3 in gtk_main () from /usr/lib/libgtk-x11-2.0.so.0
#58 0x08051228 in main (argc=1, argv=0xafda87d4) at main.c:201
(gdb)

Comment 9

[Oleg Romashin (:romaxa)]

Probably same problem with JS:

#2  0xa6f44d32 in JS_DHashTableOperate (table=0x81ca0f8, key=0x816badc, op=JS_DHASH_ADD) at mozilla/js/src/jsdhash.c:573
(gdb) bt
#0  JS_Assert (s=0xa700f67c "JS_DHASH_ENTRY_IS_FREE(newEntry)", file=0xa700f510 "mozilla/js/src/jsdhash.c", ln=517) at mozilla/js/src/jsutil.c:63
#1  0xa6f44b50 in ChangeTable (table=0x81ca0f8, deltaLog2=1) at mozilla/js/src/jsdhash.c:517
#2  0xa6f44d32 in JS_DHashTableOperate (table=0x81ca0f8, key=0x816badc, op=JS_DHASH_ADD) at mozilla/js/src/jsdhash.c:573
#3  0xa6fdc937 in InsertPropertyTreeChild (rt=0x8110ae8, parent=0x81f32ec, child=0x816badc, sweptChunk=0x0) at mozilla/js/src/jsscope.c:591
#4  0xa6fde5b6 in js_SweepScopeProperties (rt=0x8110ae8) at mozilla/js/src/jsscope.c:1727
#5  0xa6f6b996 in js_GC (cx=0x8112fa8, gckind=GC_NORMAL) at mozilla/js/src/jsgc.c:3030
#6  0xa6f39053 in js_DestroyContext (cx=0x8112fa8, mode=JSDCM_FORCE_GC) at mozilla/js/src/jscntxt.c:404
#7  0xa6f25c0c in JS_DestroyContext (cx=0x8112fa8) at mozilla/js/src/jsapi.c:969
#8  0xa621345c in mozJSComponentLoader::UnloadModules (this=0x810baa8) at mozilla/js/src/xpconnect/loader/mozJSComponentLoader.cpp:1194
#9  0xa6213e93 in mozJSComponentLoader::Observe (this=0x810baa8, subject=0x0, topic=0xa6e5a4b2 "xpcom-shutdown-loaders", data=0x0) at mozilla/js/src/xpconnect/loader/mozJSComponentLoader.cpp:1218
#10 0xa6b8804f in NS_ShutdownXPCOM_P (servMgr=0x0) at mozilla/xpcom/build/nsXPComInit.cpp:790
#11 0xa616d55c in XRE_TermEmbedding () at mozilla/toolkit/xre/nsEmbedFunctions.cpp:160
#12 0xa617edf7 in EmbedPrivate::PopStartup () at mozilla/embedding/browser/gtk/branchsrc/EmbedPrivate.cpp:918
#13 0xa617fca6 in ~EmbedPrivate (this=0x80ca648) at mozilla/embedding/browser/gtk/branchsrc/EmbedPrivate.cpp:451
#14 0xa6178ea8 in gtk_moz_embed_destroy (object=0x80b91e8) at mozilla/embedding/browser/gtk/branchsrc/gtkmozembed2.cpp:680
#15 0xa7994e1b in IA__g_cclosure_marshal_VOID__VOID (closure=0x80a6208, return_value=0x0, n_param_values=1, param_values=0xaf8aca5c, invocation_hint=0xaf8ac96c, marshal_data=0xa6178da2) at gmarshal.c:77
#16 0xa7985f49 in g_type_class_meta_marshal (closure=0x80a6208, return_value=0x0, n_param_values=1, param_values=0xaf8aca5c, invocation_hint=0xaf8ac96c, marshal_data=0x4c) at gclosure.c:567
#17 0xa7987a7c in IA__g_closure_invoke (closure=0x80a6208, return_value=0x0, n_param_values=1, param_values=0xaf8aca5c, invocation_hint=0xaf8ac96c) at gclosure.c:490
#18 0xa79986d6 in signal_emit_unlocked_R (node=0x80a6220, detail=0, instance=0x80b91e8, emission_return=0x0, instance_and_params=0xaf8aca5c) at gsignal.c:2556
#19 0xa7999429 in IA__g_signal_emit_valist (instance=0x80b91e8, signal_id=9, detail=0, var_args=0xaf8acc9c "Ø\234ç§Ø\234ç§è\221\v\bÈÌ\212¯CEÛ§è\221\v\bè\221\v\b´ñ\006\bðv\233§ðv\233§è\221\v\bèÌ\212¯1 \230§è\221\v\bP") at gsignal.c:2199
#20 0xa79995d9 in IA__g_signal_emit (instance=0x80b91e8, signal_id=9, detail=0) at gsignal.c:2243
#21 0xa7cdf6ef in gtk_object_destroy () from /usr/lib/libgtk-x11-2.0.so.0
#22 0xa7db4543 in gtk_widget_hide () from /usr/lib/libgtk-x11-2.0.so.0
#23 0xa798a031 in IA__g_object_run_dispose (object=0x80b91e8) at gobject.c:573
#24 0xa7cdf4fe in gtk_object_destroy () from /usr/lib/libgtk-x11-2.0.so.0
#25 0xa7db4725 in gtk_widget_destroy () from /usr/lib/libgtk-x11-2.0.so.0
#26 0xa7bf40d0 in gtk_box_pack_start_defaults () from /usr/lib/libgtk-x11-2.0.so.0
#27 0xa7c2ece9 in gtk_container_foreach () from /usr/lib/libgtk-x11-2.0.so.0
#28 0xa7c2f62e in _gtk_container_dequeue_resize_handler () from /usr/lib/libgtk-x11-2.0.so.0
#29 0xa7994e1b in IA__g_cclosure_marshal_VOID__VOID (closure=0x80a6208, return_value=0x0, n_param_values=1, param_values=0xaf8acffc, invocation_hint=0xaf8acf0c, marshal_data=0xa7c2f5f0) at gmarshal.c:77
#30 0xa7985f49 in g_type_class_meta_marshal (closure=0x80a6208, return_value=0x0, n_param_values=1, param_values=0xaf8acffc, invocation_hint=0xaf8acf0c, marshal_data=0x4c) at gclosure.c:567
#31 0xa7987a7c in IA__g_closure_invoke (closure=0x80a6208, return_value=0x0, n_param_values=1, param_values=0xaf8acffc, invocation_hint=0xaf8acf0c) at gclosure.c:490
#32 0xa79986d6 in signal_emit_unlocked_R (node=0x80a6220, detail=0, instance=0x806f160, emission_return=0x0, instance_and_params=0xaf8acffc) at gsignal.c:2556
#33 0xa7999429 in IA__g_signal_emit_valist (instance=0x806f160, signal_id=9, detail=0, var_args=0xaf8ad23c "Ø\234ç§Ø\234ç§`ñ\006\bhÒ\212¯CEÛ§`ñ\006\b`ñ\006

Comment 10

[Steven Kortze]

I am also seeing this while using the ProfileManager switch with Minefield (Gecko/20070130 Minefield/3.0a2pre). This does not appear if you are not using the ProfileManager switch. I'm using it because I use Firefox 2 for my UoP classes and Minefield for other web browsing.

You generally need to launch and quit Minefield after an update to see this.

1. Launch Minefield. To see this problem, you need to be using the ProfileManager switch. 
2. Select the appropriate profile.
3. Minefield relaunches using the profile, puts another Minefield icon in the Mac OS X Dock and then Mac OS X shows a dialog that the application has crashed and logs the crash to the firefox-bin.crash.log file. 

Crash log dump for Thread 0:
Date/Time:      2007-01-30 19:30:14.289 -0500
OS Version:     10.4.8 (Build 8L2127)
Report Version: 4

Command: firefox-bin
Path:    /Applications/Minefield.app/Contents/MacOS/firefox-bin
Parent:  WindowServer [71]

Version: 3.0a2pre (3.0a2pre)

PID:    360
Thread: 0

Exception:  EXC_BAD_ACCESS (0x0001)
Codes:      KERN_PROTECTION_FAILURE (0x0002) at 0x0000000c

Thread 0 Crashed:
0   libxpcom_core.dylib 	0x00dac62c PL_DHashTableOperate + 24
1   libxpcom_core.dylib 	0x00db5ccf AtomImpl::~AtomImpl [in-charge]() + 61
2   libxpcom_core.dylib 	0x00db5d55 AtomImpl::~AtomImpl [in-charge]() + 195
3   libxpcom_core.dylib 	0x00dace18 nsCOMPtr_base::~nsCOMPtr_base [not-in-charge]() + 20
4   org.mozilla.firefox 	0x003cb773 nsCSSSelector::Reset() + 73
5   org.mozilla.firefox 	0x003cb810 nsCSSSelector::~nsCSSSelector [in-charge]() + 20
6   org.mozilla.firefox 	0x003cb869 nsCSSSelectorList::~nsCSSSelectorList [in-charge]() + 25
7   org.mozilla.firefox 	0x003cb8d5 CSSStyleRuleImpl::~CSSStyleRuleImpl [in-charge deleting]() + 39
8   org.mozilla.firefox 	0x005789f7 nsCSSRule::nsCSSRule[not-in-charge](nsCSSRule const&) + 95
9   libxpcom_core.dylib 	0x00dad205 nsCOMArray_base::~nsCOMArray_base [not-in-charge]() + 49
10  org.mozilla.firefox 	0x0016904e nsCSSStyleSheetInner::~nsCSSStyleSheetInner [in-charge deleting]() + 84
11  org.mozilla.firefox 	0x0016876a nsCSSStyleSheet::~nsCSSStyleSheet [in-charge deleting]() + 216
12  org.mozilla.firefox 	0x001679ea nsMediaList::~nsMediaList [in-charge]() + 144
13  libxpcom_core.dylib 	0x00dace18 nsCOMPtr_base::~nsCOMPtr_base [not-in-charge]() + 20
14  org.mozilla.firefox 	0x0012d0ed CSSParserImpl::~CSSParserImpl [in-charge deleting]() + 69
15  org.mozilla.firefox 	0x0012cd67 CSSParserImpl::ParsePseudoClassWithIdentArg(nsCSSSelector&, nsIAtom*, unsigned&) + 331
16  libxpcom_core.dylib 	0x00dad205 nsCOMArray_base::~nsCOMArray_base [not-in-charge]() + 49
17  org.mozilla.firefox 	0x00128829 CSSLoaderImpl::Shutdown() + 25
18  org.mozilla.firefox 	0x001c0a37 nsLayoutStatics::Shutdown() + 49
19  org.mozilla.firefox 	0x003e3985 nsGlobalWindow::~nsGlobalWindow [not-in-charge]() + 519
20  org.mozilla.firefox 	0x007d6803 nsGlobalChromeWindow::~nsGlobalChromeWindow [in-charge deleting]() + 115
21  org.mozilla.firefox 	0x003dbe83 nsGlobalWindow::GetGlobalObjectOwner() + 703
22  org.mozilla.firefox 	0x00340408 XPCJSRuntime::GCCallback(JSContext*, JSGCStatus) + 222
23  org.mozilla.firefox 	0x0046ff1a nsJSContext::LoadEnd() + 124
24  libmozjs.dylib      	0x00d33607 js_GC + 3494
25  libmozjs.dylib      	0x00d1302f js_DestroyContext + 488
26  libmozjs.dylib      	0x00d065ed JS_DestroyContext + 25
27  org.mozilla.firefox 	0x000af8c2 XPCJSContextStack::~XPCJSContextStack [in-charge deleting]() + 42
28  org.mozilla.firefox 	0x000afb71 XPCPerThreadData::Cleanup() + 121
29  org.mozilla.firefox 	0x000b01c3 XPCPerThreadData::~XPCPerThreadData [in-charge]() + 19
30  org.mozilla.firefox 	0x000b0258 XPCPerThreadData::~XPCPerThreadData [in-charge]() + 168
31  libnspr4.dylib      	0x00bb647b _PR_DestroyThreadPrivate + 105
32  libnspr4.dylib      	0x00bc96f0 PR_Yield + 99
33  libnspr4.dylib      	0x00bc99ea _PR_InitThreads + 367
34  dyld                	0x8fe0e32d ImageLoaderMachO::doTermination(ImageLoader::LinkContext const&) + 85
35  dyld                	0x8fe030ec dyld::runTerminators() + 114
36  libSystem.B.dylib   	0x9000ff5c __cxa_finalize + 237
37  libSystem.B.dylib   	0x9000fe58 exit + 24
38  org.mozilla.firefox 	0x0000234e start + 278
39  org.mozilla.firefox 	0x00002261 start + 41

Comment 11

[Smokey Ardisson (offline for a while; not following bugs - do not email)]

This accounts for 20% of Camino's branch crashes.  As it looks like there's a slightly better idea of what's going on now, pulling the next 1.8.1 flag to see if it gets on the radar.

Comment 12

[Samuel Sidler (old account; do not CC)]

1.8.1.2 is too close to being finished. Requesting 1.8.1.3 on behalf of Smokey per comment 11.

Comment 14

[Adam Guthrie]

Smaug, do you have any idea what might be going on here? Bug 370738 might have steps to reproduce on Linux.

Comment 15

[Oleg Romashin (:romaxa)]

We have fixed this problem on TestGtkEmbed by adding some fixes in TestGtkEmbed.cpp

+  gtk_moz_embed_push_startup();
   gtk_main();
+  gtk_moz_embed_pop_startup();
 
+ see patch in attachment...

Comment 16

[Oleg Romashin (:romaxa)]

Attachment: Some proposed fix

Comment 17

[timeless]

this isn't really xpcom's fault.

xpcom shuts down, and there are leaks.
xpconnect at some later point has one of its object's destroyed (XPCPerThreadData) which then talks to JS (dead) and DOM (dead) which then proceed to do work. DOM then tries to do work on objects even though it has already disposed of them.

Comment 22

[Boris Zbarsky [:bzbarsky]]

Comment on attachment 255466 [details] [diff] [review]
Some proposed fix

I'm not a peer for this code.  I also don't know it.  So I shouldn't be reviewing this.  Please ask someone else?

Comment 23

[Greg Douglas]

A bug has been detected with a Web brwoser that uses the Mozilla components. 
The folks at Gnome feel that it is caused by bug#254161 or bug#238322. Folks at Mozilla feel that this may be a more appropriate bug. The application in question is the Epiphany Web browner and it crashes when it closes.  This appears to have started with the recent release of Firefox
(Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.8.0.10) Gecko/20070226
Fedora/1.5.0.10-1.fc6 Firefox/1.5.0.10 pango-text) on Fedora Core 6.  The
firefox debuginfo can be found at the following link:
http://bugzilla.gnome.org/show_bug.cgi?id=415544

Please give me a shout if you need me to install other debug packages.

Thanks.

Comment 24

[Joel Craig]

This has popped up in my March 8 and 9th Intel-only builds, and confirmed in the official March 9 build (Trunk). Crashlog looks to be similar to the attached, I'll add mine anyway.

Comment 25

[Joel Craig]

Attachment: crashlog

Comment 27

[Ray Kiddy]

Attachment: crashlog

I saw this also, on my Intel Mac. The FF that crashed was 2.0.0.3. I see a note above about profile switching.

I had FF 2003 running with profile "default" and a nightly Minefield running with profile "minefield1". I loaded a page into the FF 2003:

% cat foo.html
<html><head><title>foo</title>
</head>
<body>
<script>
  netscape.security.PrivilegeManager.enablePrivilege("UniversalXPConnect");
  var appService = Components.classes['@mozilla.org/toolkit/app-startup;1'].getService(Components.interfaces.nsIAppStartup);
  var forceQuit  = Components.interfaces.nsIAppStartup.eForceQuit;
  appService.quit(forceQuit);
</script>
</body></html>
%

This caused the browser to quit. Then I loaded it in the Minefield instance. Then I launched FF 2003. It showed me the ProfileManager, but thought the profile should be "minefield1". I switched it to "defualt" and told it to launch. FF then crashed.

I will attach the crash log. It looks (at a glance) like the log in comment #10.

Comment 28

[Daniel Veditz [:dveditz]]

Not a blocker, we've lived with it this long... :-(

Would love to see a fix, ask for approval if you get one with all the appropriate reviews and testing.

Comment 30

[Benjamin Smedberg]

Attachment: Shut down module loaders explicitly to avoid leaks and bad thread dtors, rev. 1

This patch will shut down xpconnect explicitly right as the component manager is dying (after all modules and services have been released). This prevents the leaks of nsXPConnect from causing XPCPerThreadData to be deleted when the main thread exits after XPCOM is dead and cold.

Backporting this to the branches could be a major pain due to architecture changes in the component manager, so I'm not sure I'm up for that... we'll see.

Comment 31

[Blake Kaplan (:mrbkap) (inactive)]

Comment on attachment 282450 [details] [diff] [review]
Shut down module loaders explicitly to avoid leaks and bad thread dtors, rev. 1

Is it fair to say that this trades shutdown crashes for shutdown leaks (of XPCPerThreadData)? Sounds like a fair trade-off to me. Are the leaks that are causing this filed?

Comment 32

[Blake Kaplan (:mrbkap) (inactive)]

Comment on attachment 282450 [details] [diff] [review]
Shut down module loaders explicitly to avoid leaks and bad thread dtors, rev. 1

Sorry, some late breaking nits.

>diff -r ad1c1a85d0bb js/src/xpconnect/src/nsXPConnect.cpp
>+nsXPConnect::Shutdown()
>+{
>+    if (mShuttingDown)
>+        return;

Prevalent style is |if(| with no space.

>diff -r ad1c1a85d0bb js/src/xpconnect/src/xpcthreadcontext.cpp
>+void
>+XPCPerThreadData::ThreadDataDtorCB(void* ptr)
>+{
>+    if (!ptr)

Ditto.

Comment 33

[Benjamin Smedberg]

> Is it fair to say that this trades shutdown crashes for shutdown leaks (of

No. Previously we would leak the XPCPerThreadData if we leaked XPConnect at shutdown. Now we ensure that we always call CleanupAllThreads near the very end of XPCOM shutdown. So we're fixing some leaks and some crashes. 

Comment 34

[timeless]

Comment on attachment 282450 [details] [diff] [review]
Shut down module loaders explicitly to avoid leaks and bad thread dtors, rev. 1

+++ b/js/src/xpconnect/loader/Makefile.in	
 REQUIRES	= xpcom \
+		  dom \

I don't like making xpconnect require dom.
Nor can I see why you did that.

+        NS_ERROR("Destroying non-main XPCPerThreadData after xpcom-shutdown-threads");

is there a reason not to use NS_ASSERTION (other than needing a slightly different message)?

+                 "XPCPerThreadData::CleanupAllThreads run twice.");

ran :)

     // Unload libraries
-    mNativeModuleLoader.UnloadLibraries();
+    mNativeModuleLoader.Shutdown();

is the comment correct? (the code doesn't follow)


+   * Shut down the loader. After this point loaded modules will be used.

I don't understand this

Comment 35

[Benjamin Smedberg]

The dependency of xpcprivate.h on DOM already exists, I'm just propagating it from xpconnect/src to xpconnect/loader. And the function was renamed from UnloadLibraries to Shutdown to be generic, but it still has the same functionality.

The other comment is simply a typo for "will not be used".

Comment 37

[Samuel Sidler (old account; do not CC)]

dbaron: Can you please look at this? It's a Camino topcrash.

Comment 38

[David Baron :dbaron: (⌚️UTC-4, no longer working on Mozilla)]

Comment on attachment 282450 [details] [diff] [review]
Shut down module loaders explicitly to avoid leaks and bad thread dtors, rev. 1

The variable names gThreadShutdown and gMainShutdown are hard to parse because "shutdown" can be a noun, verb, or adjective (although the latter two are usually two words).  Could you call them gAfterThreadShutdown and gAfterMainShutdown instead so that it's clear they say whether the current time is after shutdown.

Is NS_XPCOM_POST_SHUTDOWN_THREADS_OBSERVER_ID frozen?  If not, should it be in nsXPCOMPrivate.h instead?  (And I wonder if it should use "after" instead of "post" since post is more often a verb than an adverb in our codebase.)

I'm having a little trouble following this little bit of code in CleanupAllThreads that you're moving to the beginning:
    if(gTLSIndex != BAD_TLS_INDEX)
        PR_SetThreadPrivate(gTLSIndex, nsnull);
What exactly is it intended to do?  It looks like it destroys the PerThreadData for the main thread only.  If that's what's intended, could you say so?

In nsIModuleLoader, could you document when nsIModuleLoader::shutdown is called relative to the observer notifications and the general shutdown process?  (Though it seems different for the native loader and others.  (I was a little surprised to see nsStaticModuleLoader doesn't implement that interface, though...)

I'm having a good bit of trouble understanding this patch because I can't keep in my head when each piece happens, and there's no intermediate documentation saying when things run, so I have to go all the way back to the beginning...

Your changes to ThreadDataDtorCB look like you're assuming that the thread data dtor always runs on the main thread.  I would have thought it would run on its own thread (and I thought I remember that being the case, although I could be wrong).  Do you want to explicitly compare to the main thread instead?

What protects against the XPCPerTheradData being recreated after they've been destroyed?  Or is that the intent?

Comment 40

[Brian Carpenter [:geeknik]]

I crashed earlier today on Shiretoko build 20090514043924 and the crash log looks similiar.

http://crash-stats.mozilla.com/report/index/4ad05639-b1d1-4331-9b95-88c572090514

I disabled an addon, restarted Shiretoko and while it was restarting, I clicked on a link in another application and got this crash.

Comment 41

[Smokey Ardisson (offline for a while; not following bugs - do not email)]

Brian, that's not this crash, since your next frame was "free" instead of "AtomImpl::~AtomImpl" (and rest of the frames are altogether different as well).

Comment 42

[Michael Kohler [:mkohler]]

This is a mass change. Every comment has "assigned-to-new" in it.

I didn't look through the bugs, so I'm sorry if I change a bug which shouldn't be changed. But I guess these bugs are just bugs that were once assigned and people forgot to change the Status back when unassigning.