Closed
Bug 474406
Opened 15 years ago
Closed 15 years ago
[FIX]CPU usage peaking at 100% on Lufthansa website
Categories
(Core :: XBL, defect)
Tracking
()
RESOLVED
FIXED
People
(Reporter: der.ozean, Assigned: bzbarsky)
References
()
Details
(4 keywords)
Attachments
(4 files)
53.43 KB,
text/plain
|
Details | |
158.94 KB,
text/plain
|
Details | |
2.91 KB,
patch
|
sicking
:
review+
sicking
:
superreview+
|
Details | Diff | Splinter Review |
1.24 KB,
patch
|
dveditz
:
approval1.9.0.7+
|
Details | Diff | Splinter Review |
User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en; rv:1.9.0.6pre) Gecko/2009011500 Camino/2.0b2pre (like Firefox/3.0.6pre) Build Identifier: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en; rv:1.9.0.6pre) Gecko/2009011500 Camino/2.0b2pre (like Firefox/3.0.6pre) CPU starts to rise to around 100% as soon as I modify one of the date fields on the Lufthansa booking search date fields. It stays at this high level and makes quitting Camino impossible without resorting to a force-quit. OS X 10.5.6, no Camino add-ons or haxies installed. Ad-block is on, as are Flash-block and pop-up suppression. Reproducible: Always Steps to Reproduce: This is the unpromlematic part of the sequence: 1. click into the From: field and enter a city 2. press tab key to move to the Depart on: field 3. select a date with a mouse click 4. click into the To: field and enter another city 5. press tab key to move to the Return on: field 6. select another date with a mouse click Now comes the problematic part: 7. use your mouse to click (or the tab key) to get into either the Depart: or Return: field to select a different date this will send the processor usage flying! Actual Results: CPU usage is nearing 100% (i.e. on of the two cores of my C2D MacBook Pro 2.33Ghz). Camino remains useable but it becomes really slow. In addition, it is not possible to quit Camino without issuing a force-quit. Memory use seems to stay at a stable level. Expected Results: no particular increase in CPU usage and no problems in quitting Camino I have a process sample, taken right after the CPU accelerating click: http://pastebin.com/f4b176589 There has also been some discussion of this bug in the Camino forum (you can find more samples there and also a console hang-report): http://forums.mozillazine.org/viewtopic.php?f=12&t=1044265
Reporter | ||
Comment 1•15 years ago
|
||
Ah, forgot this: on the forum, phiw13 stated: “I tried next with Minefield latest nightly, then Fx 3.05 release build, and the nightly of what will be Fx 3.0.6, but none of them had a problem.” So this really seems to be a Camino-specific bug…
Comment 2•15 years ago
|
||
(In reply to comment #1) > Ah, forgot this: on the forum, phiw13 stated: “I tried next with Minefield > latest nightly, then Fx 3.05 release build, and the nightly of what will be Fx > 3.0.6, but none of them had a problem.” So this really seems to be a > Camino-specific bug… Yes, I tested Minefield latest, the official FX 3.05 build and the Gran Paradiso nightly (3.06pre) and none of them had problems. Confirming the issue meanwhile.
Status: UNCONFIRMED → NEW
Ever confirmed: true
Reporter | ||
Comment 3•15 years ago
|
||
the content of this attachment is the same as what is provided in the pastebin link in the bug description
Does this happen in 1.6.6, too, or just 2.0*?
Reporter | ||
Comment 5•15 years ago
|
||
It does not happen in 1.6.6. (I tried it on another 10.5.6 machine (MacBook C2D), also with flash- and adblock turned on)
Comment 6•15 years ago
|
||
I don't think flash has anything to do with this. The problem happens when Camino attempts to reload the calendar (loaded from an iframe). Regression window: works 2007120400 (2.0a1pre) fails 2007120500 (2.0a1pre) http://bonsai.mozilla.org/cvsquery.cgi?treeid=default&module=all&branch=HEAD&branchtype=match&dir=&file=&filetype=match&who=&whotype=match&sortby=Date&hours=2&date=explicit&mindate=2007-12-04+00%3A00%3A00&maxdate=2007-12-05+01%3A00%3A00&cvsroot=%2Fcvsroot [between 2008010800 (2.0a1pre) and 2008011500 (2.0a1pre) there was some change in behaviour; after 20080115 it works 'better' in that one needs to click a second time in the first date field for the hang to happen. Before that, moving away from the first date field was enough to send the cpu into the 100%+ zone, and hang.]
Comment 7•15 years ago
|
||
There are a handful of layout checkins in that range: Bug 406568 Bug 402567 Bug 375304 Bug 392809 Bug 406485 Bug 404209 Bug 406852 Bug 383195 There are also three event checkins in there: Bug 404870 Bug 376077 (Cocoa widget) Bug 401743 (which also has to do with XBL bindings, and nsBindingManager shows up in the sample stack)
Updated•15 years ago
|
Keywords: regression
philippe, do you have any idea how to reduce this into a testcase?
Keywords: hang
Comment 9•15 years ago
|
||
The layout bugs seem unlikely, as does the Cocoa widget change (if it was doing some fun swizzling, I'd be all over that, though). I think bug 404870 and bug 401743 are the most likely. roc and bz: Do either of you see any reason why your patch(es) would cause an issue like this? Is there more debugging we can do to help figure out the issue here?
Assignee | ||
Comment 10•15 years ago
|
||
Possible, but unlikely in the XBL case. This is not reproducible in Firefox, right? Can someone who can reproduce with a Camino build (not a camino nightly) get a shark profile? The sample linked from comment 0 is for a build with no debug symbols looks, like, so of limited utility...
Here's a plain-old sample from right after clicking back into the departure date field (because I think it might be small enough to attach to Bugzilla and be viewable; the with-Flash plain-old sample was not). I'm the farthest thing in the world from a Shark adept, but I've uploaded two profiles (Flashblock on, to match Lars's experience and generally get the excess Flash noise out of the sample; and Flashblock off) begun just before clicking back into the departure date field and ended shortly after clicking back into that field. Both of the samples that I took earlier are also uploaded. http://www.ardisson.org/smokey/moz/bug474406/
Assignee | ||
Comment 12•15 years ago
|
||
Hmm. The flashblocked profile shows us processing lots of events and spending about 30% of our time in kernel code... I guess that matches the samples, sort of. It's just not very informative, since all the time is spent outside Gecko (in Cocoa and the kernel). :( At this point I'd be willing to believe pretty much anything that sends us into a loop of some sort.... Is someone willing to just sit down and try compiling builds across that day and hunting down the exact checkin responsible?
Works: make -f client.mk checkout MOZ_CO_DATE="04 December 2007 08:56 PST" ; cvs up -r1.5 content/html/content/src/nsHTMLSelectElement.h ; make -f client.mk build Fails: make -f client.mk MOZ_CO_DATE="04 December 2007 09:35 PST" That does look like it points to bug 401743 :(
Blocks: 401743
Assignee | ||
Comment 14•15 years ago
|
||
I assume that trying to back that patch out locally with patch -R will lead to the same result. Here's a question. I assume you're ending up in DoProcessAttachedQueue with mProcessingAttachedStack true, right? And that it happens over and over again? If so, can you get me the stack at that point?
(In reply to comment #14) > I assume that trying to back that patch out locally with patch -R will lead to > the same result. Yes, backing that out of a current tree gets us back to no CPU spike/hang. > Here's a question. I assume you're ending up in DoProcessAttachedQueue with > mProcessingAttachedStack true, right? And that it happens over and over again? > If so, can you get me the stack at that point? Stuart's going to try to look into this tonight.
Comment 16•15 years ago
|
||
Sorry, I'm having to wrestle with my tree a bit so I couldn't look at it tonight after all. I'll give it another shot tomorrow.
Comment 17•15 years ago
|
||
(In reply to comment #14) > I assume you're ending up in DoProcessAttachedQueue with > mProcessingAttachedStack true, right? And that it happens over and over again? Yep. > If so, can you get me the stack at that point? #0 nsBindingManager::DoProcessAttachedQueue (this=0x1a9a32d0) at /Volumes/Chambord/Camino/trees/trunk/mozilla/content/xbl/src/nsBindingManager.cpp:943 #1 0x139c90e9 in nsRunnableMethod<nsBindingManager>::Run (this=0x1f34db10) at nsThreadUtils.h:261 #2 0x0033f95c in nsThread::ProcessNextEvent (this=0x9baad0, mayWait=0, result=0xbfffe454) at /Volumes/Chambord/Camino/trees/trunk/mozilla/xpcom/threads/nsThread.cpp:510 #3 0x002c9ece in NS_ProcessPendingEvents_P (thread=0x9baad0, timeout=20) at nsThreadUtils.cpp:180 #4 0x159389bf in nsBaseAppShell::NativeEventCallback (this=0x15ca0c40) at /Volumes/Chambord/Camino/trees/trunk/mozilla/widget/src/xpwidgets/nsBaseAppShell.cpp:121 #5 0x158f3e58 in nsAppShell::ProcessGeckoEvents (aInfo=0x15ca0c40) at /Volumes/Chambord/Camino/trees/trunk/mozilla/widget/src/cocoa/nsAppShell.mm:302 #6 0x93b035f5 in CFRunLoopRunSpecific () #7 0x93b03cd8 in CFRunLoopRunInMode () #8 0x9255d2c0 in RunCurrentEventLoopInMode () #9 0x9255d012 in ReceiveNextEventCommon () #10 0x9255cf4d in BlockUntilNextEventMatchingListInMode () #11 0x90569d7d in _DPSNextEvent () #12 0x90569630 in -[NSApplication nextEventMatchingMask:untilDate:inMode:dequeue:] () #13 0x9056266b in -[NSApplication run] () ...
Assignee | ||
Comment 18•15 years ago
|
||
That's the whole stack? Nothing else? If so, then that boolean just has the wrong value, no?
Comment 19•15 years ago
|
||
Just NSApplicationMain and main. I'm not sure what the boolean is for, not being familiar with this code, but I can tell you it's PR_TRUE because just before things hit the fan nsBindingManager::DropDocumentReference is called on the object that gets into the loop of death, which is the last time mProcessingAttachedStack is set for it: #0 nsBindingManager::DropDocumentReference (this=0x1cfc02a0) at /Volumes/Chambord/Camino/trees/trunk/mozilla/content/xbl/src/nsBindingManager.cpp:1472 #1 0x139c14f4 in nsNodeInfoManager::DropDocumentReference (this=0x1b78d8c0) at /Volumes/Chambord/Camino/trees/trunk/mozilla/content/base/src/nsNodeInfoManager.cpp:210 #2 0x139855a9 in nsDocument::~nsDocument (this=0x1060400) at /Volumes/Chambord/Camino/trees/trunk/mozilla/content/base/src/nsDocument.cpp:877 #3 0x13ac8d91 in nsHTMLDocument::~nsHTMLDocument (this=0x1060400) at /Volumes/Chambord/Camino/trees/trunk/mozilla/content/html/document/src/nsHTMLDocument.cpp:380 #4 0x139c361e in nsNodeUtils::LastRelease (aNode=0x1060400) at /Volumes/Chambord/Camino/trees/trunk/mozilla/content/base/src/nsNodeUtils.cpp:245 #5 0x139734a4 in nsDocument::Release (this=0x1060400) at /Volumes/Chambord/Camino/trees/trunk/mozilla/content/base/src/nsDocument.cpp:950 #6 0x13ac6810 in nsHTMLDocument::Release (this=0x1060400) at /Volumes/Chambord/Camino/trees/trunk/mozilla/content/html/document/src/nsHTMLDocument.cpp:419 #7 0x1386f8a2 in nsCOMPtr<nsIDocument>::assign_assuming_AddRef (this=0x1cfbce30, newPtr=0x0) at nsCOMPtr.h:568 #8 0x136df546 in nsCOMPtr<nsIDocument>::assign_with_AddRef (this=0x1cfbce30, rawPtr=0x0) at nsCOMPtr.h:1267 #9 0x136df70a in nsCOMPtr<nsIDocument>::operator= (this=0x1cfbce30, rhs=0x0) at nsCOMPtr.h:713 #10 0x13c0a980 in nsGlobalWindow::SetDocShell (this=0x1cfbccc0, aDocShell=0x0) at /Volumes/Chambord/Camino/trees/trunk/mozilla/dom/src/base/nsGlobalWindow.cpp:2040 #11 0x14fa354d in nsDocShell::Destroy (this=0x1cfbd170) at /Volumes/Chambord/Camino/trees/trunk/mozilla/docshell/base/nsDocShell.cpp:3728 #12 0x13998ab2 in nsFrameLoader::Finalize (this=0x1b78f4d0) at /Volumes/Chambord/Camino/trees/trunk/mozilla/content/base/src/nsFrameLoader.cpp:279 #13 0x13981e10 in nsDocument::InitializeFinalizeFrameLoaders (this=0x1042200) at /Volumes/Chambord/Camino/trees/trunk/mozilla/content/base/src/nsDocument.cpp:3921 #14 0x13981f35 in nsDocument::EndUpdate (this=0x1042200, aUpdateType=1) at /Volumes/Chambord/Camino/trees/trunk/mozilla/content/base/src/nsDocument.cpp:2760 #15 0x13ad364d in nsHTMLDocument::EndUpdate (this=0x1042200, aUpdateType=1) at /Volumes/Chambord/Camino/trees/trunk/mozilla/content/html/document/src/nsHTMLDocument.cpp:3752 #16 0x1376b555 in mozAutoDocUpdate::~mozAutoDocUpdate (this=0xbfffcea4) at ../../content/base/src/mozAutoDocUpdate.h:66 #17 0x139aae7f in nsGenericElement::doRemoveChildAt (aIndex=30, aNotify=1, aKid=0x1b7a8cc0, aParent=0x1cf4d940, aDocument=0x1042200, aChildArray=@0x1cf4d958) at /Volumes/Chambord/Camino/trees/trunk/mozilla/content/base/src/nsGenericElement.cpp:2851 #18 0x139aaf7f in nsGenericElement::RemoveChildAt (this=0x1cf4d940, aIndex=30, aNotify=1) at /Volumes/Chambord/Camino/trees/trunk/mozilla/content/base/src/nsGenericElement.cpp:2776 #19 0x139a4f5f in nsGenericElement::doRemoveChild (aOldChild=0x1b7a8ce8, aParent=0x1cf4d940, aDocument=0x1042200, aReturn=0xbfffd1a4) at /Volumes/Chambord/Camino/trees/trunk/mozilla/content/base/src/nsGenericElement.cpp:3438 #20 0x139a4fc8 in nsGenericElement::RemoveChild (this=0x1cf4d940, aOldChild=0x1b7a8ce8, aReturn=0xbfffd1a4) at /Volumes/Chambord/Camino/trees/trunk/mozilla/content/base/src/nsGenericElement.cpp:3004 #21 0x13a58027 in nsHTMLBodyElement::RemoveChild (this=0x1cf4d940, oldChild=0x1b7a8ce8, _retval=0xbfffd1a4) at /Volumes/Chambord/Camino/trees/trunk/mozilla/content/html/content/src/nsHTMLBodyElement.cpp:95 #22 0x0035a3b3 in NS_InvokeByIndex_P (that=0x1cf4d95c, methodIndex=17, paramCount=2, params=0xbfffd194) at /Volumes/Chambord/Camino/trees/trunk/mozilla/xpcom/reflect/xptcall/src/md/unix/xptcinvoke_unixish_x86.cpp:179 #23 0x00df47e3 in XPCWrappedNative::CallMethod (ccx=@0xbfffd3ec, mode=XPCWrappedNative::CALL_METHOD) at /Volumes/Chambord/Camino/trees/trunk/mozilla/js/src/xpconnect/src/xpcwrappednative.cpp:2393 #24 0x00dfece5 in XPC_WN_CallMethod (cx=0x18e7b480, obj=0x170cc660, argc=1, argv=0x1363730, vp=0xbfffd52c) at /Volumes/Chambord/Camino/trees/trunk/mozilla/js/src/xpconnect/src/xpcwrappednativejsops.cpp:1473 #25 0x132392a4 in js_Invoke (cx=0x18e7b480, argc=1, vp=0x1363728, flags=2) at jsinterp.c:1304 #26 0x1322c2cf in js_Interpret (cx=0x18e7b480) at /Volumes/Chambord/Camino/trees/trunk/mozilla/js/src/jsinterp.c:4864 #27 0x13239319 in js_Invoke (cx=0x18e7b480, argc=1, vp=0x1363624, flags=0) at jsinterp.c:1320 #28 0x132395d9 in js_InternalInvoke (cx=0x18e7b480, obj=0x170cdcc0, fval=386719360, flags=0, argc=1, argv=0x1363620, rval=0xbfffde4c) at jsinterp.c:1376 #29 0x131d99c6 in JS_CallFunctionValue (cx=0x18e7b480, obj=0x170cdcc0, fval=386719360, argc=1, argv=0x1363620, rval=0xbfffde4c) at /Volumes/Chambord/Camino/trees/trunk/mozilla/js/src/jsapi.c:5054 #30 0x13be34b4 in nsJSContext::CallEventHandler (this=0x18e7b3d0, aTarget=0x1b71ea40, aScope=0x170cfca0, aHandler=0x170cde80, aargv=0x1b74da90, arv=0xbfffdfdc) at /Volumes/Chambord/Camino/trees/trunk/mozilla/dom/src/base/nsJSEnvironment.cpp:1962 #31 0x13c5454b in nsJSEventListener::HandleEvent (this=0x1b735240, aEvent=0x1b7ec440) at /Volumes/Chambord/Camino/trees/trunk/mozilla/dom/src/events/nsJSEventListener.cpp:248 #32 0x13a0872f in nsEventListenerManager::HandleEventSubType (this=0x1b72e9d0, aListenerStruct=0x1b72fe70, aListener=0x1b735240, aDOMEvent=0x1b7ec440, aCurrentTarget=0x1b71ea40, aPhaseFlags=6) at /Volumes/Chambord/Camino/trees/trunk/mozilla/content/events/src/nsEventListenerManager.cpp:1080 #33 0x13a0a3f7 in nsEventListenerManager::HandleEvent (this=0x1b72e9d0, aPresContext=0x17e1f030, aEvent=0xbfffe50c, aDOMEvent=0xbfffe3d0, aCurrentTarget=0x1b71ea40, aFlags=6, aEventStatus=0xbfffe3d4) at /Volumes/Chambord/Camino/trees/trunk/mozilla/content/events/src/nsEventListenerManager.cpp:1185 #34 0x13a3815a in nsEventTargetChainItem::HandleEvent (this=0x13e6820, aVisitor=@0xbfffe3c8, aFlags=6) at /Volumes/Chambord/Camino/trees/trunk/mozilla/content/events/src/nsEventDispatcher.cpp:210 #35 0x13a38337 in nsEventTargetChainItem::HandleEventTargetChain (this=0x13e6ae0, aVisitor=@0xbfffe3c8, aFlags=6, aCallback=0x0) at /Volumes/Chambord/Camino/trees/trunk/mozilla/content/events/src/nsEventDispatcher.cpp:268 #36 0x13a38bb4 in nsEventDispatcher::Dispatch (aTarget=0x1b71ea40, aPresContext=0x17e1f030, aEvent=0xbfffe50c, aDOMEvent=0x0, aEventStatus=0xbfffe590, aCallback=0x0) at /Volumes/Chambord/Camino/trees/trunk/mozilla/content/events/src/nsEventDispatcher.cpp:483 #37 0x13a18d0d in nsEventStateManager::SendFocusBlur (this=0x9dc1b0, aPresContext=0x17e1f030, aContent=0x1b71d9e0, aEnsureWindowHasFocus=1) at /Volumes/Chambord/Camino/trees/trunk/mozilla/content/events/src/nsEventStateManager.cpp:4546 #38 0x13a19fe0 in nsEventStateManager::SetContentState (this=0x9dc1b0, aContent=0x1b71d9e0, aState=2) at /Volumes/Chambord/Camino/trees/trunk/mozilla/content/events/src/nsEventStateManager.cpp:4255 #39 0x13a48a55 in nsGenericHTMLFormElement::SetFocusAndScrollIntoView (this=0x1b71d9e0, aPresContext=0x17e1f030) at /Volumes/Chambord/Camino/trees/trunk/mozilla/content/html/content/src/nsGenericHTMLElement.cpp:2875 #40 0x13a7d5ae in nsHTMLInputElement::SetFocus (this=0x1b71d9e0, aPresContext=0x17e1f030) at /Volumes/Chambord/Camino/trees/trunk/mozilla/content/html/content/src/nsHTMLInputElement.cpp:1300 #41 0x13a13913 in nsEventStateManager::ChangeFocusWith (this=0x9dc1b0, aFocusContent=0x1b71d9e0, aFocusedWith=eEventFocusedByMouse) at /Volumes/Chambord/Camino/trees/trunk/mozilla/content/events/src/nsEventStateManager.cpp:3396 #42 0x13a1816f in nsEventStateManager::PostHandleEvent (this=0x9dc1b0, aPresContext=0x17e1f030, aEvent=0xbfffede4, aTargetFrame=0x138b400, aStatus=0xbfffeb18, aView=0x17edf040) at /Volumes/Chambord/Camino/trees/trunk/mozilla/content/events/src/nsEventStateManager.cpp:2405 #43 0x1370d42a in PresShell::HandleEventInternal (this=0x1222000, aEvent=0xbfffede4, aView=0x17edf040, aStatus=0xbfffeb18) at /Volumes/Chambord/Camino/trees/trunk/mozilla/layout/base/nsPresShell.cpp:5954 #44 0x1370d6a1 in PresShell::HandlePositionedEvent (this=0x1222000, aView=0x17edf040, aTargetFrame=0x138b400, aEvent=0xbfffede4, aEventStatus=0xbfffeb18) at /Volumes/Chambord/Camino/trees/trunk/mozilla/layout/base/nsPresShell.cpp:5821 #45 0x1370f6bb in PresShell::HandleEvent (this=0x1222000, aView=0x17edf040, aEvent=0xbfffede4, aEventStatus=0xbfffeb18) at /Volumes/Chambord/Camino/trees/trunk/mozilla/layout/base/nsPresShell.cpp:5681 #46 0x13bcfd64 in nsViewManager::HandleEvent (this=0x17edefe0, aView=0x17edf040, aPoint=@0xbfffebfc, aEvent=0xbfffede4, aCaptured=0) at /Volumes/Chambord/Camino/trees/trunk/mozilla/view/src/nsViewManager.cpp:1382 #47 0x13bd0cc3 in nsViewManager::DispatchEvent (this=0x17edefe0, aEvent=0xbfffede4, aStatus=0xbfffec88) at /Volumes/Chambord/Camino/trees/trunk/mozilla/view/src/nsViewManager.cpp:1337 #48 0x13bc6c31 in HandleEvent (aEvent=0xbfffede4) at /Volumes/Chambord/Camino/trees/trunk/mozilla/view/src/nsView.cpp:168 #49 0x18b6cf31 in nsChildView::DispatchEvent (this=0x1cfa1940, event=0xbfffede4, aStatus=@0xbfffed5c) at /Volumes/Chambord/Camino/trees/trunk/mozilla/widget/src/cocoa/nsChildView.mm:1718 #50 0x18b5ffd6 in nsChildView::DispatchWindowEvent (this=0x1cfa1940, event=@0xbfffede4) at /Volumes/Chambord/Camino/trees/trunk/mozilla/widget/src/cocoa/nsChildView.mm:1731 #51 0x18b6cae6 in nsChildView::DispatchMouseEvent (this=0x1cfa1940, aEvent=@0xbfffede4) at /Volumes/Chambord/Camino/trees/trunk/mozilla/widget/src/cocoa/nsChildView.mm:1743 #52 0x18b6d7f2 in -[ChildView mouseDown:] (self=0x1cfa19e0, _cmd=0x961e2918, theEvent=0x1b7a16a0) at /Volumes/Chambord/Camino/trees/trunk/mozilla/widget/src/cocoa/nsChildView.mm:3032 #53 0x906381a3 in -[NSWindow sendEvent:] () #54 0x18b5e15c in -[NSWindow(MethodSwizzling) nsCocoaWindow_NSWindow_sendEvent:] (self=0x17ecc2b0, _cmd=0x961b34b8, anEvent=0x1b7a16a0) at /Volumes/Chambord/Camino/trees/trunk/mozilla/widget/src/cocoa/nsCocoaWindow.mm:2153 #55 0x90604d49 in -[NSApplication sendEvent:] () #56 0x9056269f in -[NSApplication run] () #57 0x9052f8a4 in NSApplicationMain ()
Assignee | ||
Comment 20•15 years ago
|
||
Oh, well, there we go. That stack is exactly what I needed. Thank you! I have no idea why this doesn't bite other Gecko-based browsers. This code is clearly wrong.
Status: NEW → ASSIGNED
Component: General → XBL
Flags: wanted1.9.1?
Product: Camino → Core
QA Contact: general → xbl
Summary: CPU usage peaking at 100% on Lufthansa website → [FIX]CPU usage peaking at 100% on Lufthansa website
Assignee | ||
Comment 21•15 years ago
|
||
Stuart, can you check whether this fixes the issue for you? Also, do you plan to ship off of 1.9.0 or 1.9.1?
Assignee: nobody → bzbarsky
Attachment #360310 -
Flags: superreview?(jonas)
Attachment #360310 -
Flags: review?(jonas)
Comment 22•15 years ago
|
||
I'll have to answer those questions in reverse order: > Also, do you plan to ship off of 1.9.0 or 1.9.1? We have to ship from 1.9.0, unfortunately. After the move to Hg some people decided that because Camino was no longer in the same repository, we no longer mattered, and completely removed several legacy components that we still rely on and had been led to believe for some time would continue to be available through all of 1.9. We don't have the manpower to rewrite several sections of Camino a year or two ahead of schedule, so we can't use 1.9.1. > Stuart, can you check whether this fixes the issue for you? It looks like 1.9.0 will need a different patch; it applies, but the build fails: error: ‘class nsDerivedSafe<nsRunnableMethod<nsBindingManager> >’ has no member named ‘Revoke’ (Sorry if it's just a simple function substitution; I'm out of time for the morning so I can't dig beyond that right now.)
Assignee | ||
Comment 23•15 years ago
|
||
> and completely removed several legacy components that we still rely
> on and had been led to believe for some time would continue to be available
Removed from hg (as in not imported into mozilla-central), or removed altogether? Please feel free to mail me with details, ok?
I'll post a 1.9.0 patch.
Assignee | ||
Comment 24•15 years ago
|
||
Attachment #360310 -
Flags: superreview?(jonas)
Attachment #360310 -
Flags: superreview+
Attachment #360310 -
Flags: review?(jonas)
Attachment #360310 -
Flags: review+
Comment 25•15 years ago
|
||
Comment on attachment 360324 [details] [diff] [review] 1.9.0 fix Works like a charm :)
Comment 26•15 years ago
|
||
(In reply to comment #24) > Created an attachment (id=360324) [details] > 1.9.0 fix Works perfectly. :-)
Assignee | ||
Updated•15 years ago
|
Attachment #360310 -
Flags: approval1.9.1?
Assignee | ||
Comment 27•15 years ago
|
||
Pushed http://hg.mozilla.org/mozilla-central/rev/ed041ee82ec6
Status: ASSIGNED → RESOLVED
Closed: 15 years ago
Resolution: --- → FIXED
Assignee | ||
Updated•15 years ago
|
Attachment #360324 -
Flags: approval1.9.0.8?
Attachment #360324 -
Flags: approval1.9.0.7?
Comment 28•15 years ago
|
||
Comment on attachment 360324 [details] [diff] [review] 1.9.0 fix last-minute approcal for 1.9.0.7, a=dveditz for release-drivers -- if you're around still to land it. Otherwise it'll be 1.9.0.8
Attachment #360324 -
Flags: approval1.9.0.8?
Attachment #360324 -
Flags: approval1.9.0.7?
Attachment #360324 -
Flags: approval1.9.0.7+
Assignee | ||
Comment 30•15 years ago
|
||
I figure we should nominate this for blocking 1.9.1, since it's fixed everywhere else...
Flags: blocking1.9.1?
Verified FIXED in Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en; rv:1.9.0.7pre) Gecko/2009020500 Camino/2.0b2pre (like Firefox/3.0.7pre) Thanks, Boris, for the amazing turn-around on this!
Keywords: fixed1.9.0.7 → verified1.9.0.7
Updated•15 years ago
|
Flags: blocking1.9.1? → blocking1.9.1+
Assignee | ||
Comment 32•15 years ago
|
||
Pushed http://hg.mozilla.org/releases/mozilla-1.9.1/rev/b6f9b48314fc
Flags: wanted1.9.1?
Keywords: fixed1.9.1
Assignee | ||
Updated•15 years ago
|
Attachment #360310 -
Flags: approval1.9.1?
Comment 33•15 years ago
|
||
verified FIXED on Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.1b4pre) Gecko/20090403 Shiretoko/3.5b4pre ID:20090403030624 and Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.2a1pre) Gecko/20090331 Minefield/3.6a1pre ID:20090331030637
Status: RESOLVED → VERIFIED
Keywords: fixed1.9.1 → verified1.9.1
Comment 34•15 years ago
|
||
Removing verification markers for everything except 1.9.0. Aakash: This issue was only visible in Camino (though bz isn't sure why, see comment 20) and can only be verified with Camino, which doesn't have builds using either 1.9.1 or trunk, only 1.8.1 and 1.9.0.
You need to log in
before you can comment on or make changes to this bug.
Description
•