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 or...@nwra.com Boulder, CO 80301 http://www.nwra.com _______________________________________________ x2go-dev mailing list x2go-dev@lists.x2go.org http://lists.x2go.org/listinfo/x2go-dev