[X2Go-Dev] debian jessie general protection trap inlibNX_X11.so.6.2 caused by some apps

[Ulrich Sibiller]

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 at das-netzwerkteam.de>
Gesendet: ‎01.‎10.‎2015 22:11
An: "Jean-Francois Dagenais" <jeff.dagenais at gmail.com>
Cc: "x2go-dev at lists.x2go.org" <x2go-dev at 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 at 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 at entry=0x2b319b0, data=<optimized out>,
> data at entry=0x34580d4, len=14588, len at 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 at jfddesk:~$ export DISPLAY=:1 dagenaisj at 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 at das-netzwerkteam.de, http://das-netzwerkteam.de


_______________________________________________
x2go-dev mailing list
x2go-dev at lists.x2go.org
http://lists.x2go.org/listinfo/x2go-dev
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.x2go.org/pipermail/x2go-dev/attachments/20151001/d37ed402/attachment-0001.html>