Closed
Bug 24471
Opened 25 years ago
Closed 24 years ago
A wild mozilla thread is eating 99% of my CPU!
Categories
(Core :: XPCOM, defect, P3)
Tracking
()
VERIFIED
WORKSFORME
M15
People
(Reporter: dejong, Assigned: dougt)
Details
I have been running a CVS build of mozilla for about 24 hours now (Yeah), but I seem to have hit a snag. In the last hour or so, a mozilla thread went wild and started eating up 99% of my CPU. I was surfing around on http://slashdot.org/articles/00/01/19/0828245.shtml when I got this error but I had a couple of other pages open too, so I am not sure if this page caused the problem. I am running on a RedHat 6.0 system built from the CVS yesterday. All I can really do is show you the stack traces that seemed to be important. Here is what top was showing me. (PID) (CPU) 15080 mdejong 0 0 60744 24M 5932 S 0 0.0 19.8 12:54 mozilla-bin 15526 mdejong 0 0 60744 24M 5932 S 0 0.0 19.8 0:01 mozilla-bin 15529 mdejong 0 0 60744 24M 5932 S 0 0.0 19.8 0:05 mozilla-bin 15741 mdejong 16 0 60744 24M 5932 R 0 96.6 19.8 513:41 mozilla-bin 31091 mdejong 0 0 60744 24M 5932 S 0 0.0 19.8 0:00 mozilla-bin (This is the stack trace of the thread that is taking 99% of the CPU) #0 0x402ea1bb in __sigsuspend (set=0xbf7ffba4) at ../sysdeps/unix/sysv/linux/sigsuspend.c:48 #1 0x40235fe0 in pthread_cond_wait (cond=0x80cd5ac, mutex=0x80cd784) at restart.h:49 #2 0x40212fd8 in PR_WaitCondVar (cvar=0x80cd5a8, timeout=4294967295) at ptsynch.c:360 #3 0x402137d7 in PR_Wait (mon=0x80cd780, timeout=4294967295) at ptsynch.c:545 #4 0x40177d53 in nsThreadPool::GetRequest (this=0x80cd530) at ../../../mozilla/xpcom/threads/nsThread.cpp:396 #5 0x40178939 in nsThreadPoolRunnable::Run (this=0x8091618) at ../../../mozilla/xpcom/threads/nsThread.cpp:591 #6 0x40176da5 in nsThread::Main (arg=0x80cd7e8) at ../../../mozilla/xpcom/threads/nsThread.cpp:83 #7 0x4021b96b in _pt_root (arg=0x80cd800) at ptthread.c:157 #8 0x40236ce9 in pthread_start_thread (arg=0xbf7ffe7c) at manager.c:204 Here are the stacks of a couple of other threads that I thought might help. #0 0x402128ae in PR_Unlock (lock=0x8054e90) at ptsynch.c:184 #1 0x401fcda7 in PR_CEnterMonitor (address=0x9655b10) at prcmon.c:304 #2 0x4019df8c in nsAutoCMonitor::nsAutoCMonitor (this=0xbf5ffb14, lockObject=0x9655b10) at ../../dist/include/nsAutoLock.h:248 #3 0x401606f2 in nsPipe::GetReadSegment (this=0x9655b10, segmentLogicalOffset=0, resultSegment=0xbf5ffb7c, resultSegmentLen=0xbf5ffb80) at ../../../mozilla/xpcom/io/nsPipe2.cpp:227 #4 0x40160c63 in nsPipe::nsPipeInputStream::ReadSegments (this=0x9655b18, writer=0x405e9098 <nsWriteToSocket(void *, char const *, unsigned int, unsigned int, unsigned int *)>, closure=0x80cd240, count=8192, readCount=0xbf5ffc04) at ../../../mozilla/xpcom/io/nsPipe2.cpp:363 #5 0x405e97f6 in nsSocketTransport::doWriteFromBuffer (this=0x9651f30, aCount=0xbf5ffc04) at ../../../../mozilla/netwerk/base/src/nsSocketTransport.cpp:1099 #6 0x405e9592 in nsSocketTransport::doWrite (this=0x9651f30, aSelectFlags=32) at ../../../../mozilla/netwerk/base/src/nsSocketTransport.cpp:1012 #7 0x405e8830 in nsSocketTransport::Process (this=0x9651f30, aSelectFlags=32) at ../../../../mozilla/netwerk/base/src/nsSocketTransport.cpp:521 #8 0x405ec737 in nsSocketTransportService::Run (this=0x858e0b8) at ../../../../mozilla/netwerk/base/src/nsSocketTransportService.cpp:467 #9 0x40176da5 in nsThread::Main (arg=0x858e458) at ../../../mozilla/xpcom/threads/nsThread.cpp:83 #10 0x4021b96b in _pt_root (arg=0x858e470) at ptthread.c:157 #11 0x40236ce9 in pthread_start_thread (arg=0xbf5ffe7c) at manager.c:204 #0 0x403737d0 in __poll (fds=0x87d4580, nfds=3, timeout=246) at ../sysdeps/unix/sysv/linux/poll.c:45 #1 0x40b82471 in g_main_poll () #2 0x40b81e6e in g_main_iterate () #3 0x40b821e1 in g_main_run () #4 0x40aae7a9 in gtk_main () #5 0x41beb557 in nsAppShell::Run (this=0x8091cf8) at ../../../../mozilla/widget/src/gtk/nsAppShell.cpp:304 #6 0x41b8a19d in nsAppShellService::Run (this=0x80c8cb8) at ../../../../mozilla/xpfe/appshell/src/nsAppShellService.cpp:465 #7 0x804bd0d in main1 (argc=1, argv=0xbffff544) at ../../../mozilla/xpfe/bootstrap/nsAppRunner.cpp:598 #8 0x804c197 in main (argc=1, argv=0xbffff544) at ../../../mozilla/xpfe/bootstrap/nsAppRunner.cpp:691 #9 0x402e3cb3 in __libc_start_main (main=0x804bf7c <main>, argc=1, argv=0xbffff544, init=0x804a16c <_init>, fini=0x8050a58 <_fini>, rtld_fini=0x4000a350 <_dl_fini>, stack_end=0xbffff53c) at ../sysdeps/generic/libc-start.c:78
Updated•25 years ago
|
Assignee: nobody → dp
Component: Browser-General → XPCOM
Comment 1•25 years ago
|
||
dejong@cs.umn.edu : is there any way that you can think of to duplicate this (this would be really impossible to track down otherwise). By the way, you also reported bug #24472 for a graphics/scrolling issue -- did this occur at the same time -- do you think they are related (or are these independent issues that happened at different times). Passing from nobody@mozilla.org to dp/XPCOM (possibly NSPR) for a look at the stack traces. Perhaps a known problem for threads (perhaps one for the memory bank).
Updated•25 years ago
|
Assignee: dp → dougt
Comment 2•25 years ago
|
||
dougt?
I have no idea what caused this so I do not know how to reproduce it. I was running mozilla for about 24 hours straight when I got this error, so it could be anything.
Assignee | ||
Comment 7•24 years ago
|
||
Is this still happening? ccing some unix folks.
I have not run into this problem again. Of course I do not know what caused it in the first place. I am going to mark it as WORKSFORME.
Assignee | ||
Comment 9•24 years ago
|
||
marking as WORKSFORME based on comment. Please reopen if you see this problem.
Status: NEW → RESOLVED
Closed: 24 years ago
Resolution: --- → WORKSFORME
You need to log in
before you can comment on or make changes to this bug.
Description
•