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
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.
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.
Created attachment 297135 [details]
Console output when yumex died.
Bugger. Just noticed a typo in the bug's name. That should have been
"responsive". Change if you're able.
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.
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: