View previous topic :: View next topic |
Author |
Message |
RichardGv n00b
Joined: 26 Jan 2010 Posts: 43 Location: People's Republic of China
|
Posted: Sun Dec 25, 2011 10:12 am Post subject: www-client/firefox-9.0 fails in install phase |
|
|
Environment: Gentoo ~amd64 hardened / hardened-sources-3.1.5
Problem:
I failed to build firefox-9.0 in the tree. It freezes in install phase.
Here the last 20 lines of build log:
Code: |
adding: res/table-add-row-after-active.gif (deflated 11%)
adding: defaults/ (stored 0%)
adding: defaults/pref/ (stored 0%)
adding: defaults/pref/firefox.js (deflated 75%)
adding: defaults/pref/services-sync.js (deflated 75%)
adding: defaults/pref/firefox-l10n.js (deflated 49%)
adding: defaults/pref/firefox-branding.js (deflated 57%)
adding: defaults/pref/all-gentoo.js (deflated 57%)
adding: defaults/autoconfig/ (stored 0%)
adding: defaults/autoconfig/platform.js (deflated 5%)
adding: defaults/autoconfig/prefcalls.js (deflated 72%)
adding: defaults/profile/ (stored 0%)
adding: defaults/profile/bookmarks.html (deflated 73%)
adding: defaults/profile/prefs.js (deflated 35%)
adding: defaults/profile/localstore.rdf (deflated 19%)
adding: defaults/profile/mimeTypes.rdf (deflated 44%)
adding: defaults/profile/chrome/ (stored 0%)
adding: defaults/profile/chrome/userContent-example.css (deflated 47%)
adding: defaults/profile/chrome/userChrome-example.css (deflated 46%)
adding: greprefs.js (deflated 73%)
|
Here the process tree of the emerge processes when it halts. The "xpcshell" process kept running for more than an hour, using 100% of one of my CPU core, yet seems nothing was done. And it just kept running forever.
Code: |
PPID PID PGID SID TTY TPGID STAT UID TIME COMMAND
1 3542 3542 3542 ? -1 SNs 1000 1:08 tmux
3542 3543 3543 3543 pts/1 20327 SNs 0 0:00 \_ su -s /bin/zsh -
3543 3548 3548 3543 pts/1 20327 SN 0 0:00 | \_ -su
3548 20327 20327 3543 pts/1 20327 SN+ 0 0:02 | \_ /usr/bin/python2 -O /usr/bin/ebuild /usr/portage/www-client/firefox/firefox-9.0.ebuild install
20327 20367 20327 3543 pts/1 20327 SN+ 0 0:00 | \_ [www-client/firefox-9.0] sandbox "/usr/lib64/portage/bin/ebuild.sh" install
20367 20368 20327 3543 pts/1 20327 SN+ 0 0:00 | \_ /bin/bash /usr/lib64/portage/bin/ebuild.sh install
20368 20385 20327 3543 pts/1 20327 SN+ 0 0:00 | \_ /bin/bash /usr/lib64/portage/bin/ebuild.sh install
20385 20406 20327 3543 pts/1 20327 SN+ 0 0:00 | \_ /bin/bash /usr/lib64/portage/bin/ebuild-helpers/emake DESTDIR=/var/tmp/portage/www-client/firefox-9.0/image/ install
20406 20408 20327 3543 pts/1 20327 SN+ 0 0:00 | \_ make -j1 DESTDIR=/var/tmp/portage/www-client/firefox-9.0/image/ install
20408 20421 20327 3543 pts/1 20327 SN+ 0 0:00 | \_ make -C browser/installer install
20421 20490 20327 3543 pts/1 20327 SN+ 0 0:00 | \_ /bin/sh -c cd ../../dist/firefox && rm -f omni.jar components/binary.manifest && grep -h '^binary-component' components/*.manifest > binary.manifest ; for m in components/*.manifest; do sed -e 's/^binary-component/#binary-component/' $m > tmp.manifest && mv tmp.manifest $m; done; /usr/bin/zip -r9m omni.jar chrome chrome.manifest components/*.js components/*.xpt components/*.manifest modules res defaults greprefs.js jsloader -x chrome/icons/\* defaults/pref/channel-prefs.js res/cursors/\* res/MainMenu.nib/\* && /var/tmp/portage/www-client/firefox-9.0/work/mozilla-release/obj-x86_64-unknown-linux-gnu/dist/bin/run-mozilla.sh /var/tmp/portage/www-client/firefox-9.0/work/mozilla-release/obj-x86_64-unknown-linux-gnu/dist/bin/xpcshell -g "$PWD" -a "$PWD" -f /var/tmp/portage/www-client/firefox-9.0/work/mozilla-release/toolkit/mozapps/installer/precompile_cache.js -e "populate_startupcache('GreD', 'omni.jar', 'startupCache.zip');" && rm -rf jsloader && /usr/bin/unzip startupCache.zip && rm startupCache.zip && /usr/bin/zip -r9m omni.jar jsloader/resource/gre && /usr/bin/python2.7 /var/tmp/portage/www-client/firefox-9.0/work/mozilla-release/config/optimizejars.py --optimize /var/tmp/portage/www-client/firefox-9.0/work/mozilla-release/obj-x86_64-unknown-linux-gnu/browser/installer/../../jarlog//en-US ./ ./ && mv binary.manifest components && printf "manifest components/binary.manifest\n" > chrome.manifest
20490 20499 20327 3543 pts/1 20327 RNl+ 0 65:18 | \_ /var/tmp/portage/www-client/firefox-9.0/work/mozilla-release/obj-x86_64-unknown-linux-gnu/dist/bin/xpcshell -g /var/tmp/portage/www-client/firefox-9.0/work/mozilla-release/obj-x86_64-unknown-linux-gnu/dist/firefox -a /var/tmp/portage/www-client/firefox-9.0/work/mozilla-release/obj-x86_64-unknown-linux-gnu/dist/firefox -f /var/tmp/portage/www-client/firefox-9.0/work/mozilla-release/toolkit/mozapps/installer/precompile_cache.js -e populate_startupcache('GreD', 'omni.jar', 'startupCache.zip');
|
Here's my emerge --info firefox:
http://pastebin.com/gfY09vHi
A few points to note:
- I'm using a hardened Gentoo system, with the default gcc profile, basically with both PIE and SSP enabled in toolchain. I have SELinux disabled currently. Some PaX and Grsecurity options are enabled in the kernel, yet I spot no suspicious log messages while compiling firefox.
- Yes, I have a fully updated system and I'm not using any aggressive versions in toolchain.
- And I'm a Portage-2.2 user, but I guess it is not the cause of the issue. I ran out of neither disk space or memory during the process.
- I was using MAKEOPTS="-j2" when compiling firefox-9.0. I did try to change it to MAKEOPTS="-j1" in /var/tmp/portage/www-client/firefox-9.0/temp/environment and re-run the install phase with "ebuild /usr/portage/www-client/firefox/firefox-9.0.ebuild install". No luck.
- It takes more than 2 hours to compile firefox on my 4-year-old computer, so I don't like trying to compile it again without more certainly about the cause of the issue.
- In case someone would try to persuade me to use firefox-bin: I have a relative slow box, and firefox is the app I most commonly use, so it needs to be fully optimized.
- firefox-8.0 is compiled correct under nearly identical environment.
- I searched around using Google and seems no similar reports are found.
This is full build log. Beware it's about 9MB in size. http://dl.dropbox.com/u/283669/firefox-9.0-build.log
Any ideas? Thanks in advance. |
|
Back to top |
|
|
Veldrin Veteran
Joined: 27 Jul 2004 Posts: 1945 Location: Zurich, Switzerland
|
Posted: Sun Dec 25, 2011 10:18 am Post subject: |
|
|
ran into the same issue this weekend. I guess, waiting for 9.0.1 seems the best options (there is an ebuild in the zugaina overlay).
just my .02$
V. _________________ read the portage output!
If my answer is too concise, ask for an explanation. |
|
Back to top |
|
|
mv Watchman
Joined: 20 Apr 2005 Posts: 6747
|
Posted: Sun Dec 25, 2011 8:25 pm Post subject: |
|
|
I am glad to hear that somebody else has this problem, too.
However, I am also using hardened-sources (but no hardened toolchain). Did not try with a non-hardened kernel yet.
The problem seems to be that xpcshell just "hangs" (eating processor time): Even if run with no arguments and </dev/null, xpcshell does not return but needs processor time.
Tested also with no CFLAGS/CXXFLAGS/LDFLAGS -> no change. |
|
Back to top |
|
|
mv Watchman
Joined: 20 Apr 2005 Posts: 6747
|
Posted: Sun Dec 25, 2011 9:45 pm Post subject: |
|
|
Yep: This is yet another issue of hardened-sources
With kernel parameter pax_softmode=1 (if you have enabled this option in your kernel) firefox-9 compiles fine.
In "normal" mode, firefox-9 does neither compile nor run.
It seems to be a bug in hardened-sources, because the logs do not say that anything was prevented: firefox just needs processor time without doing anything. |
|
Back to top |
|
|
Veldrin Veteran
Joined: 27 Jul 2004 Posts: 1945 Location: Zurich, Switzerland
|
Posted: Mon Dec 26, 2011 5:48 am Post subject: |
|
|
sad...
I see, if I find some time to test this on my desktop (running hardened, but with gentoo sources). But I guess, it will just run fine.
I guess, this is also, why hardened (or more specifically PaX and grsec) are not in mainline. Or the other way around, if they were, it would not have happened.
V. _________________ read the portage output!
If my answer is too concise, ask for an explanation. |
|
Back to top |
|
|
West201 Tux's lil' helper
Joined: 22 Dec 2011 Posts: 115
|
Posted: Mon Dec 26, 2011 7:22 am Post subject: |
|
|
Why not just install Opera ? or Aura ? |
|
Back to top |
|
|
RichardGv n00b
Joined: 26 Jan 2010 Posts: 43 Location: People's Republic of China
|
Posted: Mon Dec 26, 2011 11:43 am Post subject: |
|
|
mv wrote: | Yep: This is yet another issue of hardened-sources
With kernel parameter pax_softmode=1 (if you have enabled this option in your kernel) firefox-9 compiles fine.
In "normal" mode, firefox-9 does neither compile nor run.
It seems to be a bug in hardened-sources, because the logs do not say that anything was prevented: firefox just needs processor time without doing anything. |
Aww, so even if I manage to install Firefox 9 with another kernel I still would not be able to use it under my hardened kernel at all? Awful...
So, I am waiting... I'm waiting...
Veldrin wrote: | sad...
I see, if I find some time to test this on my desktop (running hardened, but with gentoo sources). But I guess, it will just run fine.
I guess, this is also, why hardened (or more specifically PaX and grsec) are not in mainline. Or the other way around, if they were, it would not have happened.
V. |
PaX and Grsecurity have offered me tons of extra troubles so far... Even though far less destructive than SELinux, which I never got working. I remember I saw a sentence in a thread complaining about hardened Gentoo is hard to use: "I finally understood why it is called 'hardened'."
JESSEJJ89 wrote: | Why not just install Opera ? or Aura ? |
Being a 5-year Firefox user... Firefox is a part of my life... |
|
Back to top |
|
|
Spidey Apprentice
Joined: 07 Sep 2006 Posts: 269
|
Posted: Mon Dec 26, 2011 6:02 pm Post subject: |
|
|
Just want to share that there is probably something going on AFTER that last log entry, some process running but not reported to the log.
I'm using ~amd64, normal desktop profile, not hardened, and even so my emerge process lingered for some minutes at that stage. |
|
Back to top |
|
|
Sven Vermeulen Retired Dev
Joined: 29 Aug 2002 Posts: 1345 Location: Mechelen, Belgium
|
Posted: Mon Dec 26, 2011 7:16 pm Post subject: |
|
|
The solution is to have xpcshell (which is used during the build of firefox) pax-marked for both -m and -r. The issue here is that the RANDMMAP option is causing xpcshell to go in an infinite loop to get an address.
Either update the ebuild manually (look for pax-mark, and do the same with the "r" option) or wait for the update to hit the tree (but I'm not sure that will be very quick). _________________ Please add "[solved]" to the initial topic title when it is solved. |
|
Back to top |
|
|
Veldrin Veteran
Joined: 27 Jul 2004 Posts: 1945 Location: Zurich, Switzerland
|
Posted: Mon Dec 26, 2011 9:25 pm Post subject: |
|
|
Thanks for the hint - I will mess with the ebuild, and test it. If it works, I file a bug with the patch.
And my test on my desktop (hardened system, vanilla kernel) ended as expected: firefox just works. _________________ read the portage output!
If my answer is too concise, ask for an explanation. |
|
Back to top |
|
|
mv Watchman
Joined: 20 Apr 2005 Posts: 6747
|
Posted: Tue Dec 27, 2011 12:18 am Post subject: |
|
|
Sven Vermeulen wrote: | The solution is to have xpcshell (which is used during the build of firefox) pax-marked for both -m and -r. |
This is sufficient for the build to finish, but not sufficient to use firefox with hardened-sources afterwards:
Also the firefox binary must be max-marked with -r for this (it seems that this is not needed for firefox-bin and plugin-container),
Of course, this could be done later manually with paxctrl, but if you patch the ebuild (or report a bug) it is cleaner to do it in the ebuild. |
|
Back to top |
|
|
RichardGv n00b
Joined: 26 Jan 2010 Posts: 43 Location: People's Republic of China
|
Posted: Tue Dec 27, 2011 4:23 am Post subject: |
|
|
Thanks a million, guys, especially Sven Vermeulen. The problem was gone after applying paxctl -r to both xpcshell and firefox:
Code: |
# Since I have the temp files of a half-built firefox-9.0...
paxctl -mr /var/tmp/portage/www-client/firefox-9.0/work/mozilla-release/obj-x86_64-unknown-linux-gnu/dist/bin/xpcshell
ebuild /usr/portage/www-client/firefox/firefox-9.0.ebuild install qmerge clean
paxctl -r /usr/bin/firefox
|
plugin-container does not need -r. |
|
Back to top |
|
|
myceliv Apprentice
Joined: 29 Nov 2007 Posts: 178
|
Posted: Sun Jan 01, 2012 6:21 am Post subject: |
|
|
Even better now there's a patch on Bug 396275 to put into /etc/portage/patches/www-client/firefox-9.0/. This for me at least works to allow using RANDMMAP again. |
|
Back to top |
|
|
alucowie n00b
Joined: 23 Apr 2010 Posts: 4 Location: France
|
Posted: Fri Jan 20, 2012 11:54 pm Post subject: |
|
|
Hi,
My firefox install freeze the same way (adding: greprefs.js (deflated 73%) is my last build message) and the process tree is the same but
paxctl -r does not fix the infinite loop on my system. I must switch my compile from hardened to hardened-nopie to properly compile firefox.
strace tells me:
Code: | # strace -p 16048
Process 16048 attached - interrupt to quit
futex(0xb449c840, FUTEX_WAIT_PRIVATE, 2, NULL ) =
|
And the syscall never returns.
I had to build with nopie the same way to avoid freeze on firefox 8 startup (same issue, a futex lock), I think is bug 374289. |
|
Back to top |
|
|
Lasulu n00b
Joined: 04 Nov 2006 Posts: 17 Location: Vienna
|
Posted: Sun Jan 22, 2012 7:02 am Post subject: |
|
|
Just discovered what at first glance appears to be a virus possibly introduced through firefox and adobe-flash. Closed the browser and reopened it and the browser is taking a long time going to loading the home page and also creating a new tab. The browser blinks and blinks and cant be used for several minutes before settling down. Some minutes later it appears usable again.
I get the following on the affected machine:
Code: |
ps ax | grep flash
32518 tty2 Sl 0:00 /usr/lib64/firefox/plugin-container
/opt/Adobe/flash-player/flash-plugin/libflashplayer.so -greomni
/ /usr/lib64/firefox/omni.jar 32465 false plugin
32610 pts/0 S+ 0:00 grep --colour=auto flash
|
After a few googles I have discovered:
omni.jar is probably non-free non-open-source introduced by mozilla firefox
there have been other reports of a windows virus being introduced on linux machines using omni.jar related means
I am thinking of going to an older version of firefox as a temporary solution. The last thing done on the machine before the problem appeared was follow a link from the huffington post site to a youtube video of a trailer for a new movie (The Hunger Games). The video plays through and towards the end of it the screen starts flashing. It could only be stopped by closing the browser.
I would appreciate any thoughts on this. |
|
Back to top |
|
|
Lasulu n00b
Joined: 04 Nov 2006 Posts: 17 Location: Vienna
|
Posted: Sun Jan 22, 2012 1:04 pm Post subject: |
|
|
Lasulu wrote: | Just discovered what at first glance appears to be a virus possibly introduced through firefox and adobe-flash. Closed the browser and reopened it and the browser is taking a long time going to loading the home page and also creating a new tab. The browser blinks and blinks and cant be used for several minutes before settling down. Some minutes later it appears usable again.
...
|
Some hours later: The problem has not recurred. I am unable to reproduce it on another machine after upgrading to firefox-9.0. The affected machine is running firefox-8.0. I still can't understand what happened. I am going to upgrade it to firefox-9.0 and see if can play the same video without a problem. Sorry if I posted in the wrong place. I got a little panicky when I thought I had a virus. I had rootkit on a machine about a year ago and it was a major hassle. I have 4 machines running Gentoo and one Windows 7 (doesn't get used much). |
|
Back to top |
|
|
Hu Moderator
Joined: 06 Mar 2007 Posts: 21631
|
Posted: Sun Jan 22, 2012 6:18 pm Post subject: |
|
|
On a clean Firefox install, /usr/lib64/firefox/omni.jar exists for me. It appears to contain much of the chrome that defines the browser interface. This is not to say that malicious software might not use that base name to conceal itself, but the path shown in the ps output is not automatically suspicious to me. |
|
Back to top |
|
|
Anarchy Developer
Joined: 29 Jun 2005 Posts: 140
|
Posted: Mon Jan 30, 2012 1:56 am Post subject: |
|
|
Lasulu wrote: | Just discovered what at first glance appears to be a virus possibly introduced through firefox and adobe-flash. Closed the browser and reopened it and the browser is taking a long time going to loading the home page and also creating a new tab. The browser blinks and blinks and cant be used for several minutes before settling down. Some minutes later it appears usable again.
I get the following on the affected machine:
Code: |
ps ax | grep flash
32518 tty2 Sl 0:00 /usr/lib64/firefox/plugin-container
/opt/Adobe/flash-player/flash-plugin/libflashplayer.so -greomni
/ /usr/lib64/firefox/omni.jar 32465 false plugin
32610 pts/0 S+ 0:00 grep --colour=auto flash
|
After a few googles I have discovered:
omni.jar is probably non-free non-open-source introduced by mozilla firefox
there have been other reports of a windows virus being introduced on linux machines using omni.jar related means
I am thinking of going to an older version of firefox as a temporary solution. The last thing done on the machine before the problem appeared was follow a link from the huffington post site to a youtube video of a trailer for a new movie (The Hunger Games). The video plays through and towards the end of it the screen starts flashing. It could only be stopped by closing the browser.
I would appreciate any thoughts on this. |
Comparing windows issue with linux never works. Omni.jar is nothing more then a zip file, you can extract it if you would like to view the content, but as stated it is mostly the chrome files, omnijar is fastrer then the conventional zip due to a startup cache generation that is used. If you experience a problem in your gentoo with any mozilla product, file a bug report and I will investigate it as soon as possible. |
|
Back to top |
|
|
|