Bug#766299: [pkg-x2go-devel] Bug#766299: nxproxy: BIG-REQUESTS patch builds but fails at runtime
Hi Paul, On So 23 Nov 2014 03:19:24 CET, paul.szabo wrote: Dear Mike, I know there is "one last remaining bug" in nxproxy; I have not been able to find it. I will now stop working on nxproxy, and start using "ssh -C" instead: seems to provide similar performance, is well tested, and is less likely to cause problems seeing how it does not mess much with the X protocol (not at all with -R or -L forwarding). Cheers, Paul Thanks for giving so much time to this issue. I will look at your work and try to complete it. Greets, Mike -- DAS-NETZWERKTEAM mike gabriel, herweg 7, 24357 fleckeby fon: +49 (1520) 1976 148 GnuPG Key ID 0x25771B31 mail: mike.gabr...@das-netzwerkteam.de, http://das-netzwerkteam.de freeBusy: https://mail.das-netzwerkteam.de/freebusy/m.gabriel%40das-netzwerkteam.de.xfb pgpW5GhyAe70W.pgp Description: Digitale PGP-Signatur
Bug#766299: [pkg-x2go-devel] Bug#766299: nxproxy: BIG-REQUESTS patch builds but fails at runtime
Dear Mike, I know there is "one last remaining bug" in nxproxy; I have not been able to find it. I will now stop working on nxproxy, and start using "ssh -C" instead: seems to provide similar performance, is well tested, and is less likely to cause problems seeing how it does not mess much with the X protocol (not at all with -R or -L forwarding). Cheers, Paul Paul Szabo p...@maths.usyd.edu.au http://www.maths.usyd.edu.au/u/psz/ School of Mathematics and Statistics University of SydneyAustralia -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#766299: [pkg-x2go-devel] Bug#766299: nxproxy: BIG-REQUESTS patch builds but fails at runtime
Hi Paul, - Original message - > Dear Mike, > > > The nxproxy built for X2Go does not get built against libX11 from Xorg > > but against libNX_X11 [1] from NoMachine. > > Will this break the GenericEvents part of your patch? Or does it > > simply require a patch in libNX_X11? > > Please update your libNX_X11 file. (Seems you took a copy of some > XFree86 1.6 file back in 2003... time to move on? The only change > is that you are missing GenericEvents, and so mis-define LASTEvent.) Maybe you should research on the context how nxproxy originated. It was developed by NoMachine together with nx-X11 and nxagent. Nx-X11 is indeed a very old X.org fork (6.9ish). Several remote desktop projects are currently assembling man power to start a rebasing of NX technology against latest X.org (and get it upstreamed). It would be great to have such a skillfull man like you a member of this assembling task force. Greets, Mike -- DAS-NETZWERKTEAM mike gabriel, herweg 7, 24357 fleckeby fon: +49 (1520) 1976148 GnuPG Key ID 0x25771B13 mail: mike.gabr...@das-netzwerkteam.de, http://das-netzwerkteam.de -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#766299: [pkg-x2go-devel] Bug#766299: nxproxy: BIG-REQUESTS patch builds but fails at runtime
Dear Mike, > The nxproxy built for X2Go does not get built against libX11 from Xorg > but against libNX_X11 [1] from NoMachine. > Will this break the GenericEvents part of your patch? Or does it > simply require a patch in libNX_X11? Please update your libNX_X11 file. (Seems you took a copy of some XFree86 1.6 file back in 2003... time to move on? The only change is that you are missing GenericEvents, and so mis-define LASTEvent.) Cheers, Paul Paul Szabo p...@maths.usyd.edu.au http://www.maths.usyd.edu.au/u/psz/ School of Mathematics and Statistics University of SydneyAustralia -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#766299: [pkg-x2go-devel] Bug#766299: nxproxy: BIG-REQUESTS patch builds but fails at runtime
Hi Paul, On Fr 14 Nov 2014 21:40:26 CET, paul.szabo wrote: Dear Mike, Unfortunately, your patch does not build cleanly (FTBFS!). https://jenkins.x2go.org:8443/view/NX/job/nx-libs+nightly+debian-sid/63/console Any idea why? The "actual error" is shown towards the end of that .../console : ClientChannel.cpp:5444:33: error: 'GenericEvent' was not declared ... On my Debian wheezy i386 machine, that declaration comes from line 214 of /usr/include/X11/X.h :? 177 /* Event names. ... ... 213 #define MappingNotify 34 214 #define GenericEvent35 215 #define LASTEvent 36 /* must be bigger than any event # */ ... Is not that so on your build machine? Cheers, Paul The nxproxy built for X2Go does not get built against libX11 from Xorg but against libNX_X11 [1] from NoMachine. Will this break the GenericEvents part of your patch? Or does it simply require a patch in libNX_X11? Greets, Mike [1] http://code.x2go.org/gitweb?p=nx-libs.git;a=blob;f=nx-X11/include/X.h;h=0a9c501fb26e1bb85c6c89cb5c1d4e227bfad39e;hb=b2ac5aaf11ab128ae5a14bf79767c0c390b32221 -- DAS-NETZWERKTEAM mike gabriel, herweg 7, 24357 fleckeby fon: +49 (1520) 1976 148 GnuPG Key ID 0x25771B31 mail: mike.gabr...@das-netzwerkteam.de, http://das-netzwerkteam.de freeBusy: https://mail.das-netzwerkteam.de/freebusy/m.gabriel%40das-netzwerkteam.de.xfb pgpGx4q7IVyWg.pgp Description: Digitale PGP-Signatur
Bug#766299: [pkg-x2go-devel] Bug#766299: nxproxy: BIG-REQUESTS patch builds but fails at runtime
Dear Mike, Seems that I found a reproducible way of getting nxproxy confused: start /usr/bin/chromium then (at some stage) use ctrl-W to close its window: the window will not close but become "empty and transparent", and "nxproxy -C" will show an (endless?) stream of complaints Proxy: WARNING! Handling data for finishing FD#18 channel ID#11. Any ideas on how to solve? Thanks, Paul Paul Szabo p...@maths.usyd.edu.au http://www.maths.usyd.edu.au/u/psz/ School of Mathematics and Statistics University of SydneyAustralia -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#766299: [pkg-x2go-devel] Bug#766299: nxproxy: BIG-REQUESTS patch builds but fails at runtime
Dear Mike, > Unfortunately, your patch does not build cleanly (FTBFS!). > https://jenkins.x2go.org:8443/view/NX/job/nx-libs+nightly+debian-sid/63/console > Any idea why? The "actual error" is shown towards the end of that .../console : ClientChannel.cpp:5444:33: error: 'GenericEvent' was not declared ... On my Debian wheezy i386 machine, that declaration comes from line 214 of /usr/include/X11/X.h : 177 /* Event names. ... ... 213 #define MappingNotify 34 214 #define GenericEvent35 215 #define LASTEvent 36 /* must be bigger than any event # */ ... Is not that so on your build machine? Cheers, Paul Paul Szabo p...@maths.usyd.edu.au http://www.maths.usyd.edu.au/u/psz/ School of Mathematics and Statistics University of SydneyAustralia -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#766299: [pkg-x2go-devel] Bug#766299: nxproxy: BIG-REQUESTS patch builds but fails at runtime
Hi Paul, On Do 13 Nov 2014 23:33:03 CET, Mike Gabriel wrote: Dear Paul, On Mi 12 Nov 2014 21:22:51 CET, Paul Szabo wrote: Dear Mike, My current patches, for BIG-REQUESTS and Generic Event Extension, below. With these, nxproxy works well. (Though, once a crash was observed, unfortunately not "trapped" or de-bugged, yet...) Some other patches, that make nxproxy more useful in my environment, below also (hoping others find them, or those ideas, useful also). --- I compared the efficiency of the various compressors, recorded network traffic generated when using "plain" uncompressed X11 traffic, "ssh -C", dxpc and nxproxy, showing kBytes received and transmitted: Whatplain ssh dxpcnxproxy texworks 6828R 4816T2342R 1240T 3050R 4718T 2535R 429T libreoffice 2055R 199T1205R 130T 1145R 140T 1230R 131T matlab 51691R 1508T2096R 311T 2122R 303T 1894R 232T mathematica5 2508R 1004T1473R 522T 1354R 384T 1307R 312T mathematica933271R 5767T4118R 858T 3465R 4943T 4581R 808T and a certain youtube video in kBytes/sec (approx): Whatplain ssh dxpcnxproxy youtube 22000R 510T 16000R 300T ? 17000R 410T I wonder if it is worthwhile to persist with nxproxy, or maybe should try to use "ssh -C" in some automated way. Cheers, Paul Paul Szabo p...@maths.usyd.edu.au http://www.maths.usyd.edu.au/u/psz/ School of Mathematics and Statistics University of SydneyAustralia big-requests and generic-events patch applied upstream [1]. Once the nightly builds of nx-libs are through, you can obtain bin:packages at [2] Thanks a lot!!! Mike Unfortunately, your patch does not build cleanly (FTBFS!). https://jenkins.x2go.org:8443/view/NX/job/nx-libs+nightly+debian-sid/63/console Any idea why? Mike -- DAS-NETZWERKTEAM mike gabriel, herweg 7, 24357 fleckeby fon: +49 (1520) 1976 148 GnuPG Key ID 0x25771B31 mail: mike.gabr...@das-netzwerkteam.de, http://das-netzwerkteam.de freeBusy: https://mail.das-netzwerkteam.de/freebusy/m.gabriel%40das-netzwerkteam.de.xfb pgp2ME2R0hZ1J.pgp Description: Digitale PGP-Signatur
Bug#766299: [pkg-x2go-devel] Bug#766299: nxproxy: BIG-REQUESTS patch builds but fails at runtime
Dear Paul, On Mi 12 Nov 2014 21:22:51 CET, Paul Szabo wrote: Dear Mike, My current patches, for BIG-REQUESTS and Generic Event Extension, below. With these, nxproxy works well. (Though, once a crash was observed, unfortunately not "trapped" or de-bugged, yet...) Some other patches, that make nxproxy more useful in my environment, below also (hoping others find them, or those ideas, useful also). --- I compared the efficiency of the various compressors, recorded network traffic generated when using "plain" uncompressed X11 traffic, "ssh -C", dxpc and nxproxy, showing kBytes received and transmitted: Whatplain ssh dxpcnxproxy texworks 6828R 4816T2342R 1240T 3050R 4718T 2535R 429T libreoffice 2055R 199T1205R 130T 1145R 140T 1230R 131T matlab 51691R 1508T2096R 311T 2122R 303T 1894R 232T mathematica5 2508R 1004T1473R 522T 1354R 384T 1307R 312T mathematica933271R 5767T4118R 858T 3465R 4943T 4581R 808T and a certain youtube video in kBytes/sec (approx): Whatplain ssh dxpcnxproxy youtube 22000R 510T 16000R 300T ? 17000R 410T I wonder if it is worthwhile to persist with nxproxy, or maybe should try to use "ssh -C" in some automated way. Cheers, Paul Paul Szabo p...@maths.usyd.edu.au http://www.maths.usyd.edu.au/u/psz/ School of Mathematics and Statistics University of SydneyAustralia big-requests and generic-events patch applied upstream [1]. Once the nightly builds of nx-libs are through, you can obtain bin:packages at [2] Thanks a lot!!! Mike [1] http://code.x2go.org/gitweb?p=nx-libs.git;a=commitdiff;h=b2ac5aaf11ab128ae5a14bf79767c0c390b32221 [2] http://packages.x2go.org/debian/pool/heuler/n/nx-libs/ -- DAS-NETZWERKTEAM mike gabriel, herweg 7, 24357 fleckeby fon: +49 (1520) 1976 148 GnuPG Key ID 0x25771B31 mail: mike.gabr...@das-netzwerkteam.de, http://das-netzwerkteam.de freeBusy: https://mail.das-netzwerkteam.de/freebusy/m.gabriel%40das-netzwerkteam.de.xfb pgpp3RvlNbCb8.pgp Description: Digitale PGP-Signatur
Bug#766299: [pkg-x2go-devel] Bug#766299: nxproxy: BIG-REQUESTS patch builds but fails at runtime
Dear Mike, > Do you mean, I should rather still wait with applying your patch > upstream? Need more testing? Or do you actually say that the patch > is stable and the crash has been related to something else? I believe the patches I sent are correct and stable; but that there lurks some other and un-related bug in nxproxy, causing the crash observed. Cheers, Paul Paul Szabo p...@maths.usyd.edu.au http://www.maths.usyd.edu.au/u/psz/ School of Mathematics and Statistics University of SydneyAustralia -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#766299: [pkg-x2go-devel] Bug#766299: nxproxy: BIG-REQUESTS patch builds but fails at runtime
Hi Paul, On Do 13 Nov 2014 04:19:24 CET, paul.szabo wrote: A user just reported to me: Just had an nxproxy crash, running Dropbox, nautilus, firefox, and gedit. Didn't start any particular process when it crashed. [xcb] Unknown sequence number while processing queue [xcb] Most likely this is a multi-threaded client and XInitThreads has not been called [xcb] Aborting, sorry about that. xterm: ../../src/xcb_io.c:274: poll_for_event: Assertion `!xcb_xlib_threads_sequence_lost' failed. ... and there were no error messages from nxproxy itself! Oh... I just released nx-libs 3.5.0.28 upstream to get latest work out in the public and create some space for testing your patch. Do you mean, I should rather still wait with applying your patch upstream? Need more testing? Or do you actually say that the patch is stable and the crash has been related to something else? The more I look at your words, I think the latter. But anyway, please confirm! Thanks, Mike -- DAS-NETZWERKTEAM mike gabriel, herweg 7, 24357 fleckeby fon: +49 (1520) 1976 148 GnuPG Key ID 0x25771B31 mail: mike.gabr...@das-netzwerkteam.de, http://das-netzwerkteam.de freeBusy: https://mail.das-netzwerkteam.de/freebusy/m.gabriel%40das-netzwerkteam.de.xfb pgpgJRw4MTigG.pgp Description: Digitale PGP-Signatur
Bug#766299: [pkg-x2go-devel] Bug#766299: nxproxy: BIG-REQUESTS patch builds but fails at runtime
A user just reported to me: > Just had an nxproxy crash, running Dropbox, nautilus, firefox, and gedit. > Didn't start any particular process when it crashed. > > [xcb] Unknown sequence number while processing queue > [xcb] Most likely this is a multi-threaded client and XInitThreads has not > been called > [xcb] Aborting, sorry about that. > xterm: ../../src/xcb_io.c:274: poll_for_event: Assertion > `!xcb_xlib_threads_sequence_lost' failed. ... and there were no error messages from nxproxy itself! Cheers, Paul Paul Szabo p...@maths.usyd.edu.au http://www.maths.usyd.edu.au/u/psz/ School of Mathematics and Statistics University of SydneyAustralia -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#766299: [pkg-x2go-devel] Bug#766299: nxproxy: BIG-REQUESTS patch builds but fails at runtime
Dear Mike,
My current patches, for BIG-REQUESTS and Generic Event Extension, below.
With these, nxproxy works well. (Though, once a crash was observed,
unfortunately not "trapped" or de-bugged, yet...)
Some other patches, that make nxproxy more useful in my environment,
below also (hoping others find them, or those ideas, useful also).
---
I compared the efficiency of the various compressors, recorded network
traffic generated when using "plain" uncompressed X11 traffic, "ssh -C",
dxpc and nxproxy, showing kBytes received and transmitted:
Whatplain ssh dxpcnxproxy
texworks 6828R 4816T2342R 1240T 3050R 4718T 2535R 429T
libreoffice 2055R 199T1205R 130T 1145R 140T 1230R 131T
matlab 51691R 1508T2096R 311T 2122R 303T 1894R 232T
mathematica5 2508R 1004T1473R 522T 1354R 384T 1307R 312T
mathematica933271R 5767T4118R 858T 3465R 4943T 4581R 808T
and a certain youtube video in kBytes/sec (approx):
Whatplain ssh dxpcnxproxy
youtube 22000R 510T 16000R 300T ? 17000R 410T
I wonder if it is worthwhile to persist with nxproxy, or maybe should
try to use "ssh -C" in some automated way.
Cheers, Paul
Paul Szabo p...@maths.usyd.edu.au http://www.maths.usyd.edu.au/u/psz/
School of Mathematics and Statistics University of SydneyAustralia
--- ClientChannel.cpp-prePSz 2012-03-08 06:53:30.0 +1100
+++ ClientChannel.cpp 2014-11-11 06:33:57.0 +1100
@@ -447,6 +447,26 @@
}
}
+ // Get other bits of the header, so will not need to refer to them again
+ unsigned char inputDataByte = inputMessage[1];
+ unsigned int buffer2 = GetUINT(inputMessage + 2, bigEndian_);
+ unsigned int inputDataSize = buffer2 - 1;
+ if (buffer2 == 0)
+ {
+// BIG-REQUESTS
+inputMessage += 4;
+inputLength -= 4;
+inputDataSize = GetULONG(inputMessage, bigEndian_) - 2;
+ }
+ if (inputLength != (4 * (inputDataSize + 1)))
+ {
+#ifdef WARNING
+*logofs << "handleRead: inputLength=" << inputLength
+<< " mismatch inputDataSize=" << inputDataSize
+<< ".\n" << logofs_flush;
+#endif
+ }
+
//
// Go to the message's specific encoding.
//
@@ -455,6 +475,11 @@
{
case X_AllocColor:
{
+ #ifdef WARNING
+ if (inputLength < 14)
+*logofs << "handleRead: X_AllocColor inputLength=" << inputLength
+<< ".\n" << logofs_flush;
+ #endif
encodeBuffer.encodeCachedValue(GetULONG(inputMessage + 4, bigEndian_), 29,
clientCache_ -> colormapCache);
const unsigned char *nextSrc = inputMessage + 8;
@@ -476,6 +501,11 @@
break;
case X_ReparentWindow:
{
+ #ifdef WARNING
+ if (inputLength < 16)
+*logofs << "handleRead: X_ReparentWindow inputLength=" << inputLength
+<< ".\n" << logofs_flush;
+ #endif
encodeBuffer.encodeXidValue(GetULONG(inputMessage + 4, bigEndian_),
clientCache_ -> windowCache);
encodeBuffer.encodeXidValue(GetULONG(inputMessage + 8, bigEndian_),
@@ -486,6 +516,11 @@
break;
case X_ChangeProperty:
{
+ #ifdef WARNING
+ if (inputLength < 24)
+*logofs << "handleRead: X_ChangeProperty inputLength=" << inputLength
+<< ".\n" << logofs_flush;
+ #endif
MessageStore *messageStore = clientStore_ ->
getRequestStore(X_ChangeProperty);
@@ -501,8 +536,36 @@
encodeBuffer.encodeCachedValue(format, 8,
clientCache_ -> changePropertyFormatCache);
unsigned int dataLength = GetULONG(inputMessage + 20, bigEndian_);
+
+ // Self-preserving sanity check (otherwise we crash and dump core):
+ // some clients do this when not getting their beloved BIG-REQUESTS.
+ unsigned int maxLength = 0;
+ if (format == 8)
+ {
+maxLength = inputLength - 24;
+ }
+ else if (format == 32)
+ {
+maxLength = (inputLength - 24) >> 2;
+ }
+ else if (format == 16)
+ {
+maxLength = (inputLength - 24) >> 1;
+ }
+ if (dataLength > maxLength)
+ {
+#ifdef WARNING
+*logofs << "handleRead X_ChangeProperty bogus dataLength=" << dataLength
+<< " set to " << maxLength
+<< " when format=" << (int)format
+<< " inputLength=" << inputLength
+<< ".\n" << logofs_flush;
+#endif
+dataLength = maxLength;
+
Bug#766299: [pkg-x2go-devel] Bug#766299: nxproxy: BIG-REQUESTS patch builds but fails at runtime
Hi Paul, On Fr 07 Nov 2014 10:50:33 CET, paul.szabo wrote: Dear Mike, Maybe the issue is X Generic Event Extension http://www.x.org/releases/X11R7.7/doc/xextproto/geproto.html of variable length, as yet un-supported by nxproxy? Pre-empting anything below: I have now added code to nxproxy to correctly handle (support) "X Generic Event Extension" messages, and nautilus runs happy. - I will now test for a few more days, clean up my code (removing the debug lines), then post the patches. AWESOME!!! Looking forward to that/those patch/es. --- Seems that the issues I had with sequence numbers were a result of nxproxy mis-interpreting the data stream: my GenEvt patches seem to have "cured" those complaints. ok... --- the question here again is if nautilus crashes (a) in nxagent scenarios (b) in nxproxy -S + Xvfb/Xephyr scenarios I do not use nxagent, have no need for it. I do not use Xvfb or Xephyr, but use the Xorg server. Do you test nautilus in some desktop shell (e.g. GNOMEv3) or do you launch nautilus as a standalone (aka rootless, seamless) application? If server-side applications bind to nxproxy -S directly, then the code path (very roughly speaking) should be: (1) nautilus (1.1) libcairo (1.2) lib-X.Org's client extensions (e.g. libXext, libXrandr, etc.) (2) nxproxy -S (3) nxproxy -C (4) X.org server on client-side What I have is: on the "thin client" I run: Xorg -query loginserver DISPLAY=:0 nxproxy -S then log in to loginserver without any nxproxy involvement. On loginserver I have GDM2 running with XDMCP enabled. At login I run some session (maybe gnome or xfce or fluxbox, or something homegrown). For now, manually (in an xterm) I run nxproxy -C link=1m connect=thinclient and then use things like DISPLAY=:8 nautilus (or "DISPLAY=:8 xterm" and run further things from there). My plan, once nxproxy is "stable", is to run "nxproxy -C" within /etc/gdm/Xsession and set the new DISPLAY there, so the whole login session will go through nxproxy. OT here: Note that I plan to package MDM (the GDM2 fork in Linux Mint) for Debian. Depending on the cooperation upstream (Linux Mint) I may simply use their MDM version or even fork MDM (as MATE Display Manager then, or something similar). Also, nautilus may request some extension not supported on our client-side system. Or request an extension version that's not available. ... I have no idea what extensions the Xorg server, or clients like nautilus, may handle. My feeling is that nxproxy should be "transparent": if things work without it (whatever both nautilus and Xorg handle), then nxproxy should allow it unchanged. If nxproxy wants to be smart and make sense of the X protocol (and achieve a better result than e.g. "ssh -C -X") then it should be so (smart and actually understand the X protocol). /me nods on the above. Thanks for your great and persevering work on this! Mike -- DAS-NETZWERKTEAM mike gabriel, herweg 7, 24357 fleckeby fon: +49 (1520) 1976 148 GnuPG Key ID 0x25771B31 mail: mike.gabr...@das-netzwerkteam.de, http://das-netzwerkteam.de freeBusy: https://mail.das-netzwerkteam.de/freebusy/m.gabriel%40das-netzwerkteam.de.xfb pgpYzfjsCrzNS.pgp Description: Digitale PGP-Signatur
Bug#766299: [pkg-x2go-devel] Bug#766299: nxproxy: BIG-REQUESTS patch builds but fails at runtime
Dear Mike, >> Maybe the issue is >> X Generic Event Extension >> http://www.x.org/releases/X11R7.7/doc/xextproto/geproto.html >> of variable length, as yet un-supported by nxproxy? Pre-empting anything below: I have now added code to nxproxy to correctly handle (support) "X Generic Event Extension" messages, and nautilus runs happy. - I will now test for a few more days, clean up my code (removing the debug lines), then post the patches. --- Seems that the issues I had with sequence numbers were a result of nxproxy mis-interpreting the data stream: my GenEvt patches seem to have "cured" those complaints. --- > the question here again is if nautilus crashes >(a) in nxagent scenarios >(b) in nxproxy -S + Xvfb/Xephyr scenarios I do not use nxagent, have no need for it. I do not use Xvfb or Xephyr, but use the Xorg server. > Do you test nautilus in some desktop shell (e.g. GNOMEv3) or do you > launch nautilus as a standalone (aka rootless, seamless) application? > > If server-side applications bind to nxproxy -S directly, then the code > path (very roughly speaking) should be: > >(1) nautilus >(1.1) libcairo >(1.2) lib-X.Org's client extensions (e.g. libXext, libXrandr, etc.) >(2) nxproxy -S >(3) nxproxy -C >(4) X.org server on client-side What I have is: on the "thin client" I run: Xorg -query loginserver DISPLAY=:0 nxproxy -S then log in to loginserver without any nxproxy involvement. On loginserver I have GDM2 running with XDMCP enabled. At login I run some session (maybe gnome or xfce or fluxbox, or something homegrown). For now, manually (in an xterm) I run nxproxy -C link=1m connect=thinclient and then use things like DISPLAY=:8 nautilus (or "DISPLAY=:8 xterm" and run further things from there). My plan, once nxproxy is "stable", is to run "nxproxy -C" within /etc/gdm/Xsession and set the new DISPLAY there, so the whole login session will go through nxproxy. > Also, nautilus may request some extension not supported on our > client-side system. Or request an extension version that's not > available. ... I have no idea what extensions the Xorg server, or clients like nautilus, may handle. My feeling is that nxproxy should be "transparent": if things work without it (whatever both nautilus and Xorg handle), then nxproxy should allow it unchanged. If nxproxy wants to be smart and make sense of the X protocol (and achieve a better result than e.g. "ssh -C -X") then it should be so (smart and actually understand the X protocol). Cheers, Paul Paul Szabo p...@maths.usyd.edu.au http://www.maths.usyd.edu.au/u/psz/ School of Mathematics and Statistics University of SydneyAustralia -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#766299: [pkg-x2go-devel] Bug#766299: nxproxy: BIG-REQUESTS patch builds but fails at runtime
Hi Paul, On Mi 05 Nov 2014 21:43:15 CET, paul.szabo wrote: I just wrote: Further testing suggests that as nautilus is about to die, it gets a GenericEvent opcode=35 and then an event with opcode=0, then it dies. Maybe the issue is X Generic Event Extension http://www.x.org/releases/X11R7.7/doc/xextproto/geproto.html of variable length, as yet un-supported by nxproxy? the question here again is if nautilus crashes (a) in nxagent scenarios (b) in nxproxy -S + Xvfb/Xephyr scenarios While writing the above... Does nautilus directly bind to nxproxy -S or do you have a Xephyr (or Xvfb) xserver instance that nautilus then runs in / crashes in? Do you test nautilus in some desktop shell (e.g. GNOMEv3) or do you launch nautilus as a standalone (aka rootless, seamless) application? If server-side applications bind to nxproxy -S directly, then the code path (very roughly speaking) should be: (1) nautilus (1.1) libcairo (1.2) lib-X.Org's client extensions (e.g. libXext, libXrandr, etc.) (2) nxproxy -S (3) nxproxy -C (4) X.org server on client-side So, basically, nxproxy should allow pass-through of everything that libx11-* produces and it should be proxies through to the client side X.org. On the other hand, when Debian wheezy was in its final testing phase, we had loads of NX breakage (nxagent, that was) by libcairo. Do you see anything in the session logs of nxproxy (or in the debug output if enabled at build time) that alludes to nxproxy being the cause of those crashes? Also, nautilus may request some extension not supported on our client-side system. Or request an extension version that's not available. (This is more likely, when nautilus runs on top of nxagent, though). Can you detect where in nautilus the crash occurs? It may be helpful looking at the nautilus / libcairo code that causes the crash. Greets, Mike -- DAS-NETZWERKTEAM mike gabriel, herweg 7, 24357 fleckeby fon: +49 (1520) 1976 148 GnuPG Key ID 0x25771B31 mail: mike.gabr...@das-netzwerkteam.de, http://das-netzwerkteam.de freeBusy: https://mail.das-netzwerkteam.de/freebusy/m.gabriel%40das-netzwerkteam.de.xfb pgppiYQYfh9rI.pgp Description: Digitale PGP-Signatur
Bug#766299: [pkg-x2go-devel] Bug#766299: nxproxy: BIG-REQUESTS patch builds but fails at runtime
I just wrote: Further testing suggests that as nautilus is about to die, it gets a GenericEvent opcode=35 and then an event with opcode=0, then it dies. Maybe the issue is X Generic Event Extension http://www.x.org/releases/X11R7.7/doc/xextproto/geproto.html of variable length, as yet un-supported by nxproxy? Cheers, Paul Paul Szabo p...@maths.usyd.edu.au http://www.maths.usyd.edu.au/u/psz/ School of Mathematics and Statistics University of SydneyAustralia -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#766299: [pkg-x2go-devel] Bug#766299: nxproxy: BIG-REQUESTS patch builds but fails at runtime
Further testing suggests that as nautilus is about to die, it gets a GenericEvent opcode=35 and then an event with opcode=0, then it dies. Cheers, Paul Paul Szabo p...@maths.usyd.edu.au http://www.maths.usyd.edu.au/u/psz/ School of Mathematics and Statistics University of SydneyAustralia -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#766299: [pkg-x2go-devel] Bug#766299: nxproxy: BIG-REQUESTS patch builds but fails at runtime
On So 02 Nov 2014 22:12:00 CET, paul.szabo wrote: Dear Mike, While looking into the handling of sequence numbers, I notice: http://www.x.org/releases/X11R7.7/doc/xproto/x11protocol.html ... Every request on a given connection is implicitly assigned a sequence number, starting with one ... Does that mean that each connection should keep its own state of sequence number (and caches etc)? Whereas, nxproxy (both -C and -S instances) seems to keep just one state, across all clients and connections. Though admittedly, even when nautilus is the first and only client, it still fails and maybe complains (as reported already); in my testing it may get to show its window, then fail as the mouse pointer moves within. Thanks, Paul Paul, sorry, I have been quite busy the last 8-10 days. I will get back to you asap (not before next week). Mike -- DAS-NETZWERKTEAM mike gabriel, herweg 7, 24357 fleckeby fon: +49 (1520) 1976 148 GnuPG Key ID 0x25771B31 mail: mike.gabr...@das-netzwerkteam.de, http://das-netzwerkteam.de freeBusy: https://mail.das-netzwerkteam.de/freebusy/m.gabriel%40das-netzwerkteam.de.xfb pgpYw1Xx8b1TC.pgp Description: Digitale PGP-Signatur
Bug#766299: nxproxy: BIG-REQUESTS patch builds but fails at runtime
Dear Mike, While looking into the handling of sequence numbers, I notice: http://www.x.org/releases/X11R7.7/doc/xproto/x11protocol.html ... Every request on a given connection is implicitly assigned a sequence number, starting with one ... Does that mean that each connection should keep its own state of sequence number (and caches etc)? Whereas, nxproxy (both -C and -S instances) seems to keep just one state, across all clients and connections. Though admittedly, even when nautilus is the first and only client, it still fails and maybe complains (as reported already); in my testing it may get to show its window, then fail as the mouse pointer moves within. Thanks, Paul Paul Szabo p...@maths.usyd.edu.au http://www.maths.usyd.edu.au/u/psz/ School of Mathematics and Statistics University of SydneyAustralia -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#766299: nxproxy: BIG-REQUESTS patch builds but fails at runtime
Hi Paul, I will get you together with one of our NX adepts over the weekend. Could you join us on IRC (#x2go at Freenode)? I will be travelling during the day and only be scarce online... Mike -- DAS-NETZWERKTEAM mike gabriel, herweg 7, 24357 fleckeby fon: +49 (1520) 1976148 GnuPG Key ID 0x25771B13 mail: mike.gabr...@das-netzwerkteam.de, http://das-netzwerkteam.de - Original message - > Dear Mike, > > Could you explain to me, or point me to some documentation, about the > use of sequence numbers in X11 generally, and in nxproxy specifically? > Even more specifically, as noted in my latest patches: > > ClientChannel.cpp: > // With outputOpcode=X_UnmapSubwindows mostly we get > sequenceNum=0, // sometimes (rarely) get sequenceNum = 256. Maybe > surprising, but // "normal" and should be accepted. > > ServerChannel.cpp: > // We normally get inputSequence=0 for > inputOpcode=X_UnmapSubwindows > > Should nxproxy "accept" those zeroes, or should it handle them in some > special way? Do any other opcodes reply with a zeroed sequence number? > > Am I on the wrong track, barking up the wrong tree? > > Thanks, Paul > > Paul Szabo p...@maths.usyd.edu.au http://www.maths.usyd.edu.au/u/psz/ > School of Mathematics and Statistics University of Sydney Australia > -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#766299: nxproxy: BIG-REQUESTS patch builds but fails at runtime
Dear Mike, Could you explain to me, or point me to some documentation, about the use of sequence numbers in X11 generally, and in nxproxy specifically? Even more specifically, as noted in my latest patches: ClientChannel.cpp: // With outputOpcode=X_UnmapSubwindows mostly we get sequenceNum=0, // sometimes (rarely) get sequenceNum = 256. Maybe surprising, but // "normal" and should be accepted. ServerChannel.cpp: // We normally get inputSequence=0 for inputOpcode=X_UnmapSubwindows Should nxproxy "accept" those zeroes, or should it handle them in some special way? Do any other opcodes reply with a zeroed sequence number? Am I on the wrong track, barking up the wrong tree? Thanks, Paul Paul Szabo p...@maths.usyd.edu.au http://www.maths.usyd.edu.au/u/psz/ School of Mathematics and Statistics University of SydneyAustralia -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#766299: nxproxy: BIG-REQUESTS patch builds but fails at runtime
Dear Mike, I spoke too soon. I wrote: ... some bogosity with sequence numbers. ... [solved] but just a little further testing shows: psz@como:~$ nautilus Initializing nautilus-open-terminal extension [xcb] Unknown sequence number while processing queue [xcb] Most likely this is a multi-threaded client and XInitThreads has not been called [xcb] Aborting, sorry about that. nautilus: ../../src/xcb_io.c:274: poll_for_event: Assertion `!xcb_xlib_threads_sequence_lost' failed. Aborted Any ideas on where I should look? Thanks, Paul Paul Szabo p...@maths.usyd.edu.au http://www.maths.usyd.edu.au/u/psz/ School of Mathematics and Statistics University of SydneyAustralia -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#766299: nxproxy: BIG-REQUESTS patch builds but fails at runtime
Dear Mike,
I wrote a few days ago about a crash with kile: was due to a too-tight
setting of some OVERFLOW limit.
Other testing showed some bogosity with sequence numbers.
The patch below (replacing the one sent previously) solves the above
issues; after some (but necessarily limited) testing, I am not aware of
any other issues.
Cheers, Paul
--- ClientChannel.cpp-prePSz 2012-03-08 06:53:30.0 +1100
+++ ClientChannel.cpp 2014-10-31 09:07:03.0 +1100
@@ -447,6 +447,26 @@
}
}
+ // Get other bits of the header, so will not need to refer to them again
+ unsigned char inputDataByte = inputMessage[1];
+ unsigned int buffer2 = GetUINT(inputMessage + 2, bigEndian_);
+ unsigned int inputDataSize = buffer2 - 1;
+ if (buffer2 == 0)
+ {
+// BIG-REQUESTS
+inputMessage += 4;
+inputLength -= 4;
+inputDataSize = GetULONG(inputMessage, bigEndian_) - 2;
+ }
+ if (inputLength != (4 * (inputDataSize + 1)))
+ {
+#ifdef WARNING
+*logofs << "handleRead: inputLength=" << inputLength
+<< " mismatch inputDataSize=" << inputDataSize
+<< ".\n" << logofs_flush;
+#endif
+ }
+
//
// Go to the message's specific encoding.
//
@@ -455,6 +475,11 @@
{
case X_AllocColor:
{
+ #ifdef WARNING
+ if (inputLength < 14)
+*logofs << "handleRead: X_AllocColor inputLength=" << inputLength
+<< ".\n" << logofs_flush;
+ #endif
encodeBuffer.encodeCachedValue(GetULONG(inputMessage + 4, bigEndian_), 29,
clientCache_ -> colormapCache);
const unsigned char *nextSrc = inputMessage + 8;
@@ -476,6 +501,11 @@
break;
case X_ReparentWindow:
{
+ #ifdef WARNING
+ if (inputLength < 16)
+*logofs << "handleRead: X_ReparentWindow inputLength=" << inputLength
+<< ".\n" << logofs_flush;
+ #endif
encodeBuffer.encodeXidValue(GetULONG(inputMessage + 4, bigEndian_),
clientCache_ -> windowCache);
encodeBuffer.encodeXidValue(GetULONG(inputMessage + 8, bigEndian_),
@@ -486,6 +516,11 @@
break;
case X_ChangeProperty:
{
+ #ifdef WARNING
+ if (inputLength < 24)
+*logofs << "handleRead: X_ChangeProperty inputLength=" << inputLength
+<< ".\n" << logofs_flush;
+ #endif
MessageStore *messageStore = clientStore_ ->
getRequestStore(X_ChangeProperty);
@@ -501,8 +536,36 @@
encodeBuffer.encodeCachedValue(format, 8,
clientCache_ -> changePropertyFormatCache);
unsigned int dataLength = GetULONG(inputMessage + 20, bigEndian_);
+
+ // Self-preserving sanity check (otherwise we crash and dump core):
+ // some clients do this when not getting their beloved BIG-REQUESTS.
+ unsigned int maxLength = 0;
+ if (format == 8)
+ {
+maxLength = inputLength - 24;
+ }
+ else if (format == 32)
+ {
+maxLength = (inputLength - 24) >> 2;
+ }
+ else if (format == 16)
+ {
+maxLength = (inputLength - 24) >> 1;
+ }
+ if (dataLength > maxLength)
+ {
+#ifdef WARNING
+*logofs << "handleRead X_ChangeProperty bogus dataLength=" << dataLength
+<< " set to " << maxLength
+<< " when format=" << (int)format
+<< " inputLength=" << inputLength
+<< ".\n" << logofs_flush;
+#endif
+dataLength = maxLength;
+ }
+
encodeBuffer.encodeValue(dataLength, 32, 6);
- encodeBuffer.encodeValue(inputMessage[1], 2);
+ encodeBuffer.encodeValue(inputDataByte, 2);
encodeBuffer.encodeXidValue(GetULONG(inputMessage + 4, bigEndian_),
clientCache_ -> windowCache);
encodeBuffer.encodeCachedValue(GetULONG(inputMessage + 8, bigEndian_), 29,
@@ -533,7 +596,7 @@
nextSrc += 4;
}
}
- else
+ else if (format == 16)
{
for (unsigned int i = 0; i < dataLength; i++)
{
@@ -541,6 +604,13 @@
nextSrc += 2;
}
}
+ else
+ {
+#ifdef WARNING
+*logofs << "ChangeProperty bogus format=" << (int)format
+<< ".\n" << logofs_flush;
+#endif
+ }
}
break;
case X_SendEvent:
@@ -551,6 +621,11 @@
// ratio.
//
+ #ifdef WARNING
+ if (inputLength < 44)
+*logofs << "handleRead: X_SendEvent inputLe
Bug#766299: nxproxy: BIG-REQUESTS patch builds but fails at runtime
On Di 28 Okt 2014 12:46:10 CET, paul.szabo wrote: I have asked my users to test nxproxy, and will attempt to fix all issues as they become apparent. When nxproxy seems "stable", I intend to make it the default: start "nxproxy -S" with Xorg on the thin client, and start "nxproxy -C" and do the xauth and DISPLAY "switcheroo" within the GDM2 Xsession. I will report back here as I go. nxagent = nxproxy -S + (old) Xorg you could use nxagent instead of Xorg and connect to it directly with nxproxy -C from the client side. See [1] for the way nxagent gets launched in X2Go. Mike [1] http://code.x2go.org/gitweb?p=x2goserver.git;a=blob;f=x2goserver/bin/x2gostartagent;h=910eaa6a61202cf053433c82b5e9de527cf822a1;hb=724d1dcf77a591d07ba0838ee3772a402fbada76#l360 -- DAS-NETZWERKTEAM mike gabriel, herweg 7, 24357 fleckeby fon: +49 (1520) 1976 148 GnuPG Key ID 0x25771B31 mail: mike.gabr...@das-netzwerkteam.de, http://das-netzwerkteam.de freeBusy: https://mail.das-netzwerkteam.de/freebusy/m.gabriel%40das-netzwerkteam.de.xfb pgpnPJ7KAu_kE.pgp Description: Digitale PGP-Signatur
Bug#766299: nxproxy: BIG-REQUESTS patch builds but fails at runtime
Hi Paul, On Di 28 Okt 2014 12:46:10 CET, paul.szabo wrote: Dear Mike, If it is not possible to dynamically detect if 16 or 32 bit encoding is used on the server-side (the client-side should be the flexible part), then your patch has to wait for that rewrite to come (a design change then is absolutely ok and wanted). I don't think we should break compatibility within the 3.5.0.x release series. So again, do you see an option for detecting the server-side encoding (or querying it or triggering/enforcing it via a nxagent cmdline option)? That would be do-able, but probably not practical. The two nxproxy-ies could somehow try to detect whether the other is also capable of BIG-REQUESTS, and if so use 32-bit encodings and not use the HIDE_BIG_REQUESTS_EXTENSION setting; but if not then fall back to 16-bit and to hide. That would make the code even more messy (and likely, buggy) than it is now. PS: How do you test if the BIG-REQUESTS implementation works? With TexPower, you said. What do I have to do to trigger the BIG-REQUESTS bug if nx is not patched? It is texworks from http://tug.org/texworks http://code.google.com/p/texworks/wiki/Building All you need to trigger the bug is to run texworks. Having scrutinized things, it does QueryExtension on BIG-REQUESTS; if not getting it (because of nxproxy hide as now), then sends "broken" (ill-formatted) X11 stream that crashes the "nxproxy -C" side. With my patches, it uses BIG-REQUESTS just fine. --- One of my users told me that my patched nxproxy would crash when using kile (on his special TeX file), seems it is the "nxproxy -S" side that crashes. I am now working on reproducing this, and intend to fix. I have asked my users to test nxproxy, and will attempt to fix all issues as they become apparent. When nxproxy seems "stable", I intend to make it the default: start "nxproxy -S" with Xorg on the thin client, and start "nxproxy -C" and do the xauth and DISPLAY "switcheroo" within the GDM2 Xsession. I will report back here as I go. Cheers, Paul While working on that (have I mentioned this before? Have written too many mails today already...): A generic nxproxy has to be Big+Little Endian safe. The X2Go project is about to start a cooperation with IBM and we are about to get sponsored a PowerPC64 build machine (BE afair). So while juggling with bits and bytes, please consider Endianness during your awesome patch work!!! (NX is a complete pile of patches, actually, but the nx-libs repo is far more advanced than anything else out there derived from the NX3.5 series). Greets, Mike -- DAS-NETZWERKTEAM mike gabriel, herweg 7, 24357 fleckeby fon: +49 (1520) 1976 148 GnuPG Key ID 0x25771B31 mail: mike.gabr...@das-netzwerkteam.de, http://das-netzwerkteam.de freeBusy: https://mail.das-netzwerkteam.de/freebusy/m.gabriel%40das-netzwerkteam.de.xfb pgpWdP5RVBAha.pgp Description: Digitale PGP-Signatur
Bug#766299: nxproxy: BIG-REQUESTS patch builds but fails at runtime
Dear Mike, > If it is not possible to dynamically detect if 16 or 32 bit encoding > is used on the server-side (the client-side should be the flexible > part), then your patch has to wait for that rewrite to come (a design > change then is absolutely ok and wanted). I don't think we should > break compatibility within the 3.5.0.x release series. > > So again, do you see an option for detecting the server-side encoding > (or querying it or triggering/enforcing it via a nxagent cmdline > option)? That would be do-able, but probably not practical. The two nxproxy-ies could somehow try to detect whether the other is also capable of BIG-REQUESTS, and if so use 32-bit encodings and not use the HIDE_BIG_REQUESTS_EXTENSION setting; but if not then fall back to 16-bit and to hide. That would make the code even more messy (and likely, buggy) than it is now. > PS: How do you test if the BIG-REQUESTS implementation works? With > TexPower, you said. What do I have to do to trigger the BIG-REQUESTS > bug if nx is not patched? It is texworks from http://tug.org/texworks http://code.google.com/p/texworks/wiki/Building All you need to trigger the bug is to run texworks. Having scrutinized things, it does QueryExtension on BIG-REQUESTS; if not getting it (because of nxproxy hide as now), then sends "broken" (ill-formatted) X11 stream that crashes the "nxproxy -C" side. With my patches, it uses BIG-REQUESTS just fine. --- One of my users told me that my patched nxproxy would crash when using kile (on his special TeX file), seems it is the "nxproxy -S" side that crashes. I am now working on reproducing this, and intend to fix. I have asked my users to test nxproxy, and will attempt to fix all issues as they become apparent. When nxproxy seems "stable", I intend to make it the default: start "nxproxy -S" with Xorg on the thin client, and start "nxproxy -C" and do the xauth and DISPLAY "switcheroo" within the GDM2 Xsession. I will report back here as I go. Cheers, Paul Paul Szabo p...@maths.usyd.edu.au http://www.maths.usyd.edu.au/u/psz/ School of Mathematics and Statistics University of SydneyAustralia -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#766299: nxproxy: BIG-REQUESTS patch builds but fails at runtime
Hi Paul, On Di 28 Okt 2014 08:09:16 CET, paul.szabo wrote: Dear Mike, You have the new, patched nxproxy on both ends of the connection? The encoding of the data has changed. ... nxagent and nxproxy are installed onto different systems from different sources ... So, this should be handled by your code then, I guess. The encoding must change: some lengths must be sent; with BIG-REQUEST they can be larger than 16 bits; and (for super-efficiency reasons?) they were encoded into just 16 bits. I see no work-around other than to change the encoding to 32 bits, as I did in my patch. Please let me know if you can think of some other way. The best that could be done is for nxproxy to detect the version used on the other end, and refuse to talk if they did not match. Please let me know if you think that would be worthwhile to pursue. In the past, I see exactly similar, incompatible version changes, e.g.: - dxpc 3.9.0 being incompatible with earlier versions http://www.vigor.nu/dxpc/README - NX 3.5.0 issues with NoMachine 4 https://www.nomachine.com/AR10I00603 I guess such is the price of progress, of having made the wrong design choices (as seen in hindsight). Cheers, Paul We plan to crowd-fund a rewrite of NX. I made arrangements with Keith Packard (Mr. X.Org) on DebConf13 in Switzerland that once we come up with an integrative solution, he will support us with getting our NX rewrite into X.Org upstream. If it is not possible to dynamically detect if 16 or 32 bit encoding is used on the server-side (the client-side should be the flexible part), then your patch has to wait for that rewrite to come (a design change then is absolutely ok and wanted). I don't think we should break compatibility within the 3.5.0.x release series. So again, do you see an option for detecting the server-side encoding (or querying it or triggering/enforcing it via a nxagent cmdline option)? Thanks once more for working on this!!! Mike PS: How do you test if the BIG-REQUESTS implementation works? With TexPower, you said. What do I have to do to trigger the BIG-REQUESTS bug if nx is not patched? -- DAS-NETZWERKTEAM mike gabriel, herweg 7, 24357 fleckeby fon: +49 (1520) 1976 148 GnuPG Key ID 0x25771B31 mail: mike.gabr...@das-netzwerkteam.de, http://das-netzwerkteam.de freeBusy: https://mail.das-netzwerkteam.de/freebusy/m.gabriel%40das-netzwerkteam.de.xfb pgp04pLmsGl5C.pgp Description: Digitale PGP-Signatur
Bug#766299: nxproxy: BIG-REQUESTS patch builds but fails at runtime
Dear Mike, >> You have the new, patched nxproxy on both ends of the connection? >> The encoding of the data has changed. > ... > nxagent and nxproxy are installed onto different systems from > different sources ... > So, this should be handled by your code then, I guess. The encoding must change: some lengths must be sent; with BIG-REQUEST they can be larger than 16 bits; and (for super-efficiency reasons?) they were encoded into just 16 bits. I see no work-around other than to change the encoding to 32 bits, as I did in my patch. Please let me know if you can think of some other way. The best that could be done is for nxproxy to detect the version used on the other end, and refuse to talk if they did not match. Please let me know if you think that would be worthwhile to pursue. In the past, I see exactly similar, incompatible version changes, e.g.: - dxpc 3.9.0 being incompatible with earlier versions http://www.vigor.nu/dxpc/README - NX 3.5.0 issues with NoMachine 4 https://www.nomachine.com/AR10I00603 I guess such is the price of progress, of having made the wrong design choices (as seen in hindsight). Cheers, Paul Paul Szabo p...@maths.usyd.edu.au http://www.maths.usyd.edu.au/u/psz/ School of Mathematics and Statistics University of SydneyAustralia -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#766299: nxproxy: BIG-REQUESTS patch builds but fails at runtime
Hi Paul, On Di 28 Okt 2014 00:17:55 CET, paul.szabo wrote: Dear Mike, I test your patch and it results in several nxproxy crashes ... You have the new, patched nxproxy on both ends of the connection? The encoding of the data has changed. Cheers, Paul Ah... Good point. No. And this would also be a very rare use case. In my test case, I had a new nxproxy on the client-side, but tested against a non-patched nxagent (which has libxcomp compiled-in). nxagent and nxproxy are installed onto different systems from different sources (official distro archives, X2Go Client for Windows, etc.). Only nxagent comes from packages.x2go.org, but people might upgrade the client-side, but not the server-side and vice versa. So, this should be handled by your code then, I guess. Glad we are about to narrow that down, actually. Greets, Mike -- DAS-NETZWERKTEAM mike gabriel, herweg 7, 24357 fleckeby fon: +49 (1520) 1976 148 GnuPG Key ID 0x25771B31 mail: mike.gabr...@das-netzwerkteam.de, http://das-netzwerkteam.de freeBusy: https://mail.das-netzwerkteam.de/freebusy/m.gabriel%40das-netzwerkteam.de.xfb pgphOo9j7Jt3_.pgp Description: Digitale PGP-Signatur
Bug#766299: nxproxy: BIG-REQUESTS patch builds but fails at runtime
Dear Mike, > I test your patch and it results in several nxproxy crashes ... You have the new, patched nxproxy on both ends of the connection? The encoding of the data has changed. Cheers, Paul Paul Szabo p...@maths.usyd.edu.au http://www.maths.usyd.edu.au/u/psz/ School of Mathematics and Statistics University of SydneyAustralia -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#766299: nxproxy: BIG-REQUESTS patch builds but fails at runtime
Dear Mike, Thanks for the various infos, will follow up sometime. > ... I decided not to package MDM for Debian ... [conflict] GDMv3 ... Pity, I would be happy to ditch the buggy GDM3. On wheezy I still use GDM2 from squeeze (replacing GDM3), unfortunately that does not work on jessie anymore. I have my "own" LTSP-lookalike, a PXE-booted Linux environment, that runs "Xorg -query server", and is where I am looking to improve X traffic. (Now to get on with some coding/patching in nxproxy...) Thanks, Paul Paul Szabo p...@maths.usyd.edu.au http://www.maths.usyd.edu.au/u/psz/ School of Mathematics and Statistics University of SydneyAustralia -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#766299: nxproxy: BIG-REQUESTS patch builds but fails at runtime
Hi Paul, On Mo 27 Okt 2014 22:02:02 CET, paul.szabo wrote: Dear Mike, A MATE session is a session running the MATE desktop environment. It is available in Debian jessie. MATE is GNOME desktop environment (version 2) continued. It is _the_ recommended desktop environment for remote desktop usage on Linux at the moment. ... Where is that recommendation documented? https://ubuntu-mate.org/about/ (search the page for "X2Go" or "LTSP"). Does MATE contain a replacement for GDM, with XDMCP support? Or, how else to provide for remote thin clients? The X2Go (and the LTSP) project provides their own thinclient PXE chroots. In X2Go, I am currently working on X2Go Thinclient Environment 1.5 [1]. The thinclient launches a minimal desktop locally on the thin client (also a MATE desktop, with iceweasel and flashplugin installed). On that minimal thinclient desktop (session comes up with autologin feature of lightdm), you find a desktop icon "X2Go Client". With X2Go Client you can connect to other X2Go Servers on your network. X2Go also supports connecting to a display/login manager (like GDM/KDM) that supports the XDMCP protocol. MATE is not tied to any display/login manager per-se (neither is GNOME tied to GDM, nor KDE tied to KDM). When using LTSP, you run the LTSP Display Manager on the LTSP Servers and hook the LTSP thinclient onto them. Back to your question, if MATE has a display manager of its own: The old GDMv2 code has been forked by the Linux Mint project (MDM -> Mint Display Manager). However, the fork was not done cleanly and there are many files that cannot be installed in parallel with GDMv3. :-( Also, the efforts of two MATE developers of providing MDM patches that makes the fork a real fork (using a completely different file namespace compared to its origin GDMv2) had been rejected by the Linux Mint maintainers a year back or so. Thus, in terms of Debian, I decided not to package MDM for Debian (as we would get in trouble with the GDMv3 package and I personally like having an cooperative partner on the upstream side). Thanks, Paul Greets, Mike [1] http://code.x2go.org/gitweb?p=x2gothinclient.git;a=summary -- DAS-NETZWERKTEAM mike gabriel, herweg 7, 24357 fleckeby fon: +49 (1520) 1976 148 GnuPG Key ID 0x25771B31 mail: mike.gabr...@das-netzwerkteam.de, http://das-netzwerkteam.de freeBusy: https://mail.das-netzwerkteam.de/freebusy/m.gabriel%40das-netzwerkteam.de.xfb pgpC5uvTuz4Mu.pgp Description: Digitale PGP-Signatur
Bug#766299: nxproxy: BIG-REQUESTS patch builds but fails at runtime
Dear Mike, > A MATE session is a session running the MATE desktop environment. > It is available in Debian jessie. MATE is GNOME desktop environment > (version 2) continued. It is _the_ recommended desktop environment for > remote desktop usage on Linux at the moment. ... Where is that recommendation documented? Does MATE contain a replacement for GDM, with XDMCP support? Or, how else to provide for remote thin clients? Thanks, Paul Paul Szabo p...@maths.usyd.edu.au http://www.maths.usyd.edu.au/u/psz/ School of Mathematics and Statistics University of SydneyAustralia -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#766299: nxproxy: BIG-REQUESTS patch builds but fails at runtime
Dear Paul, On So 26 Okt 2014 22:38:57 CET, paul.szabo wrote: Dear Mike, with my test setup I simply launched an X2Go session and clicked here and there in a MATE desktop session. At some points (they don't seem to be predictable), the X2Go session suspends (i.e. nxproxy dies) with earlier reported error messages. Ah, easy: I will just need to find out what is a MATE, and click at the exact "here and there" spots... A MATE session is a session running the MATE desktop environment [1]. It is available in Debian jessie. MATE is GNOME desktop environment (version 2) continued. It is _the_ recommended desktop environment for remote desktop usage on Linux at the moment. I presumed this as prevalent knowledge, sorry for my erroneous presumption. But you can use any other desktop environment on the X2Go Server except GNOMEv3, Cinnamon (>= 1.4), Unity (if using Ubuntu >> 12.04) for testing this, I assume. On the client side, in X2Go Client you can set up the connection (basically parameters you would give to an SSH command) and the "Session Type". Here you can select from various desktop envs, amongst others: "MATE". OK, I will now review the nxproxy code, look for places where it misses sanity checks and blindly follows data, and fix so as to avoid crashes. Then maybe you can test. Fair enough, but if you are interested in remote X11, you maybe really want to play with X2Go... Greets, Mike [1] apt-get install mate-desktop-environment -- DAS-NETZWERKTEAM mike gabriel, herweg 7, 24357 fleckeby fon: +49 (1520) 1976 148 GnuPG Key ID 0x25771B31 mail: mike.gabr...@das-netzwerkteam.de, http://das-netzwerkteam.de freeBusy: https://mail.das-netzwerkteam.de/freebusy/m.gabriel%40das-netzwerkteam.de.xfb pgpVZ2Wiw5N5W.pgp Description: Digitale PGP-Signatur
Bug#766299: nxproxy: BIG-REQUESTS patch builds but fails at runtime
Dear Mike, > with my test setup I simply launched an X2Go session and clicked here > and there in a MATE desktop session. > > At some points (they don't seem to be predictable), the X2Go session > suspends (i.e. nxproxy dies) with earlier reported error messages. Ah, easy: I will just need to find out what is a MATE, and click at the exact "here and there" spots... OK, I will now review the nxproxy code, look for places where it misses sanity checks and blindly follows data, and fix so as to avoid crashes. Then maybe you can test. Cheers, Paul Paul Szabo p...@maths.usyd.edu.au http://www.maths.usyd.edu.au/u/psz/ School of Mathematics and Statistics University of SydneyAustralia -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#766299: nxproxy: BIG-REQUESTS patch builds but fails at runtime
Hi Paul On So 26 Okt 2014 22:26:52 CET, paul.szabo wrote: Dear Mike, OK, so maybe I can build nxproxy and nxagent. (I certainly can, and did, build nxproxy with my patches; so far do not have nxagent.) But then, what do I do to elicit your crash: what do I run? Thanks, Paul Paul Szabo p...@maths.usyd.edu.au http://www.maths.usyd.edu.au/u/psz/ School of Mathematics and Statistics University of SydneyAustralia with my test setup I simply launched an X2Go session and clicked here and there in a MATE desktop session. At some points (they don't seem to be predictable), the X2Go session suspends (i.e. nxproxy dies) with earlier reported error messages. Mike -- DAS-NETZWERKTEAM mike gabriel, herweg 7, 24357 fleckeby fon: +49 (1520) 1976 148 GnuPG Key ID 0x25771B31 mail: mike.gabr...@das-netzwerkteam.de, http://das-netzwerkteam.de freeBusy: https://mail.das-netzwerkteam.de/freebusy/m.gabriel%40das-netzwerkteam.de.xfb pgpmZPRptJHwL.pgp Description: Digitale PGP-Signatur
Bug#766299: nxproxy: BIG-REQUESTS patch builds but fails at runtime
Dear Mike, OK, so maybe I can build nxproxy and nxagent. (I certainly can, and did, build nxproxy with my patches; so far do not have nxagent.) But then, what do I do to elicit your crash: what do I run? Thanks, Paul Paul Szabo p...@maths.usyd.edu.au http://www.maths.usyd.edu.au/u/psz/ School of Mathematics and Statistics University of SydneyAustralia -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#766299: nxproxy: BIG-REQUESTS patch builds but fails at runtime
Hi Paul, (re-Cc:ing the bug, hope that is ok...) On So 26 Okt 2014 21:02:18 CET, paul.szabo wrote: Dear Mike, Just in case I was not clear enough in my previous message: Please send me instructions on how to reproduce the nxproxy crash, and I will try to fix the problem. Cheers, Paul As the nx-libs-lite src:package is derived from this [0] project, I think easiest approach is testing with the upstream .deb packages. Easiest approach (requires you to install X2Go Server on one machine and X2Go Client on another machine): Server: sudo -i # (or su -) echo "deb http://packages.x2go.org/debian jessie main" > /etc/apt/sources.list.d/x2go.list apt-get update apt-get install x2goserver exit # (from sudo) Client: apt-get install x2goclient Configure X2Go Client with a session profile that connects to your server machine. On either side, you can obtain nx-libs.git from http://git.x2go.org and build it from source. Your patch has been added to that project [1], but is disabled for now [2]. sudo apt-get install devscripts sudo apt-get build-dep nxproxy mkdir x2go cd x2go git clone git://code.x2go.org/nx-libs.git cd nx-libs vim debian/patches/series # enable patch number 401_.patch (remove the comment hash) # save the series file debuild -uc -us # type "y" if queried for a decision # wait for the build (full NX with nxproxy _and_ nxagent) to finish, take a while cd .. dpkg -i *3.5.0.28*.deb I hope I haven't forgotten anything. If you need further help, don't hesitate to ping me. Thanks for giving your time to this!!! Mike [0] http://code.x2go.org/gitweb?p=nx-libs.git;a=summary [1] http://code.x2go.org/gitweb?p=nx-libs.git;a=commitdiff;h=c69c2e2ea177fd9e369a6342640bdedda9a500d8 [2] http://code.x2go.org/gitweb?p=nx-libs.git;a=commitdiff;h=d505944e064f54c82c8bc66943238b49db05d37f -- DAS-NETZWERKTEAM mike gabriel, herweg 7, 24357 fleckeby fon: +49 (1520) 1976 148 GnuPG Key ID 0x25771B31 mail: mike.gabr...@das-netzwerkteam.de, http://das-netzwerkteam.de freeBusy: https://mail.das-netzwerkteam.de/freebusy/m.gabriel%40das-netzwerkteam.de.xfb pgpztzKKH1VPF.pgp Description: Digitale PGP-Signatur
Bug#766299: nxproxy: BIG-REQUESTS patch builds but fails at runtime
Dear Mike,
> I test your patch and it results in several nxproxy crashes every 1-2
> minutes. The output of the session.log file you can find below.
> ...
> Error: Can't add a message of 3306686292 bytes to write buffer.
> Error: Assuming error handling data in context [B].
That comes from WriteBuffer::addMessage(), line 192 of WriteBuffer.cpp;
the reported length of 3GB is ridiculous.
This error does not seem to be directly caused by my patches, because
the "sanity check" lines
if (dataLength < 8 || dataLength > 1024*1024*1024)
{
#ifdef WARNING
*logofs << "BIG-REQUESTS with unacceptable dataLength="
<< dataLength << ", now set to 8.\n" << logofs_flush;
#endif
dataLength = 8;
}
in my patched ClientReadBuffer.cpp did not "fire". (You do have WARNING
on, right?)
I would suggest to scrutinize your data (X11 protocol input) stream.
Maybe I could help, if I could reproduce your crashes. I do not use
nxagent (do not have it now, do not intend to use it). Is there a way
to elicit your error, by having some (common) X client display to an
nxproxy-ied server?
Maybe someone should add sanity checks to ClientChannel.cpp, there are
many places where data lengths and similar are "blindly" accepted from
the input stream... as I had pointed out.
(This is so cute, so back-to-front: the maintainer asking me for help in
fixing his crash. No matter, I also want to make nxproxy useable, I am
in the process of trying to use it myself.)
Cheers, Paul
Paul Szabo p...@maths.usyd.edu.au http://www.maths.usyd.edu.au/u/psz/
School of Mathematics and Statistics University of SydneyAustralia
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#766299: nxproxy: BIG-REQUESTS patch builds but fails at runtime
Control: tag -1 moreinfo Control: tag -1 - patch Hi Paul, thanks for helping with improving NX code. I am one of the Debian maintainers of nx-libs-lite as well of the release manager of X2Go, a terminal server solution that uses nxproxy and acts as upstream for the packages in Debian. I test your patch and it results in several nxproxy crashes every 1-2 minutes. The output of the session.log file you can find below. Please check nxproxy when working together with nxagent (deb http://packages.x2go.org/debian jessie main) and hopefully you can find some changes for your patch (as I would love to have BIG-REQUESTS support in NX). """ NXPROXY - Version 3.5.0 Copyright (C) 2001, 2010 NoMachine. See http://www.nomachine.com/ for more information. Info: Proxy running in client mode with pid '30148'. Session: Starting session at 'Sat Oct 25 22:41:21 2014'. Info: Using abstract X11 socket in kernel namespace for accessing DISPLAY=:0. Info: Connecting to remote host '127.0.0.1:30001'. Info: Connection to remote proxy '127.0.0.1:30001' established. Info: Connection with remote proxy completed. Warning: Unrecognized session type 'unix-kde-depth_24'. Assuming agent session. Info: Using ADSL link parameters 512/24/1/0. Info: Using cache parameters 4/4096KB/8192KB/8192KB. Info: Using pack method '16m-png-9' with session 'unix-kde-depth_24'. Info: Using ZLIB data compression 1/1/32. Info: Using ZLIB stream compression 4/4. Info: No suitable cache file found. Info: Forwarding X11 connections to display ':0'. Session: Session started at 'Sat Oct 25 22:41:22 2014'. Info: Established X server connection. Info: Using shared memory parameters 0/0K. Error: Can't add a message of 640681836 bytes to write buffer. Error: Assuming error handling data in context [B]. Session: Terminating session at 'Sat Oct 25 22:42:10 2014'. Session: Session terminated at 'Sat Oct 25 22:42:10 2014'. NXPROXY - Version 3.5.0 Copyright (C) 2001, 2010 NoMachine. See http://www.nomachine.com/ for more information. Info: Proxy running in client mode with pid '30615'. Session: Starting session at 'Sat Oct 25 22:42:28 2014'. Info: Using abstract X11 socket in kernel namespace for accessing DISPLAY=:0. Info: Connecting to remote host '127.0.0.1:30001'. Info: Connection to remote proxy '127.0.0.1:30001' established. Info: Connection with remote proxy completed. Warning: Unrecognized session type 'unix-kde-depth_24'. Assuming agent session. Info: Using ADSL link parameters 512/24/1/0. Info: Using cache parameters 4/4096KB/8192KB/8192KB. Info: Using pack method '16m-png-9' with session 'unix-kde-depth_24'. Info: Using ZLIB data compression 1/1/32. Info: Using ZLIB stream compression 4/4. Info: No suitable cache file found. Info: Forwarding X11 connections to display ':0'. Session: Session started at 'Sat Oct 25 22:42:28 2014'. Info: Established X server connection. Info: Using shared memory parameters 0/0K. Error: Can't add a message of 2184185436 bytes to write buffer. Error: Assuming error handling data in context [B]. Session: Terminating session at 'Sat Oct 25 22:42:51 2014'. Session: Session terminated at 'Sat Oct 25 22:42:51 2014'. NXPROXY - Version 3.5.0 Copyright (C) 2001, 2010 NoMachine. See http://www.nomachine.com/ for more information. Info: Proxy running in client mode with pid '30893'. Session: Starting session at 'Sat Oct 25 22:43:07 2014'. Info: Using abstract X11 socket in kernel namespace for accessing DISPLAY=:0. Info: Connecting to remote host '127.0.0.1:30001'. Info: Connection to remote proxy '127.0.0.1:30001' established. Info: Connection with remote proxy completed. Warning: Unrecognized session type 'unix-kde-depth_24'. Assuming agent session. Info: Using ADSL link parameters 512/24/1/0. Info: Using cache parameters 4/4096KB/8192KB/8192KB. Info: Using pack method '16m-png-9' with session 'unix-kde-depth_24'. Info: Using ZLIB data compression 1/1/32. Info: Using ZLIB stream compression 4/4. Info: No suitable cache file found. Info: Forwarding X11 connections to display ':0'. Session: Session started at 'Sat Oct 25 22:43:07 2014'. Info: Established X server connection. Info: Using shared memory parameters 0/0K. Error: Can't add a message of 3306686292 bytes to write buffer. Error: Assuming error handling data in context [B]. Session: Terminating session at 'Sat Oct 25 22:44:15 2014'. Session: Session terminated at 'Sat Oct 25 22:44:15 2014'. """ PS: I also noticed that nxproxy still has the old maintainer registered in Debian BTS. Please make sure that you Cc: our team mailing list (pkg-x2go-de...@lists.alioth.debian.org). PPS: @Matthew Johnson: I have asked the debbugs maintainers, if they can change something on the override files, so that the mails for nxproxy end up on pkg-x2go-devel (and not in your INBOX). Greets, Mike -- DAS-NETZWERKTEAM mike gabriel, herweg 7, 24357 fleckeby fon: +49 (1520) 1976 148 GnuPG Key ID 0x25771B31 mail: mike.gabr...@das-netzwerkteam.de, http://das-n
