Closed Bug 416745 Opened 16 years ago Closed 15 years ago

SeaMonkey hangs at closedown

Categories

(SeaMonkey :: General, defect)

Product:
SeaMonkey
Component:
General
Platform:
x86
All
Type:
defect
Priority:
Not set
Severity:
critical

Tracking

(Not tracked)

Status:
RESOLVED WORKSFORME

People

(Reporter: tonymec, Unassigned)

Details

(Keywords: hang) 

User-Agent:       Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9b4pre) Gecko/2008021001 SeaMonkey/2.0a1pre
Build Identifier: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9b4pre) Gecko/2008021001 SeaMonkey/2.0a1pre

After Ctrl-Q (or File -> Quit) and confirming the "close all tabs?" dialog, SeaMonkey hangs forever

Reproducible: Always

Steps to Reproduce:
1. Hit Ctrl-Q
2. When the "close all tabs?" dialog comes up, hit Enter.

Actual Results:  
hang

Expected Results:  
normal browser closedown

Additional info:

- I used "kill -4" in order to get a stack trace: bp-bb05e45e-d839-11dc-b757-001a4bd43ef6

- List of installed addons is available at http://users.skynet.be/antoine.mechelynck/My%20Config%20-%20Mozilla%20%28default%29.html
Keywords: hang
Version: unspecified → Trunk
Does this also happen in Safe Mode then?
In Safe Mode, it didn't hang, but a lot of messages were printed at the console (I used "seamonkey -safe-mode &" in bash and saw the program's stdout/stderr). Some of them went away, but here's the tail end of it; as you'll see, it ends with a segfault. See also the remark at bottom.

(seamonkey-bin:9626): Gdk-CRITICAL **: gdk_gc_set_ts_origin: assertion `GDK_IS_GC (gc)' failed

(seamonkey-bin:9626): Gdk-CRITICAL **: gdk_gc_set_ts_origin: assertion `GDK_IS_GC (gc)' failed

(seamonkey-bin:9626): Gdk-CRITICAL **: gdk_gc_set_ts_origin: assertion `GDK_IS_GC (gc)' failed

(seamonkey-bin:9626): Gdk-CRITICAL **: gdk_gc_set_ts_origin: assertion `GDK_IS_GC (gc)' failed

(seamonkey-bin:9626): Gdk-CRITICAL **: gdk_gc_set_ts_origin: assertion `GDK_IS_GC (gc)' failed

(seamonkey-bin:9626): Gdk-CRITICAL **: gdk_gc_set_ts_origin: assertion `GDK_IS_GC (gc)' failed

(seamonkey-bin:9626): Gdk-CRITICAL **: gdk_gc_set_ts_origin: assertion `GDK_IS_GC (gc)' failed

(seamonkey-bin:9626): Gdk-CRITICAL **: gdk_gc_set_ts_origin: assertion `GDK_IS_GC (gc)' failed

(seamonkey-bin:9626): Gdk-CRITICAL **: gdk_gc_set_ts_origin: assertion `GDK_IS_GC (gc)' failed

(seamonkey-bin:9626): Gtk-CRITICAL **: gtk_paint_arrow: assertion `style->depth == gdk_drawable_get_depth (window)' failed

(seamonkey-bin:9626): Gdk-CRITICAL **: gdk_screen_get_display: assertion `GDK_IS_SCREEN (screen)' failed

(seamonkey-bin:9626): GLib-GObject-WARNING **: invalid (NULL) pointer instance

(seamonkey-bin:9626): GLib-GObject-CRITICAL **: g_signal_handlers_disconnect_matched: assertion `G_TYPE_CHECK_INSTANCE (instance)' failed

(seamonkey-bin:9626): GLib-GObject-CRITICAL **: g_object_ref: assertion `G_IS_OBJECT (object)' failed

(seamonkey-bin:9626): Gdk-CRITICAL **: gdk_screen_get_display: assertion `GDK_IS_SCREEN (screen)' failed

(seamonkey-bin:9626): GLib-GObject-CRITICAL **: g_object_get_data: assertion `G_IS_OBJECT (object)' failed

(seamonkey-bin:9626): Gdk-CRITICAL **: gdk_screen_get_display: assertion `GDK_IS_SCREEN (screen)' failed

(seamonkey-bin:9626): GLib-GObject-CRITICAL **: g_object_get_data: assertion `G_IS_OBJECT (object)' failed

(seamonkey-bin:9626): Gdk-CRITICAL **: gdk_screen_get_display: assertion `GDK_IS_SCREEN (screen)' failed

(seamonkey-bin:9626): GLib-GObject-CRITICAL **: g_object_get_data: assertion `G_IS_OBJECT (object)' failed

(seamonkey-bin:9626): GLib-GObject-WARNING **: gsignal.c:2180: invalid unclassed object pointer for value type `GdkScreen'

(seamonkey-bin:9626): Gdk-CRITICAL **: gdk_screen_get_display: assertion `GDK_IS_SCREEN (screen)' failed

(seamonkey-bin:9626): GLib-GObject-CRITICAL **: g_object_get_data: assertion `G_IS_OBJECT (object)' failed

(seamonkey-bin:9626): GLib-GObject-WARNING **: gsignal.c:2180: invalid unclassed object pointer for value type `GdkScreen'

(seamonkey-bin:9626): GLib-GObject-CRITICAL **: g_object_unref: assertion `G_IS_OBJECT (object)' failed

(seamonkey-bin:9626): Gdk-CRITICAL **: gdk_screen_get_display: assertion `GDK_IS_SCREEN (screen)' failed
/usr/local/seamonkey/run-mozilla.sh: line 131:  9626 Segmentation fault      "$prog" ${1+"$@"}




The hang seems to be related with the tabbrowser component: in one of my test runs (not in safe mode), I only succeeded to bring up a number of "tabless" windows (i.e., suffering from bug 354991 ): when hitting Ctrl-Q to that, only one window closed, but hitting Ctrl-Q again closed the rest in quick succession, then exited with no hang. I haven't got the stdout/stderr from that run.
Oh, and I forgot to mention: when "hanging at closedown", Sm gobbles up a lot of CPU time ("whatever is available": more than 50%; often more than 80% if Firefox is not also running); about one-third, maybe, of that "SeaMonkey time" is shown in red (i.e. "system time") by ksysguard (the KDE "Task Manager").
Hm. With only MR-Tech Local Install disabled (in addition to those mentioned as disabled in the list linked from comment #1) it seems that I don't get the hang. Too bad I dont know Mel Reyes's bugzilla.mozilla.org email address of record. I wonder if the breakpad report (see comment #0) could help him find where the problem comes from.
Did you submit a breakpad report for the safe-mode crash from comment 3?

The stack from comment 0 just shows that javascript was running, but there's no way to know what the javascript was doing.
(In reply to comment #6)
> Did you submit a breakpad report for the safe-mode crash from comment 3?

I didn't get any: the only symptom of segfault was on stdout/stderr.
Tonight I got a crash, bug 419342; then I closed down again (in order to install today's nightly) and (for the first time with my usual extensions since reporting the present bug) it exited with neither hang nor crash.
Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9pre) Gecko/2008042401 SeaMonkey/2.0a1pre

Had a hang today, trying to change from Modern to Classic theme. 100% CPU including quite some "system" time. Finally killed it -15.
Can you reproduce with current SeaMonkey v2.0a1pre ?
(with safe-mode ? with new profile ?
still seeing the same assertions ? still no breakpad report ?)

Could you try and test if this is a regression ?
(from v1.1.9, from v1.5a, ...)
(In reply to comment #10)
> Can you reproduce with current SeaMonkey v2.0a1pre ?
> (with safe-mode ? with new profile ?
> still seeing the same assertions ? still no breakpad report ?)
> 
> Could you try and test if this is a regression ?
> (from v1.1.9, from v1.5a, ...)
> 

- I'm seeing this sporadically now, I can't reproduce it at will anymore. It still happens at times with current trunk nightlies.
- This is a hang, not a crash, therefore no breakpad report (unless I artificially kill it with SIGILL or SIGSEGV but normally I don't).
- I'm not going back to Sm 1.1.x or earlier, that's final. Among other flaws, it hasn't got a workable addons manager.
- When this happened recently (yesterday or maybe the day before), I saved the sysout/syserr log; here it is:

nsHeaderInfo: registerSelf called!
nsHeaderInfo: registerSelf called!
/usr/local/seamonkey/run-mozilla.sh: line 131: 19931 Terminated              "$prog" ${1+"$@"}

Comparison with the currently running instance's log seems to imply that the first two lines were output at startup, so they are not necessarily related to this bug. The last line (folded here) is obviously the result of the kill.
P.S. Here's the stack from the kill -4 (i.e. SIGILL) in comment #0:

Frame  	Module  	Signature [Expand]  	Source
0 		@0xffffe410 	
1 	libglib-2.0.so.0.1400.1 	libglib-2.0.so.0.1400.1@0x329a4 	
2 	libglib-2.0.so.0.1400.1 	libglib-2.0.so.0.1400.1@0x32f2d 	
3 	libwidget_gtk2.so 	nsAppShell::ProcessNextNativeEvent 	mozilla/widget/src/gtk2/nsAppShell.cpp:144
4 	libwidget_gtk2.so 	nsBaseAppShell::DoProcessNextNativeEvent 	mozilla/widget/src/xpwidgets/nsBaseAppShell.cpp:137
5 	libwidget_gtk2.so 	nsBaseAppShell::OnProcessNextEvent 	mozilla/widget/src/xpwidgets/nsBaseAppShell.cpp:247
6 	libxpcom_core.so 	nsThread::ProcessNextEvent 	mozilla/xpcom/threads/nsThread.cpp:497
7 	libxpcom_core.so 	NS_ProcessNextEvent_P 	nsThreadUtils.cpp:227
8 	libnecko.so 	nsSyncStreamListener::WaitForData 	mozilla/netwerk/base/src/nsSyncStreamListener.cpp:58
9 	libnecko.so 	nsSyncStreamListener::Available 	mozilla/netwerk/base/src/nsSyncStreamListener.cpp:160
10 	libnecko.so 	NS_ImplementChannelOpen 	mozilla/netwerk/base/src/nsBaseChannel.cpp:601
11 	libnecko.so 	nsHttpChannel::Open 	mozilla/netwerk/protocol/http/src/nsHttpChannel.cpp:3634
12 	libxpcom_core.so 	xptiInterfaceEntry::EnsureResolved 	
13 	libxpconnect.so 	XPCWrappedNative::CallMethod 	mozilla/js/src/xpconnect/src/xpcwrappednative.cpp:2339
14 	libxpconnect.so 	XPC_WN_CallMethod 	mozilla/js/src/xpconnect/src/xpcwrappednativejsops.cpp:1470
15 	libmozjs.so 	js_Invoke 	mozilla/js/src/jsinterp.c:1400
16 	libmozjs.so 	js_Interpret 	mozilla/js/src/jsinterp.c:4530
17 	libmozjs.so 	js_Invoke 	mozilla/js/src/jsinterp.c:1416
18 	libxpconnect.so 	nsXPCWrappedJSClass::CallMethod 	mozilla/js/src/xpconnect/src/xpcwrappedjsclass.cpp:1473
19 	libxpconnect.so 	nsXPCWrappedJS::CallMethod 	mozilla/js/src/xpconnect/src/xpcwrappedjs.cpp:556
20 	libxpcom_core.so 	PrepareAndDispatch 	mozilla/xpcom/reflect/xptcall/src/md/unix/xptcstubs_gcc_x86_unix.cpp:95
21 	libxpcom_core.so 	nsObserverList::NotifyObservers 	mozilla/xpcom/ds/nsObserverList.cpp:128
22 	libxpcom_core.so 	nsObserverService::NotifyObservers 	mozilla/xpcom/ds/nsObserverService.cpp:181
23 	libxpcom_core.so 	xptiInterfaceEntry::EnsureResolved 	
24 	libxpconnect.so 	XPCWrappedNative::CallMethod 	mozilla/js/src/xpconnect/src/xpcwrappednative.cpp:2339
25 	libxpconnect.so 	XPC_WN_CallMethod 	mozilla/js/src/xpconnect/src/xpcwrappednativejsops.cpp:1470
26 	libmozjs.so 	js_Invoke 	mozilla/js/src/jsinterp.c:1400
27 	libmozjs.so 	js_Interpret 	mozilla/js/src/jsinterp.c:4530
28 	libmozjs.so 	js_Invoke 	mozilla/js/src/jsinterp.c:1416
29 	libxpconnect.so 	nsXPCWrappedJSClass::CallMethod 	mozilla/js/src/xpconnect/src/xpcwrappedjsclass.cpp:1473
30 	libxpconnect.so 	nsXPCWrappedJS::CallMethod 	mozilla/js/src/xpconnect/src/xpcwrappedjs.cpp:556
31 	libxpcom_core.so 	PrepareAndDispatch 	mozilla/xpcom/reflect/xptcall/src/md/unix/xptcstubs_gcc_x86_unix.cpp:95
32 	libappcomps.so 	nsBrowserStatusFilter::OnStateChange 	mozilla/xpfe/browser/src/nsBrowserStatusFilter.cpp:183
33 	libdocshell.so 	nsDocLoader::FireOnStateChange 	mozilla/uriloader/base/nsDocLoader.cpp:1235
34 	libdocshell.so 	nsDocLoader::doStopDocumentLoad 	mozilla/uriloader/base/nsDocLoader.cpp:869
35 	libdocshell.so 	nsDocLoader::DocLoaderIsEmpty 	mozilla/uriloader/base/nsDocLoader.cpp:763
36 	libdocshell.so 	nsDocLoader::OnStopRequest 	mozilla/uriloader/base/nsDocLoader.cpp:679
37 	libnecko.so 	nsLoadGroup::RemoveRequest 	mozilla/netwerk/base/src/nsLoadGroup.cpp:688
38 	libgklayout.so 	nsDocument::DoUnblockOnload 	mozilla/content/base/src/nsDocument.cpp:5533
39 	libgklayout.so 	nsDocument::UnblockOnload 	mozilla/content/base/src/nsDocument.cpp:5482
40 	libgklayout.so 	nsDocument::DispatchContentLoadedEvents 	mozilla/content/base/src/nsDocument.cpp:2764
41 	libgklayout.so 	nsRunnableMethod<nsDocument>::Run 	mozilla/content/base/src/nsDocument.cpp:261
42 	libxpcom_core.so 	nsThread::ProcessNextEvent 	mozilla/xpcom/threads/nsThread.cpp:510
43 	libxpcom_core.so 	NS_ProcessNextEvent_P 	nsThreadUtils.cpp:227
44 	libwidget_gtk2.so 	nsBaseAppShell::Run 	mozilla/widget/src/xpwidgets/nsBaseAppShell.cpp:154
45 	libtoolkitcomps.so 	nsAppStartup::Run 	mozilla/toolkit/components/startup/src/nsAppStartup.cpp:181
46 	libxul.so 	XRE_main 	mozilla/toolkit/xre/nsAppRunner.cpp:3145
47 	seamonkey-bin 	main 	mozilla/suite/app/nsSuiteApp.cpp:103
48 	libc-2.6.1.so 	libc-2.6.1.so@0x15fdf 	
Is xptiInterfaceEntry::EnsureResolved reentrancy safe?
I have these crashes periodically. Almost at any program exit i'm getting:
(seamonkey-bin:17916): Gtk-CRITICAL **: gtk_widget_hide: assertion `GTK_IS_WIDGET (widget)' failed

(seamonkey-bin:17916): Gtk-CRITICAL **: gtk_widget_destroy: assertion `GTK_IS_WIDGET (widget)' failed

(seamonkey-bin:17916): Gtk-CRITICAL **: gtk_widget_hide: assertion `GTK_IS_WIDGET (widget)' failed

(seamonkey-bin:17916): Gtk-CRITICAL **: gtk_widget_destroy: assertion `GTK_IS_WIDGET (widget)' failed
./run-mozilla.sh: line 131: 17916 Segmentation fault      "$prog" ${1+"$@"}
Status: UNCONFIRMED → NEW
Ever confirmed: true
This bug is symptomatically similar to bug 450371, but the stacks from these 
two bugs do not appear to have relevant functions in common, so I'm not 
confident that they are duplicates.  But if one fix cures both, then OK. :)
(In reply to comment #16)
> This bug is symptomatically similar to bug 450371, but the stacks from these 
> two bugs do not appear to have relevant functions in common, so I'm not 
> confident that they are duplicates.  But if one fix cures both, then OK. :)

If some patch fixes one but not the other, then of course the one it didn't fix will have to be REOPENED, possibly by its reporter.
I've been seeing this problem on Windows XP A LOT lately.
I've been breaking into the hung process with the debugger and 
looking around, and I've noticed a number of things.  These observations 
have led to a workaround or two, one of which seems satisfactory.

There's always one thread trying to close a socket.  The stack of Windows
system shared libraries on that thread is VERY deep, as if Windows code
called by NSPR to close the socket has called itself recursively a lot.  

On another thread, there's some kind of timer event firing over and over.
Since I don't have sources to match my browser, I cannot tell exactly 
what code is doing that.  I think that one thread is starving the other,
and the starved thread needs to finish for the shut down to complete.

While it is using 100% of the CPU, setting the process priority down from
8 (normal) to 4 (idle) with Windows Process Explorer usually causes it to
stop hanging and terminate normally within a second after doing so.

Going "offline" before exiting the process seems to avoid the hang.  
The process shuts down very quickly when I do that.  I am now doing that
frequently, and have never seen a shutdown hang since I started doing that.
Whenever I recently see the "CPU overuse" symptom mentioned in comment #4, not only at shutdown (recently at startup of SeaMonkey Mail without the Browser) a lot of the CPU time is apparently consumed by the FAM daemon. Restarting the fam service (by "/etc/init.d/fam restart") cures the CPU overuse but not the hang. I suspect this is the Linux counterpart of the Windows "socket hang" described in comment #18.
OS: Linux → All
Tony, I think the problem seen on Linux is simply a different problem than 
the one seen on Windows, and therefore I doubt that this bug (Linux only, 
originally) is truly a duplicate of bug 450371.  I think they are similar
only in symptom, and even then not very similar.  On Windows, there is no
"hang" apart from the 100% CPU, and it's only at shutdown.
Well, Nelson, if you have grounds for that thinking, the logical consequence would be reopening bug 450371. I've seen it at shutdown and at startup, and I suspect there might be a "socket hang" problem on Linux too.
Tony, exactly what TCP ports are still open (http/imap/ldap?) when it's in the hung state using CPU?
(In reply to comment #22)
> Tony, exactly what TCP ports are still open (http/imap/ldap?) when it's in the
> hung state using CPU?

Don't know, it's been quite some time (months?) that I've seen this latest (while installing the next trunk nightly every day or almost). FYI I don't use IMAP or LDAP. The ports I use are (a) in the mailer: SMTP (plain = 25) POP (with and without SSL), HTTP (for RSS -- or is it a different port? and sometimes for 3rd-party images in mail); (b) in the browser: http, https, ftp [and the file, chrome and about schemes which IIUC don't use any port at all] (c) I rarely, but sometiimes, use ChatZilla which is on still another port.

I'm setting this bug to WORKSFORME. Please reopen, anyone, if seen in a current trunk build as found at the following outlets:
- 2.0a3 release http://www.seamonkey-project.org/releases/seamonkey2.0a3/
- 2.0b1pre nightly http://ftp.mozilla.org/pub/mozilla.org/seamonkey/nightly/latest-trunk/
... or in a later version if some time passes between this comment and when you see the bug.
Status: NEW → RESOLVED
Closed: 15 years ago
Resolution: --- → WORKSFORME
You need to log in before you can comment on or make changes to this bug.