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.
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: 0x0000000014de3880 ***