Bugzilla will be upgraded to version 5.0 on a still to be determined date in the near future. The original upgrade date has been delayed.
Bug 19692 - rpm2cpio 4.0 dumps core on Solaris 2.8
rpm2cpio 4.0 dumps core on Solaris 2.8
Product: Red Hat Linux
Classification: Retired
Component: rpm (Show other bugs)
sparc Linux
medium Severity medium
: ---
: ---
Assigned To: Jeff Johnson
David Lawrence
Depends On:
  Show dependency treegraph
Reported: 2000-10-24 11:44 EDT by luc.maisonobe
Modified: 2007-04-18 12:29 EDT (History)
0 users

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2000-11-10 03:56: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)

  None (edit)
Description luc.maisonobe 2000-10-24 11:44:39 EDT
I have compiled rpm 4.0 on a sparc station running Solaris 2.8 (btw, I have
added the proper
os_compat line in the rpmrc file to declare solaris 2.8).

The rpm command seems to run (I have not tested it fully), but the rpm2cpio
command dumps core with the following message :

   cannot re-open payload: Segmentation Fault(coredump)

The trace stack from the core file is :

(gdb) bt
#0  0xff0b29ec in strlen () from /usr/lib/libc.so.1
#1  0xff1012c0 in _doprnt () from /usr/lib/libc.so.1
#2  0xff102d68 in fprintf () from /usr/lib/libc.so.1
#3  0x18d20 in main ()

If I use rpm -qip on the same rpm file, I get the right informations, so
the file by itself seems to be OK.
Comment 1 luc.maisonobe 2000-11-10 03:56:13 EST
2000-11-10 08:30:00 MET

I have checked older versions of rpm. The problem seem to have been introduced
between versions
3.0.3 and 3.0.4 of the distribution.

Further investigation showed me that in the gzdFdopen function of rpmio.c, the
   fdSetFdno(fd, -1);
stores -1 in the structure pointed to by the fdi variable of the main function,
the file descriptor which
was 4 before this is later pushed on the following element of the fps table.
However, there is a test later on in main :
  if (gzdi == NULL || Ferror(gzdi)) {
   fprintf(stderr, _("cannot re-open payload: %s\n"), Fstrerror(gzdi));

The Ferror (gzdi) tests both the element where fd = 4 and the previous ones
where fd = -1. This
triggers the error handling.  The Fstrerror function then returns the errcookie
pointer, which is NULL
since its creation by XfdNew. This leads to a segmentation violation in the
fprintf call.

I think there are two separate problems:
  - an inconsistency between the resetting of the fd to -1 which seems to means
this entry is not
    valid anymore and the the Ferror test which fails when it detects this -1

  - an initialization problem of the errcookie pointer to NULL.

hope this helps
Comment 2 Jeff Johnson 2000-12-30 14:36:57 EST
I believe this is now fixed in rpm CVS. The "fix" I am remembering is in
rpm2cpio.c to
change the check for the return code to

    gzdi = Fdopen(fdi, rpmio_flags);    /* XXX gzdi == fdi */
    if (gzdi == NULL) {
        fprintf(stderr, _("cannot re-open payload: %s\n"), Fstrerror(gzdi));

Please reopen if I'm misremembering.

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