Closed Bug 533632 Opened 15 years ago Closed 15 years ago

Application remains active after closing it. (started after PGO fix)

Categories

(Firefox :: General, defect)

x86_64
Linux
defect
Not set
normal

Tracking

()

RESOLVED INVALID

People

(Reporter: newb, Unassigned)

References

()

Details

User-Agent:       Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.3a1pre) Gecko/20091208 Firefox/3.7a1pre
Build Identifier: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.3a1pre) Gecko/20091208 Firefox/3.7a1pre

I have been building both of these firefox-pgo-beta and firefox-pgo-minefield packages.

http://aur.archlinux.org/packages.php?ID=32030
http://aur.archlinux.org/packages.php?ID=22919


Both of these versions had worked normally until they started using the PGO fix patch that is in upstream.


Now when I close firefox from the Firefox menu, or 'ctrl + q', or from my xmonad keybinding of "mod+shift+close", it closes the window but leaves a bunch of processes running in htop.


The screenshot I included shows 16 processes of /usr/lib/firefox-3.7a1pre/firefox-bin in htop after I had closed the app.

Reproducible: Sometimes

Steps to Reproduce:
1.Build a PGO Firefox using the new patch (either 3.6b4 or 3.7a1pre).
2.Run it for a hour, then close it. Now try to reopen it.
3.Look in htop to see the processes still running. Look at CPU jumping up to about 50%. Then killall firefox-bin and restart the app. Repeat from step 1.
Actual Results:  
See my screenshot I attached. (htop and my CPU running 50% until the app is killed)

Expected Results:  
The program should just close normally.

Build platform
target
x86_64-unknown-linux-gnu

Build tools
Compiler 	Version 	Compiler flags
gcc 	gcc version 4.4.2 (GCC) 	-Wall -W -Wno-unused -Wpointer-arith -Wcast-align -W -Wno-long-long -march=athlon64-sse3 -O2 -pipe -fno-strict-aliasing -pthread -pipe -DNDEBUG -DTRIMMED -fprofile-use -Os -freorder-blocks -fno-reorder-functions
c++ 	gcc version 4.4.2 (GCC) 	-fno-rtti -fno-exceptions -Wall -Wpointer-arith -Woverloaded-virtual -Wsynth -Wno-ctor-dtor-privacy -Wno-non-virtual-dtor -Wcast-align -Wno-invalid-offsetof -Wno-variadic-macros -Wno-long-long -march=athlon64-sse3 -O2 -pipe -fno-strict-aliasing -fshort-wchar -pthread -pipe -DNDEBUG -DTRIMMED -fprofile-use -Os -freorder-blocks -fno-reorder-functions

Configure arguments
--enable-application=browser --prefix=/usr --libdir=/usr/lib --with-system-nss --with-system-jpeg --with-pthreads --with-system-zlib --with-system-bz2 --with-system-png --enable-system-cairo --with-system-hunspell --with-system-sqlite --with-system-nspr --disable-installer --disable-updater --enable-official-branding --enable-startup-notification --disable-pedantic --enable-jemalloc --enable-xterm-updates --enable-optimize --disable-debug --disable-tests --enable-profile-guided-optimization --enable-strip --enable-install-strip --disable-crashreporter --disable-parental-controls --enable-printing --enable-xinerama --enable-default-toolkit=cairo-gtk2 --enable-places --enable-svg --enable-pango --enable-canvas --enable-smil --disable-java-xpcom --enable-canvas3d --disable-safe-browsing
The fix that you refer to simply allows the correct 'cleaning' after the first build pass before starting the second build pass which uses the generated profile. The problems you report are probably due to the fact the your Archlinux build can now produce an 'actual' PGO build.

I have no problem with PGO builds on Linux (Slackware) using this patch with Firefox 3.6b4.  

There are several other patches involved in the 'Archlinux' build of Firefox and I suggest these be investigated.
Thank you for your info. Do you build a x86 PGO build or a x86_64 PGO build? I'm just wondering if this could be a 64-bit related issue rather than something having to do with any of these other 5 patches used in the Arch minefield PGO package:

http://aur.archlinux.org/packages/firefox-pgo-minefield/firefox-pgo-minefield/mozilla-ps-pdf-simplify-operators.patch
http://aur.archlinux.org/packages/firefox-pgo-minefield/firefox-pgo-minefield/mozilla-firefox-1.0-lang.patch
http://aur.archlinux.org/packages/firefox-pgo-minefield/firefox-pgo-minefield/ldflags-namespec.patch
http://aur.archlinux.org/packages/firefox-pgo-minefield/firefox-pgo-minefield/jemalloc-enable-pgo.patch
http://aur.archlinux.org/packages/firefox-pgo-minefield/firefox-pgo-minefield/fix-mozilla-launcher.patch


If anybody sees anything in these 5 other patches that might cause firefox to continue running after being closed then please let me know.


Thank you.
I only build x86 PGO so it could be an x86_64 issue.

I would suggest trying a build without the 'fix-mozilla-launcher' patch as a first thing.

The 'Arch' mozconfig' has lots of non-default items so another approach might be a simpler 'mozconfig'.
I'll give it a try without that patch and with a simpler mozconfig. Thanks for your reply.
I just built it without that patch and the problem remains. I didn't simplify the mozconfig because I wasn't sure of what I would need to remove.

These are the options that are added in compared to the Arch official package:

ac_add_options --enable-profile-guided-optimization
ac_add_options --enable-jemalloc
ac_add_options --disable-pedantic
ac_add_options --enable-smil
ac_add_options --enable-canvas
ac_add_options --disable-canvas3d
ac_add_options --enable-startup-notification
ac_add_options --disable-crashreporter
ac_add_options --disable-safe-browsing
ac_add_options --enable-official-branding
ac_add_options --disable-updater
ac_add_options --disable-parental-controls
ac_add_options --disable-printing
ac_add_options --with-system-bz2
ac_add_options --with-system-hunspell
ac_add_options --with-system-sqlite
ac_add_options --enable-places
ac_add_options --disable-java-xpcom
I think perhaps this is not the place to be discussing a possible 'Mozilla bug' when the build is using a patched source rather than a 'virgin' Mozilla source.  The 'bug' could actually be an issue caused by one of the 'Archlinux' source patches or other parts of the 'Arch' build process that would not be considered a 'default' Mozilla build.
Alright then, I'll close this. Thanks for the info anyway.
Status: UNCONFIRMED → RESOLVED
Closed: 15 years ago
Resolution: --- → INVALID
You need to log in before you can comment on or make changes to this bug.