Hi all!
Long time x2go user.
Just remade my box with debian jessie. Followed the server instructions steps. I can run xterm and other programs, but some (like gnome-terminal, xfce-terminal, mate-terminal ... and others) cause x2goagent to crash with:
traps: x2goagent[8626] general protection ip:7fdf1317fe6d sp:7ffe79b7dd70 error:0 in libNX_X11.so.6.2[7fdf13133000+123000]
This is using today's nightly build.
Wondering how to proceed now. Sources build to get more debug information?
FYI, I am a general software and linux kernel developer but am not familiar with the x2go project development.
Thanks!
Hi Jean-Francois,
On Di 29 Sep 2015 20:13:52 CEST, Jean-Francois Dagenais wrote:
Hi all!
Long time x2go user.
Just remade my box with debian jessie. Followed the server
instructions steps. I can run xterm and other programs, but some
(like gnome-terminal, xfce-terminal, mate-terminal ... and others)
cause x2goagent to crash with:traps: x2goagent[8626] general protection ip:7fdf1317fe6d
sp:7ffe79b7dd70 error:0 in libNX_X11.so.6.2[7fdf13133000+123000]This is using today's nightly build.
Wondering how to proceed now. Sources build to get more debug information?
FYI, I am a general software and linux kernel developer but am not
familiar with the x2go project development.Thanks!
Please checkout the latest nx-libs code for this: http://github.com/ArcticaProject/nx-libs (3.6.x branch)
Run you test on that code-base, please. You can obtain binaries for
some Debian and Ubuntu sytems at [1].
Normally, you should be able to reproduce that issue via a local
nxagent session, i.e. run "nxagent :1" on a local display. This pops
up a Xephyr like nxagent window. Test the above tests in that nxagent
session (export DISPLAY=:1 gnome-terminal).
For debugging nxagent, please refer to the standard X11 debugging
procedures [2].
Mike
[1] deb http://packages.arctica-project.org/debian-nightly
{jessie,stretch,unstable} main
deb http://packages.arctica-project.org/ubuntu-nightly trusty main
[2] http://www.x.org/wiki/Development/Documentation/ServerDebugging/
--
DAS-NETZWERKTEAM mike gabriel, herweg 7, 24357 fleckeby fon: +49 (1520) 1976 148
GnuPG Key ID 0x25771B31 mail: mike.gabriel@das-netzwerkteam.de, http://das-netzwerkteam.de
freeBusy: https://mail.das-netzwerkteam.de/freebusy/m.gabriel%40das-netzwerkteam.de.xf...
Hi Mike, 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. 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 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; 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) 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 Thanks for your help, and let me know if I can further help! /jfd
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
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
Hi, thanks again for replying.
On Oct 1, 2015, at 4:10 PM, Mike Gabriel <mike.gabriel@das-netzwerkteam.de> wrote:
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 fear this may be out of my current reach, only given the amount of time I can devote to this. Hopefully you (or others with more familiarity with the Xorg project) may end up fixing this by applying "upstream" changes... or the problem may creep back on me and force my hand for good.
Didn't you say that you observed those issues with gnome3 apps? How does xterm come into play here as a testing candidate?
I would only use xterm to confirm that my changes hadn't completely crippled the libs. Frome there, I would invoke 'gnome-terminal' or 'gedit' to cause the segfault.
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.
I will try that. Thank you for educating me... and thank you most for your service: x2go has been invaluable to my work setup for years now.
Regards /jfd
Hi Jean-Francois, On Do 01 Okt 2015 22:10:04 CEST, Mike Gabriel wrote:
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...
attached is the only change that has happened since 2006 or so around the code block you reference. @@ -1739,7 +1739,7 @@ void Data( int _XData32( Display *dpy, - register long *data, + register _Xconst long *data, unsigned len) { register int *buf; Mike -- DAS-NETZWERKTEAM mike gabriel, herweg 7, 24357 fleckeby fon: +49 (1520) 1976 148 GnuPG Key ID 0x25771B31 mail: mike.gabriel@das-netzwerkteam.de, http://das-netzwerkteam.de freeBusy: https://mail.das-netzwerkteam.de/freebusy/m.gabriel%40das-netzwerkteam.de.xf...
-
Jean-Francois Dagenais -
Mike Gabriel -
Ulrich Sibiller