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).

Are you able to isolate this down to a specific script with NoScript or similar?

Yes, if I adblock http://promodity.appspot.com/pmy.js:1, the page loads normally.

Ads suck.

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).

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.

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.

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.

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

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.

Did you shift-reload just in case it was stuck in the cache?

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.

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=, stackLimit=, 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=, 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=, 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=, 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=, argv=, rval=) 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=, 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=, aPusher=0xef4e72d4) at /Volumes/Mac_OS_9/mozilla-beta/js/src/xpconnect/src/xpcwrappednative.cpp:2334

688 0x071b7f38 in nsEventDispatcher::Dispatch (aTarget=, 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=, 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=) 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=) at /Volumes/Mac_OS_9/mozilla-beta/js/src/xpconnect/src/xpcwrappednative.cpp:2334

698 0x0785c8a4 in nsIDOMNSHTMLElement_SetInnerHTML (cx=0x11e9e340, obj=, id=425412768, strict=, 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

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.

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.

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.

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...

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.

I could check this if you posted a patchset.

Almost done :)

Okay, up. See if it still happens. I still can't trigger it.

It's still an issue for me. I had to force quit.

Somebody who can trigger the bug, we need a test case.

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.

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

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.

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.

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).

Chemspill on 10 is possible, btw (see issue 118).

Still can't confirm on 10.0.2pre. Did this change it for anyone?

Fixed for me.

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.

Hmm. Well, let's just mark this WorksForMe and move on, and reopen if needed then.