Bug 205840 - yumex crashes and exits during update
yumex crashes and exits during update
Product: Fedora
Classification: Fedora
Component: yumex (Show other bugs)
All Linux
medium Severity medium
: ---
: ---
Assigned To: Tim Lauridsen
Fedora Extras Quality Assurance
Depends On:
  Show dependency treegraph
Reported: 2006-09-08 18:18 EDT by Andy Burns
Modified: 2007-11-30 17:11 EST (History)
1 user (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2006-09-18 04:24:29 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)

  None (edit)
Description Andy Burns 2006-09-08 18:18:15 EDT
Description of problem:

Several times in last couple of weeks I have noticed yumex "silently" exits
during a update operation, so I have taken to running yumex from a console
window, in order to catch any dying information from it, this is the first time
I have caught some output ...

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

yum.noarch                               2.9.5-4                installed       
yum.noarch                               2.9.6-1                installed       
yum-metadata-parser.i386                 1.0-7.1.fc6            installed       
yum-utils.noarch                         0.6-5.fc6              installed       
yumex.noarch                             1.1.2-1.1.fc6          installed       
yumex.noarch                             1.1.3-1.0.fc6          installed       
gnome-yum.i386                           0.1.3-3.fc6            extras-developme
kyum.i386                                0.7.5-4.fc6            extras-developme
yum-changelog.noarch                     0.6-5.fc6              extras-developme
yum-downloadonly.noarch                  0.6-5.fc6              extras-developme
yum-fastestmirror.noarch                 0.6-5.fc6              extras-developme
yum-fedorakmod.noarch                    0.6-5.fc6              extras-developme
yum-kernel-module.noarch                 0.6-5.fc6              extras-developme
yum-protectbase.noarch                   0.6-5.fc6              extras-developme
yum-tsflags.noarch                       0.6-5.fc6              extras-developme
yum-updateonboot.noarch                  0.6-5.fc6              extras-developme
yum-updatesd.noarch                      2.9.6-1                development     
yum-versionlock.noarch                   0.6-5.fc6              extras-developme

How reproducible:
randomly, but perhaps 1/3 of all updates

Actual results:

---> Package eclipse-rcp.i386 1:3.2.0-4.fc6 set to be updated
---> Package openoffice.org-calc.i386 1:2.0.4-3.1 set to be updated
Running Transaction
Shutting down restorecond: [  OK  ]
Starting restorecond: [  OK  ]
The program 'yumexmain.pyc' received an X Window System error.
This probably reflects a bug in the program.
The error was 'BadRequest (invalid request code or no such operation)'.
  (Details: serial 8252566 error_code 1 request_code 0 minor_code 0)
  (Note to programmers: normally, X errors are reported asynchronously;
   that is, you will receive the error a while after causing it.
   To debug your program, run it with the --sync command line
   option to change this behavior. You can then get a meaningful
   backtrace from your debugger if you break on the gdk_x_error() function.)

Just noticed while capturing the version information, that I somehow have
multiple versions of yum and yumex installed, will try to clean that up and see
if it helps ...
Comment 1 Tim Lauridsen 2006-09-09 03:38:15 EDT
I look like an error in X, triggered when the rpm backend running a scriptlet.
I dont think the error is caused by yumex, It is something on a lower level. I
have head that job running rpm transaction sometimes segfault. I have not got
any error myself.
It is very hard to detect what is wrong, but i dont think that it is something i
can fix in yumex.
Comment 2 Andy Burns 2006-09-09 03:55:05 EDT
I must admit I though the real cause might be in pygtk or even lower, please
feel free to close this bug if appropriate ...

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