Just run nxagent -ac :1 to get rid if all the magic cookie stuff during testing.
Uli
----- Ursprüngliche Nachricht -----
Von: "Mike Gabriel" <[email protected]>
Gesendet: 01.10.2015 22:11
An: "Jean-Francois Dagenais" <[email protected]>
Cc: "[email protected]" <[email protected]>
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 <[email protected]>
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/[email protected]/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: [email protected], http://das-netzwerkteam.de
_______________________________________________
x2go-dev mailing list
[email protected]
http://lists.x2go.org/listinfo/x2go-dev_______________________________________________
x2go-dev mailing list
[email protected]
http://lists.x2go.org/listinfo/x2go-dev
