Closed Bug 34871 Opened 24 years ago Closed 24 years ago

calling gettimeofday() an insane number of times

Categories

(SeaMonkey :: General, defect, P3)

Product:
SeaMonkey
Component:
General
Platform:
x86
Linux
Type:
defect

Tracking

(Not tracked)

Status:
VERIFIED FIXED

People

(Reporter: sspitzer, Assigned: waqar)

References

(
URL
)

Details

(Keywords: platform-parity, Whiteboard: [nsbeta2+][dogfood-]) 

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.
Component: Front End → Browser-General
Product: MailNews → Browser
Target Milestone: --- → M15
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.
Assignee: sspitzer → asadotzler
QA Contact: lchiang → jelwell
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.
Keywords: dogfood
Adding pp.
This is only occurring on Linux platform.....
Keywords: pp
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.
Assignee: asadotzler → travis
I don't own that code.  I'm flipping it over to jst since I think it is some 
core part of the DOM.
Assignee: travis → jst
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.
Assignee: jst → kmcclusk
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.
Keywords: beta2
Whiteboard: [beta2+]
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
Status: NEW → ASSIGNED
Target Milestone: M15 → M16
Keywords: nsbeta2
Updating [beta2+] to be [nsbeta2+]
Keywords: beta2
Whiteboard: [beta2+] → [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.
Assignee: kmcclusk → waqar
Status: ASSIGNED → NEW
Accepting
Status: NEW → ASSIGNED
*** 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).
Severity: normal → blocker
Putting on [dogfood-] radar since an [nsbeta2+]
Whiteboard: [nsbeta2+] → [nsbeta2+][dogfood-]
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
QA Contact: jelwell → doronr
Blocks: 35284
*** 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.
Status: ASSIGNED → RESOLVED
Closed: 24 years ago
Resolution: --- → FIXED
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.
Status: RESOLVED → REOPENED
Resolution: FIXED → ---
reassigning
Assignee: waqar → pavlov
Status: REOPENED → NEW
no, i don't like that.  i'm opening a new bug.
Assignee: pavlov → waqar
re-resolving fixed
Status: NEW → RESOLVED
Closed: 24 years ago → 24 years ago
Resolution: --- → 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).
Status: RESOLVED → VERIFIED
QA Contact: doronr → jrgm
Product: Browser → Seamonkey
You need to log in before you can comment on or make changes to this bug.