Closed Bug 29023 Opened 24 years ago Closed 24 years ago

recent CVS builds seem CPU-hungry

Categories

(Core :: DOM: UI Events & Focus Handling, defect, P3)

x86
Linux
defect

Tracking

()

VERIFIED FIXED

People

(Reporter: sarnold, Assigned: pavlov)

Details

Three times today I have had to kill mozilla (using my window manager's "destroy
this window" button) when mozilla spins itself off the deep end. `top` reported
mozilla using 86% of my CPU, and one could watch the "CPU time elapsed" number
increasing roughly in sync with normal time.

I built today's mozilla from CVS sources around 22:00 pacific on feb 22.
Something seems to chew through CPU in a bad way. Most of what I have viewed is
bugzilla pages.

Thanks :)
This could be related, or it could be a VMS specific bug (VMS builds like UNIX).

I don't know when it started, but I assume some time in the past couple of days, 
but as soon as I start Mozilla on OpenVMS it's going CPU-bound. Its in the main 
GDK event loop, but I haven't tracked down what's going on yet.
Ok, using the CVS tree from the evening of February 25, a build I made under
linux reports 82% CPU usage, the remainder being chewed by sshd2,
distributed.net, and seti@home clients. I have PLENTY of physical memory free,
some 15 megs, and over 120 megs of swap space free. This is on a pentium II 300.
I was visiting a web page that did not seem very demanding, and had left my
computer alone for around fifteen minutes. Upon returning, mozilla was hung.

When it hung (the "M" logo did not redraw, scroll bars did not work, sizing the
window larger left large grey expanses, none of the buttons worked, links did
not work, etc..) I attached a gdb and tried to learn gdb while things were
running. A fun experience, I think. :)

Here is a stack trace I got out of my machine with gdb. :)

If there is anything I should be doing to help find out what happens, please do
let me know. :)

Thanks! :)

(gdb) backtrace
#0  0x402ab7ee in select () from /lib/libc.so.6
#1  0x402ecad8 in __check_rhosts_file () from /lib/libc.so.6
#2  0x402aa1cf in poll () from /lib/libc.so.6
#3  0x40687b05 in g_main_is_running () from /usr/lib/libglib-1.2.so.0
#4  0x406874bd in g_get_current_time () from /usr/lib/libglib-1.2.so.0
#5  0x40687785 in g_main_iteration () from /usr/lib/libglib-1.2.so.0
#6  0x404e8793 in nsAppShell::DispatchNativeEvent ()
   from /usr/lib/mozilla/libwidget_gtk.so
#7  0x4041fa97 in NSGetModule ()
   from /home/sarnold/.mozilla/components/libnsappshell.so
#8  0x40425cf7 in NSGetModule ()
   from /home/sarnold/.mozilla/components/libnsappshell.so
#9  0x4041b5d8 in NSGetModule ()
   from /home/sarnold/.mozilla/components/libnsappshell.so
#10 0x40360185 in GlobalWindowImpl::OpenInternal ()
   from /usr/lib/mozilla/libjsdom.so
#11 0x4035cd5b in GlobalWindowImpl::OpenDialog ()
   from /usr/lib/mozilla/libjsdom.so
#12 0x4043033a in NSGetModule ()
   from /home/sarnold/.mozilla/components/libnsappshell.so
#13 0x4042f422 in NSGetModule ()
   from /home/sarnold/.mozilla/components/libnsappshell.so
#14 0x40427dcf in NSGetModule ()
   from /home/sarnold/.mozilla/components/libnsappshell.so
#15 0x40890ee1 in nsWebShell::OnEndDocumentLoad ()
   from /usr/lib/mozilla/libraptorwebwidget.so
#16 0x408c6662 in NSGetModule ()
   from /home/sarnold/.mozilla/components/liburiloader.so
#17 0x408c6554 in NSGetModule ()
   from /home/sarnold/.mozilla/components/liburiloader.so
#18 0x408c644a in NSGetModule ()
   from /home/sarnold/.mozilla/components/liburiloader.so
#19 0x40479568 in NSGetModule ()
   from /home/sarnold/.mozilla/components/libnecko.so
#20 0x4104a692 in NSGetModule ()
   from /home/sarnold/.mozilla/components/libnecko_http.so
#21 0x4104cfce in NSGetModule ()
   from /home/sarnold/.mozilla/components/libnecko_http.so
#22 0x4046b4fe in NSGetModule ()
   from /home/sarnold/.mozilla/components/libnecko.so
#23 0x4046af25 in NSGetModule ()
   from /home/sarnold/.mozilla/components/libnecko.so
#24 0x401015cd in PL_HandleEvent () from /usr/lib/mozilla/libxpcom.so
#25 0x40101559 in PL_ProcessPendingEvents () from
/usr/lib/mozilla/libxpcom.so
#26 0x4010227f in nsEventQueueImpl::ProcessPendingEvents ()
   from /usr/lib/mozilla/libxpcom.so
#27 0x404e81b9 in nsAppShell::SetDispatchListener ()
   from /usr/lib/mozilla/libwidget_gtk.so
#28 0x404e7f66 in keysym2ucs () from /usr/lib/mozilla/libwidget_gtk.so
#29 0x40685a00 in g_io_add_watch () from /usr/lib/libglib-1.2.so.0
#30 0x406870c9 in g_get_current_time () from /usr/lib/libglib-1.2.so.0
#31 0x406876d3 in g_get_current_time () from /usr/lib/libglib-1.2.so.0
#32 0x4068786c in g_main_run () from /usr/lib/libglib-1.2.so.0
#33 0x405aad97 in gtk_main () from /usr/lib/libgtk-1.2.so.0
#34 0x404e8713 in nsAppShell::Run () from
/usr/lib/mozilla/libwidget_gtk.so
#35 0x40421888 in NSGetModule ()
   from /home/sarnold/.mozilla/components/libnsappshell.so
#36 0x804ad8f in JS_PushArguments ()
#37 0x804b142 in JS_PushArguments ()
#38 0x4022da42 in __libc_start_main () from /lib/libc.so.6

are you still seeing this on m15 nightlies?
I haven't gotten a clean M15 build yet (see my postings in the newsgroups!). 
Once I have, I'll let you know if its still happening.
Using March 14th CVS builds, I have seen it once or twice, but not nearly as
frequently as when I made the bugzilla report. Once in a while, one will spin
off and wedge itself, but I haven't been thinking enough to get a stack trace
when that happens. :(

So, it still happens, just a lot less frequently. :)
Assignee: cbegle → cls
Component: Browser-General → Build Config
QA Contact: asadotzler → cyeh
-> Build Config
Again, not a build config issue.  It dies in libwidget_gtk.  That's pavlov's
baby.
Assignee: cls → pavlov
Component: Build Config → Event Handling
I've got my M15 builds up and running now. I haven't seen the CPU problem yet, 
but to be fair, I haven't really had a chance to hammer it yet. I'll keep 
watching...
The problem is *much* better than when I filed this bug report. Builds in
mid-april seem quite a bit happier than they used to be around late february. :)
Unless anyone notices anything in the next few days, I am going to mark this one
wfm. :)

Thanks.
Marking closed due to sarnold's comments
marking fixed again
Status: UNCONFIRMED → RESOLVED
Closed: 24 years ago
Resolution: --- → FIXED
verified on build 2001-08-06-03-trunk
Status: RESOLVED → VERIFIED
Component: Event Handling → User events and focus handling
You need to log in before you can comment on or make changes to this bug.