Red Hat Bugzilla – Bug 155790
32-bit apps crash on start up, but not if started by gdb
Last modified: 2007-11-30 17:11:04 EST
From Bugzilla Helper: User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.7.7) Gecko/20050416 Fedora/1.0.3-2 Firefox/1.0.3 Description of problem: Many (all?) 32-bit programs crash shortly after they start running on today's rawhide kernel. Going back to 2.6.11-1.1253_FC4, they work fine again. I couldn't figure out exactly what's wrong with them, because, if I start them from within GDB, they work fine. strace reports only two syscalls: execve and brk(0), that returns a reasonable value and is followed by a segmentation fault. Examples of programs that crash at start up are an ancient 32-bit build of gtimer I have, dag's openvpn and the glibc.i686's /usr/sbin/glibc_post_upgrade.i686, that crashed when I tried rpm -Uv --replacepkgs glibc-2.3.5-1.i686.rpm. It was not related with prelinking, since I tried to prelink -u all of the relevant binaries, and it didn't make any difference within kernel 1258. Going back to 1253, everything was functional again. Version-Release number of selected component (if applicable): kernel-2.6.11-1.1258_FC4 How reproducible: Always Steps to Reproduce: 1.Boot into 1258_FC4 for x86_64 2.Run 32-bit programs such as /usr/sbin/glibc_post_ugprade.i686 3.Boot inot 1253_FC4 4.Ditto Actual Results: The former crashes, the latter works Expected Results: Both should work Additional info:
I think that exec-shield is conflicting with the recent changes to the 32-bit VDSO in -rc3. This problem does not occur in vanilla 2.6.13-rc3. Apr 23 14:25:46 citadel kernel: wine[10626]: segfault at 00000000ffffe01c rip 000000004dffa575 rsp 00000000ffffd38c error 4
Well, work around it with sysctl -w kernel.vsyscall32=0 for the moment.
The catch for a workaround in comment #2 is that at least for 2.6.11-1.1261_FC4 'sysctl -w kernel.vsyscall32=0' comes back with "unknown key". There is 'kernel.vsyscall64' but this is not that (which is not a surprise).
In fact it's abi.vsyscall32 that's the one I meant.
*** Bug 156166 has been marked as a duplicate of this bug. ***
We have a fix for this (it was exec-shield changes running afoul of recent upstream changes to the vdso stuff for 32-bit). The next kernel build will have the fix.
kernel-2.6.11-1.1276_FC4 fixes it for me.