Bug 56989 - up2date crashes due to sementation fault
up2date crashes due to sementation fault
Status: CLOSED CURRENTRELEASE
Product: Red Hat Linux
Classification: Retired
Component: up2date (Show other bugs)
7.2
i686 Linux
medium Severity medium
: ---
: ---
Assigned To: Adrian Likins
Jay Turner
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2001-12-02 03:28 EST by markoj
Modified: 2015-01-07 18:53 EST (History)
4 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2003-05-21 14:24:44 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)
Output from BugBuddy (6.13 KB, text/plain)
2001-12-05 17:01 EST, markoj
no flags Details
up2date crash output from bugbuddy (6.66 KB, text/plain)
2001-12-05 21:00 EST, dsbrown
no flags Details
The one file found in /var/spool/up2date (389.39 KB, text/plain)
2002-01-05 16:46 EST, markoj
no flags Details
hdr files from spool dir when segfault was happening (394.36 KB, application/octet-stream)
2002-02-08 10:23 EST, Steve Conklin
no flags Details

  None (edit)
Description markoj 2001-12-02 03:28:48 EST
From Bugzilla Helper:
User-Agent: Mozilla/4.78 [en] (X11; U; Linux 2.4.9-13smp i686)

Description of problem:
up2date keeps crashing after I click on the "Next" button on the "Channels"
screen.  A small message box titled "Update Agent Progress" appears, and
immediately after that another window opens with the message that the
application "/usr/bin/python" has crashed due to a fatal error
(segmentation fault).  Below the message is a link to GNOME Application
Crash page.  

This started happening about two weeks ago.  Before that, up2date worked
without any problems.

Version-Release number of selected component (if applicable): 2.7.2


How reproducible:
Always

Steps to Reproduce:
1. Run up2date.
2. Click Next on the Welcome window.
3. Click Next on the Channel window.
	

Actual Results:  The application crashes and returns 1.

Expected Results:  Shouldn't have crashed?

Additional info:
Comment 1 Adrian Likins 2001-12-03 11:33:14 EST
Hmm, segfault eh?

Typically, if up2date segfaults, it's one of the underlying libraries
that one of the python modules is linked to that is crashing (for
example, rpm, openssl, etc).


Have you installed different versions of rpm, gtk+, openssl, or popt?

If you follow the crash wizard, could you save a copy of the stacktrace
to a file and attach it to this report?
Comment 2 markoj 2001-12-05 17:01:27 EST
Created attachment 39787 [details]
Output from BugBuddy
Comment 3 markoj 2001-12-05 17:05:18 EST
I attached output of the GNOME Bug Buddy.  While doing that I noticed output on
stderr that I missed before (sorry):

petunia 334 ~ > up2date
/root/19503: No such file or directory.
172     wrapsyscall.c: No such file or directory.
97      signals.c: No such file or directory.

Python binary doesn't seem to know how to find something.

To answer your question about any updates I might have applied, this is a fresh
7.2 install with all updated coming from up2date and nowhere else.

I hope this helps.
Comment 4 dsbrown 2001-12-05 21:00:03 EST
Created attachment 39808 [details]
up2date crash output from bugbuddy
Comment 5 dsbrown 2001-12-05 21:00:43 EST
I have same problem with a fresh install of rh7.2 I get a segfault during 
"Getting headers for available packages" at 49%.  After I manually installed 
the new up2date rpm packages, it segfaults at 11%.  Attached output from 
bugbuddy.

Comment 6 Need Real Name 2001-12-28 01:05:55 EST
I am having the exact same problem as dsbrown@speakeasy.org. I updated up2date,
up2date-gnome, rhn_register, rhn_register-gnome, and python-xmlrpc since these
were listed in the up2date errata on my RHN page. I was unable to locate the
python-popt package that was also listed, but after running up2date -p the
up2date errata was no longer listed in the updates that my machine needed on
RHN. However it still segfaults just after "Getting headers for available
packages". I am working entirely from the console, without X installed.
Comment 7 Mihai Ibanescu 2001-12-28 15:49:30 EST
linuxnut@earthlink.net, could you please try the following:

mkdir /tmp/up2datespool
mv /var/spool/up2date/*hdr /tmp/up2datespool

and run up2date again? This should clear the cached headers spool and you 
should be fine.

If it does work, would you be so kind and send us the .hdr files?
Comment 8 markoj 2002-01-05 16:46:11 EST
Created attachment 41872 [details]
The one file found in /var/spool/up2date
Comment 9 markoj 2002-01-05 16:47:59 EST
There were no .hdr files in /var/spool/up2date on this machine.  I uploaded for
you the only file that was there.  However, removing that file from
/var/spool/up2date seems to have corrected the problem.  up2date is working fine
now.

Thank you.
Comment 10 Steve Conklin 2002-02-08 10:23:53 EST
Created attachment 44957 [details]
hdr files from spool dir when segfault was happening
Comment 11 Steve Conklin 2002-02-08 10:27:10 EST
I had the same problem on a vanilla workstation install yesterday. It was on a
Dell Domension V350 machine. It always segfaulted python right after "Getting
headers for available packages" in both graphical and --nox modes. After
removing the .hdr files from /usr/spool/up2date, it appeared to work fine (It
was still updating when I left the machine). I have attached the .hdr files to
this report

Steve
Comment 12 Adrian Likins 2002-03-06 18:58:54 EST
This should be fixed in the next version of the client. 

Sound like a corrupt header file making rpmlib segfault. The new
client is much more rubust about this circumstance.
Comment 13 Matt Jamison 2003-05-21 14:24:44 EDT
closing bug.

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