When using a hardened gcc profile (or the new gcc 6.4.0), vserver-stat command segfaults: execve("/usr/sbin/vserver-stat", [...], [/* 40 vars */]) = 0 --- SIGSEGV {si_signo=SIGSEGV, si_code=SEGV_MAPERR, si_addr=0x28} --- +++ killed by SIGSEGV +++ Segmentation fault The only way to get a working vserver-stat binary is to build with the -hardenednossp profile. I tried adding -fno-stack-protector to the flags in a custom ebuild, but that was not enough. The only thing that differs between that custom ebuild and using the nossp profile is the GCC_SPECS, and I don't know about that so I cannot dig any deeper here. Reproducible: Always
Created attachment 510126 [details] build log resulting in working binary The only difference between the working binary and the segfaulting one is the GCC_SPECS being the hardenednossp. I'm still attaching the build.log for completeness' sake
Comment on attachment 510126 [details] build log resulting in working binary That's not very useful, is it?
(In reply to Romain Riviere from comment #0) > When using a hardened gcc profile (or the new gcc 6.4.0), vserver-stat > command segfaults: > > execve("/usr/sbin/vserver-stat", [...], [/* 40 vars */]) = 0 > --- SIGSEGV {si_signo=SIGSEGV, si_code=SEGV_MAPERR, si_addr=0x28} --- > +++ killed by SIGSEGV +++ > Segmentation fault Use sys-devel/gdb to produce a backtrace. > > The only way to get a working vserver-stat binary is to build with the > -hardenednossp profile. > I tried adding -fno-stack-protector to the flags in a custom ebuild, but > that was not enough. The only thing that differs between that custom ebuild > and using the nossp profile is the GCC_SPECS, and I don't know about that so > I cannot dig any deeper here. Nobody can dig any deeper unless you at the very least post your `emerge --info` output.
Created attachment 511978 [details] emerge --info with gcc 5.4.0 hardened
Created attachment 511980 [details] emerge --info with gcc 5.4.0 hardened nossp
Created attachment 511984 [details] backtace
(In reply to Jeroen Roovers from comment #2) > Comment on attachment 510126 [details] > build log resulting in working binary > > That's not very useful, is it? As I said above, it is the exact same build log for the broken binary, not much I could do about that. The requested info is attached above.
The problem comes from the __constructor__ attribute in the initHertz() and initPageSize() function declarations. I'm waiting for some feedback from upstream devs.
Package removed.
