Note: This is a public test instance of Red Hat Bugzilla. The data contained within is a snapshot of the live data so any changes you make will not be reflected in the production Bugzilla. Email is disabled so feel free to test any aspect of the site that you want. File any problems you find or give feedback at bugzilla.redhat.com.

Bug 88349

Summary: if up2date itself tracebacks, up2date GUI freezes
Product: [Fedora] Fedora Reporter: Barry K. Nathan <barryn>
Component: up2dateAssignee: Bret McMillan <bretm>
Status: CLOSED WONTFIX QA Contact: Fanny Augustin <fmoquete>
Severity: high Docs Contact:
Priority: medium    
Version: 3CC: barryn, gafton, mihai.ibanescu
Target Milestone: ---   
Target Release: ---   
Hardware: i686   
OS: Linux   
Whiteboard:
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2006-04-22 15:34:23 UTC Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:
Bug Depends On:    
Bug Blocks: 120092    
Attachments:
Description Flags
the traceback that causes the freeze none

Description Barry K. Nathan 2003-04-09 10:32:54 UTC
From Bugzilla Helper:
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.4a) Gecko/20030401

Description of problem:
When up2date itself fails with a traceback (for example, because of a buggy
server), the up2date GUI freezes.

Version-Release number of selected component (if applicable):
up2date-3.1.23-1

How reproducible:
Always

Steps to Reproduce:
1. Set up a current 1.4.3 server. (Grab current from current.tigris.org. It
*must* be 1.4.3, and not a future release -- in these steps I'm *relying* on a
1.4.3 bug in order to trigger this client-side behavior with 100%
reproducibility.) FWIW, the server I used to test this is running on Red Hat
Linux 7.3.
2. Set up a Red Hat Linux 9 client to this server (and register this client with
the server). Start the client from the command line if you want to see
everything that's going on, or start it from the menus if you want to see the
(IMO) more devastating variant of this.
3. Choose to update one or more packages.
4. Watch the package(s) download, then click "Next".
5. Watch the package(s) install.
6. Notice the traceback, if you launched the up2date GUI from the command line.
(This, in and of itself, is *not* the bug I'm reporting -- the bug I'm reporting
is what happens next.) If you started the GUI from the menus, just wait for
things to start seeming like they're taking too long, I guess...

Actual Results:  up2date GUI just stands there. If the up2date GUI was launched
from a terminal window, the user has to manually press Control-C. If the up2date
GUI was started from the menus, the only clue that something went wrong is that
things seem to be taking an awfully long time...

Expected Results:  I expected some kind of indication from the GUI that
something went wrong (like an error message), and I expected the GUI to not
freeze up. 

(The text-only interface drops back to the command line after the traceback,
without freezing; AFAIK that UI works properly and does not appear to have this
bug.)

Additional info:

I am *not* reporting the buggy behavior of the Current server. Current, of
course, is not Red Hat's responsibility. What I *am* reporting is the up2date
*GUI's* non-robust error handling. I am merely using Current 1.4.3 as a 100%
reproducible way of triggering this client bug.

Comment 1 Barry K. Nathan 2003-04-09 10:34:58 UTC
Created attachment 91037 [details]
the traceback that causes the freeze

This is the traceback which causes the up2date GUI to freeze. I'm attaching it
in case it helps Red Hat to fix the GUI freeze.

Comment 2 Adrian Likins 2003-04-09 19:21:30 UTC
I'll take a look at catching generic expections for the gui
at that point, and existing more forcefully. As much as I
dislike coding in generic catch all exception handlers, adding
one at the top level is probabaly acceptable. 

But that error is bubbling up from way deep down in the xml
parsing library. Pretty obtuse error case (the system libs
exploded...)

Comment 3 Barry K. Nathan 2004-05-29 19:29:54 UTC
Changing from Red Hat 9 to Fedora Core 2, as this bug still affects
FC2. (I haven't tried the exact testcase I originally used, but I've
seen other tracebacks freeze up the up2date GUI.)

Comment 4 Matthew Miller 2005-04-26 15:35:24 UTC
Fedora Core 2 is now maintained by the Fedora Legacy project for
security updates only. If this problem is a security issue, please
reopen and reassign to the Fedora Legacy product. If it is not a
security issue and hasn't been resolved in the current FC3 updates or
in the FC4 test release, reopen and change the version to match.

Comment 5 Barry K. Nathan 2005-04-28 21:11:20 UTC
Ok, I'll retest with FC3 and/or rawhide at some point in the next few days.

Comment 6 Matthew Miller 2005-05-02 12:15:50 UTC
(Putting this back into NEEDINFO state pending comment #5.... Thanks....)

Comment 7 Barry K. Nathan 2005-05-03 07:24:31 UTC
I didn't get to retest yet due to a family emergency. I'll try to do this ASAP,
but if I don't manage to do it tonight, I may not get to it for another week.
Sorry about this.

Comment 8 Barry K. Nathan 2005-05-03 09:52:14 UTC
Ok, I retested, it still happens with FC3 (up2date 4.3.47-5).

I'll try to retest with FC4t2 or a recent rawhide, but I don't know if I'll be
able to do that tonight.

Comment 9 Matthew Miller 2005-05-03 12:09:03 UTC
Thanks!

Comment 10 Barry K. Nathan 2005-05-03 13:00:44 UTC
I just reproduced this with FC4t2 as well (up2date-4.4.9-1). I also just
reproduced it with up2date-4.4.17-1 from rawhide (with the rest of the system
running with FC4t2 packages).

Comment 11 John Thacker 2006-04-22 15:34:23 UTC
In any case, up2date is no longer shipped with Fedora Core; its functionality 
has been replaced by pup, found in the pirut package.  The only fixes 
likely to be made to up2date in RedHat Linux and earlier Fedora Core 
versions are security fixes by Fedora Legacy.  This does not seem to 
be a security bug, so I'm closing it.

If the problem is appropriate to RHEL and occurs to a user there, it 
can be filed as such.