Excessive CPU and the Firefox crashes at close

[gbcox]

I'm running version 1.1.1

When I download files, I notice that with the extension installed Firefox CPU goes up to 300% or more... then when download is finished Firefox CPU stays between 150 - 200%. Without the addon, Firefox CPU is about 15% when downloading a file.

When I close Firefox, it crashes (when CPU is looping).

[kotelnik]

Hí! Thanks for report. I cannot replicate this behaviour... I didn't notice any CPU increases while downloading one or multiple files when using this widget. Does it even work or it just eats CPU?

I've only saw these kinds of CPU increases when enabling debugging of addons but I believe it is not related to this particular addon.

Could you please try this addon with a clean firefox profile to narrow the issue?

[gbcox]

Yes, while I was trying to figure out what was causing it, I already had done a refresh. If I install the extension (and associated files in the .mozilla directory) then try to download a file, the cpu appears to start to loop on something. If I delete the extension, restart and do a download it works fine. What happens is the CPU goes up during the download and just stays at that higher level (which as I mentioned is higher than doing it without the extension). If you can think of anything else I can do to help troubleshoot, let me know. Of course, if I don't try to download anything, everything also works fine. Whatever is causing it is triggered by the download.

Sorry, didn't answer your other question. Yes, it appears to work fine. The file is downloaded properly and I see the animation on the panel showing the download status. I just noticed by chance on day that Firefox was using 150% cpu and it took me a while to figure out it was being caused by downloading a file. Then when I try to close Firefox after a download with the extension it crashes. I always close Firefox after the download completed - but it appears that something was triggered by that process which isn't stopped. It just keeps chugging along. Here is some information from one of the crashes:

ID: f586c0a5-cf18-4828-b87a-6e4042170310 Signature: AsyncShutdownTimeout | profile-before-change | Native Messaging: Wait for application launcher_api_firefox_stdin.py to exit,Native Messaging: Wait for application launcher_api_firefox_stdin.py to exit,Native Messaging: Wait for application launcher_api...

Fedora release 25 (Twenty Five)FP(D00-L1000-W00000000-T0000) OpenGL: X.Org -- Gallium 0.4 on AMD PITCAIRN (DRM 2.48.0 / 4.9.13-200.fc25.x86_64, LLVM 3.9.1) -- 3.0 Mesa 13.0.4 -- texture_from_pixmap xpcom_runtime_abort(###!!! ABORT: file resource://gre/modules/NativeMessaging.jsm, line 386)

[kotelnik]

Thanks for extensive info about the issue. Please try calling these commands directly on the python script:

echo -n -e '\x09\x00\x00\x00"count=3"' | ./launcher_api_firefox_stdin.py
echo -n -e '\x0e\x00\x00\x00"progress=0.4"' | ./launcher_api_firefox_stdin.py

Does it work? Does the command correctly end and what about CPU? The script calls should return no errors or log messages.

I'd also like to know your Firefox version and edition. And I'm assuming you are using Fedora 25 KDE spin, is that right?

[kotelnik]

Oh and also try this new version 1.1.2: https://dl.dropboxusercontent.com/u/15557617/unity_launcher_api_addon_e10s-1.1.2.xpi

It's not signed from mozilla, so you will have to add it on about:debugging page...

[gbcox]

Yes, I'm using Fedora 25 with KDE. Firefox is 52. Problem also occurred with FF 51.
Wasn't sure how you wanted me to execute those commands. I did it first without the extension installed. Didn't really notice anything... the commands exited without any output. Then I did it with the extension installed. Same thing. Then I did it after downloading a file with the extension installed. The CPU was at 100-125% after the download. I ran the commands and didn't notice any effect.

Just saw your new message. Will give it a try and let you know.

[gbcox]

I just tried 1.1.2 and same result. I also noticed that there is a lag on the download indicator on the panel, and also it never really shows complete on the panel. Sometimes it's about 50% other times maybe 75% - but in the tests never goes up to 100 - and as I mentioned a few comments back when using the extension the CPU is at least 2 times what it would be without the extension so possibly whatever is going on is in addition to the download - and whatever that thing is, it never stops.

[kotelnik]

Thanks for making all the tests for me! The python script is there to call dbus which in turn tells plasmashell to show progress and count. So the the command calls should have shown the progress and count of firefox (regardless of running firefox) in panel just as if it was used by the firefox extension. I suppose this worked as well.

The lag is caused by "optimizations" I originally made - browser sends the progress and count update to python script once in 3 seconds. This is also why you don't really see 100% progress in case of small downloads. That is also why I don't understand the CPU usage.

It is good that calling python script directly isn't causing any CPU increase. So there have to be a problem with communication between firefox and the script.

I'll install Fedora and see if I manage to replicate the issue. If I understand it right, the issue is "firefox" process start eating at least one whole CPU core.

[gbcox]

Yes, when I manually run the commands it shows up in the panel: CPU only goes out of control when I actually download a file - and yes, it uses at least one whole CPU core... usually on average 150%. Strange you don't see it on your distro. I'm plasma 5.8.6 and I would expect to roll to 5.9.3 in the next month or so.

[kotelnik]

I've finally freed up some space to install Fedora KDE 25 (to VirtualBox). Sorry it took me so long. I've got Firefox 52, Plasma 5.8.6, KF 5.32, Qt 5.7.1 in there. And I was testing with addon version 1.1.1 because I couldn't download 1.1.2 version for some reason (I have to ask Mozilla why it doesn't work).

Anyway I couldn't replicate the issue. There was no CPU raise while downloading, no residual CPU activity and I managed to close Firefox without a crash. I'm currently clueless what could go wrong in your Firefox...

[gbcox]

Hummmmm... are you using Fx from the Fedora repository? That is the version I'm using.

[kotelnik]

Yes, I have vanilla 64-bit Fedora KDE 25 (with latest updates, Firefox 52 was there preinstalled) with literally no additionally installed packages / repositories / alien files - except the ~/.mozilla/native-messaging-hosts/ folder with 2 files needed for the addon + installed this addon to Firefox from AMO. That's it. Although I believe You are having the problems, I currently cannot think of any explanation.

Just to blindly brainstorm: Firefox is using "stdio" type of communication with the application side of addon. So maybe some kind of kernel config / security restrictions are in effect? Application side of addon (python script) is probably started as separate process by Firefox, can this kind of stuff be regulated by some security software?

I know it's a pain but can you please also try to test on vanilla Fedora e.g. in VirtualBox to narrow down the issue?

[gbcox]

Sorry, the first thing I should have checked was extensions. I found the issue. Your extension and flashgot don't play well together. If flashgot is enabled and I tell it to use the Fx downloader (which is what would show with your extension) - Fx then starts the CPU loop. If flashgot is disabled, no issue.

[kotelnik]

I'm glad you've figured this out. I'm not sure if I should tweak the code somehow so it can work with other extensions. But I suppose this will be resolved when flashgot is ported to WebExtensions. I'd at least wait for that. What do you think?

[gbcox]

I think it would be good if it worked with other extensions, especially flashgot... it is a very popular extension. That said, I agree you should wait to see what happens. Fx has too many moving parts right now.