Bug 7046 - Mozilla applications use 100% cpu for 2 mins on first run in a session
Summary: Mozilla applications use 100% cpu for 2 mins on first run in a session
Status: RESOLVED INVALID
Alias: None
Product: Mageia
Classification: Unclassified
Component: RPM Packages (show other bugs)
Version: 2
Hardware: x86_64 Linux
Priority: Normal major
Target Milestone: ---
Assignee: Mageia Bug Squad
QA Contact:
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2012-08-13 21:03 CEST by Barry Jackson
Modified: 2013-04-05 19:00 CEST (History)
1 user (show)

See Also:
Source RPM:
CVE:
Status comment:


Attachments
Screenshot showing cpu usage during launch of Firefox. (687.02 KB, image/png)
2012-08-13 21:06 CEST, Barry Jackson
Details
strace output (303.04 KB, application/octet-stream)
2012-12-29 14:02 CET, Barry Jackson
Details

Description Barry Jackson 2012-08-13 21:03:18 CEST
Description of problem:
After a re-boot both Firefox and Thunderbird lock the system for
about 2 minutes when first run. Up to all 4 cores hit 100% during this time after which the application opens correctly. Subsequent runs of either program during that session start instantly.

It's hard to get any feedback from the system as nothing responds except mouse
and I can switch windows - also KDE system monitor plasmoid keeps running, but top freezes. Memory useage during freeze is minimal.

This problem first appeared in Cauldron about a month ago but was not reported, there I switched to the nightly build of Firefox (16a1) and the problem was fixed for FF but it still affected TB. I didn't want to move to the Daily build of TB as it does not support Lightning.

Version-Release number of selected component (if applicable):


How reproducible:
Always after a re-boot.

Steps to Reproduce:
1. Re-boot
2. Launch Firefox or Thunderbird and wait and wait...
3. Monitor cpu load with KDE plasmoid
4. Finally Application starts normally and the system is fully usable.
5. Close Application and re-launch it - opens instantly.
Comment 1 Barry Jackson 2012-08-13 21:06:55 CEST
Created attachment 2641 [details]
Screenshot showing cpu usage during launch of Firefox.

If I can find anything that looks relevant in the logs I will add later.
Comment 2 Manuel Hiebel 2012-08-14 00:02:53 CEST
I don't see what we can do with such bugs... are you sure it's not flash or something like that ?
Comment 3 Barry Jackson 2012-08-14 01:02:17 CEST
(In reply to comment #2)
> I don't see what we can do with such bugs... are you sure it's not flash or
> something like that ?

No idea.

I didn't report this in Cauldron because I expect things to be a bit broken, however now it has migrated to mga2 it's more serious.

I guess that it must be some common dependency of these Mozilla apps that has been recently updated in mga2.   

I am hoping that others will notice this too and add comments. 

Any suggestions on debugging ?
Comment 4 Barry Jackson 2012-08-23 18:38:49 CEST
I tried firefox in -safe-mode (i.e. no extensions, add-ons - flash etc.) but it makes no difference.

I notice that recently the duration is somewhat less in Cauldron, but it's still a long delay.

I can't believe that this only affects me - in both mga2 and mga3. :\
Comment 5 Barry Jackson 2012-12-29 00:31:45 CET
This is still happening and Mga3 is getting closer.

In a clean net-installed Cauldron the first run of Firefox in a session now takes 35 seconds to start. 

This is a KDE installation on an SSD.

Subsequent starts of Firefox take a few hundred milliseconds.

This is a major issue as a novice user would keep clicking the icon thinking they had not clicked it properly. Even the clock hangs for a large part of the time.

Am I really the only one seeing this?
Comment 6 Dave Hodgins 2012-12-29 01:23:31 CET
On a VirtualBox install of Mageia 3 x86-64, from the beta 1 kde dvd, with all
updates installed, I created a new user. Starting firefox for the first
time took less than a second here.  Same with thunderbird.

As part of the qa testing for the alpha/beta iso images, (14 installs
on real hardware, per build, 3 builds for beta 3), plus additional
testing under VirtualBox, one of the things I always do, is start firefox.

I haven't seen any noticeable delays here.

For debugging, I think running
$ sudo urpmi strace
$ strace -r -ostrace.txt firefox (close firefox, as soon as it does open).
$ grep -v gettimeofday strace.txt>strace2.txt

The compress and attach the strace2.txt

CC: (none) => davidwhodgins

Comment 7 Barry Jackson 2012-12-29 14:02:31 CET
Created attachment 3299 [details]
strace output

Likewise I never see this in a vbox install.

This is so frustrating.
I ran strace on the clean install and FF opened instantly. Thinking that strace was affecting things I tried over and over in the new installation that yesterday was exhibiting this issue, and it always opens without problem after reboots today. I wondered if KDE session management was upsetting it but changing the defaults to not remember previous sessions made no difference.

I reverted to my regular Cauldron installation which I use full time, and ran strace on that in a new user - it took around 35 seconds. The two files strace.txt and strace2.txt are binary equal, so I compressed the former.

After a reboot I again timed the opening of FF in my user in my normal Cauldron. It takes 1 min 5 seconds. During the first 20 seconds one core is at 100% then two then 3 hit 100% then it opens.

The strace output indicates little to me - maybe you can see something.
Comment 8 Barry Jackson 2013-01-17 00:57:31 CET
I found it!

I have been seeing a few HD problems with my SSD and today I backed it up and cloned my Cauldron system onto a regular HD.

I am now not seeing this issue - launch time for FF after boot is about 1 second and Thunderbird about 3 seconds - (very large profile).

I am going to update the firmware in the SSD and clone this clone back to it, when I have checked it over and re-partitioned it.

Note that it was only / that was on the SSD, I am still using the same /home.


Closing as invalid for now, but I may be back ;)

Status: NEW => RESOLVED
Resolution: (none) => INVALID

Comment 9 Dave Hodgins 2013-04-05 05:01:04 CEST
Make sure you have discard in the mount options in fstab, for every filesystem
on the ssd.

With my ssd drive on sdb, I also run the following after every boot ...

#!/bin/bash

IFS=$'\n'
dfout=($(df -h|grep sdb|sort))
for dfline in "${dfout[@]}"; do
    mountpoint="/${dfline##*/}"
    fstrim -v "$mountpoint"
done
Comment 10 Barry Jackson 2013-04-05 19:00:48 CEST
Yes I do, however prior to my SSD firmware update discard was not working.
Now all is well - I wrote a little script to check it.
http://mtf.no-ip.co.uk/pub/linux/barjac/soft/chkdiscard

I ran your script and it reported some very large numbers, so I will run it from time to time to get an idea of how often it is really needed. I uploaded it here with a couple of enhancements (nothing important ;)
http://mtf.no-ip.co.uk/pub/linux/barjac/soft/trimfs

Thanks for that,
Barry

Note You need to log in before you can comment on or make changes to this bug.