Bug 903410

Summary: gtk-3.0 programs cannot run in a remote NX session
Product: [Fedora] Fedora Reporter: Tom Horsley <horsley1953>
Component: gtk3Assignee: Matthias Clasen <mclasen>
Status: CLOSED WONTFIX QA Contact: Fedora Extras Quality Assurance <extras-qa>
Severity: unspecified Docs Contact:
Priority: unspecified    
Version: 18CC: igeorgex, jonathan.underwood, mclasen, ngaywood, rvokal
Target Milestone: ---   
Target Release: ---   
Hardware: Unspecified   
OS: Unspecified   
Whiteboard:
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2014-02-05 18:25:01 UTC Type: Bug
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:
Attachments:
Description Flags
backtrace none

Description Tom Horsley 2013-01-23 22:44:26 UTC 
Description of problem:

I finally got a NX session to work after using work around from bug 903186,
but now when I try to start emacs, this happens:

tomh> emacs -Q

(emacs:24583): Gdk-ERROR **: The program 'emacs' received an X Window System error.
This probably reflects a bug in the program.
The error was 'BadValue (integer parameter out of range for operation)'.
  (Details: serial 130 error_code 2 request_code 25 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 GDK_SYNCHRONIZE environment
   variable to change this behavior. You can then get a meaningful
   backtrace from your debugger if you break on the gdk_x_error() function.)
Fatal error (5)Trace/breakpoint trap

In a normal "real" X session, emacs works fine.


Version-Release number of selected component (if applicable):
emacs-24.2-5.fc18.x86_64


How reproducible:
Every time I've tried inside the NX session.

Steps to Reproduce:
1.try to start emacs
2.get X error
  
Actual results:
The error shown

Expected results:
An emacs session

Additional info:
Comment 1 Tom Horsley 2013-01-24 00:00:19 UTC 
Created attachment 686367 [details]
backtrace

I followed the instructions in the error message to sync the GTK X requests and installed loads of debuginfo files and got this backtrace. Looks like it might have something to do with me having selected the oxygen-gtk theme (which is too bad, because if it gets far enough to run my .emacs, I turn off every bit of all the menus and wot-not that are using gtk - if I could bypass all the gtk nonsense in the first place, I wouldn't have this problem :-).
Comment 2 Tom Horsley 2013-01-24 00:10:50 UTC 
Looks like this probably isn't emacs specific. I tried to run dconf-editor to set a different theme, and it blew up identically. Not sure what component to report it against though.
Comment 3 Tom Horsley 2013-01-24 12:50:28 UTC 
Running ldd and grepping for gtk libs, I see that apps using the gtk-3.0 lib all get this error and apps using gtk-2.0 do not (at least for the small sample size I've checked so far). I guess I should change the component to gtk 3.
Comment 4 Tom Horsley 2013-01-24 17:31:43 UTC 
The more I look at this, the more I have no idea what component this bug should be.

I've found what looks like a patch for NX (or some variant of it) here:

http://lists.berlios.de/pipermail/x2go-dev/2012-May/003962.html

and what looks like a patch to cairo here:

http://lists.cairographics.org/archives/cairo-bugs/2011-June/004387.html
Comment 5 Tom Horsley 2013-01-24 19:20:09 UTC 
I still have no real idea what is happening at the lowest level, but I did
devise a work around:

Go to my fedora 17 system:

cd /lib64
tar cf - *cairo* | bzip2 -9 > ~/oldcairo.tar.bz2

Go to my fedora 18 system:

mkdir /zooty/oldcairo
cd /zooty/oldcairo
bzip2 -d < ~/oldcairo.tar.bz2 | tar xf -

Now, in my NX session, if I set

export LD_LIBRARY_PATH=/zooty/oldcairo

I can run emacs or dconf-editor, etc. and they don't blow up.
Comment 6 Norman Gaywood 2013-01-29 03:48:04 UTC 
I saw this as well.

I tried:

yum --enablerepo=updates-testing update cairo

to get  cairo.x86_64 0:1.12.10-1.fc18 and the problem seems to have gone.
Comment 8 Fedora End Of Life 2013-12-21 10:46:05 UTC 
This message is a reminder that Fedora 18 is nearing its end of life.
Approximately 4 (four) weeks from now Fedora will stop maintaining
and issuing updates for Fedora 18. It is Fedora's policy to close all
bug reports from releases that are no longer maintained. At that time
this bug will be closed as WONTFIX if it remains open with a Fedora 
'version' of '18'.

Package Maintainer: If you wish for this bug to remain open because you
plan to fix it in a currently maintained version, simply change the 'version' 
to a later Fedora version prior to Fedora 18's end of life.

Thank you for reporting this issue and we are sorry that we may not be 
able to fix it before Fedora 18 is end of life. If you would still like 
to see this bug fixed and are able to reproduce it against a later version 
of Fedora, you are encouraged  change the 'version' to a later Fedora 
version prior to Fedora 18's end of life.

Although we aim to fix as many bugs as possible during every release's 
lifetime, sometimes those efforts are overtaken by events. Often a 
more recent Fedora release includes newer upstream software that fixes 
bugs or makes them obsolete.
Comment 9 Fedora End Of Life 2014-02-05 18:25:01 UTC 
Fedora 18 changed to end-of-life (EOL) status on 2014-01-14. Fedora 18 is
no longer maintained, which means that it will not receive any further
security or bug fix updates. As a result we are closing this bug.

If you can reproduce this bug against a currently maintained version of
Fedora please feel free to reopen this bug against that version. If you
are unable to reopen this bug, please file a new report against the
current release. If you experience problems, please add a comment to this
bug.

Thank you for reporting this bug and we are sorry it could not be fixed.