Bug 213799 - gkrellm BadRequest since upgrading to FC6
gkrellm BadRequest since upgrading to FC6
Status: CLOSED NOTABUG
Product: Fedora
Classification: Fedora
Component: gkrellm (Show other bugs)
6
All Linux
medium Severity medium
: ---
: ---
Assigned To: Hans de Goede
Fedora Extras Quality Assurance
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2006-11-02 19:19 EST by Patrick C. F. Ernzer
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:
Environment:
Last Closed: 2006-11-28 08:16:24 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description Patrick C. F. Ernzer 2006-11-02 19:19:49 EST
Description of problem:
ever since I upgraded this box to FC6 the local gkrellm will crap out regularly
as follows:
$ gkrellm --sync

(gkrellm:17442): Pango-CRITICAL **: pango_layout_set_text: assertion `length ==
0 || text != NULL' failed

(gkrellm:17442): Pango-CRITICAL **: pango_layout_set_text: assertion `length ==
0 || text != NULL' failed

(gkrellm:17442): Pango-WARNING **: Invalid UTF-8 string passed to
pango_layout_set_text()
The program 'gkrellm' 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 39336870 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.)


Version-Release number of selected component (if applicable):
gkrellm-2.2.9-10.fc6

How reproducible:
not always

Steps to Reproduce:
1. start gkrellm
2. leave it running over the course of a day
3. craps out before 24 hours are over
  
Actual results:
gkrellm quits

Expected results:
gkrellm continues running as it used to

Additional info:
I usually have 4 additional gkrellms open (through ssh) on the following machines
  a RHL 9 box
  a RHEL 2.1 box
  a RHEL 4 box
  a debian unstable box

these do not crap out

this machine's gkrellm was fine under FC4 as well.

I do use that closed source ATi driver packaged by livna and I think but cannot
100% confirm that the gkrellm only dies when I use OpenGL (either the really
slick gnome screensaver or WoW in OpenGL mode under cedega)
Comment 1 Patrick C. F. Ernzer 2006-11-02 19:20:41 EST
and forgot top add I have no X or gkrelm related SELinux error messages
Comment 2 Hans de Goede 2006-11-03 00:39:08 EST
Hmm,

Can you try the following:
1) Install gkrellm from development / devel, that has a --without-libsensors 
   cmdline option and run it with that option?

2) Disable your screensaver to confirm it is opengl usage related

3) Downgrade to gkrellm from FC-5 to see where/when exactly this broke

And not all at once of course but one by one. Given the duration needed to
reproduce this I will patiently wait for the results.

BTW are you using / have installed any gkrellm plugins?
Comment 3 Patrick C. F. Ernzer 2006-11-03 06:06:42 EST
in response to comment #2
1-3 will be done next week, no access to the problematic machine until then

But I wnted to tell you the following; my other FC6 box does not use the closed
source driver (that's the work notebook, need that clean and it's not for playing)

On that box I have:
$ rpm -qa|grep saver
gnome-screensaver-2.16.1-2.fc6
rss-glx-gnome-screensaver-0.8.1.p-6.fc6
xscreensaver-gl-extras-gss-5.01-3.fc6
xscreensaver-gl-extras-5.01-3.fc6

so lodsa GL bling and this machine has been running for a few days, logged in,
screen locked, and the local gkrellm on that box is still running.

I guess that makes the closed source driver the prime suspect.

I will run the required tests so we get a better idea, probably in thoe order 3,
1, 2.
Comment 4 Patrick C. F. Ernzer 2006-11-08 16:48:39 EST
in response to comment #2

1) did not help. used gkrellm-2.2.10-1.fc7 as follows:
gkrellm --without-libsensors &

configured gnome-screensave to only blank screen, we'll se how that goes
Comment 5 Patrick C. F. Ernzer 2006-11-20 10:17:44 EST
in response to comment #2

2) did not help either, was away for a few days and gkrellm was not running any
more on my return.

Switched screensaver back to normal (i.e. eyecandy OpenGL stuff)

Will try downgrading gkrellm to the FC5 one next.

Note to self: also updated ATI closed source driver yesterday, so only do test
3) in a few days to be sure the problem is still there.
Comment 6 Patrick C. F. Ernzer 2006-11-22 20:35:10 EST
in response to comment #2

3) no joy either;
$ gkrellm --sync
The program 'gkrellm' 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 43313178 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.)
$ rpm -q gkrellm
gkrellm-2.2.9-0.fc5.1

once agin it died while I was playing WoW under cedega.

Now what to test next?

One thing to note is that this test was again with sensors display on, not sure
if that is part of trhe problem or not.
Comment 7 Hans de Goede 2006-11-23 06:43:55 EST
I say bad fglrx drivers, I've tried the fglrx drivers on my system because I 
needed them to reproduce an OpenGL problem which only showed up under them. And 
they are a piece of shit.

I tend to closing this as worksforme, agreed?

Why do you still use the fglrx driver? Have you tried switching to the new 
opensource r300 dri driver in FC-6 that wokrs very well for me and should work 
for all ati cards except pretty new ones.
Comment 8 Patrick C. F. Ernzer 2006-11-23 06:58:50 EST
It's the only one of my boxes that has that driver, simplyu because when I play
WoW under cedega it's trhe only way to get decent framerates.

Alternative would be to boot that Games Loader, but that is annoying.

FWIW: The card is a  ATI Technologies Inc R420 JJ [Radeon X800SE]

Leave it open but in needinfo please, I have another box here that will get
upgraded to FC6 as soon as I have a few free cycles, that will use the open
source driver and has a ATI Technologies Inc Radeon R300 NG [FireGL X1] (rev
80). It's a work box. If problem does not show on that one we will be sure it's
the evil closed driver and can bug ATI.
Comment 9 Hans de Goede 2006-11-23 07:07:55 EST
OK
Comment 10 Patrick C. F. Ernzer 2006-11-28 08:16:24 EST
the box with the open driver has not yet shown the problem.
guess it's time to ebay my X800 and buy a Nvidia card for playing WoW under
cedega :-(
closing as NOTABUG
Comment 11 Hans de Goede 2006-11-28 08:39:16 EST
Ok, Thanks for the follow up.

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