Bug 19692 - rpm2cpio 4.0 dumps core on Solaris 2.8
Summary: rpm2cpio 4.0 dumps core on Solaris 2.8
Keywords:
Status: CLOSED WORKSFORME
Alias: None
Product: Red Hat Linux
Classification: Retired
Component: rpm
Version: 6.2
Hardware: sparc
OS: Linux
medium
medium
Target Milestone: ---
Assignee: Jeff Johnson
QA Contact: David Lawrence
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2000-10-24 15:44 UTC by luc.maisonobe
Modified: 2007-04-18 16:29 UTC (History)
0 users

Fixed In Version:
Clone Of:
Environment:
Last Closed: 2000-11-10 08:56:16 UTC
Embargoed:


Attachments (Terms of Use)

Description luc.maisonobe 2000-10-24 15:44:39 UTC
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
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 ()
(gdb) 

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 08:56:13 UTC
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
statement
   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));
    	exit(EXIT_FAILURE);
    }

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
                                                                                     
Luc

Comment 2 Jeff Johnson 2000-12-30 19:36:57 UTC
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));
        exit(EXIT_FAILURE);
    }

Please reopen if I'm misremembering.


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