search

keeleysam / tenfourfox

Automatically exported from code.google.com/p/tenfourfox
0 stars 0 forks source link

Methodjit slows down sendspace.com #119

Closed GoogleCodeExporter closed 9 years ago

GoogleCodeExporter commented 9 years ago 
1) Enable Methodjit in about:config
2) Clear cache (if the page is already cached, the bug does not occur).
3) visit http://www.sendspace.com

With Methodjit and Tracejit enabled together (or only Methodjit enabled) the 
page takes about 4-6 minutes to load on my 1.33 GHz G4 (varies). The browser 
stalls and shows the blue progress radar (tab) and the spinning beachball (OS 
X), while memory usage slowly increases in Activity Monitor. Eventually the 
browser recovers and the page is displayed. No crash. But I doubt anyone will 
wait that long before force-quitting.

With only Tracejit (or no jit) enabled, it takes about 10-20 seconds until 
whatever script they're using has finished and the page has loaded completely. 

Tested on PowerBook G4 1.33 GHz, 2GB RAM, 10.5.8 with G4 7450 TFF 9.0 RC.
Also happens on G3 with 10.4.11 (time to load: ~12 minutes).

Original issue reported on code.google.com by chtru...@web.de on 19 Dec 2011 at 9:32

GoogleCodeExporter commented 9 years ago 
Are you able to isolate this down to a specific script with NoScript or similar?

Original comment by classi...@floodgap.com on 19 Dec 2011 at 9:34

GoogleCodeExporter commented 9 years ago 
Yes, if I adblock http://promodity.appspot.com/pmy.js:1, the page loads 
normally.

Original comment by chtru...@web.de on 19 Dec 2011 at 9:53

GoogleCodeExporter commented 9 years ago 
Ads suck.

Original comment by classi...@floodgap.com on 19 Dec 2011 at 11:58

GoogleCodeExporter commented 9 years ago 
Just to make sure (in this case probably useless information): sendspace.com 
loads within 20 seconds in FF 9.0b6 Win XP SP3 in VirtualPC (emulated 300 MHz 
Pentium 2).

Original comment by chtru...@web.de on 20 Dec 2011 at 9:16

GoogleCodeExporter commented 9 years ago 
It gets stuck in an infinite loop (in the debugging browser, it actually pops 
up the "stop script" dialogue). However, it's not a code generation problem 
because the script does finish execution; it just immediately reruns. So some 
sort of state is not being saved.

Original comment by classi...@floodgap.com on 20 Dec 2011 at 1:51

GoogleCodeExporter commented 9 years ago 
If you can minimize this down to a simple page with just the offending script 
and whatever page elements are required to allow it to run, it would be very 
helpful. I can try to deobfuscate the script itself from there. Throwing the 
script onto a blank page for debugging doesn't cause the problem; the script 
just doesn't run.

Original comment by classi...@floodgap.com on 20 Dec 2011 at 1:52

GoogleCodeExporter commented 9 years ago 
Locally, the website just loads without a problem. I have no idea how to make a 
local testcase from that. I think the offending script tries to load something 
from server.promodity.com, which doesn't exist locally, of course.

Original comment by chtru...@web.de on 20 Dec 2011 at 7:01

GoogleCodeExporter commented 9 years ago 
This appears to be fixed by the TI-capable methodjit -- leaving open so you can 
verify with 9.0.1pre when it becomes available.

Original comment by classi...@floodgap.com on 26 Dec 2011 at 10:53

GoogleCodeExporter commented 9 years ago 
Sorry to report that I can't verify the fix in 9.0.1pre. With MJ+type inference 
the offending script still stalls the browser for several minutes (I force quit 
after four minutes). There must be another reason for this bug.

Original comment by chtru...@web.de on 28 Dec 2011 at 1:52

GoogleCodeExporter commented 9 years ago 
Did you shift-reload just in case it was stuck in the cache?

Original comment by classi...@floodgap.com on 28 Dec 2011 at 2:15

GoogleCodeExporter commented 9 years ago 
On my G4 1GHz, I get an unresponsive script dialogue, but just once. If I close 
the script, the page will load (JM+TI, no TM). The G5 seems to run it normally. 
I do have Adblock, but it's turned off for this, so we're loading everything.

Original comment by classi...@floodgap.com on 28 Dec 2011 at 2:18

GoogleCodeExporter commented 9 years ago 
I can confirm that it does get stuck (G4-7450 1.5GHz) in an infinite loop. At 
least it didn't terminate within some minutes. I get the unresponsive script 
dialog but stopping the script doesn't help to get out of the loop
A stack backtrace (done with a custom optimized build with debug symbols 
enabled) representing one loop iteration is attached below.

#675 js::mjit::EnterMethodJIT (cx=0x11e9e340, fp=0xf6fd900, code=<value 
temporarily unavailable, due to optimizations>, stackLimit=<value temporarily 
unavailable, due to optimizations>, partial=false) at 
/Volumes/Mac_OS_9/mozilla-beta/js/src/xpconnect/src/xpcwrappednative.cpp:2334
#676 0x0829571c in js::mjit::JaegerShot (cx=0x11e9e340, partial=false) at 
/Volumes/Mac_OS_9/mozilla-beta/js/src/xpconnect/src/xpcwrappednative.cpp:2334
#677 0x080b8bec in js::RunScript (cx=0x11e9e340, script=0x1fbc2600, 
fp=0xf6fd900) at 
/Volumes/Mac_OS_9/mozilla-beta/js/src/xpconnect/src/xpcwrappednative.cpp:2334
#678 0x080ba3f4 in js::InvokeKernel (cx=0x11e9e340, argsRef=<value temporarily 
unavailable, due to optimizations>, construct=js::NO_CONSTRUCT) at 
/Volumes/Mac_OS_9/mozilla-beta/js/src/xpconnect/src/xpcwrappednative.cpp:2334
#679 0x080baa98 in js::Invoke (cx=0x11e9e340, thisv=@0xef4e69f8, fval=<value 
temporarily unavailable, due to optimizations>, argc=1, argv=0xef4e6c4c, 
rval=0xef4e6ac0) at 
/Volumes/Mac_OS_9/mozilla-beta/js/src/xpconnect/src/xpcwrappednative.cpp:2334
#680 0x07fe8870 in CallMethodHelper::Call () at xpcinlines.h:2385
#681 JS_CallFunctionValue (cx=0x11e9e340, obj=<value temporarily unavailable, 
due to optimizations>, fval={data = {asBits = 18446743554550898408, s = {tag = 
JSVAL_TAG_OBJECT, payload = {i32 = 532389608, u32 = 532389608, boo = 532389608, 
str = 0x1fbb9ee8, obj = 0x1fbb9ee8, ptr = 0x1fbb9ee8, why = 532389608, word = 
532389608}}, asDouble = -nan(0xfff871fbb9ee8), asPtr = 0xffffff87}}, 
argc=<value temporarily unavailable, due to optimizations>, argv=<value 
temporarily unavailable, due to optimizations>, rval=<value temporarily 
unavailable, due to optimizations>) at 
/Volumes/Mac_OS_9/mozilla-beta/js/src/xpconnect/src/xpcwrappednative.cpp:2334
#682 0x077dc94c in nsXPCWrappedJSClass::CallMethod (this=0x203386d0, 
wrapper=0xef4e6c08, methodIndex=34120, info=0x203386d0, 
nativeParams=0x2134bec8) at 
/Volumes/Mac_OS_9/mozilla-beta/js/src/xpconnect/src/xpcwrappednative.cpp:2334
#683 0x077d4598 in nsXPCWrappedJS::CallMethod (this=0x20165700, methodIndex=3, 
info=0x608e758, params=0xef4e6ff8) at 
/Volumes/Mac_OS_9/mozilla-beta/js/src/xpconnect/src/xpcwrappednative.cpp:2334
#684 0x07da2424 in PrepareAndDispatch (self=0x20164430, methodIndex=<value 
temporarily unavailable, due to optimizations>, argsStack=0xef4e717c, 
argsGPR=0xef4e70dc, argsFPR=0xef4e70f8) at 
/Volumes/Mac_OS_9/mozilla-beta/js/src/xpconnect/src/xpcwrappednative.cpp:2334
#685 0x07da2e30 in SharedStub () at 
/Volumes/Mac_OS_9/mozilla-beta/js/src/xpconnect/src/xpcwrappednative.cpp:2334
#686 0x0719080c in nsEventListenerManager::HandleEventInternal 
(this=0x1fced2c0, aPresContext=0x2084ea00, aEvent=0x212b0a50, 
aDOMEvent=0xef4e72e8, aCurrentTarget=0x2084f200, aFlags=2, 
aEventStatus=0xef4e72ec, aPusher=0xef4e72d4) at 
/Volumes/Mac_OS_9/mozilla-beta/js/src/xpconnect/src/xpcwrappednative.cpp:2334
#687 0x071b7218 in nsEventTargetChainItem::HandleEventTargetChain 
(this=0x20d2ea50, aVisitor=@0x212b0a50, aFlags=6, aCallback=0x2, 
aMayHaveNewListenerManagers=<value temporarily unavailable, due to 
optimizations>, aPusher=0xef4e72d4) at 
/Volumes/Mac_OS_9/mozilla-beta/js/src/xpconnect/src/xpcwrappednative.cpp:2334
#688 0x071b7f38 in nsEventDispatcher::Dispatch (aTarget=<value temporarily 
unavailable, due to optimizations>, aPresContext=0x2084ea00, aEvent=0x212b0a50, 
aDOMEvent=0x212b2df0, aEventStatus=0xef4e744c, aCallback=0x0, aTargets=0x0) at 
/Volumes/Mac_OS_9/mozilla-beta/js/src/xpconnect/src/xpcwrappednative.cpp:2334
#689 0x071b83e0 in nsEventDispatcher::DispatchDOMEvent (aTarget=0x212b2e30, 
aEvent=<value temporarily unavailable, due to optimizations>, 
aDOMEvent=0x212b2df0, aPresContext=0x2084ea00, aEventStatus=0xef4e744c) at 
/Volumes/Mac_OS_9/mozilla-beta/js/src/xpconnect/src/xpcwrappednative.cpp:2334
#690 0x070caf18 in nsINode::DispatchEvent (this=0x212b2e30, aEvent=0x212b2df0, 
aRetVal=0xef4e74bc) at 
/Volumes/Mac_OS_9/mozilla-beta/js/src/xpconnect/src/xpcwrappednative.cpp:2334
#691 0x071b5578 in CallMethodHelper::Call () at xpcinlines.h:2385
#692 nsPLDOMEvent::Run (this=0x212b1a30) at 
/Volumes/Mac_OS_9/mozilla-beta/js/src/xpconnect/src/xpcwrappednative.cpp:2334
#693 0x0706c08c in nsContentUtils::RemoveScriptBlocker () at 
/Volumes/Mac_OS_9/mozilla-beta/js/src/xpconnect/src/xpcwrappednative.cpp:2334
#694 0x070aa8f8 in nsDocument::EndUpdate (this=0x11f3, aUpdateType=4595) at 
/Volumes/Mac_OS_9/mozilla-beta/js/src/xpconnect/src/xpcwrappednative.cpp:2334
#695 0x0728fae8 in nsHTMLDocument::EndUpdate (this=0x2084f200, 
aUpdateType=<value temporarily unavailable, due to optimizations>) at 
/Volumes/Mac_OS_9/mozilla-beta/js/src/xpconnect/src/xpcwrappednative.cpp:2334
#696 0x071dccbc in CallMethodHelper::Call () at xpcinlines.h:2385
#697 0x071dccbc in nsGenericHTMLElement::SetInnerHTML (this=0x5ed5cd0, 
aInnerHTML=<value temporarily unavailable, due to optimizations>) at 
/Volumes/Mac_OS_9/mozilla-beta/js/src/xpconnect/src/xpcwrappednative.cpp:2334
#698 0x0785c8a4 in nsIDOMNSHTMLElement_SetInnerHTML (cx=0x11e9e340, obj=<value 
temporarily unavailable, due to optimizations>, id=425412768, strict=<value 
temporarily unavailable, due to optimizations>, vp=0xef4e7888) at 
/Volumes/Mac_OS_9/mozilla-beta/js/src/xpconnect/src/xpcwrappednative.cpp:2334
#699 0x080d3eb8 in js_NativeSet (cx=0x11e9e340, obj=0x203386d0, 
shape=0x1fbcd6a0, added=false, strict=false, vp=0xef4e7888) at 
/Volumes/Mac_OS_9/mozilla-beta/js/src/xpconnect/src/xpcwrappednative.cpp:2334
#700 0x082aa97c in js::mjit::stubs::SetName<0> (f=@0xef4e78e0, 
origAtom=0x195b48a0) at 
/Volumes/Mac_OS_9/mozilla-beta/js/src/xpconnect/src/xpcwrappednative.cpp:2334
#701 0x083aa818 in JaegerStubVeneer () at 
/Volumes/Mac_OS_9/mozilla-beta/js/src/xpconnect/src/xpcwrappednative.cpp:2334
#702 0x08295234 in CallMethodHelper::Call () at xpcinlines.h:2385
#703 CallMethodHelper::Call () at xpcinlines.h:2385

Original comment by Tobias.N...@gmail.com on 28 Dec 2011 at 2:29

GoogleCodeExporter commented 9 years ago 
We're going to need to reduce this to a simple test case. The problem is that I 
can't verify this myself for some reason, so I can't do it.

Original comment by classi...@floodgap.com on 28 Dec 2011 at 2:32

GoogleCodeExporter commented 9 years ago 
>Did you shift-reload just in case it was stuck in the cache?
I tested with a completely new FF profile. I've tried several times since and 
it always stalls, then after about 5-7 minutes the page loads completely. There 
is no difference in behavior at all with or without TI. 

>On my G4 1GHz, I get an unresponsive script dialogue, but just once. If I 
close the script, the page will load.
This is what I get with Tracejit solo. Maybe the ad script tries to load 
different stuff for you because you're in a different country.

>We're going to need to reduce this to a simple test case.
As I said above, I don't know how to make the ad database locally available 
that the script tries to load something from (at least that's Safari's activity 
window says). The script without the remote part runs normally. I tried 
downloading the remote part (it's just one file if I remember correctly), and 
hint the script to load it from the hard drive, but that didn't work.

Original comment by chtru...@web.de on 28 Dec 2011 at 6:18

GoogleCodeExporter commented 9 years ago 
It's entirely possible it's location dependent, yes.

Tobias, when I traced this before (when I could confirm it), it got the browser 
stuck in an infinite loop but not the JS engine (i.e., it would complete the 
script but immediately run it again). Is that what you're seeing? In a debug 
build with JMFLAGS=full you should be able to see if the JS engine is just 
running the script over and over again.

There should be some specific operation that's failing that we can replicate.

Original comment by classi...@floodgap.com on 28 Dec 2011 at 6:28

GoogleCodeExporter commented 9 years ago 
Well, I don't have a debug build ready to this.
But it seems the behaviour is as you describe because I get the unresponsive 
script dialogue and when I choose to stop the script it simply is run again 
until the dialogue appears again...

Original comment by Tobias.N...@gmail.com on 28 Dec 2011 at 6:59

GoogleCodeExporter commented 9 years ago 
I see native CALLs in this. Perhaps the fix I landed in issue 96 will work for 
the situation which fixes the last remaining failures, but since I can't 
reproduce it now I don't know for sure.

Original comment by classi...@floodgap.com on 5 Jan 2012 at 2:26

GoogleCodeExporter commented 9 years ago 
I could check this if you posted a patchset.

Original comment by Tobias.N...@gmail.com on 5 Jan 2012 at 6:53

GoogleCodeExporter commented 9 years ago 
Almost done :)

Original comment by classi...@floodgap.com on 5 Jan 2012 at 6:55

GoogleCodeExporter commented 9 years ago 
Okay, up. See if it still happens. I still can't trigger it.

Original comment by classi...@floodgap.com on 9 Jan 2012 at 12:35

GoogleCodeExporter commented 9 years ago 
It's still an issue for me. I had to force quit.

Original comment by superdre...@gmail.com on 9 Jan 2012 at 4:45

GoogleCodeExporter commented 9 years ago 
Somebody who can trigger the bug, we need a test case.

Original comment by classi...@floodgap.com on 9 Jan 2012 at 4:49

GoogleCodeExporter commented 9 years ago 
In 10.0b1 I can still reproduce with the browser as shipped (TJ off, MJ on, 
type inference on). 

Unfortunately now, when the Unresponsive Scipt dialog occurs (after a few 
seconds on default installations) and I click "stop script", the script 
actually stops and the page loads. This now also happens in TFF 9.0.1pre, 
meaning that the script must have changed slightly. So we may never find the 
cause for the infinite loop.

Original comment by chtru...@web.de on 9 Jan 2012 at 1:18

GoogleCodeExporter commented 9 years ago 
Well, that's an improvement, at least, even if we don't know why. But it looks 
like superdreamkilla is seeing something different. Tobias?

Original comment by classi...@floodgap.com on 9 Jan 2012 at 2:10

GoogleCodeExporter commented 9 years ago 
Behaviour here with AdBlock enabled is:
- times out approx. 8 times if choosing to stop the script (it's in AdBlock 
script code)
- after that the page loads fine

With AdBlock disabled the page loads fine without delay - but disabling AdBlock 
at runtime doesn't seem to work reliably, so one might have to disable the 
whole addon.

I'd call it an AdBlock problem - might even be that ad server is causing this 
on purpose in order to prevent AdBlock users from using that page. I've seen 
something similar for parts of viamichelin before.

Original comment by Tobias.N...@gmail.com on 9 Jan 2012 at 5:51

GoogleCodeExporter commented 9 years ago 
Now we have four testers and four different behaviors. Great. I do my testings 
with new FF profiles (i.e., no Adblock installed), and, as I said, can still 
reproduce the bug in 10.0b1.

Original comment by chtru...@web.de on 9 Jan 2012 at 7:27

GoogleCodeExporter commented 9 years ago 
Still seems to be okay with Ben's new branchwork, so please annotate your 
observations when I get that done by this weekend (trying to find a fix for 
issue 129 at the same time).

Original comment by classi...@floodgap.com on 4 Feb 2012 at 11:22

GoogleCodeExporter commented 9 years ago 
Chemspill on 10 is possible, btw (see issue 118).

Original comment by classi...@floodgap.com on 7 Feb 2012 at 8:43

GoogleCodeExporter commented 9 years ago 
Still can't confirm on 10.0.2pre. Did this change it for anyone?

Original comment by classi...@floodgap.com on 15 Feb 2012 at 1:21

GoogleCodeExporter commented 9 years ago 
Fixed for me.

Original comment by superdre...@gmail.com on 15 Feb 2012 at 4:04

GoogleCodeExporter commented 9 years ago 
Sendspace.com loads without problems in TFF 10.0.2pre. However, it now also 
loads ok in TFF 9 because the website changed. It doesn't use the Promodity 
script (see comment 2) anymore. Since we don't have another test case, I can't 
tell if the bug was fixed by the latest Methodjit modifications, or if it's the 
website, or both.

Original comment by chtru...@web.de on 15 Feb 2012 at 6:51

GoogleCodeExporter commented 9 years ago 
Hmm. Well, let's just mark this WorksForMe and move on, and reopen if needed 
then.

Original comment by classi...@floodgap.com on 15 Feb 2012 at 9:16