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 81834

Summary: rpm segfaults when installing libpng-1.2.2-8.i386.rpm
Product: [Retired] Red Hat Linux Reporter: a.e.lawrence
Component: rpmAssignee: Jeff Johnson <jbj>
Status: CLOSED WORKSFORME QA Contact: Mike McLean <mikem>
Severity: medium Docs Contact:
Priority: medium    
Version: 8.0   
Target Milestone: ---   
Target Release: ---   
Hardware: i386   
OS: Linux   
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2003-01-14 20:46:16 UTC Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Description Flags
The rpm file that exposed the bug. none

Description a.e.lawrence 2003-01-14 15:47:07 UTC
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 15:49:49 UTC
rpm version 4.1

Comment 2 a.e.lawrence 2003-01-14 15:53:23 UTC
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 20:46:16 UTC
    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 09:27:12 UTC
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 10:08:30 UTC
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.