Bug 104952 - RPM segfaults when trying to update to binutils from rawhide
RPM segfaults when trying to update to binutils from rawhide
Product: Red Hat Linux
Classification: Retired
Component: rpm (Show other bugs)
i386 Linux
medium Severity high
: ---
: ---
Assigned To: Paul Nasrat
Mike McLean
Depends On:
  Show dependency treegraph
Reported: 2003-09-23 16:26 EDT by Owen Marshall
Modified: 2007-04-18 12:57 EDT (History)
1 user (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2005-10-25 20:32:18 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)
strace of the rpm command (2.12 KB, text/plain)
2003-09-23 16:31 EDT, Owen Marshall
no flags Details

  None (edit)
Description Owen Marshall 2003-09-23 16:26:13 EDT
We are currently upgrading our RH7.2 machine, and I want to upgrade gcc to
version 3.3.1-5. To do this, I have to upgrade binutils to version

So, I do an rpm -Uvh binutils-*

And it dies. /every time/

This may be a result of me doing a funky upgrade, things out of sync, etc, but I
would hope RPM prevents me from _totally_ screwing my system up (but I know
there are still ways to make things fubar ;-))

1. rpm -Uvh binutils-*

Package versions:
rpm -q glibc
rpm -q rpm
rpm -q binutils
Comment 1 Owen Marshall 2003-09-23 16:31:03 EDT
Created attachment 94658 [details]
strace of the rpm command

This is the last couple lines from strace after the "Preparing..." and the hash
marks. If anyone wants to explain gdb I can get a backtrace ;)
Comment 2 Owen Marshall 2003-09-23 16:57:15 EDT
Hmmm, upgrading glibc fixes this. Shouldn't I get an error rather than a
segfault, though?

Or have I thoroughly hosed my system by using an install procedure like this:
7.2 glibc --> 7.3 glibc --> 8.0 glibc (etc etc)
Comment 3 Owen Marshall 2003-09-23 17:00:11 EDT
Dang it, I lied. Sorry for the spam :(
Comment 4 Jeff Johnson 2003-10-09 11:36:50 EDT
Presumably "lied" indicates the problem is fixed, otherwise reopen.
Comment 5 Owen Marshall 2003-11-06 17:20:53 EST
Sorry for all the garbage. I can confirm that this problem still exists.

# rpm -ih kernel-2.4.20-20.9.i686.rpm
warning: kernel-2.4.20-20.9.i686.rpm: V3 DSA signature: NOKEY, key ID
Segmentation fault

Any ideas? The strace looks the same - ending with this:
read(8, "\177ELF\1\1\1\0\0\0\0\0\0\0\0\0\3\0\3\0\1\0\0\0\200\n\0"...,
1024) = 1024
fstat64(8, {st_mode=S_IFREG|0755, st_size=89516, ...}) = 0
old_mmap(NULL, 76504, PROT_READ|PROT_EXEC, MAP_PRIVATE, 8, 0) = 0x4040c000
mprotect(0x4041e000, 2776, PROT_NONE)   = 0
old_mmap(0x4041e000, 4096, PROT_READ|PROT_WRITE,
MAP_PRIVATE|MAP_FIXED, 8, 0x11000) = 0x4041e000

The changes on ld-linux seem to fail...
Comment 6 Jeff Johnson 2003-12-27 16:00:28 EST
A --rebuilddb with rpm-4.1.1 for RHL 7.3 from
should fix.

Can you try upgrading and then doing --rebuilddb?
Comment 7 Owen Marshall 2003-12-30 13:57:58 EST
Attempted to upgrade, same problems.

With my current version (rpm-4.1-1.06), I ran --rebuilddb. This is
pretty hard on an active server ;-)

However, the same problem still exists. I cannot upgrade to the RPM
packages because RPM segfaults.
Comment 8 Jeff Johnson 2004-02-10 14:38:32 EST
Hmmm, this might be the dangling ptr problem from
    - fix: dangling pointer brain fart (#107835).

If the following "fixes", then this is likely #107835:
    rm -f /var/lib/rpm/Pubkeys
    rpm -Uvh binutils-*.rpm
Doing rpm --rebuilddb -vv will recreate the Pubkeys index.

If this is #107835, then rpm-4.2.2-0.8 and later have the fix.
Comment 9 Jeff Johnson 2004-02-10 14:42:26 EST
OTOH, the strace is not what I would expect from #107835.
Looks more like a glibc mis-install somehow, the segfault
occurs while loading rpm afaict.
Comment 10 Owen Marshall 2004-02-10 17:36:32 EST
Pulled the latest binutils from Fedora Project.

mv /var/lib/rpm/Pubkeys /var/lib/rpm/Pubkeys.old
rpm --rebuilddb -vv
rpm -Uvh binutils*

Still bombs out, same strace. If glibc was put in wrong, how should I
put it back in safely? I wonder if this goes back to my incremental
upgrade method...

Yikes ;-)
Comment 11 Jeff Johnson 2004-02-11 01:54:58 EST
You've upgraded to glibc from RHL 8.0?

Try the rpm-4.1.1 for 8.0 then.
Comment 12 Owen Marshall 2004-03-30 17:21:34 EST
OK, I tried this, same result. I have been trying to do the steps
listed here:

I get this error:
db_verify: Program version 3.2.9 doesn't match environment version 4.0.14

rpm -q db3

I can't upgrade to the 'transitions', because my versions are higher
than those.

So, what are my options here? Could I force a downgrade to RH7.2
glibc/gcc/RPM? ___Should I?___
Comment 13 Jeff Johnson 2004-03-30 20:42:19 EST
The msg will disappear if you do
    rm -f /var/lib/rpm/__db*

You can either upgrade or downgrade. That's up to you.

I'd suggest upgrading on general principles, not anything specific.

Which is it? Up or down?
Comment 14 Owen Marshall 2004-03-31 15:53:30 EST
OK, let me try to be gutsy and go up ;)

Best practice question:
Should I pull Fedora Core stuff -- eg RPM, glibc, gcc... then resolve
the dependency hell and go up? Or should I pick a lower target?

If it turns out that it is a glibc misinstall(per comment 9), will
pushing in the latest version resolve these problems?

I want to be __very__ careful here and not make things more FUBAR than
they are now, as a reinstall on this machine wouldn't be fun.

Any advice?
Comment 15 Jeff Johnson 2005-10-25 20:32:18 EDT
This problem is ancient historyt. Reopen if still a problem.

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