Bug 205840

Summary:	yumex crashes and exits during update
Product:	[Fedora] Fedora	Reporter:	Andy Burns <fedora>
Component:	yumex	Assignee:	Tim Lauridsen <tim.lauridsen>
Status:	CLOSED CANTFIX	QA Contact:	Fedora Extras Quality Assurance <extras-qa>
Severity:	medium	Docs Contact:
Priority:	medium
Version:	rawhide	CC:	extras-qa
Target Milestone:	---
Target Release:	---
Hardware:	All
OS:	Linux
Whiteboard:
Fixed In Version:		Doc Type:	Bug Fix
Doc Text:		Story Points:	---
Clone Of:		Environment:
Last Closed:	2006-09-18 08:24:29 UTC	Type:	---
Regression:	---	Mount Type:	---
Documentation:	---	CRM:
Verified Versions:		Category:	---
oVirt Team:	---	RHEL 7.3 requirements from Atomic Host:
Cloudforms Team:	---	Target Upstream Version:
Embargoed:

Description Andy Burns 2006-09-08 22:18:15 UTC

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 07:38:15 UTC

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 07:55:05 UTC

I must admit I though the real cause might be in pygtk or even lower, please
feel free to close this bug if appropriate ...