Package: x2goserver Version : 4.0.1.15
Package: x2goagent Version : 3.5.0.24
Hello,
I'm using the latest package provided by fedora rawhide repo (v21) for x2goserver on IBM POWER8 Server (ppc64)
Here is a copy of the session.log:
NXAGENT - Version 3.5.0
Copyright (C) 2001, 2011 NoMachine. See http://www.nomachine.com/ for more information.
Info: Agent running with pid '3864'. Session: Starting session at 'Sat Jun 14 20:26:54 2014'. Info: Proxy running in server mode with pid '3864'. Info: Waiting for connection from 'localhost' on port '30123'. Info: Accepted connection from '127.0.0.1'. Info: Connection with remote proxy completed. Info: Using WAN link parameters 768/24/1/0. Info: Using agent parameters 5000/5/50/0/0. Info: Using cache parameters 4/4096KB/8192KB/8192KB. Info: Using pack method '16m-png-9' with session 'unix-kde-depth_32'. Info: Using ZLIB data compression 1/1/32. Info: Using ZLIB stream compression 1/1. Info: No suitable cache file found. Info: Listening to X11 connections on display ':89'. Info: Established X client connection. Info: Using shared memory parameters 1/1/1/2048K. Info: Using alpha channel in render extension. Info: Not using local device configuration changes. keyboard file created SessionPath not defined Session: Session started at 'Sat Jun 14 20:27:04 2014'. Session: Terminating session at 'Sat Jun 14 20:35:09 2014'. Info: Waiting the cleanup timeout to complete. Session: Session terminated at 'Sat Jun 14 20:35:10 2014'.
Cordialement / Best Regards
Sébastien Chabrolles Power Systems Benchmark Specialist IBM Client Center, Montpellier 1 rue vieille poste 34000 Montpellier FRANCE Tel +33 4 67 34 40 95 Email : s.chabrolles@fr.ibm.com
Sauf indication contraire ci-dessus:/ Unless stated otherwise above: Compagnie IBM France Siège Social : 17 avenue de l'Europe, 92275 Bois-Colombes Cedex RCS Nanterre 552 118 465 Forme Sociale : S.A.S. Capital Social : 655.732.332,20 ? SIREN/SIRET : 552 118 465 03644 - Code NAF 6202A
HI Sebastien,
On Sa 14 Jun 2014 22:23:10 CEST, sebastien chabrolles wrote:
Package: x2goserver Version : 4.0.1.15
Package: x2goagent Version : 3.5.0.24
Hello,
I'm using the latest package provided by fedora rawhide repo (v21) for x2goserver on IBM POWER8 Server (ppc64)
- Installation is ok without error
- Connexion from client to server is ok
- But Nothing happen on the screen, I try several option (desktop, firefox browser, xterm), but no windows is shown and no errors in the logs.
- I also try a ssh -X connexion and try xterm command, erverything works, but not with x2go
Here is a copy of the session.log:
NXAGENT - Version 3.5.0
Copyright (C) 2001, 2011 NoMachine. See http://www.nomachine.com/ for more information.
Info: Agent running with pid '3864'. Session: Starting session at 'Sat Jun 14 20:26:54 2014'. Info: Proxy running in server mode with pid '3864'. Info: Waiting for connection from 'localhost' on port '30123'. Info: Accepted connection from '127.0.0.1'. Info: Connection with remote proxy completed. Info: Using WAN link parameters 768/24/1/0. Info: Using agent parameters 5000/5/50/0/0. Info: Using cache parameters 4/4096KB/8192KB/8192KB. Info: Using pack method '16m-png-9' with session 'unix-kde-depth_32'. Info: Using ZLIB data compression 1/1/32. Info: Using ZLIB stream compression 1/1. Info: No suitable cache file found. Info: Listening to X11 connections on display ':89'. Info: Established X client connection. Info: Using shared memory parameters 1/1/1/2048K. Info: Using alpha channel in render extension. Info: Not using local device configuration changes. keyboard file created SessionPath not defined Session: Session started at 'Sat Jun 14 20:27:04 2014'. Session: Terminating session at 'Sat Jun 14 20:35:09 2014'. Info: Waiting the cleanup timeout to complete. Session: Session terminated at 'Sat Jun 14 20:35:10 2014'.
Cordialement / Best Regards
There was at least one other size_t/socklen_t initialization issue
(see [1]) that got fixed with a commit on Wednesday [2].
So, you may actually experience other unitialized memory issues with
nx-libs 3.5.0.24.
Please use nx-libs from the nightly builds (or build it your self) and
re-test with my fixes for the xtrans code in NX/X11. (xtrans is
responsible to set up listening sockets for the X-Server as well as
handle incoming connections).
Another issue may well be: does your Fedora PPC64 system use
poly-instatiated /tmp directories? If so, then you want 3.5.0.25, as
well.
Mike
[1]
http://code.x2go.org/gitweb?p=nx-libs.git;a=blob;f=debian/patches/028_nx-X11...
[2]
http://code.x2go.org/gitweb?p=nx-libs.git;a=commitdiff;h=656f29cc631972002ec...
--
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...
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512
Hello Mike and Sebastien,
I hope I may answer.
Please use nx-libs from the nightly builds (or build it your self) and re-test with my fixes for the xtrans code in NX/X11. (xtrans is responsible to set up listening sockets for the X-Server as well as handle incoming connections).
I did. Built Fedora RPM packages for nx-libs based on today's git repo and installed them.
Another issue may well be: does your Fedora PPC64 system use poly-instatiated /tmp directories? If so, then you want 3.5.0.25, as well.
No, the test system does not.
Still, the problem persists.
There's also not really any clue why this might be happening, either.
x2goserver's debug messages look all fine:
Jun 15 05:23:07 localhost /usr/bin/x2gostartagent: x2gostartagent called with options: 800x600 wan 16m-png-9 unix-kde-depth_32 us query 0 R firefox Jun 15 05:23:07 localhost /usr/bin/x2gosessionlimit[10364]: x2gosessionlimit has been called Jun 15 05:23:07 localhost /usr/bin/x2golistsessions[10367]: x2golistsessions has been called with options: --all-servers Jun 15 05:23:10 localhost /usr/bin/x2gofeature: x2gofeature called with options: X2GO_RUN_EXTENSIONS Jun 15 05:23:11 localhost /usr/share/x2go/x2gofeature.d/x2goserver-extensions.features: x2goserver-extensions.features called with options: X2GO_RUN_EXTENSIONS Jun 15 05:23:11 localhost /usr/bin/x2goserver-run-extensions: x2goserver-run-extensions called with options: root-93-1402802588_stRfirefox_dp32 pre-start Jun 15 05:23:11 localhost /usr/bin/x2gostartagent: successfully started X2Go agent session with ID root-93-1402802588_stRfirefox_dp32 Jun 15 05:23:11 localhost /usr/bin/x2gofeature: x2gofeature called with options: X2GO_RUN_EXTENSIONS Jun 15 05:23:11 localhost /usr/share/x2go/x2gofeature.d/x2goserver-extensions.features: x2goserver-extensions.features called with options: X2GO_RUN_EXTENSIONS Jun 15 05:23:11 localhost /usr/bin/x2goserver-run-extensions: x2goserver-run-extensions called with options: root-93-1402802588_stRfirefox_dp32 post-start Jun 15 05:23:11 localhost /usr/bin/x2gostartagent: blocking creation of agent's keyboard file /root/.x2go/C-root-93-1402802588_stRfirefox_dp32/keyboard as requested by session startup command Jun 15 05:23:16 localhost /usr/bin/x2goruncommand: x2goruncommand called with options: 93 10575 root-93-1402802588_stRfirefox_dp32 30136 /usr/bin/firefox nosnd R Jun 15 05:23:16 localhost /usr/bin/x2gofeature: x2gofeature called with options: X2GO_RUN_EXTENSIONS Jun 15 05:23:16 localhost /usr/share/x2go/x2gofeature.d/x2goserver-extensions.features: x2goserver-extensions.features called with options: X2GO_RUN_EXTENSIONS Jun 15 05:23:16 localhost /usr/bin/x2goserver-run-extensions: x2goserver-run-extensions called with options: root-93-1402802588_stRfirefox_dp32 pre-runcommand Jun 15 05:23:16 localhost /usr/bin/x2gomountdirs[10764]: x2gomountdirs has been called with options: dir root-93-1402802588_stRfirefox_dp32 ionic /root/.x2go/ssh/key.J82727 /Users/ionic/.x2go/S-root-93-1402802588_stRfirefox_dp32/spool__PRINT_SPOOL___REVERSESSH_PORT__30137 Jun 15 05:23:16 localhost /usr/bin/x2gosetkeyboard: x2gosetkeyboard called with options: Jun 15 05:23:16 localhost /usr/bin/x2gofeature: x2gofeature called with options: X2GO_XSESSION Jun 15 05:23:16 localhost /usr/bin/x2gosetkeyboard: /root/.x2go/C-root-93-1402802588_stRfirefox_dp32/keyboard is blocked, not setting keyboard parameters from client-side settings Jun 15 05:23:16 localhost /usr/share/x2go/x2gofeature.d/x2goserver-extensions.features: x2goserver-extensions.features called with options: X2GO_XSESSION Jun 15 05:23:16 localhost /usr/share/x2go/x2gofeature.d/x2goserver.features: x2goserver.features called with options: X2GO_XSESSION Jun 15 05:23:16 localhost /usr/share/x2go/x2gofeature.d/x2goserver-fmbindings.features: x2goserver-fmbindings.features called with options: X2GO_XSESSION Jun 15 05:23:16 localhost /usr/share/x2go/x2gofeature.d/x2goserver-xsession.features: x2goserver-xsession.features called with options: X2GO_XSESSION Jun 15 05:23:17 localhost /usr/bin/x2gomountdirs[10764]: successfully mounted ionic@127.0.0.1:30137/Users/ionic/.x2go/S-root-93-1402802588_stRfirefox_dp32/spool to /tmp/.x2go-root/spool/C-root-93-1402802588_stRfirefox_dp32
But there is one interesting bit in the C-... directory.
The "clients" contains those lines:
error opening security policy file /usr/lib64/nx/X11/xserver/SecurityPolicy The XKEYBOARD keymap compiler (xkbcomp) reports:
Error: Can't find file "null" for symbols include Exiting Abandoning symbols file "default" Error: Cannot open "compiled/server-93.xkm" to write keyboard description Exiting
We can ignore the first one.
This, however, leaves us with the xkbcomp errors.
I tried "debugging" that and /usr/bin/xkbcomp has indeed been called with "-w 1 -R/usr/share/X11/xkb -xkm - -em1 'The XKEYBOARD keymap compiler (xkbcomp) reports:' -emp '>' -eml 'Errors from xkbcomp are not fatal to the X server' compiled/server-93.xkm"
Now, while normally xkbcomp errors may not be fatal to the X server, they could be fatal to x2go. Is that true?
I can get rid of the first error ('Can't find file "null"') by forcing a specific keyboard layout in x2goclient.
Further, I'm wondering why xkbcomp is called with "compiled/server-93.xkm" as its output argument. To my understanding, xkbcomp should rather upload its compiled xkbmap to the Xserver on display 93 (note that the value is within the output file name) instead of writing it to a file. Am I mistaken?
Unfortunately, I have been unable to reproduce this on any of my other two machines. I tried everything, from setting a specific keyboard value to sending null/null as on the ppc64 machine, but my x86_64 machines never even called xkbcomp.
I've had a quick look at nx-libs sources and grepped for xkbcomp, but this string is all over the place in the X11 sources, so getting some useful information extracted is difficult.
Do YOU know, by any chance, when xkbcomp is supposed to be called? As none of my machines are doing that, I suppose xkbcomp is not supposed to be called at all?
I'll try to get a closer look at that later today, those were my initial findings.
Any input is appreciated.
Mihai -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.22 (Darwin) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/
iQIcBAEBCgAGBQJTnRkxAAoJEB/WLtluJTqHoikP/3F29hsW7wzUOgXyWbEy94j8 grwtjShkX3DY3lnDNiAMA8aFsSH+DjkEwe//G+8iIBC8pKuYq98Pd8On3mqKV6Ug SjP80DPG0KXt/bZTYEGT1Ou6qseCBjSXY0PjiAK5GKf0MEVXL75V6T/YQG8OWO4O JBtjBVd0+dIcqTfewLUMeCvYzJFKKFuszaaZJDqODtdz8TH7KlcPE64Mi8N0BYNr BXZWDm/VyOeYhCIToPfEEDC4DOsJb01xtvStNxqmWW+Uoo79fKEAOVc1voWPemYO /j5mRjn/6KTL5JMplLi8gfG4ilRPB10XN2wHpElDFLyjVMGz2H4wtBf2GuceiRCH LGtvnRJ/XfYvTuiFeK7ZM8wcy/cc6BBPXa+6v5bMt0qKv7q4wp3vtbs81UzKJGAw /WwIkSPjZFkDmaWtutcxWiuw62OB9KO3AsYXlj9nUOOHF4UyeX6CL2jC6WMixapN jj6CXBJyrV8+P3UerB/JExLZgHJ73KLKBNuokinKA95luO8QGDjndz5o1sa0WiNO jc7+lkvx0CZd3/fxyAKnnseFi2jsusrTMz3BUcTDEG3QgxLEnSl0rvPHS+MC55D7 eOoAj+zdYzDUq/ifZ30HcatlmMESzIv/CZ1dc03kKT1DEvxMjZELCjca12SYmYek l/FzUx/7hc1E4Ul/vfag =n1F0 -----END PGP SIGNATURE-----
Hi,
Well, I have done quite some work.
The xkbcomp issue I've been seeing seems to be normal - other machines behave the same. It was a missing directory (keymaps.dir) in /usr/share/X11/xkb on my x86_64 machine that prevented xkbcomp from being called and a root-non-root issue regarding the file location (/var/tmp/server-$DISPLAYNO.xkm vs. compiled/server-$DISPLAYNO.xkm.)
Alas, none of these were critical or actually had any influence on the X server as such. Both machines produces the same messages. So xkb was totally the wrong thing to look at.
I have then compiled with even more debug info in nxproxy and nxagent to see whether the problem is in the connection part between two machines.
I even straced the nxagent/x2goagent process to get some useful information out of there. After going through a several megabytes big strace file, I ended up seeing that both ppc64 and x86_64 are behaving the same establishing the connection and everything is functional. Bummer, nothing on that front either.
There's no indication of what may be wrong. Not even with nxagent (being the X server itself) compiled with -DDEBUG -DDEBUG_CMD -DNX_TRANS_TEST. This produces quite a lot of messages every once in a place, but there's nothing regarding being unable to create/show windows.
Not even starting another application from a shell via DISPLAY=:<current-sessions-display-number> xeyes bring's anything to light.
At least X clients (programs) and server are constantly exchanging information, so the missing window issue must be nested deep within the X server itself.
However, I have no idea where to look.
To make matters worse, attaching gdb to nxagent during normal operation is quite impossible. As soon as nxagent is stopped for single-stepping through functions and examining variables/code in detail, the (remote) nxproxy client will get a timeout as it's not able to communicate with the agent anymore (well, sure, we've just been stopping that for debugging...) and close the connection.
Pretty much the only way possible is print-debugging in the code.
I could live with that, had I at least any idea of where the problem could be.
Maybe finding the code drawing/creating a window would be interesting.
In other news, I can report that outgoing connections via x2goclient are working just fine. I've been connecting to my ionic.de machine in order to start a simple xterm from the ppc64 box and that worked flawlessly. How wouldn't it, as "this way 'round" doesn't use the very old X server distributed with NX, but actually the recent, known-to-work X server as shipped with Fedora.
Thus, it's really just a server-side issue.
Mihai
Nevermind, we have a window!
But the colors are all off and redrawing is broken. More bugs wait to be discovered. :)
Mihai
The following five patches apply against the current nx-libs repository with the other full+lite patches applied.
This one is required:
nxagent_Window.c-ppc64-create-windows.patch
Theses ones are optional, as they either don't add functionality if not building nx-libs in debug mode or only have minimal impact in output, but I still recommend applying:
dix_dixfonts.c-nxagent_X_NXdispatch.c_NXdixfonts.c-run-with-global-DEBUG.patch nxagent_Keyboard.c-misc-logic.patch nxagent_Render.c-run-with-TEST.patch nxtrans_Xtranssock.c-big-endian-socklen.patch
Mihai
An endiannes issue was setting incorrect event masks when creating X11 windows.
This time, a smaller integer has been casted to a bigger one and passed to some function actually setting its value.
This meant, that garbage from stack was attached to the smaller integer value, putting unknown memory into the lower bytes of the bigger integer.
Fix this by creating a big, initialized temporary variable, let the function do its magic on that one and pass the value back to the smaller variable -- and cross your fingers the smaller variable can hold it without overrunning. (The last bit is a design issue we can't really fix and has been around even before this patch.)
Mihai
Hi Mihai,
thanks for digging into this. I wish you could work more on NX!!! Good work!!!
On Sa 21 Jun 2014 05:15:43 CEST, Mihai Moldovan wrote:
An endiannes issue was setting incorrect event masks when creating
X11 windows.This time, a smaller integer has been casted to a bigger one and
passed to some function actually setting its value.This meant, that garbage from stack was attached to the smaller
integer value, putting unknown memory into the lower bytes of the bigger integer.Fix this by creating a big, initialized temporary variable, let the
function do its magic on that one and pass the value back to the smaller variable -- and cross your fingers the smaller variable can hold it without overrunning. (The last bit is a design issue we can't really fix and has been around
even before this patch.)
I have a question on this patch. While integrating it into the
nx-libs.git repo, I realized, that it can be applied to Windows.c
twice. Once at the position that you provide in the patch file,
another (second) time around line 2895...
"""
mike@minobo:~/MyDocuments/4projects/x2go-upstream/nx-libs$ patch -p1 <
nxagent_Window.c-ppc64-create-windows.patch
patching file nx-X11/programs/Xserver/hw/nxagent/Window.c
Hunk #1 succeeded at 2894 (offset 2559 lines).
"""
Maybe the same patch is needed at that second position?
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...
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512
Maybe the same patch is needed at that second position?
No. It's needed in two other places, actually. I totally didn't catch that, sorry.
Let me test the changes and I'll get back with an updated patch.
Mihai -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.22 (Darwin) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/
iQIcBAEBCgAGBQJTpe14AAoJEB/WLtluJTqHl7sP+wSh5zSiyWwCfcC4x+XRMCE/ lGuP5k+L6e4oi2hXaMwAIe8ONkGWvMrQa6W652KA1/0SX94L7ITIMbWyCl2uWwUh b7wydQUk8tSZ4f/XsHSWUozGtSaG2XzQMZjE/crWoEZ8Avb/SwIBVCQm+JVbrXDp u+Z0lrCzty9IZ+G45w6/mE3ZYcKIsE5nR/B6/4n/gpYw9Y7+YdjTAqEGU+Imtn2t XAKHwKRiKsRxgZZHKEgYF3mSNc6S123FiQQRD587iLOkFTPTbZxVJtNKcwvHaj8z lc8paFD0dELnSnP7f44h4CtAJhUXEEY1FcYpMlp6mRAE2+6kgOjSeiU+ShBPgLmp Pe4fhRmL2400K07HgVBj8vL8ZExouiUbyyKG74R4K5WcpFu8fCBDy+jZWaDO3Paa l70ltja3/zdyvVsJVNHqo5Lf/jC0CxH0fe1d747vJ252I68QGp2Wdb8Mr79qV82q ZlFrX2PBVkZJEOWHx9/KrVsLTbaWUjmeL/fd12dkMa/xo/R0voXgpeq1FWBNBCwe IBSkSpisCzhqgN8THUJ5OHfnE7yNlkUMjzTZGBfz/KlE5epxjRP/N7q1Q0F3vawR khSeEF53TPJMPzjbwXT7OJ8EEEbG7P7WhQS9HZUlf3YRidS6UstJ4NrmtU64IV8H /wLf28vszDeAuvjqcnxn =18u1 -----END PGP SIGNATURE-----
Hi Mihai,
On Sa 21 Jun 2014 22:39:21 CEST, Mihai Moldovan wrote:
- On 21.06.2014 10:26 pm, Mike Gabriel wrote:
Maybe the same patch is needed at that second position?
No. It's needed in two other places, actually. I totally didn't
catch that, sorry.Let me test the changes and I'll get back with an updated patch.
Ok. Cool.
I have everything in place and can rebase any more changes in once you
send them.
Holding back git push for now...
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...
Am 21.06.2014 22:26, schrieb Mike Gabriel:
Hi Mihai,
thanks for digging into this. I wish you could work more on NX!!! Good work!!!
+1
And by now, I guess we can officially grant Mihai the honorary title of "Cowbyte - the chaser of Endians".
SCNR, Stefan
Am 21.06.2014 22:26, schrieb Mike Gabriel:
Hi Mihai, thanks for digging into this. I wish you could work more on NX!!! Good work!!! +1
And by now, I guess we can officially grant Mihai the honorary title of "Cowbyte - the chaser of Endians".
SCNR, Stefan
And with that, we have Firefox, xeyes (the two programs I tested) working on ppc64 in Big Endian mode:
http://www.ionic.de/tmp/x2go-Firefox-ppc64.png
Mike, please note that the patch name, description and title changed in the updated revision.
Mihai
Hi all,
I just test on the Power8 system and It works !!!!!!!
Many thanks to all of you for your help; Especially to Mihai "the Endian bug killer" for his fantastic work.
Sébastien Chabrolles Power Systems Benchmark Specialist IBM Client Center, Montpellier 1 rue vieille poste 34000 Montpellier FRANCE Tel +33 4 67 34 40 95 Email : s.chabrolles@fr.ibm.com
Le 21 juin 2014 à 22:30, "Mike Gabriel" <mike.gabriel@das-netzwerkteam.de> a écrit :
Hi Mihai,
thanks for digging into this. I wish you could work more on NX!!! Good work!!!
On Sa 21 Jun 2014 05:15:43 CEST, Mihai Moldovan wrote:
An endiannes issue was setting incorrect event masks when creating X11 windows.
This time, a smaller integer has been casted to a bigger one and passed to some function actually setting its value.
This meant, that garbage from stack was attached to the smaller integer value, putting unknown memory into the lower bytes of the bigger integer.
Fix this by creating a big, initialized temporary variable, let the function do its magic on that one and pass the value back to the smaller variable -- and cross your fingers the smaller variable can hold it without overrunning. (The last bit is a design issue we can't really fix and has been around even before this patch.)
I have a question on this patch. While integrating it into the nx-libs.git repo, I realized, that it can be applied to Windows.c twice. Once at the position that you provide in the patch file, another (second) time around line 2895...
""" mike@minobo:~/MyDocuments/4projects/x2go-upstream/nx-libs$ patch -p1 < nxagent_Window.c-ppc64-create-windows.patch patching file nx-X11/programs/Xserver/hw/nxagent/Window.c Hunk #1 succeeded at 2894 (offset 2559 lines). """
Maybe the same patch is needed at that second position?
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...
x2go-dev mailing list x2go-dev@lists.x2go.org http://lists.x2go.org/listinfo/x2go-dev
Multiple endiannes issues were setting incorrect event masks when creating and drawing X11 windows.
This time, a smaller integer has been casted to a bigger one and passed to some function actually setting its value.
This meant, that garbage from stack was attached to the smaller integer value, putting unknown memory into the lower bytes of the bigger integer.
Fix this by creating a big, initialized temporary variable, let the function do its magic on that one and pass the value back to the smaller variable -- and cross your fingers the smaller variable can hold it without overrunning. (The last bit is a design issue we can't really fix and has been around even before this patch.)
This fixes window creation and redrawing/updating issues on Big Endian 64bit systems.
Hi Mihai,
On Sa 21 Jun 2014 23:12:59 CEST, Mihai Moldovan wrote:
Multiple endiannes issues were setting incorrect event masks when
creating and drawing X11 windows.This time, a smaller integer has been casted to a bigger one and
passed to some function actually setting its value.This meant, that garbage from stack was attached to the smaller
integer value, putting unknown memory into the lower bytes of the bigger integer.Fix this by creating a big, initialized temporary variable, let the
function do its magic on that one and pass the value back to the smaller variable -- and cross your fingers the smaller variable can hold it without overrunning. (The last bit is a design issue we can't really fix and has been around
even before this patch.)This fixes window creation and redrawing/updating issues on Big Endian 64bit systems.
Fixed patch included. However, unfortunately I forgot to rebase before
pushing...
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...
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512
Hi Mihai,
On Sa 21 Jun 2014 23:12:59 CEST, Mihai Moldovan wrote:
Multiple endiannes issues were setting incorrect event masks when creating and drawing X11 windows.
This time, a smaller integer has been casted to a bigger one and passed to some function actually setting its value.
This meant, that garbage from stack was attached to the smaller integer value, putting unknown memory into the lower bytes of the bigger integer.
Fix this by creating a big, initialized temporary variable, let the function do its magic on that one and pass the value back to the smaller variable -- and cross your fingers the smaller variable can hold it without overrunning. (The last bit is a design issue we can't really fix and has been around even before this patch.)
This fixes window creation and redrawing/updating issues on Big Endian 64bit systems.
Fixed patch included. However, unfortunately I forgot to rebase before pushing...
Thanks, Mike!
Unfortunately the "057_nx-X11-bigendian-ppc64-no-session-window.full.patch" description is still the "old" one. Mind updating that? -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.22 (Darwin) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/
iQIcBAEBCgAGBQJTpfqeAAoJEB/WLtluJTqHtc4P/3RB4o6sfk0xP8LAqxNRk42q beKzVXVUEBiRgXJmDfnkDbHav/AAe2M6ATxPMdut+EYUmk/+W9dzrJwZHPoD5shu /TmPRV3EYIaoGDOKo3ZXZP/k+rkFXg1eBrnDgzoJJf0bF7fn9NztJ3vqHjSA8Cu7 VMtw7/J/uXBffSni0UKjaCtMHOe/GnrZM6bcjph6AykiLT0xPOXOxx1kTXvGeNx0 uFG3maxHYJC/nf2zs8pPt9/5K/lc+v09RoJptrFjZpzzIldCki0Q1/n3jZhsm5mJ 9dDeQg59wIyCSo7OU2vVX2RLByvAzkfr8TaU1+zThYkf58NJNmpuXXqBPuDXC0PI Ve51GrUF4mLz2bdZD57d27iYyu9H41S+5c6GNkhcObVHd6C6MKfL5AqwIgGvSbie If3+s7kpDv8p6UqERL6PnSBT6HMk8cYbNc2+mA9cFisYwi/kwESc5jd8odz2oG08 uTT+AS6MIncg9l5OSPKT79BGLNm390beY3C+hIgo84zyRCFghMOmdPRbCSOOOjR2 0f8hiN5QHxH59m4ZNKkE0eE5RY61AFMdn+PE5zqX6p75e4YxYG8oOjYcE2L6mtTG miT0YqEItpP//v2m7jr0g1FfT73sFXGDSnL/VrXiRR0eJJ/QSahYWtkGEgRV6RYg Fi+nHSePnoeo04jx3twM =pKrh -----END PGP SIGNATURE-----
Hi Mihai,
On Sa 21 Jun 2014 23:35:26 CEST, Mihai Moldovan wrote:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512
- On 21.06.2014 11:23 pm, Mike Gabriel wrote:
Hi Mihai,
On Sa 21 Jun 2014 23:12:59 CEST, Mihai Moldovan wrote:
Multiple endiannes issues were setting incorrect event masks when
creating and drawing X11 windows.This time, a smaller integer has been casted to a bigger one and
passed to some function actually setting its value.This meant, that garbage from stack was attached to the smaller
integer value, putting unknown memory into the lower bytes of the bigger integer.Fix this by creating a big, initialized temporary variable, let
the function do its magic on that one and pass the value back to the smaller
variable -- and cross your fingers the smaller variable can hold it without
overrunning. (The last bit is a design issue we can't really fix and has been around
even before this patch.)This fixes window creation and redrawing/updating issues on Big
Endian 64bit systems.Fixed patch included. However, unfortunately I forgot to rebase
before pushing...Thanks, Mike!
Unfortunately the "057_nx-X11-bigendian-ppc64-no-session-window.full.patch" description is still the "old" one. Mind updating that?
Done.
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...
Fix several compile errors when specifying -DDEBUG globally. Previous GCC versions were more liberal and the code thus compiled.
Also initialize/reset a count variable correctly.
The subject line should have spelled "Fix issues when globally enabling DEBUG macro.", but you'll get the idea. Sorry for having forgotten to change the subject line.
Don't print out nonsensical information, if there really was no error when creating the keyboard file or the other way around.
Also add the reason when failing to create the keyboard file.
Lastly, only print an error message if SessionPath *really* is not defined.
Check for pSrc->pDrawable to exist instead of having nxagent segfault when it does not.
This enables the possibility of compiling all nxagent modules in TEST mode.
While the code was working before, I'd still rather use socklen_t instead of int and not cast its address to void* but rather socklen_t*.
Don't change the SVR4/SCO section, as I have no means of testing that.
This patch is strictly speaking not necessary, but just a tiny bit cleaner compared to before.