It may be futile, but I'm trying to run x2goagent under valgrind. The first problem seems to be that it takes too long to initialize, and x2goclient yields:
x2go-DEBUG-../src/sshmasterconnection.cpp:1559> "channel_open_session failed.": "Socket error: Operation now in progress"
It seems that x2goclient doesn't handle that as a "try again" error message.
I was able to connect via pyhoca-gui, so that might work.
-- Orion Poplawski Technical Manager 303-415-9701 x222 NWRA/CoRA Division FAX: 303-415-9702 3380 Mitchell Lane orion@cora.nwra.com Boulder, CO 80301 http://www.cora.nwra.com
Hi Orion. It may be off-topic but did you try using sanitizers? AFAIR, they've appeared first in Clang but now you can use these instruments in GCC too. Currently I don't see any reason for using Valgrind instead of AddressSanitizer (one should specify -fsanitize=address for compilation and linking) except the case when you don't have the full source code or have limited test environment (such as 32-bit system, VZ container or system with some ancient compiler). IMHO this is much faster than valgrind and catches more problems.
On 01/19/2017 02:34 PM, Nable wrote:
Hi Orion. It may be off-topic but did you try using sanitizers? AFAIR, they've appeared first in Clang but now you can use these instruments in GCC too. Currently I don't see any reason for using Valgrind instead of AddressSanitizer (one should specify -fsanitize=address for compilation and linking) except the case when you don't have the full source code or have limited test environment (such as 32-bit system, VZ container or system with some ancient compiler). IMHO this is much faster than valgrind and catches more problems.
Thanks for this note - didn't know about this. With it I seem to be hitting the same issue found with valgrind reported here:
https://github.com/ArcticaProject/nx-libs/issues/293
With -fsanitize=address the program exits immediately:
================================================================= ==30566== ERROR: AddressSanitizer: heap-use-after-free on address 0x601c0000bd68 at pc 0xd6d797 bp 0x7ffc3bc161c0 sp 0x7ffc3bc161b0 READ of size 8 at 0x601c0000bd68 thread T0 #0 0xd6d796 (/usr/lib64/nx/bin/nxagent+0xd6d796) #1 0xd6e455 (/usr/lib64/nx/bin/nxagent+0xd6e455) #2 0x5c353d (/usr/lib64/nx/bin/nxagent+0x5c353d) #3 0x5c3ce7 (/usr/lib64/nx/bin/nxagent+0x5c3ce7) #4 0x5874fd (/usr/lib64/nx/bin/nxagent+0x5874fd) #5 0x58b621 (/usr/lib64/nx/bin/nxagent+0x58b621) #6 0x5a9ff6 (/usr/lib64/nx/bin/nxagent+0x5a9ff6) #7 0x51129d (/usr/lib64/nx/bin/nxagent+0x51129d) #8 0x53bb2a (/usr/lib64/nx/bin/nxagent+0x53bb2a) #9 0x485dd9 (/usr/lib64/nx/bin/nxagent+0x485dd9) #10 0x419fa4 (/usr/lib64/nx/bin/nxagent+0x419fa4) #11 0x7fb32fc7ab34 (/usr/lib64/libc-2.17.so+0x21b34) #12 0x41d14d (/usr/lib64/nx/bin/nxagent+0x41d14d) 0x601c0000bd68 is located 40 bytes inside of 152-byte region [0x601c0000bd40,0x601c0000bdd8) freed by thread T0 here: #0 0x7fb332a05009 (/usr/lib64/libasan.so.0.0.0+0x16009) #1 0xd82478 (/usr/lib64/nx/bin/nxagent+0xd82478) previously allocated by thread T0 here: #0 0x7fb332a05129 (/usr/lib64/libasan.so.0.0.0+0x16129) #1 0xd82896 (/usr/lib64/nx/bin/nxagent+0xd82896) Shadow bytes around the buggy address: 0x0c03ffff9750: fa fa fa fa 00 00 00 00 00 00 00 00 00 00 00 00 0x0c03ffff9760: 00 00 00 00 00 00 04 fa fa fa fa fa fa fa fa fa 0x0c03ffff9770: fd fd fd fd fd fd fd fd fd fd fd fd fd fd fd fd 0x0c03ffff9780: fd fd fd fa fa fa fa fa fa fa fa fa fd fd fd fd 0x0c03ffff9790: fd fd fd fd fd fd fd fd fd fd fd fd fd fd fd fa =>0x0c03ffff97a0: fa fa fa fa fa fa fa fa fd fd fd fd fd[fd]fd fd 0x0c03ffff97b0: fd fd fd fd fd fd fd fd fd fd fd fa fa fa fa fa 0x0c03ffff97c0: fa fa fa fa fd fd fd fd fd fd fd fd fd fd fd fd 0x0c03ffff97d0: fd fd fd fd fd fd fd fa fa fa fa fa fa fa fa fa 0x0c03ffff97e0: fd fd fd fd fd fd fd fd fd fd fd fd fd fd fd fd 0x0c03ffff97f0: fd fd fd fd fa fa fa fa fa fa fa fa 00 00 00 00 Shadow byte legend (one shadow byte represents 8 application bytes): Addressable: 00 Partially addressable: 01 02 03 04 05 06 07 Heap left redzone: fa Heap righ redzone: fb Freed Heap region: fd Stack left redzone: f1 Stack mid redzone: f2 Stack right redzone: f3 Stack partial redzone: f4 Stack after return: f5 Stack use after scope: f8 Global redzone: f9 Global init order: f6 Poisoned by user: f7 ASan internal: fe ==30566== ABORTING
which makes discovering any additional issues later in the session impossible.
It would be nice to get this fixed.
-- Orion Poplawski Technical Manager 720-772-5637 NWRA, Boulder/CoRA Office FAX: 303-415-9702 3380 Mitchell Lane orion@nwra.com Boulder, CO 80301 http://www.nwra.com
which makes discovering any additional issues later in the session impossible. There is way to "skip" known problems and continue further: https://github.com/google/sanitizers/wiki/AddressSanitizer#turning-off-instr... This is quite risky but may help in finding more bugs while waiting for fixes for known ones.