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)
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
Comment 1•15 years ago
|
||
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.
Comment 3•15 years ago
|
||
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
Comment 6•15 years ago
|
||
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.
Description
•