Thunderbird using 100% CPU on newly installed ArcaOS 5.0.6

[Eugene Tucker]

I do not see this 100% CPU utilization on any of my Thunderbird installs.

[Bennie Nelson]

Yes, those are the instructions I used. It appears that something significant has changed since ArcaOS 5.0.4, resulting in both Thunderbird and Firefox becoming CPU hogs. At least the SMP VM is responsive, so I'll stick with that for now.

Thanks for the help,
Bennie

[Dave Yeo]

Well, the Mozilla apps themselves were updated from 38ESR to 45ESR code. You seem to be the only one though with this issue.
You should test Firefox with a new profile and see if it helps. I take it that you moved your Firefox profile along with the Thunderbird profile.
You could try the latest builds, currently at Hobbes in incoming. They're built with a much newer GCC, and seem more stable to me. You could even downgrade to the 38ESR versions, of course that'll make Firefox fail to load even more sites.

[Bennie Nelson]

I did not migrate a Firefox profile and I have tried TB with a new profile, as well, and the CPU usage is high. I did deviate from the installation instructions a bit: I did not install DOS/Windows,  USB, and Audio support.

Since I have an extra ArcaOS VM, I can test different versions of TB and FireFox, as was suggested.

Thanks,
Bennie

[Dave Yeo]

Could you try a setup with audio support?

[roberto]

Could you run this program and send the file that is generated to this forum? It would help to know the hardware you have.

 c:\sys\install\detect\pci.exe >mifile-mipc.txt

Saludos

[Bennie Nelson]

> Could you run this program and send the file that is generated to this forum? It would help to know the hardware you have.
>
> c:\sys\install\detect\pci.exe >mifile-mipc.txt

The output is attached.

Bennie

[Bennie Nelson]

Could you try a setup with audio support?

I reran the install and included the audio support, but it made no difference. Firefox still runs at 100% CPU.

Bennie

[Dave Yeo]

Shame, as that is one thing that isn't very well tested.
Lets find out which thread is causing the high CPU load. Please download http://www.warpcave.com/betas/monitorthreads-0.4-shl-2020-10-13.zip and run at a cmd prompt and then run Thunderbird or Firefox for a bit and report which thread is using all the CPU.
Also, could you generate a trp report? Probably won't say much but one never knows. At a cmd prompt, do "set exceptq=Z" without the quotes then from the same prompt, fire up Thunderbird or Firefox after CDing to their program directory. Let the program run a bit and then close it. There should be a trp report in the program directory, please post it.

[Ian B Manners]

Hi,

With Dave's mozilla 45.x builds, I discovered quite quickly late last year that if you have i686 DLL libraries installed, use Daves 686 builds, not the Pentium builds.
Otherwise strange things happen every now and then, including regular CPU usage being at 100%. Keeping build types together keeps the programs happy
I can not comment on the recent builds on hobbes as I haven't got that far to install them yet.

[Doug Bissett]

I don't know about Thunderbird, I don't use it, but in Firefox there are some settings for "telemetry" (go to about:config, and type in telemetry). This is basically spyware. After I turned off a lot of that (use your best judgment), Firefox has been working better. An added advantage is that my backups don't need to back that stuff up. There are probably more of those things, if you can find them.

I am pretty sure that nobody looks at that information, for our ancient version of Firefox anyway.

[Rich Walsh]

strange things happen every now and then, including regular CPU usage being at 100%.

Thanks for that tip - it gets me closer to maybe explaining this:

On an idle system, open a Pentium-M version of FF to a blank page. Wait precisely 8 minutes from the time FF's window first appears. Nonstop bursts of activity will begin and never stop. Do the exact same with a 686 build (same profile) and there's no such activity.

I tested this with Dave's FF builds that are currently in 'incoming/' at hobbes. Months ago I discovered the same unexplained activity in SM, but there it takes 15 minutes. I looked at every possible entry in about:config for something that might control the timing but never found anything. I don't think it's associated with the FF "Health Report" (which I always turn off) or any other network activity.

Any ideas?

[Dave Yeo]

I get the high CPU now and again, never noticed any timing to it and have found that minimizing the window and then unminimizing often clears it up. The odd time I've only got away from it by reverting to an older backup of the profile. This is with SM.
Guess could try building without various external libraries to see if that changes the behaviour.
There's also the mystery of using the NSPR/NSS in netlabs-exp causing the browser to simple vanish now and again, should make sure the architecture is the same between the libraries and browser.

[Dariusz Piatkowski]

...I am pretty sure that nobody looks at that information, for our ancient version of Firefox anyway.

Even when you're not collecting the FULL bucket of data, the 'about:telemetry' page does have some interesting information, worth a look.

[Doug Bissett]

Even when you're not collecting the FULL bucket of data, the 'about:telemetry' page does have some interesting information, worth a look.

Interesting, indeed. Things like pictures of my bank login page (and other login pages). I turned off all telemetry, and deleted all of that stuff. Now, FF is working better, it isn't wasting bandwidth sending things to somebody, somewhere, and my backups are a little smaller.

I am pretty sure there are more things like that in FF, and they all contribute to instability, not to mention that it could easily be hijacked by somebody who wants information. Mozilla claims that isn't possible, but we all know better, and it probably can be done, if somebody tries. Firefox (et al.) on all platforms, would probably work a lot better, if those parts were totally removed from the program.