mozilla-1.4-r3 fails to build with gcc-3.3.1-r1, giving the following error: nsPluginHostImpl.cpp: In member function `nsresult nsPluginHostImpl::AddInstanceToActiveList(nsCOMPtr<nsIPlugin>, nsIPluginInstance*, nsIURI*, int, nsIPluginInstancePeer*)': nsPluginHostImpl.cpp:3646: internal compiler error: in cp_expr_size, at cp/cp-lang.c:312 A complete build output and preprocessed source will be attached. I've tried this on two different i386 systems; see bug #28352. I've also tried modifying the current mozilla ebuild to add -fno-strict-aliasing on all platforms, to no effect. Portage 2.0.49-r4 (default-x86-1.4, gcc-3.3.1, glibc-2.3.2-r1, 2.4.21_rc2-gss) ================================================================= System uname: 2.4.21_rc2-gss i686 Intel(R) Pentium(R) III Mobile CPU 1000MHz ACCEPT_KEYWORDS="x86 ~x86" AUTOCLEAN="yes" CFLAGS="-march=pentium3 -O2 -fstack-protector -finline-functions -falign-functions=32 -falign-loops=4 -falign-jumps=4 -pipe" CHOST="i686-pc-linux-gnu" COMPILER="gcc3" CONFIG_PROTECT="/etc /var/qmail/control /usr/kde/2/share/config /usr/kde/3/share/config /usr/X11R6/lib/X11/xkb /usr/kde/3.1/share/config /usr/share/config" CONFIG_PROTECT_MASK="/etc/gconf /etc/env.d" CXXFLAGS="-march=pentium3 -O2 -fstack-protector -finline-functions -falign-functions=32 -falign-loops=4 -falign-jumps=4 -pipe" DISTDIR="/usr/portage/distfiles" FEATURES="sandbox ccache autoaddcvs" GENTOO_MIRRORS="ftp://ftp.gtlib.cc.gatech.edu/pub/gentoo http://distro.ibiblio.org/pub/Linux/distributions/gentoo http://gentoo.oregonstate.edu/" MAKEOPTS="-j2" PKGDIR="/usr/portage/packages" PORTAGE_TMPDIR="/var/tmp" PORTDIR="/usr/portage" PORTDIR_OVERLAY="/usr/local/portage" SYNC="rsync://rsync.us.gentoo.org/gentoo-portage" USE="x86 oss apm avi crypt cups encode foomaticdb gif jpeg libg++ libwww mad mikmod mmx mpeg ncurses nls pdflib png quicktime spell truetype xml2 xmms xv zlib gtkhtml gdbm berkdb slang readline bonobo java guile mysql X sdl gpm tcpd pam ssl perl python esd imlib oggvorbis gnome gtk qt kde opengl mozilla gphoto2 cdr gtk2 alsa -motif tcltk -arts -svga innodb dvd snmp"
Created attachment 17716 [details] build output with error
Created attachment 17717 [details] preprocessed source
This bug should probably be reassigned to the GCC team.
I have verified that this internal compiler error does not occur with gcc-3.2.3-r2. However I see there is now a gcc-3.3.1-r2, so I will retest with that. Adding azarah because this bug got misassigned to the Mozilla team and is apparently being ignored, or at least not seen by the GCC team. It *may* be a relative of bug #28266.
I merged gcc-3.3.1-r2 and tried to update gnome, but it died on atk. Since it appears from new bug reports today that there are still a lot of problems with 3.3.1-r2, I've masked it locally; I don't have any more time left to try to figure this out for now. emerge gnome # seems to be a pretty good stress/smoke test
The internal compiler error is triggered by the CFLAG -fstack-protector; see also Bug #29005. I have tried to emerge mozilla with and without this particular flag. Dropping -fstack-protector results in a flawless emerge. Therefore, one of the Bugs #28728 or #29005 might be marked as duplicate.
*** Bug 29005 has been marked as a duplicate of this bug. ***
I get the same error message using gcc-3.3.1-r3, compiling mozilla-1.4-r4. I also have -fstack-protector.
I had the same problem but with latest samba ebuild, see bug 30268 Comment #9 and try with those flags.
I also have the same internal compiler error when compiling media-video/mjpegtools-1.6.1.90-r1 using -fstack-protector and gcc-3.3.1-r3. When I remove -fstack-protector, the compile is successful.
Howard: add -ffast-math and -fforce-addr to your CFLAGS and give it a shot. That fixed the Samba compile issue with -fstack-protector in some strange and mysterious way. You might also try upgrading to gcc-3.3.1-r4, as it has a newer propolice patch in it which also resolved compiling Samba and Openssl on my sparc64/sparc32 machines.
Kumba: I was mistaken about which gcc I was using. I'm already using gcc-3.3.1-r4, so comment #10 was with gcc-3.3.1-r4. I added -ffast-math and -fforce-addr, as you suggested. Then, mjpegtools compiled successfully using -fstack-protector. (Now I just have to look up what those flags mean -- so I can see if I can use them routinely. If so, they seem to be a workaround.)
I tried compiling mjpegtools again, adding -fforce-addr but not -ffast-math. The compilation was successful. It appears to me that -fforce-addr is a safe optimization, but -ffast-math looks like an optimization to avoid if you want IEEE compliance. So I'm going to add -fforce-addr as a routine workaround. Will report again if I have any more internal compiler errors.
Howard: rather interesting. I wonder what -fforce-addr does that makes -fstack-protector work. See if this solves the Mozilla problem as well. Also CC'ing the hardened people on this, as they might find it of interest.
Kumba: Compiled mozilla-1.4-r4 with -fstack-protector and -fforce-addr but not -ffast-math, as you requested (using gcc-3.3.1-r4). The compilation was successful. So far, the -fforce-addr workaround is a success. (I have no idea why it helps. Has anyone referred this upstream to gcc maintainers?)
Howard: I added the Gentoo Hardened team to this bug and the Samba bug that also experienced this. So far, this shows three different programs which cause GCC to generate an ICE to work when -fforce-addr is supplied. Rather interesting. One of the Hardened people will likely have a much better idea of what is going on between those two flags, and whether it's even a good thing.
info gcc reveals (for the curious): `-fforce-mem' Force memory operands to be copied into registers before doing arithmetic on them. This produces better code by making all memory references potential common subexpressions. When they are not common subexpressions, instruction combination should eliminate the separate register-load. Enabled at levels `-O2', `-O3', `-Os'. `-fforce-addr' Force memory address constants to be copied into registers before doing arithmetic on them. This may produce better code just as `-fforce-mem' may. My interpretation of this is that -fforce-addr is not normally enabled, even when -fforce-mem is normally on at -O2 or higher. -fforce-addr *sounds* like a generally safe option, but then, it's normally off.
Andy: I agree with your reading of the gcc info: -fforce-addr *sounds* safe (but why is it off even when -fforce-mem is on? (Unanswered question)). Perhaps the -fforce-addr code is less-tested? I'm keeping the flag until I hear of some reason no to. I received an e-mail from Dr. Hiroaki Etoh requesting the failing source about 12 hours ago, which I provided. Therefore, I surmise he is working on the bug. (The Internet is amazing!)
Maybe there is a performance hit at compile time during optimization, or the run-time performance gains aren't as certain as with -force-mem, or it works better on certain architectures (these are all guesses). But after a little checking I found that -fstack-protector doesn't show up in the GNU info for gcc at all, i.e. it is technically an undocumented feature. Probably this is because it's patched in and not officially part of GCC yet. Thus -fforce-mem and -fforce-addr seem to be more mainline -- and perhaps safer -- than -fstack-protector.
Dr. Etoh just e-mailed me as follows: "I confirmed this is a propolice issue. I'd like to fix this in the weekend. I'll tell you when it is finished."
After recompiling mozilla-1.4-r4 with -fstack-protector and -fforce-addr, I have been experiencing frequent lock-ups in Mozilla. I don't know if this is related in any way to -fstack-protector and/or -fforce-addr, but I thought I should report this here, in case anyone else is experiencing similar lock-ups. I have decided to recompile everything(!) without -fstack-protector and -fforce-addr to see whether this affects Mozilla's stability on my system.
Created attachment 19134 [details, diff] Patch supplied by Dr. Hiroaki Etoh Here is the patch I received from Dr. Hiroaki Etoh. His e-mail stated: "This is the patch for this issue. if you have any trouble, please inform me. See attached file: pp20031010-all-3_3.patch)" I am passing the patch along as received. I will apply it to gcc-3.3.1-r4 and test it, but this will take a while. Also, I'm not familiar with gcc internals, so I'm only able to test it as an end-user. If there are any regression tests I should attempt, please point me in the right direction.
See comment #22 and Dr. Etoh's patch. (I am posting this comment because I didn't get an e-mail with comment #22, and I want to make sure you get an e-mail about the availability of the patch. My apology if this is a duplicate for you.)
the lastest GCC and MOZ ebuilds seem to play nice together... I think this can be closed or it's just going to turn into a 'garbage collecter' bug for anyone having trouble with Mozilla.
Why, yes, they do. But only because the mozilla-1.4-r4 ebuild adds -fforce-addr to the CFLAGS as a workaround. But then, this is a gcc bug, so now one of the test cases for the real bug is no longer a test case. The bug's not fixed; it's just covered up. I'm removing -fforce-addr from my mozilla build and retesting with -fstack-protector and I will report back with results compiling with gcc-3.3.1-r5. I'm also reassigning to azarah, since he seems to be handling these gcc issues.
I stripped out -fforce-addr from the mozilla-1.4-r4 ebuild and was able to successfully compile with gcc-3.3.1-r5 with -fstack-protector. Additionally, it seems to run.
Re: Comment #24 and comment #26: The changes in gcc-3.3.1-r5 (from -r4) do NOT include Dr. Etoh's patch of 2003-10-12. I am now applying this patch and testing it with -r5. (Sorry for delay in doing so.) If -r5 runs without the internal compiler error (without the patch), then maybe the patch is unnecessary. Therefore, I will also test -r5 (without the patch) on mjpegtools (with -fstack-protector, but without -fforce-addr) (see comment #10), since -r4 failed on this. At this point I suggest keeping the bug open.
Re comment #27: media-video/mjpegtools-1.6.1.90-r1 fails with the identical internal compiler error (see comment #10) when compiled under gcc-3.3.1-r5 (without Dr. Etoh's patch of 2003-10-12). Next I will test with the patch.
Re: Comment #27: After applying Dr. Etoh's 2003-10-12 patch to gcc-3.3.1-r5, mjpegtools compiles successfully with -fstack-protector and without -fforce-addr. Next I will test Mozilla and Samba.
Using Dr. Etoh's patch to gcc-3.3.1-r5, I successfully compiled with -fstack-protector both mozilla-1.4-r4 (after removing -fforce-addr from the ebuild) and samba-3.0.0-r1. Therefore, all three ebuilds that previously failed with -fstack-protector now compile successfully. I am unable to test the functionality of the -fstack-protector patch (as far as whether the generated code is correct), as I don't have any test code. However, I am reasonably satisfied that the patch fixes the internal compiler errors that were previously experienced when -fstack-protector was used.
This is one way to verify that the compiled executable is actually using ssp, works on stripped binarys as well. readelf -s /usr/lib/mozilla/mozilla-bin | grep _guard The _guard symbol will always be present one or more times. You should also see a __guard_setup Here is some simple test code. solar@simple c $ cat vuln.c #include <stdio.h> int main(int argc, char **argv) { char buf[10]; strcpy(buf, argv[1]); return 0; } solar@simple c $ ./vuln 1234567890123456 vuln: stack smashing attack in function mainAborted
Re: Comment #31: Solar, 1. I found 1 __guard, but no __guard_setup using your readelf command. 2. Your vuln.c test code produced the "stack smashing attack" message when compiled with the -fstack-protector option. (Both of these results were obtained with programs compiled with gcc-3.3.1-r5 with Dr. Etoh's patch.)
I believe this bug is now fixed in gcc-3.3.2-r2 which includes Dr. Etoh's propolice patch of 2003-10-12. I haven't experienced any ICEs lately using this version. Also, I believe that ebuilds which have added --fforce-addr as a workaround should remove this flag.
closing with higher gcc version & mozilla 1.5
closing
