Bug 436423 - yumex gui left unresonsive after error on CLI
Summary: yumex gui left unresonsive after error on CLI
Status: CLOSED CANTFIX
Alias: None
Product: Fedora
Classification: Fedora
Component: yumex (Show other bugs)
(Show other bugs)
Version: rawhide
Hardware: x86_64 Linux
low
low
Target Milestone: ---
Assignee: Tim Lauridsen
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
Keywords:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2008-03-07 02:50 UTC by Austin
Modified: 2008-03-09 01:58 UTC (History)
0 users

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2008-03-07 08:59:50 UTC
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)
Console output when yumex died. (36.15 KB, text/plain)
2008-03-07 02:50 UTC, Austin
no flags Details

Description Austin 2008-03-07 02:50:59 UTC
Description of problem: Yumex was "unable to allocate memory" and left the GUI
in an unresponsive state.


Version-Release number of selected component (if applicable): v2.04 from the
title bar.


How reproducible: Uncertain.


Steps to Reproduce:
1. Selecting a few packages in yumex to upgrade. Find that dependency resolution
sucks, and it fails to complete with conflicts from i386 and x86_64 versions of
the same package.
2. Go back to the update list and select the i386 version of the conflicting
package and wait for the next barf.
3. Repeat until you have 87 packages queued up for a single package's update.
4. Finally get yumex to download and begin Transaction test.
5. Go to lunch because it's taking so long.
6. Come back to an unresponsive GUI, and because you ran it from the CLI, you
can see why: you see the attached messages.
  
Actual results:
An unresponsive GUI, which when closed, does NOT free up the console. When you
press CTRL+C to then kill the process it does not free up yum, as it's still locked.

Expected results: Better error handling. If it can't allocate memory for a task,
then cease attempting to, and popup a small dialog informing the user of the
outcome. (Assuming the popup can be displayed when the other task can't allocate
memory...)

Also, I would have expected CTRL+C on the CLI to be handled so it can free up yum.

Additional info: Available upon request.

Comment 1 Austin 2008-03-07 02:50:59 UTC
Created attachment 297135 [details]
Console output when yumex died.

Comment 2 Austin 2008-03-07 02:52:21 UTC
Bugger. Just noticed a typo in the bug's name. That should have been
"responsive". Change if you're able.

Comment 3 Tim Lauridsen 2008-03-07 08:59:50 UTC
I looks like it is a very low level error, if there is not raised a Python
Exception there is nothing i can do in yumex to catch the error.
So i can't fix there kind of low level craches.

Comment 4 Austin 2008-03-09 01:58:20 UTC
Isn't this line Python related:
error: Couldn't fork %post: Cannot allocate memory

... or this one?

*** glibc detected *** /usr/bin/python: corrupted double-linked list:
0x0000000014de3880 ***


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