Created attachment 454530 [details] emerge --info '=dev-java/icedtea-7.2.6.8::gentoo' When I try to emerge dev-java/icedtea-7.2.6.8 with gcc-5.4.0, it always fails with a segmentation fault of cc1plus. Step to reproduce: x86_64-pc-linux-gnu-g++ -DLINUX -D_GNU_SOURCE -DAMD64 -DPRODUCT -I. -I/home/portage/portage/dev-java/icedtea-7.2.6.8/work/icedtea-2.6.8/openjdk/hotspot/src/share/vm/prims -I/home/portage/portage/dev-java/icedtea-7.2.6.8/work/icedtea-2.6.8/openjdk/hotspot/src/share/vm -I/home/portage/portage/dev-java/icedtea-7.2.6.8/work/icedtea-2.6.8/openjdk/hotspot/src/share/vm/precompiled -I/home/portage/portage/dev-java/icedtea-7.2.6.8/work/icedtea-2.6.8/openjdk/hotspot/src/cpu/x86/vm -I/home/portage/portage/dev-java/icedtea-7.2.6.8/work/icedtea-2.6.8/openjdk/hotspot/src/os_cpu/linux_x86/vm -I/home/portage/portage/dev-java/icedtea-7.2.6.8/work/icedtea-2.6.8/openjdk/hotspot/src/os/linux/vm -I/home/portage/portage/dev-java/icedtea-7.2.6.8/work/icedtea-2.6.8/openjdk/hotspot/src/os/posix/vm -I../generated -DHOTSPOT_RELEASE_VERSION="\"24.121-b00\"" -DHOTSPOT_BUILD_TARGET="\"product\"" -DHOTSPOT_BUILD_USER="\"portage\"" -DHOTSPOT_LIB_ARCH=\"amd64\" -DHOTSPOT_VM_DISTRO="\"OpenJDK\"" -DDERIVATIVE_ID="\"IcedTea 2.6.8\"" -DDISTRIBUTION_ID="\"Gentoo Base System release 2.3, package Gentoo icedtea-7.2.6.8\"" -march=native -O2 -pipe -fomit-frame-pointer -DTARGET_OS_FAMILY_linux -DTARGET_ARCH_x86 -DTARGET_ARCH_MODEL_x86_64 -DTARGET_OS_ARCH_linux_x86 -DTARGET_OS_ARCH_MODEL_linux_x86_64 -DTARGET_COMPILER_gcc -DCOMPILER2 -DCOMPILER1 -std=gnu++98 -fno-rtti -fno-exceptions -D_REENTRANT -fcheck-new -fvisibility=hidden -m64 -pipe -g -DTARGET_OS_FAMILY_linux -DTARGET_ARCH_x86 -DTARGET_ARCH_MODEL_x86_64 -DTARGET_OS_ARCH_linux_x86 -DTARGET_OS_ARCH_MODEL_linux_x86_64 -DTARGET_COMPILER_gcc -DCOMPILER2 -DCOMPILER1 -std=gnu++98 -fpic -fno-rtti -fno-exceptions -D_REENTRANT -fcheck-new -fvisibility=hidden -m64 -pipe -g -O3 -fno-strict-aliasing -DVM_LITTLE_ENDIAN -D_LP64=1 -fno-omit-frame-pointer -DINCLUDE_TRACE=1 -Wpointer-arith -Wsign-compare -DDTRACE_ENABLED -c -fpch-deps -MMD -MP -MF ../generated/dependencies/accessFlags.o.d -o accessFlags.o /home/portage/portage/dev-java/icedtea-7.2.6.8/work/icedtea-2.6.8/openjdk/hotspot/src/share/vm/utilities/accessFlags.cpp Result: x86_64-pc-linux-gnu-g++: internal compiler error: Segmentation fault (program cc1plus) Kernel messages: Nov 27 17:51:54 kernel: cc1plus[22598]: segfault at 3863feb3ec8 ip 00000000011d68b7 sp 00000389735c8d10 error 4 in cc1plus[400000+1541000] Nov 27 17:51:54 kernel: grsec: Segmentation fault occurred at 000003863feb3ec8 in /usr/libexec/gcc/x86_64-pc-linux-gnu/5.4.0/cc1plus[cc1plus:22598] uid/euid:0/0 gid/egid:0/0, parent / usr/x86_64-pc-linux-gnu/gcc-bin/5.4.0/x86_64-pc-linux-gnu-g++[x86_64-pc-linux:22597] uid/euid:0/0 gid/egid:0/0
Created attachment 454532 [details] build.log
Created attachment 454730 [details] 3.2.0 build.log
Created attachment 454732 [details] emerge --info (not on hardened)
I'm getting this on both 3.2.0 & 7.2.6.8, but I'm not on a hardened profile, maybe this should be reassigned to an other team? I've attached emerge info & build.log for 3.2.0.
I agree, this is probably not related to hardened.
Sorry for passing the buck but it's gcc failing, not Java, so I'm reassigning to the toolchain team. I'm slightly suspicious of both your CXXFLAGS. Ondřej, please retest without -fvisibility-inlines-hidden. Also -fomit-frame-pointer does nothing on amd64 IIRC. William, isn't that ridiculously long list included in -march=broadwell?
William, please also retest with distcc disabled.
Created attachment 455002 [details] no distcc Same thing without distcc.
For the record, I've just built icedtea 3.2.0 with gcc 5.4.0 and it worked fine.
Created attachment 455096 [details] icedtea build.log Without -fomit-frame-pointer, no change.
Created attachment 455098 [details] icedtea environment
look in `dmesg` to see if there's anything interesting in there try going into the build dir and running the command from build.log that is crashing. if it still fails for you there, change the -c flag to -E and attach the output of the command here for us (you'll prob have to compress it).
Nothing related in dmesg. Just segfault report in syslog: Dec 7 10:17:30 kernel: cc1plus[6290]: segfault at 3c75c743b10 ip 00000000011d68b7 sp 000003f25d2a7750 error 4 in cc1plus[400000+1541000] Dec 7 10:17:30 kernel: grsec: Segmentation fault occurred at 000003c75c743b10 in /usr/libexec/gcc/x86_64-pc-linux-gnu/5.4.0/cc1plus[cc1plus:6290] uid/euid:0/0 gid/egid:0/0, parent /usr/x86_64-pc-linux-gnu/gcc-bin/5.4.0/x86_64-pc-linux-gnu-g++[x86_64-pc-linux:6289] uid/euid:0/0 gid/egid:0/0 Dec 7 10:17:30 kernel: grsec: denied resource overstep by requesting 4096 for RLIMIT_CORE against limit 0 for /usr/libexec/gcc/x86_64-pc-linux-gnu/5.4.0/cc1plus[cc1plus:6290] uid/euid:0/0 gid/egid:0/0, parent /usr/x86_64-pc-linux-gnu/gcc-bin/5.4.0/x86_64-pc-linux-gnu-g++[x86_64-pc-linux:6289] uid/euid:0/0 gid/egid:0/0
Created attachment 455384 [details] Preprocessed output Result of x86_64-pc-linux-gnu-g++ -DLINUX -D_GNU_SOURCE -DAMD64 -DPRODUCT -I. -I/home/portage/portage/dev-java/icedtea-7.2.6.8/work/icedtea-2.6.8/openjdk/hotspot/src/share/vm/prims -I/home/portage/portage/dev-java/icedtea-7.2.6.8/work/icedtea-2.6.8/openjdk/hotspot/src/share/vm -I/home/portage/portage/dev-java/icedtea-7.2.6.8/work/icedtea-2.6.8/openjdk/hotspot/src/share/vm/precompiled -I/home/portage/portage/dev-java/icedtea-7.2.6.8/work/icedtea-2.6.8/openjdk/hotspot/src/cpu/x86/vm -I/home/portage/portage/dev-java/icedtea-7.2.6.8/work/icedtea-2.6.8/openjdk/hotspot/src/os_cpu/linux_x86/vm -I/home/portage/portage/dev-java/icedtea-7.2.6.8/work/icedtea-2.6.8/openjdk/hotspot/src/os/linux/vm -I/home/portage/portage/dev-java/icedtea-7.2.6.8/work/icedtea-2.6.8/openjdk/hotspot/src/os/posix/vm -I../generated -DHOTSPOT_RELEASE_VERSION="\"24.121-b00\"" -DHOTSPOT_BUILD_TARGET="\"product\"" -DHOTSPOT_BUILD_USER="\"portage\"" -DHOTSPOT_LIB_ARCH=\"amd64\" -DHOTSPOT_VM_DISTRO="\"OpenJDK\"" -DDERIVATIVE_ID="\"IcedTea 2.6.8\"" -DDISTRIBUTION_ID="\"Gentoo Base System release 2.3, package Gentoo icedtea-7.2.6.8\"" -march=native -O2 -pipe -DTARGET_OS_FAMILY_linux -DTARGET_ARCH_x86 -DTARGET_ARCH_MODEL_x86_64 -DTARGET_OS_ARCH_linux_x86 -DTARGET_OS_ARCH_MODEL_linux_x86_64 -DTARGET_COMPILER_gcc -DCOMPILER2 -DCOMPILER1 -std=gnu++98 -fno-rtti -fno-exceptions -D_REENTRANT -fcheck-new -fvisibility=hidden -m64 -pipe -g -DTARGET_OS_FAMILY_linux -DTARGET_ARCH_x86 -DTARGET_ARCH_MODEL_x86_64 -DTARGET_OS_ARCH_linux_x86 -DTARGET_OS_ARCH_MODEL_linux_x86_64 -DTARGET_COMPILER_gcc -DCOMPILER2 -DCOMPILER1 -std=gnu++98 -fpic -fno-rtti -fno-exceptions -D_REENTRANT -fcheck-new -fvisibility=hidden -m64 -pipe -g -O3 -fno-strict-aliasing -DVM_LITTLE_ENDIAN -D_LP64=1 -fno-omit-frame-pointer -DINCLUDE_TRACE=1 -Wpointer-arith -Wsign-compare -DDTRACE_ENABLED -E -fpch-deps -MMD -MP -MF ../generated/dependencies/ad_x86_64_clone.o.d -o ad_x86_64_clone.o ../generated/adfiles/ad_x86_64_clone.cpp
while you aren't using a hardened profile, you are using a hardened (grsec) kernel. that does not work well with pch which it looks like icedtea is using. if that manual compile was crashing for you, try dropping the -fpch-deps flag and try to compile it again.
(In reply to SpanKY from comment #15) > while you aren't using a hardened profile, you are using a hardened (grsec) > kernel. that does not work well with pch which it looks like icedtea is > using. Are you implying I should mask that flag on hardened?
(In reply to James Le Cuirot from comment #16) if that's the source of the problem, then yes. you can use `host-is-pax` from the pax-utils eclass to detect the scenario. pch flags only speed up the compile, it doesn't affect the final installed objects. let's get confirmation from the reporters though that dropping the flag helps.
What do paxctl-ng -v /usr/libexec/gcc/x86_64-pc-linux-gnu/5.4.0/cc1plus show?
(In reply to Magnus Granberg from comment #18) > What do paxctl-ng -v /usr/libexec/gcc/x86_64-pc-linux-gnu/5.4.0/cc1plus show? /usr/libexec/gcc/x86_64-pc-linux-gnu/5.4.0/cc1plus: PT_PAX : not found XATTR_PAX : -e-r-
(In reply to SpanKY from comment #15) > while you aren't using a hardened profile, you are using a hardened (grsec) > kernel. that does not work well with pch which it looks like icedtea is > using. > > if that manual compile was crashing for you, try dropping the -fpch-deps > flag and try to compile it again. I am using a hardened profile and hardened kernel. Without -fpch-deps, no change: x86_64-pc-linux-gnu-g++ -DLINUX -D_GNU_SOURCE -DAMD64 -DPRODUCT -I. -I/home/portage/portage/dev-java/icedtea-7.2.6.8/work/icedtea-2.6.8/openjdk/hotspot/src/share/vm/prims -I/home/portage/portage/dev-java/icedtea-7.2.6.8/work/icedtea-2.6.8/openjdk/hotspot/src/share/vm -I/home/portage/portage/dev-java/icedtea-7.2.6.8/work/icedtea-2.6.8/openjdk/hotspot/src/share/vm/precompiled -I/home/portage/portage/dev-java/icedtea-7.2.6.8/work/icedtea-2.6.8/openjdk/hotspot/src/cpu/x86/vm -I/home/portage/portage/dev-java/icedtea-7.2.6.8/work/icedtea-2.6.8/openjdk/hotspot/src/os_cpu/linux_x86/vm -I/home/portage/portage/dev-java/icedtea-7.2.6.8/work/icedtea-2.6.8/openjdk/hotspot/src/os/linux/vm -I/home/portage/portage/dev-java/icedtea-7.2.6.8/work/icedtea-2.6.8/openjdk/hotspot/src/os/posix/vm -I../generated -DHOTSPOT_RELEASE_VERSION="\"24.121-b00\"" -DHOTSPOT_BUILD_TARGET="\"product\"" -DHOTSPOT_BUILD_USER="\"portage\"" -DHOTSPOT_LIB_ARCH=\"amd64\" -DHOTSPOT_VM_DISTRO="\"OpenJDK\"" -DDERIVATIVE_ID="\"IcedTea 2.6.8\"" -DDISTRIBUTION_ID="\"Gentoo Base System release 2.3, package Gentoo icedtea-7.2.6.8\"" -march=native -O2 -pipe -DTARGET_OS_FAMILY_linux -DTARGET_ARCH_x86 -DTARGET_ARCH_MODEL_x86_64 -DTARGET_OS_ARCH_linux_x86 -DTARGET_OS_ARCH_MODEL_linux_x86_64 -DTARGET_COMPILER_gcc -DCOMPILER2 -DCOMPILER1 -std=gnu++98 -fno-rtti -fno-exceptions -D_REENTRANT -fcheck-new -fvisibility=hidden -m64 -pipe -g -DTARGET_OS_FAMILY_linux -DTARGET_ARCH_x86 -DTARGET_ARCH_MODEL_x86_64 -DTARGET_OS_ARCH_linux_x86 -DTARGET_OS_ARCH_MODEL_linux_x86_64 -DTARGET_COMPILER_gcc -DCOMPILER2 -DCOMPILER1 -std=gnu++98 -fpic -fno-rtti -fno-exceptions -D_REENTRANT -fcheck-new -fvisibility=hidden -m64 -pipe -g -O3 -fno-strict-aliasing -DVM_LITTLE_ENDIAN -D_LP64=1 -fno-omit-frame-pointer -DINCLUDE_TRACE=1 -Wpointer-arith -Wsign-compare -DDTRACE_ENABLED -c -MMD -MP -MF ../generated/dependencies/ad_x86_64_clone.o.d -o ad_x86_64_clone.o ../generated/adfiles/ad_x86_64_clone.cpp Dec 8 14:55:23 guthondr-t520 kernel: cc1plus[15783]: segfault at 3c75c743b10 ip 00000000011d68b7 sp 0000039a73aa3890 error 4 in cc1plus[400000+1541000] Dec 8 14:55:23 guthondr-t520 kernel: grsec: Segmentation fault occurred at 000003c75c743b10 in /usr/libexec/gcc/x86_64-pc-linux-gnu/5.4.0/cc1plus[cc1plus:15783] uid/euid:0/0 gid/egid:0/0, parent /usr/x86_64-pc-linux-gnu/gcc-bin/5.4.0/x86_ 64-pc-linux-gnu-g++[x86_64-pc-linux:15782] uid/euid:0/0 gid/egid:0/0 Dec 8 14:55:23 guthondr-t520 kernel: grsec: denied resource overstep by requesting 4096 for RLIMIT_CORE against limit 0 for /usr/libexec/gcc/x86_64-pc-linux-gnu/5.4.0/cc1plus[cc1plus:15783] uid/euid:0/0 gid/egid:0/0, parent /usr/x86_64-pc -linux-gnu/gcc-bin/5.4.0/x86_64-pc-linux-gnu-g++[x86_64-pc-linux:15782] uid/euid:0/0 gid/egid:0/0
it's prob not just that flag. earlier in the log is: Generating precompiled header precompiled.hpp.gch so need to have icedtea disable all precompiled header usage.
Is there a workaround we can use? I am running into this compiling with gcc 4.9.4 as well as gcc 6.2.0.
(In reply to devsk from comment #22) > Is there a workaround we can use? I am running into this compiling with gcc > 4.9.4 as well as gcc 6.2.0. vapier is suggesting to try USE=-pch. Please let us know if that works.
(In reply to James Le Cuirot from comment #23) > (In reply to devsk from comment #22) > > Is there a workaround we can use? I am running into this compiling with gcc > > 4.9.4 as well as gcc 6.2.0. > > vapier is suggesting to try USE=-pch. Please let us know if that works. I have just successfully emerge dev-java/icedtea-3.2.0 with USE=-pch (default on my profile).
There is no such USE flag "pch" for dev-java/icedtea-7.2.6.8 which fails to compile for me, so I haven't tried.
Confirming: 3.2.0 builds fine with -pch with 6.2.0.
ok, i think we can be confident it's a problem with the icedtea ebuild. instead of USE=pch, i'd suggest using dynamic detection (see comment #17). that'll make it work on all kernels, not just hardened profiles. you could even make that change to the 3.2.0 ebuild.
Okay, I can disable this dynamically. There is no configure flag for 7 but I think it can still be done. This isn't making sense though. Precompiled headers were always used before. What's new is the ability to disable them. Why has this suddenly become a problem? I really want to ask upstream but he's been very quiet of late.
(In reply to James Le Cuirot from comment #28) i'm not sure what your relative points are. icedtea-3 had a USE=pch flag which has been masked in hardened profiles. icedtea-7 doesn't have that flag, so it'll always fail. it's probably a simple matter of a venn diagram: the population of users running a hardened kernel & building icedtea from source & reporting bugs when they fail in this case is probably low. using precompiled headers on hardened kernels is known to always fail because of how gcc implements it internally. it's not the fault of icedtea, although it would be nice if they could offer a configure flag again.
(In reply to SpanKY from comment #29) > (In reply to James Le Cuirot from comment #28) > > i'm not sure what your relative points are. icedtea-3 had a USE=pch flag > which has been masked in hardened profiles. icedtea-7 doesn't have that > flag, so it'll always fail. it's probably a simple matter of a venn > diagram: the population of users running a hardened kernel & building > icedtea from source & reporting bugs when they fail in this case is probably > low. I didn't realise the flag was already masked but that aside, I know for a fact that people have successfully built icedtea on hardened before. fordfrog, who is on the Java team, is one such example.
(In reply to James Le Cuirot from comment #30) keep in mind that running a hardened profile in the userland does not mean you're running a "hardened" kernel -- that means you've applied the grsec patchset and turned on the PaX features. you can do the latter w/out the former.
IcedTea 3.x's pch flag is a recent addition, and comes about because IcedTea 3.2.0 allowed pre-compiled headers to be disabled (http://bitly.com/it30200). All prior versions of IcedTea, including the entire 1.x and 2.x series, have always been built *with* pre-compiled headers. The feature is due to be added to the 2.x series in 2.7.0 (http://icedtea.classpath.org/bugzilla/show_bug.cgi?id=3180) but, if your gcc is really failing because of pre-compiled headers, then it would have done so for the last decade of IcedTea/OpenJDK. Thus, I find it hard to believe that's the only issue here. The java overlay has a 2.7.0 ebuild, though it's not currently up-to-date. Once updated, this could be tried to see if disabling pch works with 2.x as well.
Incidentally, I ran a hardened kernel with PaX for years, building IcedTea/OpenJDK daily, with pch. So, again, I doubt that's the only cause.
(In reply to Andrew John Hughes from comment #32) it is a well known problem that gcc running under hardened kernels (i.e. PaX stuff turned on) cannot support PaX. if it worked for you, then you just got lucky, or you didn't enable all the kernel config options that other people are. see bug 301299 for details as to why PCH support fundamentally cannot work.
Guys, there's no need to get hung up on the whys and wherefores, we can simply say that PaX breaks pch at least some of the time. I'll keep the pch flag but make it ineffective when host-is-pax returns true. This can go into 3 now and 7.2 later.
(In reply to James Le Cuirot from comment #35) > I'll keep the pch > flag but make it ineffective when host-is-pax returns true. This can go into > 3 now and 7.2 later. 3 is now done.
7.2 was dropped so closing this now.
