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)

x86
Linux
defect

Tracking

()

VERIFIED WORKSFORME

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
Assignee: nobody → dp
Component: Browser-General → XPCOM
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).
Assignee: dp → dougt
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.
Also see 17810
setting milestone optimistically.
Target Milestone: M14
moving to m15
Target Milestone: M14 → M15
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.
marking as WORKSFORME based on comment.  Please reopen if you see this problem.
Status: NEW → RESOLVED
Closed: 24 years ago
Resolution: --- → WORKSFORME
vrfy worksforme
Status: RESOLVED → VERIFIED
QA Contact: nobody → jrgm
You need to log in before you can comment on or make changes to this bug.