Bug 111400 - rpm 4.1 segfaults during package operation
rpm 4.1 segfaults during package operation
Status: CLOSED WORKSFORME
Product: Red Hat Linux
Classification: Retired
Component: rpm (Show other bugs)
8.0
i386 Linux
medium Severity high
: ---
: ---
Assigned To: Jeff Johnson
Mike McLean
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2003-12-02 22:10 EST by Jamie
Modified: 2007-04-18 12:59 EDT (History)
0 users

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2003-12-27 16:16:23 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)
Stack trace from segfault (845 bytes, text/plain)
2003-12-02 22:11 EST, Jamie
no flags Details
The new, different stack trace (755 bytes, text/plain)
2003-12-03 15:48 EST, Jamie
no flags Details

  None (edit)
Description Jamie 2003-12-02 22:10:03 EST
From Bugzilla Helper:
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.6a)
Gecko/20031002 Firebird/0.7+

Description of problem:
Due to flaw in the recent errata update for glibc, pthread debugging
info was stripped which made debugging threaded apps practically
impossible. I needed this for an assignment, so to rectify this I
installed the latest glibc 2.3.2 (release 101), which restored the
threading symbols.

I suspect this procedure has somewhat neutered rpm though, as it now
segfaults whenever I try to modify my packages (install, up/downgrade,
or erase). Due to this, I cannot regress my glibc version nor upgrade
rpm itself to a newer version.

I did a backtrace of the segfault in gdb, which I have attached.

It seems the call to getpwnam is the exit point for rpm into the
library, I would guess the library was at fault, but I have no other
problems with it other than this one. I have looked at
http://bugzilla.redhat.com/bugzilla/long_list.cgi?buglist=89122 , but
I do not have compat listed in nsswitch.conf, so it should not apply.

Some research seems to indicate that rpm in RH8 is staically linked to
libnss, and the change in the binary interface of glibc between 3.2.1
and 2.3.2 is the root cause.... (
http://www.mail-archive.com/debian-glibc@lists.debian.org/msg04763.html ).

If this is the case then surely a change in the rpm package's
requirements is needed to stop this occurring to other systems.
Anything else can be regressed, but not rpm if it stops working. :(

Any solutions will be welcome. :)

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

How reproducible:
Always

Steps to Reproduce:
On my system at least, 
1. Install glibc 2.3.2
2. Attempt to modify your installed packages, eg.
rpm -e postgresql-server



Actual Results:  rpm segfaults

Expected Results:  rpm should have performed the operation without
segfaulting

...or at least the requirements of rpm should prevent the installation
of newer versions of glibc if they are incompatible

Additional info:

I have attemped the generic fix of rebuilding my database, which
succeeds fine, but does not rectify the situation.

Versions:
glibc version is glibc-2.3.2-101.i386.rpm
rpm version is rpm-4.1-1.06.i386.rpm
openssl version is openssl-0.9.6b-35.8.i386.rpm
Comment 1 Jamie 2003-12-02 22:11:51 EST
Created attachment 96303 [details]
Stack trace from segfault
Comment 2 Jeff Johnson 2003-12-03 09:13:52 EST
This smells like the LDAP problem that causes statically
linked binaries to segfault if/when LDAP passwords are
used but nscd is not running.

Are you using LDAP p[asswords?

Try starting nscd (as root)
    service nscd restart

Verify running, repeat the failing rpm command.
Comment 3 Jamie 2003-12-03 15:47:16 EST
I'm not currently using LDAP, but I figured I'd try starting the
service you reommended anyway. Suffice to say, it still segfaults, but
I get a different stack trace now.
Comment 4 Jamie 2003-12-03 15:48:17 EST
Created attachment 96320 [details]
The new, different stack trace
Comment 5 Jamie 2003-12-05 04:32:17 EST
Ok, now the update server load has reached levels so that my demo
account can update from them, it seems up2date still works fine. Which
is a small, but welcome bit of help.

I take it up2date uses rpm to do its dirty work?
Comment 6 Jeff Johnson 2003-12-05 09:01:10 EST
Hmmm, you may have mixed new fangled TLS encumbered
modules with statically linked non-TLS rpm. That's my
best guess looking at the stack strace, statically linked
/bin/rpm is very tricky with thread local storage.

Try rpm -V glibc glibc-common to insure no crud.

You might try upgrading (use rpm2cpio if necessary) to
rpm-4.2, or rpm-4.1.1, from ftp.rpm.org:/pub/rpm/dist.

Use rpm-4.2 if you have upgraded to RHL 9 glibc, rpm-4.1.1
if RHL 8.0 glibc.

up2date uses rpm-python which is linked to rpm libraries, yes.
Comment 7 Jamie 2003-12-05 20:40:28 EST
*sigh* Homer just do something stupid.

I followed your instructions, but I figured I'd try rpm 4.1 just in
case, but even after rpm2cpio'ing it, it still segfaulted, and both
stack traces were identical to the orignal traces. So I tried rpm2cpio
on rpm 4.2

Oh dear, I didn't know how to back up everything that'd be changed so
I just went for broke and I just extracted over the top, and...no
segfault this time, but I now get told I'm missing libelf.so.1

*sigh*

I remembered this was one of the dependecies which is why I couldn't
upgrade rpm earlier, as I couldn't get hold of all of the rpms
required to update openSSL and all of the software that depended on
the existing version, libelf being amoung them, I think.

But of course, rpm2cpio and the rpm libraries have now has been
updated....and all require libelf.so.1, which I don't have, which I
can't install from rpm, and now can't extract from a rpm. 

I'm pretty good at screwing myself up, aren't I?

I found a perl script that claims to be able to have the functionality
of rpm2cpio, but it insists all my rpm .rpm's have invalid headers.
Which isn't true, as file says it is a V3, which is the version
supported by the script
(http://www.linuxmafia.com/pub/linux/utilities-general/rpm2cpio,
should you be interested)

I'm gonna keep looking for an alternative to rpm2cpio so I can get the
old rpm functionality back as I suspect adding the libelf.so.1 file
will probably break yet more things, as seems about par for the course
for me

BTW, thanks for your assistance on this, it's much appreciated.
Comment 8 Jeff Johnson 2003-12-06 14:31:36 EST
There's a shell script version of rpm2cpio, look for
/usr/lib/rpm/rpm2cpio.sh.

Using that (with some patience) should be able to fix anything
but /var/lib/rpm/Packages (so make sure that is backed up).
Everything else is fixable. Packages restorable, too, but reinstall is
often most expedient.
Comment 9 Jeffrey Stuckman 2003-12-08 10:16:05 EST
I just resolved this problem with rpm2cpio. The problem is that rpm-
4.1-1.06 works with glibc-2.2.93-5 but not glibc-2.3.2-11.9. I had to 
install rpm-4.2-0.69. First, I used rpm2cpio to carefully install all 
dependecies of the new rpm. Once they were installed, I used rpm2cpio 
to install rpm (unCPIOing to a temp directory and using cp -b so I 
had backups in case the manual install hosed my system.) Then, rpm 
started working, and I was able to tell rpm to "install" all the 
packages I just cpio'd to update the rpm database.

Adding libelf.so.1 didn't cause conflicts of any kind for me (it 
seems to co-exist with the older libelf), but I understand why you 
would be suspicious (given that upgrading another package 
(glibc) "breaks" rpm without warning the user first...)

Thanks to everyone for helping me get this resolved...

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