Build 2001050104 After some time browsing, closing the last window will cause Mozilla to hang at 100% CPU. Fairly reliable way to duplicate: open about half a dozen different pages in different windows. (a few cnn.com stories, dilbert.com, stlcardinals.com, stlouisblues.com were my test cases). On closing the final window, while no windows are open, mozilla.exe is using >95% CPU as reported by Task Manager, and must be killed to start a new mozilla process successfully. This might be related to bug 66730 but I don't see anything near maximum memory usage, only a hang on exit. Total memory usage in the session is maybe 50 MB RAM + 50 MB VM, and I have 512 MB RAM + a bunch of pagefile space. I also see no PSM window, etc. Because of these differences, I filed this as a separate bug. If it is caused by the same thing, go ahead and mark it as a duplicate.
Note this is not directly tied to the number of windows, etc. It just happened when I only had opened one window at bugzilla, and it does not always happen if I have 20 windows open. The likelihood of a hang on exit just seems to increase somewhat with increased usage.
I see something like this, too. I upgraded from 0.8.1 and tried various pre0.9 builds the last days. =Mozilla/5.0 (X11; U; Linux 2.4.4 i686; en-US; rv:0.9) Gecko/20010503 and previous builds Oh joy, all bugs I know are fixed, but quite often upon exit Mozilla simply hangs. Cpu goes to 100%, manual killing of Moz process necessary to get resources back -> annoying! I havn't been able to find a way to always reproduce this and no low memory, no plugins, no special things at all, just normal browsing.
do you have any sort of plugins installed? java or flash?
No plugins, and it'll sometimes happen even if I've only had a mail window open.
I'm seeing a hang on exit under linux. The hang doesn't appear consistently with the nightlies but does with my custom builds but the stack is fairly consistent. To reproduce: Bring up browser with homepage set to "Blank page" Go to http://tinderbox.mozilla.org/showbuilds.cgi?tree=SeaMonkey Close the close button on the browser. With a nightly build (2001-06-13-08), I have to repeat the above about 10x before reproducing the problem. My custom builds can usually hit it every other time. (gdb) info threads * 5 Thread 15459 0x40446dcb in __sigsuspend (set=0xbf3ffc20) at ../sysdeps/unix/sysv/linux/sigsuspend.c:48 3 Thread 15457 0x404d3f30 in __poll (fds=0xbf7ffd00, nfds=1, timeout=35000) at ../sysdeps/unix/sysv/linux/poll.c:45 (gdb) bt #0 0x40446dcb in __sigsuspend (set=0xbf3ffc20) at ../sysdeps/unix/sysv/linux/sigsuspend.c:48 #1 0x401cfc62 in __pthread_wait_for_restart_signal (self=0xbf3ffe40) at pthread.c:783 #2 0x401cc960 in pthread_cond_wait (cond=0x8148fbc, mutex=0x8148f60) at restart.h:26 #3 0x401b43fe in PR_WaitCondVar () from /usr/cls/moz/mozilla/libnspr4.so #4 0x400c96f5 in nsThreadPool::GetRequest () from /usr/cls/moz/mozilla/libxpcom.so #5 0x400c9d6e in nsThreadPoolRunnable::Run () from /usr/cls/moz/mozilla/libxpcom.so #6 0x400c8b4a in nsThread::Main () from /usr/cls/moz/mozilla/libxpcom.so #7 0x401b86ee in PR_Select () from /usr/cls/moz/mozilla/libnspr4.so #8 0x401cdb85 in pthread_start_thread (arg=0xbf3ffe40) at manager.c:241 (gdb) thread 3 [Switching to thread 3 (Thread 15457)] #0 0x404d3f30 in __poll (fds=0xbf7ffd00, nfds=1, timeout=35000) at ../sysdeps/unix/sysv/linux/poll.c:45 45 ../sysdeps/unix/sysv/linux/poll.c: No such file or directory. (gdb) bt #0 0x404d3f30 in __poll (fds=0xbf7ffd00, nfds=1, timeout=35000) at ../sysdeps/unix/sysv/linux/poll.c:45 #1 0x401b7684 in PR_Poll () from /usr/cls/moz/mozilla/libnspr4.so #2 0x407936d2 in NSGetModule () from /usr/cls/moz/mozilla/components/libnecko.so #3 0x400c8b4a in nsThread::Main () from /usr/cls/moz/mozilla/libxpcom.so #4 0x401b86ee in PR_Select () from /usr/cls/moz/mozilla/libnspr4.so #5 0x401cdb85 in pthread_start_thread (arg=0xbf7ffe40) at manager.c:241 (gdb)
Reporter: Is this still a problem with a more recent build ?
I haven't had it happen with 0.9.3 Haven't tried the nightly builds since then yet.
marking worksforme Reporter: Please open a new bug if you see this again !