the 6.0 start page (http://home.netscape.com/browsers/6/su_setup.html) is calling gettimeofday an absurd number of times on linux. it pings the CPU, so the release builds are barely usable, until you switch pages, which is hard to do with the CPU pegged. I'm going to go see why gettimeofday() is getting called like there is no tomorrow. (it might be result of some JS on that page. I have no idea yet.)

switching to browser product.

i'm pretty sure glib calls gettimeofday every cycle it processes in the event loop. So if the event loop is being pegged hard, then gettimeofday is going to be getting called a lot. I would try and find out why the event loop is being pegged hard.

I think this is the stack to the gettimeofday call that is killing us. #0 0x40525770 in __gettimeofday () #1 0x408aa9ab in ?? () from /usr/lib/libglib-1.2.so.0 #2 0x408ab950 in ?? () from /usr/lib/libglib-1.2.so.0 #3 0x4074499e in ?? () from /builds/seth/seamonkey/mozilla/dist/bin/components/libtimer_gtk.so #4 0x4034d07c in GlobalWindowImpl::SetTimeoutOrInterval (this=0x84d83d8, cx=0x85e02d8, argv=0x86dbcf4, argc=2, aReturn=0xbfffde8c, aIsInterval=0) at nsGlobalWindow.cpp:3001 #5 0x40345b01 in GlobalWindowImpl::SetTimeout (this=0x84d83d8, cx=0x85e02d8, argv=0x86dbcf4, argc=2, aReturn=0xbfffde8c) at nsGlobalWindow.cpp:1474 #6 0x40339562 in WindowSetTimeout (cx=0x85e02d8, obj=0x8595af8, argc=2, argv=0x86dbcf4, rval=0xbfffdf40) at nsJSWindow.cpp:1876 #7 0x40099d86 in js_Invoke (cx=0x85e02d8, argc=2, flags=0) at jsinterp.c:686 #8 0x400aad9b in js_Interpret (cx=0x85e02d8, result=0xbfffe90c) at jsinterp.c:2464 #9 0x40099de5 in js_Invoke (cx=0x85e02d8, argc=1, flags=2) at jsinterp.c:702 #10 0x4009a11c in js_InternalInvoke (cx=0x85e02d8, obj=0x8595af8, fval=140817376, flags=0, argc=1, argv=0xbfffeb8c, rval=0xbfffea80) at jsinterp.c:775 #11 0x4006dad7 in JS_CallFunctionValue (cx=0x85e02d8, obj=0x8595af8, fval=140817376, argc=1, argv=0xbfffeb8c, rval=0xbfffea80) at jsapi.c:2794 #12 0x403342c9 in nsJSContext::CallEventHandler (this=0x84d84a0, aTarget=0x8595af8, aHandler=0x864b3e0, argc=1, argv=0xbfffeb8c, aBoolResult=0xbfffeadc) at nsJSEnvironment.cpp:730 #13 0x403718f9 in nsJSEventListener::HandleEvent (this=0x86e1540, aEvent=0x88b620c) at nsJSEventListener.cpp:128 #14 0x411d3191 in nsEventListenerManager::HandleEventSubType (this=0x86e0ef0, aListenerStruct=0x86e1578, aDOMEvent=0x88b620c, aSubType=1, aPhaseFlags=7) at nsEventListenerManager.cpp:703 #15 0x411d47de in nsEventListenerManager::HandleEvent (this=0x86e0ef0, aPresContext=0x8608918, aEvent=0xbffff3ac, aDOMEvent=0xbfffef6c, aFlags=7, aEventStatus=0xbffff3ec) at nsEventListenerManager.cpp:1266 #16 0x4033fd1b in GlobalWindowImpl::HandleDOMEvent (this=0x84d83d8, aPresContext=0x8608918, aEvent=0xbffff3ac, aDOMEvent=0xbfffef6c, aFlags=1, aEventStatus=0xbffff3ec) at nsGlobalWindow.cpp:380 #17 0x40291173 in ?? () from /builds/seth/seamonkey/mozilla/dist/bin/libraptorwebwidget.so #18 0x40d3d772 in ?? () from /builds/seth/seamonkey/mozilla/dist/bin/components/liburiloader.so #19 0x40d3d213 in ?? () from /builds/seth/seamonkey/mozilla/dist/bin/components/liburiloader.so #20 0x40d3d088 in ?? () from /builds/seth/seamonkey/mozilla/dist/bin/components/liburiloader.so #21 0x40c3a4f2 in nsLoadGroup::RemoveChannel (this=0x85ea3e8, channel=0x88ba948, ctxt=0x0, status=0, errorMsg=0x0) at nsLoadGroup.cpp:543 #22 0x41863cea in nsHTTPChannel::ResponseCompleted (this=0x88ba948, aListener=0x868d0b8, aStatus=0, aMsg=0x0) at nsHTTPChannel.cpp:1488 #23 0x4186a8d0 in nsHTTPServerListener::OnStopRequest (this=0x868d428, channel=0x88ba024, i_pContext=0x88ba948, i_Status=0, i_pMsg=0x0) at nsHTTPResponseListener.cpp:552 #24 0x40c221c8 in nsOnStopRequestEvent::HandleEvent (this=0x41a01d48) at nsAsyncStreamListener.cpp:306 #25 0x40c21777 in nsStreamListenerEvent::HandlePLEvent (aEvent=0x41a01d68) at nsAsyncStreamListener.cpp:97 #26 0x40196afe in PL_HandleEvent (self=0x41a01d68) at plevent.c:563 #27 0x401969ac in PL_ProcessPendingEvents (self=0x813a948) at plevent.c:508 #28 0x40198650 in nsEventQueueImpl::ProcessPendingEvents (this=0x813a920) at nsEventQueue.cpp:316 #29 0x406ef0a4 in ?? () from /builds/seth/seamonkey/mozilla/dist/bin/libwidget_gtk.so #30 0x406eecef in ?? () from /builds/seth/seamonkey/mozilla/dist/bin/libwidget_gtk.so #31 0x408a93ca in ?? () from /usr/lib/libglib-1.2.so.0 #32 0x408aaa86 in ?? () from /usr/lib/libglib-1.2.so.0 #33 0x408ab041 in ?? () from /usr/lib/libglib-1.2.so.0 #34 0x408ab1e1 in ?? () from /usr/lib/libglib-1.2.so.0 #35 0x407d47a9 in ?? () from /usr/lib/libgtk-1.2.so.0 #36 0x406ef6d7 in ?? () from /builds/seth/seamonkey/mozilla/dist/bin/libwidget_gtk.so #37 0x40645b04 in ?? () from /builds/seth/seamonkey/mozilla/dist/bin/components/libnsappshell.so #38 0x804eb44 in main1 (argc=1, argv=0xbffff9c4, splashScreen=0x0) at nsAppRunner.cpp:758 #39 0x804f130 in main (argc=1, argv=0xbffff9c4) at nsAppRunner.cpp:879 #40 0x404b6cb3 in __libc_start_main (main=0x804ee50 <main>, argc=1, argv=0xbffff9c4, init=0x804b950 <_init>, fini=0x80548a8 <_fini>, rtld_fini=0x4000a350, stack_end=0xbffff9bc) at ../sysdeps/generic/libc-start.c:78

this bug needs a rightful owner. any suggestions?

re-assign to the default owner.

On Mac, loading that page causes huge numbers of assersions from layout and the view manager. Assertions are of two kinds: ###!!! ASSERTION: prev sibling not in line list: 'nsnull != prevSibLine', file nsBlockFrame.cpp, line 4936 ###!!! ASSERTION: bad clip values: 'aLeft <= aRight && aTop <= aBottom', file nsView.cpp, line 1033

I don't think that Asa is the right owner! Should this go to rickg in layout? adding dogfood - this bug makes it seem that the build is not working or very, very slow.

Adding pp. This is only occurring on Linux platform.....

I still have problem for today's Linux build....didn't we change the start page for today's build yet? Can anybody post workaround here?

here is the workaround, sorry for not posting it yesterday after you download the package, remove the following file: package/defaults/pref/config-ns.js that should fix the problem for you. the bad this news is, all linux beta users will have this problem. the bug got assigned to asa, as he is the default owner. I'll work on finding a better owner.

I get this to seem to lock up my lower end Linux boxes when it goes to the default home page of http://home.netscape.com/browsers/6/su_setup.html with a new profile. (200mhz P/128mb ram & 133 mhz P/64mb ram). I am forced to lauch my apps via the -mail or -aim parameter because of this apparent freeze. IF I click on Tasks menu, after about 1 minute I actually get a pull down, but if I select Instant Messenger(for example) from that, it won't comes back with the IM Standalone in a reasonable amount of time (I let it sit 2 minutes before giving up).

adding myself and prass to cc

this bug also effects high end linux boxes. re-assign to travis, as GlobalWindowImpl is the caller.

I don't own that code. I'm flipping it over to jst since I think it is some core part of the DOM.

I don't think the fact that we're calling gettimeofday() alot is the problem here, I think this is really only a dup of bug 19388 (and bug 4807) but the problem shows up even worse here. It seems that the above url doesn't work very well with async reflow, turning off async reflow (layout.reflow.async.afterDocLoad) makes the page a lot more useable here on my system. I think that the reason for this working better on windows is because we're faster on windows or our event processing (priorities n' such) is different than on linux and mac. Reassigning to kmcclusk@netscape.com since he owns bug 19388, Cc:ing myself and troy in case he has some good ideas on this.

PDT thinks this is beta2+ but dogfood-. We can do our work with poor performance on this page, but we wouldn't ship to users without fixing this.

unfortunately, we already shipped beta with this. not a great first impression for linux users, but it only happened on the official netscape bits, not mozilla, so maybe we didn't get too hard.

Moving to M16

Updating [beta2+] to be [nsbeta2+]

The root of the problem is the nsITimer implementation for GTK. We schedule system timers for each nsITimer instance. A large number of timer events end up on the message queue and Mozilla spends all of it's time in JavaScript code which manipulates the DOM, without ever getting to the paint, mouse, and keyboard events sitting in the message queue after the timer events. WIN32 and Mac place give the paint,mouse, and keyboard events higher priority than the timer events. The solution is to explictly manage the timer events by writing cross-platform code for maintaining a list of pending timers and make calls to process the timer list within the message pump based on a single system timer.

Accepting

*** Bug 40211 has been marked as a duplicate of this bug. ***

pardon the spam: adding self to cc list. and bumping up sev to blocker (as per bug 40211).

Putting on [dogfood-] radar since an [nsbeta2+]

Sorry for the spam. New QA Contact for Browser General. Thanks for your help Joseph (good luck with the new job) and welcome aboard Doron Rosenberg

*** Bug 41563 has been marked as a duplicate of this bug. ***

just out oc curiousity, does anyone know why this is happening on the netscape 6 start page and not on other pages?

M16 has been out for a while now, these bugs target milestones need to be updated.

Fix checked in.

The netscape6 home page setups up multiple timers (7 I believe) each one is manipulating the position, or changing the color of the "big" Netscape 6 or the spinning Netscapes. The timeouts for the timers is short enough that most machines can not process all of the timers and related layout changes before another timer fires. On WIN32 this is not a problem because the timer implementation forces all paints to happen before the next set of timers fire. On Linux the timer just keeps firing, triggering additional changes. The paint messages on Linux never get processed. Most pages use a single timer to drive each animation frame which is much more

reopening. we introduced numerous regressions with this fix. we are no longer firing timers when they should get fired... but have no fear... I have a fix.

reassigning

no, i don't like that. i'm opening a new bug.

re-resolving fixed

pavlov, what's the new bugid?

verified fixed -- linux 2000070608 -- loading this page no longer locks up mozilla; other mouse and keyboard events get service while the dhtml animation runs. FYI: Pavlov's other bug on timers was filed (and fixed) as bug #43789. (I noticed that there are drawing errors in the DHTML (i.e., the "smoothing" of the text and numbers is not complete), but that existed before the timer fix. I'll look at this, and file a bug, possibly on whomever developed the DHTML for this animation).