Note: This is a beta release of Red Hat Bugzilla 5.0. The data contained within is a snapshot of the live data so any changes you make will not be reflected in the production Bugzilla. Also email is disabled so feel free to test any aspect of the site that you want. File any problems you find or give feedback here.
Bug 155790 - 32-bit apps crash on start up, but not if started by gdb
Summary: 32-bit apps crash on start up, but not if started by gdb
Alias: None
Product: Fedora
Classification: Fedora
Component: kernel
Version: rawhide
Hardware: x86_64
OS: Linux
Target Milestone: ---
Assignee: Roland McGrath
QA Contact: Brian Brock
: 156166 (view as bug list)
Depends On:
Blocks: FC4Blocker
TreeView+ depends on / blocked
Reported: 2005-04-23 02:56 UTC by Alexandre Oliva
Modified: 2007-11-30 22:11 UTC (History)
8 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Last Closed: 2005-04-29 05:31:00 UTC

Attachments (Terms of Use)

Description Alexandre Oliva 2005-04-23 02:56:55 UTC
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):

How reproducible:

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

Actual Results:  The former crashes, the latter works

Expected Results:  Both should work

Additional info:

Comment 1 Brian Gerst 2005-04-23 20:57:38 UTC
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

Comment 2 Roland McGrath 2005-04-26 09:06:17 UTC
Well, work around it with sysctl -w kernel.vsyscall32=0 for the moment.

Comment 3 Michal Jaegermann 2005-04-27 15:32:28 UTC
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).

Comment 4 Roland McGrath 2005-04-28 20:04:05 UTC
In fact it's abi.vsyscall32 that's the one I meant.

Comment 5 Dave Jones 2005-04-29 00:59:15 UTC
*** Bug 156166 has been marked as a duplicate of this bug. ***

Comment 6 Roland McGrath 2005-04-29 05:31:00 UTC
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.

Comment 7 Brian Gerst 2005-04-29 17:00:11 UTC
kernel-2.6.11-1.1276_FC4 fixes it for me.

Note You need to log in before you can comment on or make changes to this bug.