Bug 145193 - ia32 gdb blows up the kernel
ia32 gdb blows up the kernel
Status: CLOSED CANTFIX
Product: Fedora
Classification: Fedora
Component: kernel (Show other bugs)
3
x86_64 Linux
medium Severity medium
: ---
: ---
Assigned To: Dave Jones
Brian Brock
:
Depends On:
Blocks: 116894
  Show dependency treegraph
 
Reported: 2005-01-14 22:53 EST by Bill Nottingham
Modified: 2015-01-04 17:15 EST (History)
6 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2005-10-02 21:21:06 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:


Attachments (Terms of Use)
the oops (1.96 KB, text/plain)
2005-01-14 22:53 EST, Bill Nottingham
no flags Details
the fix (1.09 KB, patch)
2005-01-15 23:04 EST, Roland McGrath
no flags Details | Diff

  None (edit)
Description Bill Nottingham 2005-01-14 22:53:29 EST
Description of problem:

SSIA

Version-Release number of selected component (if applicable):

2.6.10-1.741_FC3

How reproducible:

Dunno. I can try again.

Steps to Reproduce:
1. Install 32-bit chroot.
2. chroot
3. Attempt to install a kernel rpm
4. Watch rpm segfault
# rpm -i kernel-2.6.10-1.737_FC3.i686.rpm --force
Segmentation fault
5. Attempt to debug rpm
# gdb /usr/lib/rpm/rpmi
<gdb> set args -i kernel-2.6.10-1.737_FC3.i686.rpm --force
<gdb> run

Actual results:

Kaboom.

Expected results:

Not that.
Comment 1 Bill Nottingham 2005-01-14 22:53:58 EST
Created attachment 109807 [details]
the oops
Comment 2 Bill Nottingham 2005-01-14 22:57:56 EST
FWIW:
a) I was root
b) strace doesn't oops
Comment 3 Bill Nottingham 2005-01-14 23:08:57 EST
It's reproducible with any 32-bit process, it appears.
Comment 4 Roland McGrath 2005-01-15 18:52:11 EST
Please supply a trivial recipe for "reproduce with any 32-bit process".
I didn't have any luck making it crash.  (I'm testing the 1.741_FC3.x86_64
kernel, but on otherwise RHEL4 userland since that's the install I have handy.
Also, this is EM64T rather than AMD64.)
Comment 5 Roland McGrath 2005-01-15 20:36:22 EST
Ok, I think I have a clue.  It's not any 32-bit process, but any 32-bit process
that hasn't previously used the vsyscall page (e.g. by making a syscall).
So probably you can only see it on a statically linked app, since those don't
use the vsyscall mechanism for syscalls.  The lazy mapping done in get_gate_vma
(__map_syscall32) seems like it should make the pte happy, but it appears not to.
However, the normal fault path (i.e. the process itself doing a normal read from
0xffffe000) does make it happy so that access_process_vm works thereafter.
Comment 6 Roland McGrath 2005-01-15 21:24:14 EST
Vanilla 2.6.10 on x86-64 does have the same bug.
Comment 8 Roland McGrath 2005-01-15 23:04:49 EST
Created attachment 109836 [details]
the fix

What a maroon.
Comment 9 Elena Zannoni 2005-02-17 10:29:35 EST
Has this been committed to the kernel?
Comment 10 Dave Jones 2005-07-15 15:17:11 EDT
An update has been released for Fedora Core 3 (kernel-2.6.12-1.1372_FC3) which
may contain a fix for your problem.   Please update to this new kernel, and
report whether or not it fixes your problem.

If you have updated to Fedora Core 4 since this bug was opened, and the problem
still occurs with the latest updates for that release, please change the version
field of this bug to 'fc4'.

Thank you.
Comment 11 Dave Jones 2005-10-02 21:21:06 EDT
This bug has been automatically closed as part of a mass update.
It had been in NEEDINFO state since July 2005.
If this bug still exists in current errata kernels, please reopen this bug.

There are a large number of inactive bugs in the database, and this is the only
way to purge them.

Thank you.

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