Bug 81834 - rpm segfaults when installing libpng-1.2.2-8.i386.rpm
rpm segfaults when installing libpng-1.2.2-8.i386.rpm
Product: Red Hat Linux
Classification: Retired
Component: rpm (Show other bugs)
i386 Linux
medium Severity medium
: ---
: ---
Assigned To: Jeff Johnson
Mike McLean
Depends On:
  Show dependency treegraph
Reported: 2003-01-14 10:47 EST by a.e.lawrence
Modified: 2007-04-18 12:49 EDT (History)
0 users

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

Attachments (Terms of Use)
The rpm file that exposed the bug. (150.46 KB, application/octet-stream)
2003-01-14 10:53 EST, a.e.lawrence
no flags Details

  None (edit)
Description a.e.lawrence 2003-01-14 10:47:07 EST
From Bugzilla Helper:
User-Agent: Mozilla/5.0 Galeon/1.2.6 (X11; Linux i686; U;) Gecko/20020830

Description of problem:
# rpm -Fhv libpng-1.2.2-8.i386.rpm
Segmentation fault

And an strace shows:-
getuid32()                              = 0
getgid32()                              = 0
stat64("/", {st_mode=S_IFDIR|0755, st_size=4096, ...}) = 0
stat64("/var/", {st_mode=S_IFDIR|0755, st_size=4096, ...}) = 0
stat64("/var/lib/", {st_mode=S_IFDIR|0755, st_size=4096, ...}) = 0
stat64("/var/lib/rpm", {st_mode=S_IFDIR|0755, st_size=4096, ...}) = 0
access("/var/lib/rpm", W_OK)            = 0
access("/var/lib/rpm/__db.001", F_OK)   = 0
access("/var/lib/rpm/Requirename", F_OK) = 0
open("/var/lib/rpm/Requirename", O_RDONLY|O_LARGEFILE) = 8
fcntl64(8, F_SETFD, FD_CLOEXEC)         = 0
fstat64(8, {st_mode=S_IFREG|0644, st_size=237568, ...}) = 0
_llseek(8, 0, [0], SEEK_SET)            = 0
read(8, "\0\0\0\0\1\0\0\0\0\0\0\0a\25\6\0\7\0\0\0\0\20\0\0\0\10"..., 256) = 256
close(8)                                = 0
open("/var/lib/rpm/Requirename", O_RDONLY|O_LARGEFILE) = 8
fcntl64(8, F_SETFD, FD_CLOEXEC)         = 0
fstat64(8, {st_mode=S_IFREG|0644, st_size=237568, ...}) = 0
brk(0x82a9000)                          = 0x82a9000
--- SIGSEGV (Segmentation fault) ---
+++ killed by SIGSEGV +++

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

How reproducible:

Steps to Reproduce:
1.See above

Additional info:

As it happens I have just expanded the memory on this machine and did more than
1 hour soak test using memtest3.0 before accepting it. So hardware failure is
most unlikely.

And the same bug was experienced *before* expanding memory. Machine in intensive
use for > 1 year without problems, so hardware fault extremely unlikely.

Will attach libpng-1.2.2-8.i386.rpm for check, but it is taken from an update

rpm thereafter hangs and requires SIGKILL as reported in other bugs.
Comment 1 a.e.lawrence 2003-01-14 10:49:49 EST
rpm version 4.1
Comment 2 a.e.lawrence 2003-01-14 10:53:23 EST
Created attachment 89353 [details]
The rpm file that exposed the bug.

I haven't verified or checksummed. But even a trojan shouldn't be able to
segfault rpm?
Comment 3 Jeff Johnson 2003-01-14 15:46:16 EST
    rpm -Kvv libpng-1.2.2-8.i386.rpm
to convince yourself that package is OK.

    rpm --rebuilddb -vv
to eliminate (my guess) the segfault.

Reopen this bug if I've guessed incorrectly.
Comment 4 a.e.lawrence 2003-01-15 04:27:12 EST
The package signature was ok. Rebuilding data base cleared problem. Thought that
I had done that, but presumably not :-(

So guess correct. Bug stays closed. Thanks.
Comment 5 a.e.lawrence 2003-01-15 05:08:30 EST
What I didn't say in the original report was that this problem arose while
executing the bash loop:

for f in *.rpm; do rpm -Fhv $f; done

and that several packages in that loop were upgraded successfully. So rpm
corrupted its own database.  The current directory there was a mirror of the
i386 updates site.

So this bug is really, it seems, that rpm corrupts the database. I have not kept
a record of the immediately preceeding successfully updated package. It may have
been the kernel. Perhaps there are precise intstallation timestamps that would
allow me to discover that. But with so little information available, it does not
seem worth reopening this bug.

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