Bug 81834 - rpm segfaults when installing libpng-1.2.2-8.i386.rpm
Summary: rpm segfaults when installing libpng-1.2.2-8.i386.rpm
Status: CLOSED WORKSFORME
Alias: None
Product: Red Hat Linux
Classification: Retired
Component: rpm (Show other bugs)
(Show other bugs)
Version: 8.0
Hardware: i386 Linux
medium
medium
Target Milestone: ---
Assignee: Jeff Johnson
QA Contact: Mike McLean
URL:
Whiteboard:
Keywords:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2003-01-14 15:47 UTC by a.e.lawrence
Modified: 2007-04-18 16:49 UTC (History)
0 users

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: ---


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

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:
Always

Steps to Reproduce:
1.See above
2.
3.
    

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
mirror.

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
Run
    rpm -Kvv libpng-1.2.2-8.i386.rpm
to convince yourself that package is OK.

Run
    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.


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