Bugzilla will be upgraded to version 5.0 on a still to be determined date in the near future. The original upgrade date has been delayed.
Bug 436423 - yumex gui left unresonsive after error on CLI
yumex gui left unresonsive after error on CLI
Product: Fedora
Classification: Fedora
Component: yumex (Show other bugs)
x86_64 Linux
low Severity low
: ---
: ---
Assigned To: Tim Lauridsen
Fedora Extras Quality Assurance
Depends On:
  Show dependency treegraph
Reported: 2008-03-06 21:50 EST by Austin
Modified: 2008-03-08 20:58 EST (History)
0 users

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2008-03-07 03:59:50 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
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-06 21:50 EST, Austin
no flags Details

  None (edit)
Description Austin 2008-03-06 21:50:59 EST
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

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-06 21:50:59 EST
Created attachment 297135 [details]
Console output when yumex died.
Comment 2 Austin 2008-03-06 21:52:21 EST
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 03:59:50 EST
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-08 20:58:20 EST
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.