broken configuration test with fortify source

seen on amd64

breaks the gawk build on amd64

I can't seem to reproduce this in current Maverick; gawk builds fine.

still reproducible for me on maverick, note that on Debian/sid, it does work:

gcc-4.4 -g -O2 -fstack-protector -D_FORTIFY_SOURCE -Wall conftest.c && ./a.out

the test succeeds with gcc-4.4 in maverick built without the Linaro patchset.

Confirmed in ronne's maverick amd64 chroot. Attached conftest.c and preprocessed source. strace shows:

...
setrlimit(RLIMIT_STACK, {rlim_cur=1024*1024, rlim_max=1024*1024}) = 0
sigaltstack({ss_sp=0x7fffd7df0130, ss_flags=0, ss_size=8192}, NULL) = 0
rt_sigaction(SIGSEGV, {0x4008d0, [], SA_RESTORER|SA_STACK, 0x7f6373fe0c20}, NULL, 8) = 0
rt_sigaction(SIGBUS, {0x4008d0, [], SA_RESTORER|SA_STACK, 0x7f6373fe0c20}, NULL, 8) = 0
rt_sigprocmask(SIG_BLOCK, [], [], 8) = 0
--- SIGSEGV (Segmentation fault) @ 0 (0) ---
rt_sigprocmask(SIG_SETMASK, [], NULL, 8) = 0
sigaltstack(NULL, {ss_sp=0x7fffd7df0130, ss_flags=SS_ONSTACK, ss_size=8192}) = 0
--- SIGSEGV (Segmentation fault) @ 0 (0) ---
rt_sigprocmask(SIG_SETMASK, [], NULL, 8) = 0
sigaltstack(NULL, {ss_sp=0x7fffd7df0130, ss_flags=SS_ONSTACK, ss_size=8192}) = 0
[repeats]

It seems to go into the same infinite loop under strace both with -O2 and -O1, although -O1 exits normally and immediately without strace.

I went through all the optimisations that are in -O2 but not -O1 (-falign-functions -falign-jumps -falign-labels -fcaller-saves -fcrossjumping -fcse-follow-jumps -fdelete-null-pointer-checks -fexpensive-optimizations -fforward-propagate -fgcse -finline-small-functions -fipa-cp -foptimize-register-move -foptimize-sibling-calls -fpeephole2 -fregmove -freorder-blocks -freorder-functions -frerun-cse-after-loop -fschedule-insns2 -fstrict-aliasing -fthread-jumps -ftree-builtin-call-dce -ftree-pre -ftree-switch-conversion -ftree-vrp). Not a single one of them produces this effect reliably, but the bulk of them produce it sometimes.

The fault occurs as the 'pass' value given to longjmp() gets corrupted before use by setjmp(), causing the 'setjmp() < 2' test to fail and the system to loop forever. The only assembler level fortify/non-fortify difference is a call to longjmp_chk instead of longjmp.

Note that shifting 'mystack' off the stack and into static memory also works around the problem.

(Tested using gcc 4.4.4-9ubuntu1)

eglibc-2.11.1/sysdeps/unix/sysv/linux/x86_64/____longjmp_chk.S is broken. It saves the value of 'pass' in ecx for later use but ecx is trashed by a syscall.

The syscall is used to bring in the signal stack so that the fortify code can print an error message if needed. The problem goes away with -U_FORTIFY_SOURCE as no such syscall is used.

FWIW, this is broken on Lucid too. I've attached a slightly more minimal testcase that disables stack randomization and adds an alarm call to make the loop more obvious.

Oh, and it fails for me with gcc-4.3 and gcc-4.5 as well. I think the differences in failure modes was due to stack randomization somehow.

http://sourceware.org/git/?p=glibc.git;a=commitdiff;h=c044aa75354b48d4b7aaffe465706282192e54c2

fixed in maverick, and gawk built

lucid has seen the end of its life and is no longer receiving any updates. Marking the lucid task for this ticket as "Won't Fix".