100% CPU with javascript

[ydario]

On my dual core laptop some sites are raising one core to 100% cpu usage; it happens on sites using heavy scripting (facebook) or using extensions. E.g. passwordbox.com extension is getting a long delay on login due to this issue, while login is almost instant using windows or linux builds. FF17 is not showing this issue. But in the recent 17.0.11 it appears again, I don't know if due to backported code or what: the delay is not as long as in ff24.

Even the free passwordbox shows the login delay, but smaller due to the limit of 25 passwords.

[StevenLevine]

A simple site for testing this is

http://coupons.staterbros.com/

Click on the Coupon link.

Offhand it looks like it might be an Ajax timing issue.

Steven

---

"Steven Levine" steve53@earthlink.net Warp/DIY/eComStation etc.

www.scoug.com

[dryeo]

On 06/21/14 04:56 PM, StevenLevine wrote:

A simple site for testing this is

http://coupons.staterbros.com/

Click on the Coupon link.

Offhand it looks like it might be an Ajax timing issue.

This seems to be a different issue then ydario brought up, I tested on FF10.12, FF17.0.5, FF17.0.11, FF24.3.0, TB17.11, SM17 and Qupzilla. All the 17 and 24 based browsers peaked the CPU roughly the same with only TB offering to cancel the script and as usual all the Firefox's downloading way longer then SM but that's probably just crappy Firefox cache code. Qupzilla also peaked the CPU meter and immediately offered to cancel the script and Firefox 10.0.12 didn't quite peak the CPU meter. I think there is something wrong with the JavaScript JIT in general, especially in the 17 builds which seem as slow as pre-JIT (FF3.5 IIRC). I haven't noticed ydario's problem but I should note that FF17.0.11 has the disable oop preference wrong due to a brainfart on my part and almost sounds like Flash problem, he needs to check if plugin-container.exe is running when logging into Facebook. Amazing where Flash is used, 10's of instances at Github for example.

[dmik]

Tested it with 24.8.0. Facebook works for me w/o any significant delay. http://coupons.staterbros.com/ looks pretty ok too, however I don't have a login there so I can't fully test it. Could you guys take this and report back?

http://rpm.netlabs.org/test/248sldy.rar

The login delays you saw could actually be related to mtudiscover (see #53). I remember I also saw them with Facebook. But not now.

[guzzi-g5]

I see those script errors too on Facebook. Tested with 24.8 and it is much better but I still see script errors and cpu spiking if I leave facebook open for more than about 24 hours.

[dmik]

"More than 24 hours" — that sounds tough. Perhaps, you experience the out of memory situation here. It is known that FF leaks memory on OS/2 and this is about to be investigated yet (#55). In other words, this doesn't seem to be related to the original JS problem this issue is about.

[guzzi-g5]

That could be. The symptoms are: cpu peaks, firefox becomes unresponsive, after a while pops up a screen about an unresponsive script. This may repeat several times, with the os/2 window list popping up too because of clicking somewhere in an unresposive firefox. Closing the tab or tabs with heavily scripted pages will restore normal functionality. I can normally start soffice or other programs as soon as the cpu peak is gone, so it doesn't look like lack of memory to me.

[dmik]

@guzzi-g5 and what is your mtodiscover setting? Paste the inetcfg -g mtudiscover output here please.

[guzzi-g5]

Inetcfg: CURRENT DEFAULT MINIMUM MAXIMUM

mtudiscover 1 1 0 1 TCP Path MTU Discovery ON/OFF

[SilvanScherrer]

I just tried this coupon link, but I saw no cpu pike at all.

[ydario]

Update (from #83): I'm using passwordbox to handle my passwords. While with ffox 17.0.5 it was working well, with 24.x releases the startup is getting very slow. It seems the extension is doing some background work (probably syncing data) and it requires at least a couple of minutes to complete. The system is not usable until work ends. With 24.8.1 beta2 things are slightly better, still high load but the PC is able to do other tasks (but very slowly). I noticed a similar performance loss with ffox 17.0.11.

Things are even worse if you install Lastpass extension at the same time: the 2 extensions are probably accessing the same resource and startup requires a lot of time. Lastpass alone does not cause high cpu load. Startup time on windows is measurable in seconds.

[StevenLevine]

The staterbros site changed significantly about two weeks after I posted my comment and no longer exhibits any delays.

[ydario]

I discovered that this issue goes away if I disable my lastpass extension (last one working on os2 is 3.0.1, https://lastpass.com/releases/lp3.0.1.xpi). I have a few hundreds password saved, I don't know if this makes a difference, I will try again later with an empty account.

[ydario]

I created an empty account, the issue is still here :-)

and one more thing: when ffox is busy, if I type 'ctrl-esc' and wait for OS/2 termination program dialog, it says

'program: LastPass Master login'

is the guilty program. is it possible we have hidden PM windows around?

[aschnellb]

is it possible we have hidden PM windows around?

Your question rings a bell for me. In most cases when SeaMonkey or Firefox crash, I see hidden Mozilla windows in the process list. Most of them are cookies confirmation windows. (I have cookies configured to ask me everytime.) That happens here with all Mozilla versions since about 4 years.

[dmik]

It seems that ESR31 improves JS performance a lot here. I could successfully use Lastpass 3.1.95 here and also I don't experience any problems with staying on facebook.com for quite a while and even chatting from there. Tried it on ESR24 again and there web content becomes unresponsive quite soon after going to facebook.com but the main window's menu works and I could terminate Firefox it quickly.

I did get a system freeze on facebook with ESR31 after some time but this seems to be unrelated to the original problem Yuri reported — see #105 (and #106) for details.

I will leave it open until I give Yuri a test build of ESR31 to try.

[dmik]

@ydario so can we close it with your ESR31 experience?

[dbanet]

I think ESR31 doesn't solve this. It's usually quite performing, but after some time of active usage, and after ~1 GiB of RAM gets allocated (closing even all but one tab doesn't return the memory or original performance back, see #55), I get CPU peaks with FF going unresponsive quite often, especially when I type text (huge sentences/paragraphs on one line) in whatever input field on a web page. I'm suffering from this right now.

[dmik]

Are you sure it is not related to #105 and #106? And also I'm not sure your problems and Yuri's are the same. Perhaps, yours deserve a separate ticket (if they are not #105/#106).

[dbanet]

Well, does it quit after some time? I can't imagine plugin-container.exe starting up for several seconds, giving 100% CPU, then quitting, returning responsiveness to Firefox.

Anyway #105 and #106 appear to be 31ESR-only related (are they?), but I have had this issue with 24ESR and probably 17ESR.

[dmik]

Yes, that's what plugin-container.exe occasionally does now: starts up, gives 100% CPU load, then exits and all works well afterwards.

No, #106 has been always there. Only #105 is new. This means that if you see plugin-container.exe among the running processes when you get 100% CPU pikes (provided that you have dom.ipc.plugins.enabled set to false), then it's a new issue and most likely unrelated to this one.

[dbanet]

Well, I actually cannot see it running at all neither during those peaks, nor while operating normally.

[dbanet]

I don't have any native plugins currently installed.

[dbanet]

Eh, how the fuck did I read your last message.

I indeed do have dom.ipc.plugins.enabled set to false, so it's unrelated to #105 and #106.

[dmik]

I think that you still read it wrong :) If you have IPC plugins disabled and still have CPU spikes, then, if you notice plugin-contanier is running during these spikes, then it's a subject of #105. Otherwise, this must be something else but it's not necessarily related to this defect, #73.

[dbanet]

Well yea :), but at least my conclusion is still justified, as I really don't see plugin-container.exe running during the spikes.

[dmik]

How do you check that? It can really start very quickly and then go away.

[dbanet]

I have left WatchCat running along with Firefox on the screen with processes sorted alphabetically and the process list scrolled down to the processes with module name starting with P. Then I began typing into the Github issue comment field making Firefox unresponsive for ~10 seconds. plugin-container.exe did not appear.

To be sure that the process list is actually updating while everything is unresponsive, I've compiled a small program which calls DosSleep(1000), then quits, named it p.exe and made Bourne shell to run it in a loop. So during the CPU peak, when PM user input is blocked, I was able to see p.exe constantly reappearing in the process list, while plugin-container.exe never appeared.

[dbanet]

I have to remark that if I restart Firefox, it will handle text input correctly without going unresponsive so frequently and so easily, until it allocates almost all of my RAM again.

[dmik]

Okay, then your issue is completely different indeed from both #105 and this one and sounds to me more related to #55.

[ydario]

The ffox31 test build does no longer show the 100% CPU usage related to lastpass and passwordbox extensions. No issues even with facebook browsing. CPU usage is now comparable to what I can see in windows build, so I'm closing this ticket.

[dmik]

Good, thanks.