Just run nxagent -ac :1 to get rid if all the magic cookie stuff during testing. Uli ----- Ursprüngliche Nachricht ----- Von: "Mike Gabriel" <mike.gabriel@das-netzwerkteam.de> Gesendet: 01.10.2015 22:11 An: "Jean-Francois Dagenais" <jeff.dagenais@gmail.com> Cc: "x2go-dev@lists.x2go.org" <x2go-dev@lists.x2go.org> Betreff: Re: [X2Go-Dev] debian jessie general protection trap inlibNX_X11.so.6.2 caused by some apps Hi Jean-Francois, On Thu Oct 1 14:33:36 2015 Jean-Francois Dagenais <jeff.dagenais@gmail.com> wrote:
Thanks for the reply. I was able to get a bit further since my mail. I did the 'apt-get source x2goagent' and 'debuild' to get a stack trace.
Tried the deb repo you pointed, same behaviour. Although "deb http://packages.arctica-project.org/debian-nightly/ jessie main" gave me versions "3.5.99.0-0~git20150928.1021+jessie.nightly.1", not 3.6.x. I have built 3.6.x (commit 81d92cd0fa293e44bbb063d373d9289ddc358c99) using "DEB_BUILD_OPTIONS=nocheck debuild -b -uc -us -j8", I will try the generated .debs later.
The 3.6.x branch currently carries a 3.5.99.0 version, that is ok. 3.5.99.0-0~git20150928.1021+jessie.nightly.1 is the lates build taken from the 3.6.x branch.
In the mean time, here's what i got from my debug effort on the version from x2go.org. The fault comes from:
Program received signal SIGSEGV, Segmentation fault. _XData32 (dpy=dpy@entry=0x2b319b0, data=<optimized out>, data@entry=0x34580d4, len=14588, len@entry=18652) at XlibInt.c:3792 3792 *buf++ = *data++; (gdb) l 3787 i = len; 3788 dpy->bufptr = (char *)buf + i; 3789 len -= i; 3790 i >>= 2; 3791 while (--i >= 0) 3792 *buf++ = *data++; 3793 } 3794 return 0; 3795 } 3796 #endif /* LONG64 */
Then I did several tests. To get better debug resolution, I compiled the lib again, but with '-Og' (or -O0, I tried both). Oddly, the problem goes away! I think there's some alignment problems here: See also: https://www.mail-archive.com/misc@openbsd.org/msg129941.html
Ok... Have you checked upstram X.Org already? Checked what they have at that place in the code? They probably have already fixed it. See the xorg/libx11 Git repo on git.freedesktop.org. I normally compare the nxagent code with latest X.Org and then many issues dissolve when apply their changes.
I'm really confused, If i change the "data" member to an int (32bits) then it doesn't work. I get no errors, my x11 clients just don't show up (I use xterm as a test client app). I did manage to fix it by doing: diff --git a/nx-X11/lib/X11/XlibInt.c b/nx-X11/lib/X11/XlibInt.c index 47e2ea1..bfcab8d 100644 --- a/nx-X11/lib/X11/XlibInt.c +++ b/nx-X11/lib/X11/XlibInt.c @@ -3770,11 +3770,11 @@ void Data( int _XData32( Display *dpy, - register long *data, + volatile long *data, unsigned len) { - register int *buf; - register long i; + volatile int *buf; + volatile long i; while (len) { buf = (int *)dpy->bufptr; @@ -3785,6 +3785,7 @@ _XData32( } if (len < i) i = len; + i &= ~0x3; dpy->bufptr = (char *)buf + i; len -= i; i >>= 2;
Ok...
I also tried to rewrite the method using memcpy but could not get it to work. It compiles and looks sound, but at execution, my windows (xterm)
Didn't you say that you observed those issues with gnome3 apps? How does xterm come into play here as a testing candidate?
never appear in the server. Lack of proper debugging environment and further time to invest (too much already) means I will need to drop this for a while. Especially since now my system runs all of the gnome3 apps I've tried, so I'm no longer stalled.
P.S. I was unable to use the nxagent :1 strategy. I do get a Xephyr style black window, but when I start a client I get this: dagenaisj@jfddesk:~$ export DISPLAY=:1 dagenaisj@jfddesk:~$ xeyes No protocol specified Error: Can't open display: :1
Oh, that's maybe because you have no magic cookie in you .Xauthority file, yet. Do an X2Go session from localhost to localhost, that runs the proper xauth command. I can also look it up tomorrow when sitting at my notebook. Testing nxagent on localhost really eases the debugging and often let's certain issues disappear. If that happens, then the cause of observed issues may also be hidden in the libxcomp* libraries which handle the NX compression and caching part.
Thanks for your help, and let me know if I can further help! /jfd
Greets, Mike -- DAS-NETZWERKTEAM mike gabriel, herweg 7, 24357 fleckeby fon: +49 (1520) 1976148 GnuPG Key ID 0x25771B13 mail: mike.gabriel@das-netzwerkteam.de, http://das-netzwerkteam.de _______________________________________________ x2go-dev mailing list x2go-dev@lists.x2go.org http://lists.x2go.org/listinfo/x2go-dev