Bug 102986 - up2date sometimes segfaults when installing gdm errata
up2date sometimes segfaults when installing gdm errata
Status: CLOSED RAWHIDE
Product: Red Hat Linux
Classification: Retired
Component: rpm (Show other bugs)
9
i686 Linux
medium Severity medium
: ---
: ---
Assigned To: Jeff Johnson
Mike McLean
: Security
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2003-08-24 05:17 EDT by Barry K. Nathan
Modified: 2007-04-18 12:57 EDT (History)
2 users (show)

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


Attachments (Terms of Use)
explode2date shell script (127 bytes, text/plain)
2003-08-24 05:17 EDT, Barry K. Nathan
no flags Details

  None (edit)
Description Barry K. Nathan 2003-08-24 05:17:06 EDT
From Bugzilla Helper:
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.4) Gecko/20030630

Description of problem:
I don't know whether this bug is really in up2date, or if it's in gdm, or in
RPM, or something else altogether. up2date is my best guess for now.

When installing the new gdm errata package for Red Hat 9, sometimes up2date will
segfault after downloading the package. If rollbacks are enabled, the segfault
happens before the old version of gdm is repackaged.

The segfaults magically disappear when GPG checking is disabled in
/etc/sysconfig/rhn/up2date.

In the real world I've seen this only when installing the Red Hat 9 GDM errata
onto Red Hat 9 boxes. I haven't tried pushing Red Hat 7.x or 8 boxes to see if I
can make them fail like this, however. I also have not seen this happen with any
other packages.

Version-Release number of selected component (if applicable):
up2date-3.1.23.1-5 (maybe up2date-3.1.23-1 as well)

How reproducible:
Sometimes (although I will be attaching a shell script that makes the bug easy
if not trivial to reproduce)

Steps to Reproduce:
1. Install Red Hat 9 on machine. 
2. Register it with RHN (or a Current server).
3. (Optional?) Install all of the errata packages (except gdm).
4. (Optional?) Install RPM 4.2-1 from ftp.rpm.org.

Method 1:
5. Run "up2date gdm" as root.
6. If that failed to blow up, use "rpm -Uvh --oldpackage" to reinstall the old
gdm package, and repeat step 5.
7. If it still hasn't blown up, repeat step 6 several (up to 20?) more times.

Method 2:
5. Run the "explode2date" shell script which I will be attaching. (Keep a copy
of the gdm package, as shipped with Red Hat 9, in the current directory when you
run the script.)

Bonus Bug ;)
If you keep trying to run explode2date even after up2date's segfaulted once
already, rpm will get slower and slower. If you do this enough times, you may be
able to run "rpm -qa" and read all the package names in real time without using
a pager or scrollback, on a multi-GHz machine. At that point it may take up2date
half an hour per run, though, so you'll probably get sick of waiting for up2date
before you slow down rpm that much. Rebooting will restore things back to full
speed. AFAICT this effect, like the segfault, only happens when up2date's GPG
checking is enabled -- but I could be wrong. (I'll file a separate bug for this
if you want.)

Actual Results:  [root@crystal3 root]# ./explode2date

Fetching package list for channel: redhat-linux-i386-9...
########################################

Fetching Obsoletes list for channel: redhat-linux-i386-9...
########################################

Fetching rpm headers...
########################################

Testing package set / solving RPM inter-dependencies...
########################################
gdm-2.4.1.3-5.1.i386.rpm:   ########################## Done.
./explode2date: line 10:  1511 Segmentation fault      up2date gdm
1
[root@crystal3 root]#

Expected Results:  up2date shouldn't segfault. The script should keep upgrading
and downgrading gdm until RHN or your hardware dies. (To see what the expected
results look like, disable GPG checking in /etc/sysconfig/rhn/up2date and try
running the script again.)

Additional info:

I get the strange feeling that it takes more attempts for the explode2date
script to fail against my RHN account (4-10 tries) than against my own Current
1.4.4 server (1-4 tries). This could very well be some other variable in my
testing, however.

I've set the bug's severity to "Security" because, well, it prevented a security
update from being automatically applied on some of my boxes. If that's an
overreaction, feel free to reduce the Severity to "High".
Comment 1 Barry K. Nathan 2003-08-24 05:17:42 EDT
Created attachment 93886 [details]
explode2date shell script
Comment 2 Barry K. Nathan 2003-08-24 05:33:12 EDT
I forgot to mention, you'll probably want to set up2date to keep packages after
installing. That will cut down on time/bandwidth, but it appears to have no
effect either way on reproducibility.

FWIW, here's another "explode2date" run that's probably more typical than the
one I included in the original bug report:

[root@crystal3 root]# ./explode2date

Fetching package list for channel: redhat-linux-i386-9...
########################################

Fetching Obsoletes list for channel: redhat-linux-i386-9...
########################################

Fetching rpm headers...
########################################

Testing package set / solving RPM inter-dependencies...
########################################
gdm-2.4.1.3-5.1.i386.rpm:   ########################## Done.                   
Preparing              ########################################### [100%]

Installing...
Installing...
   1:gdm                    ########################################### [100%]
1
Preparing...                ########################################### [100%]
   1:gdm                    ########################################### [100%]

Fetching package list for channel: redhat-linux-i386-9...
########################################

Fetching Obsoletes list for channel: redhat-linux-i386-9...
########################################

Fetching rpm headers...
########################################

Testing package set / solving RPM inter-dependencies...
########################################
gdm-2.4.1.3-5.1.i386.rpm:   ########################## Done.
./explode2date: line 10:  1196 Segmentation fault      up2date gdm
2
[root@crystal3 root]# 
Comment 3 Adrian Likins 2003-08-28 14:20:59 EDT
trying to get jbj to take a look at this, since it's probabaly
an rpm issue
Comment 4 Barry K. Nathan 2003-12-31 09:07:03 EST
Idle speculation: Could this possibly be a manifestation of bug
107835? (In the next few days I'll see if I can test this hypothesis
at all.)
Comment 5 Barry K. Nathan 2004-01-01 00:34:24 EST
This doesn't completely answer the question of whether this bug is
related to bug 107835, but if I run rpm 4.2.1-0.30 (on Red Hat 9), I
cannot reproduce this bug at all. If I downgrade to either 4.2-1 or
4.2-0.69, I can reproduce this bug very easily.
Comment 6 Barry K. Nathan 2004-01-01 02:35:56 EST
Hmmm... RPM 4.2 plus the patch from bug 107835 also prevents me from
reproducing the bug...
Comment 7 Barry K. Nathan 2004-01-05 22:39:34 EST
One of my production machines, running Fedora Core 1 and
rpm-4.2.1-0.30, somehow got itself into a state where it seemed to be
reproducing this bug 100% of the time. rpm-4.2.1-0.30 definitely isn't
the fix.
Comment 8 Barry K. Nathan 2004-01-05 22:40:45 EST
To clarify my previous comment: I'm not trying to apply the RHL 9 gdm
errata to FC1 -- it's choking in the same way, but on other packages.
Comment 9 Jeff Johnson 2004-01-16 14:06:03 EST
Nope, rpm-4.2.1 not a fix if applying patch from #107835 "fixes".

rpm-4.2.2-0.6 (and later) appears to be the fix.

Thanks for verifying.

RAWHIDE, no clue if/when redhat desires to release an rpm errata.

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