-
Notifications
You must be signed in to change notification settings - Fork 39
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Make nxagent aware of its NX'ish version string (and number). #3
Make nxagent aware of its NX'ish version string (and number). #3
Conversation
NX_VERSION_MINOR=$(shell cat VERSION | cut -d"." -f2) | ||
NX_VERSION_MICRO=$(shell cat VERSION | cut -d"." -f3) | ||
NX_VERSION_PATCH=$(shell cat VERSION | cut -d"." -f4) | ||
|
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Maybe it's better to use a "real" shell script here which fetches the version number part and, if it is unset, defaults to "0", to always have the parts well-defined?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The script can be as easy as:
#!/bin/sh
COMPONENT="$1"
VERSION_FILE="VERSION"
# More than one line is not supported.
VER="$(head -n "1" "${VERSION_FILE}" | cut -d"." -f"${COMPONENT}")"
[ "x${VER}" = "x" ] && VER="0"
printf "${VER}"
Is there a reason why we are differing from upstream? Like because our build system is so different? With VcXsrv, both I and marha use the convention that X.org uses: In particular, note that they use: |
NX always used their own version numbering scheme and has incremented the MAJOR version often, while X never has. I feel the MAJOR/MINOR/MICRO/PATCH definition is a better fix for nx-libs. |
Understood, I will continue reviewing. |
I need to learn make syntax better. Based on my review, this looks OK to me. |
Well, this is additionally complicated, because this is not exactly make syntax. That's imake syntax, which is different and even requires a pre-processor... |
Hi Mihai, hi Michael, I just pushed three more commits to the feature/nxagent-version PR branch. If there are no more objections within the next 9h (1300 UTC), I will merge. Mike |
... I will rebase the new commits with commit 0e341f5 before merging... |
About the versioning in NX. In X2Go we received a patch that allows for having four digit versions. There the original author also used M.m.µ.p as naming scheme. I like it back then and adopted it here. |
This feature copies the way how X.Org version string and number are propagated at build time. First use case: if people start nxagent, it reports its version number on stderr. This is about being human-friendly. Second use case: None, so far. But it will now be easy to use the NXAGENT_VERSION_STRING in later feature add-ons.
1d4e263
to
203d971
Compare
Make nxagent aware of its NX'ish version string (and number).
If compiled with -fsanitize=address this showed up when running startlxde: ==11551==ERROR: AddressSanitizer: heap-buffer-overflow on address 0x60d000018fbc at pc 0x7f270a9ed57b bp 0x7fff30ef3050 sp 0x7fff30ef2800 READ of size 204 at 0x60d000018fbc thread T0 #0 0x7f270a9ed57a (/usr/lib/x86_64-linux-gnu/libasan.so.5+0xb857a) #1 0x559dafcd5c93 in FindGlyphRef ../../render/glyph.c:179 #2 0x559dafcd705d in AddGlyph /work/nx-libs/nx-X11/programs/Xserver/hw/nxagent/NXglyph.c:71 #3 0x559dafccc0ff in ProcRenderAddGlyphs ../../mi/../render/render.c:1186 ArcticaProject#4 0x559dafcbd5a5 in ProcRenderDispatch /work/nx-libs/nx-X11/programs/Xserver/hw/nxagent/NXrender.c:1689 ArcticaProject#5 0x559dafcbc4ea in Dispatch /work/nx-libs/nx-X11/programs/Xserver/hw/nxagent/NXdispatch.c:476 ArcticaProject#6 0x559dafc4e9b0 in main /work/nx-libs/nx-X11/programs/Xserver/dix/main.c:353 ArcticaProject#7 0x7f2708e1d09a in __libc_start_main ../csu/libc-start.c:308 ArcticaProject#8 0x559dafc4f5d9 in _start (/work/nx-libs/nx-X11/programs/Xserver/nxagent+0x6e5d9) 0x60d000018fbc is located 0 bytes to the right of 140-byte region [0x60d000018f30,0x60d000018fbc) allocated by thread T0 here: #0 0x7f270aa1e330 in __interceptor_malloc (/usr/lib/x86_64-linux-gnu/libasan.so.5+0xe9330) #1 0x559dafcd646c in AllocateGlyph ../../render/glyph.c:348 This happens when two glyphs are compared via memcmp and the smaller one happens to be identical to the beginning of the bigger one. Newer render implementations use a sha1 hash instead of memcmp so this patch will (hopefully) be obsolete once render gets updated.
If compiled with -fsanitize=address this showed up when running startlxde: ==11551==ERROR: AddressSanitizer: heap-buffer-overflow on address 0x60d000018fbc at pc 0x7f270a9ed57b bp 0x7fff30ef3050 sp 0x7fff30ef2800 READ of size 204 at 0x60d000018fbc thread T0 #0 0x7f270a9ed57a (/usr/lib/x86_64-linux-gnu/libasan.so.5+0xb857a) #1 0x559dafcd5c93 in FindGlyphRef ../../render/glyph.c:179 #2 0x559dafcd705d in AddGlyph /work/nx-libs/nx-X11/programs/Xserver/hw/nxagent/NXglyph.c:71 #3 0x559dafccc0ff in ProcRenderAddGlyphs ../../mi/../render/render.c:1186 ArcticaProject#4 0x559dafcbd5a5 in ProcRenderDispatch /work/nx-libs/nx-X11/programs/Xserver/hw/nxagent/NXrender.c:1689 ArcticaProject#5 0x559dafcbc4ea in Dispatch /work/nx-libs/nx-X11/programs/Xserver/hw/nxagent/NXdispatch.c:476 ArcticaProject#6 0x559dafc4e9b0 in main /work/nx-libs/nx-X11/programs/Xserver/dix/main.c:353 ArcticaProject#7 0x7f2708e1d09a in __libc_start_main ../csu/libc-start.c:308 ArcticaProject#8 0x559dafc4f5d9 in _start (/work/nx-libs/nx-X11/programs/Xserver/nxagent+0x6e5d9) 0x60d000018fbc is located 0 bytes to the right of 140-byte region [0x60d000018f30,0x60d000018fbc) allocated by thread T0 here: #0 0x7f270aa1e330 in __interceptor_malloc (/usr/lib/x86_64-linux-gnu/libasan.so.5+0xe9330) #1 0x559dafcd646c in AllocateGlyph ../../render/glyph.c:348 This happens when two glyphs are compared via memcmp and the smaller one happens to be identical to the beginning of the bigger one. Newer render implementations use a sha1 hash instead of memcmp so this patch will (hopefully) be obsolete once render gets updated.
If compiled with -fsanitize=address this showed up when running startlxde: ==11551==ERROR: AddressSanitizer: heap-buffer-overflow on address 0x60d000018fbc at pc 0x7f270a9ed57b bp 0x7fff30ef3050 sp 0x7fff30ef2800 READ of size 204 at 0x60d000018fbc thread T0 #0 0x7f270a9ed57a (/usr/lib/x86_64-linux-gnu/libasan.so.5+0xb857a) #1 0x559dafcd5c93 in FindGlyphRef ../../render/glyph.c:179 #2 0x559dafcd705d in AddGlyph /work/nx-libs/nx-X11/programs/Xserver/hw/nxagent/NXglyph.c:71 #3 0x559dafccc0ff in ProcRenderAddGlyphs ../../mi/../render/render.c:1186 ArcticaProject#4 0x559dafcbd5a5 in ProcRenderDispatch /work/nx-libs/nx-X11/programs/Xserver/hw/nxagent/NXrender.c:1689 ArcticaProject#5 0x559dafcbc4ea in Dispatch /work/nx-libs/nx-X11/programs/Xserver/hw/nxagent/NXdispatch.c:476 ArcticaProject#6 0x559dafc4e9b0 in main /work/nx-libs/nx-X11/programs/Xserver/dix/main.c:353 ArcticaProject#7 0x7f2708e1d09a in __libc_start_main ../csu/libc-start.c:308 ArcticaProject#8 0x559dafc4f5d9 in _start (/work/nx-libs/nx-X11/programs/Xserver/nxagent+0x6e5d9) 0x60d000018fbc is located 0 bytes to the right of 140-byte region [0x60d000018f30,0x60d000018fbc) allocated by thread T0 here: #0 0x7f270aa1e330 in __interceptor_malloc (/usr/lib/x86_64-linux-gnu/libasan.so.5+0xe9330) #1 0x559dafcd646c in AllocateGlyph ../../render/glyph.c:348 This happens when two glyphs are compared via memcmp and the smaller one happens to be identical to the beginning of the bigger one. Newer render implementations use a sha1 hash instead of memcmp so this patch will (hopefully) be obsolete once render gets updated.
In compext Atom has the size of XlibAtom. Therefore calling functions of Compext.c requires to use/pass XlibAtom. Same for Window/XlibWindow. ==15438==ERROR: AddressSanitizer: stack-buffer-overflow on address 0x7fffffffcdc0 at pc 0x5555556a81b5 bp 0x7fffffffcd10 sp 0x7fffffffcd08 WRITE of size 8 at 0x7fffffffcdc0 thread T0 #0 0x5555556a81b4 in NXGetCollectedProperty nx-X11/programs/Xserver/hw/nxagent/compext/Compext.c:4124 #1 0x5555557d0488 in nxagentCollectPropertyEvent nx-X11/programs/Xserver/hw/nxagent/Clipboard.c:1202 #2 0x555555723340 in nxagentHandleCollectPropertyEvent nx-X11/programs/Xserver/hw/nxagent/Events.c:3923 #3 0x55555571d4db in nxagentHandleProxyEvent nx-X11/programs/Xserver/hw/nxagent/Events.c:3007 ArcticaProject#4 0x55555571bb92 in nxagentHandleClientMessageEvent nx-X11/programs/Xserver/hw/nxagent/Events.c:2595 ArcticaProject#5 0x555555717dfc in nxagentDispatchEvents nx-X11/programs/Xserver/hw/nxagent/Events.c:1827 ArcticaProject#6 0x555555750813 in nxagentBlockHandler nx-X11/programs/Xserver/hw/nxagent/Handlers.c:437 ArcticaProject#7 0x5555556c1b5d in BlockHandler nx-X11/programs/Xserver/dix/dixutils.c:403 ArcticaProject#8 0x5555556d47ff in WaitForSomething nx-X11/programs/Xserver/os/WaitFor.c:232 ArcticaProject#9 0x555555665b22 in Dispatch nx-X11/programs/Xserver/hw/nxagent/NXdispatch.c:365 ArcticaProject#10 0x5555555ed760 in main nx-X11/programs/Xserver/dix/main.c:350 ArcticaProject#11 0x7ffff604909a in __libc_start_main ../csu/libc-start.c:308 ArcticaProject#12 0x5555555edc09 in _start (nx-X11/programs/Xserver/nxagent+0x99c09) Address 0x7fffffffcdc0 is located in stack of thread T0 at offset 32 in frame #0 0x5555557d0324 in nxagentCollectPropertyEvent nx-X11/programs/Xserver/hw/nxagent/Clipboard.c:1190 This frame has 5 object(s): [32, 36) 'atomReturnType' <== Memory access at offset 32 partially overflows this variable [96, 100) 'resultFormat' [160, 168) 'ulReturnItems' [224, 232) 'ulReturnBytesLeft' [288, 296) 'pszReturnData' HINT: this may be a false positive if your program uses some custom stack unwind mechanism, swapcontext or vfork (longjmp and C++ exceptions *are* supported) SUMMARY: AddressSanitizer: stack-buffer-overflow nx-X11/programs/Xserver/hw/nxagent/compext/Compext.c:4124 in NXGetCollectedProperty ...
In compext Atom has the size of XlibAtom. Therefore calling functions of Compext.c requires to use/pass XlibAtom. Same for Window/XlibWindow. ==15438==ERROR: AddressSanitizer: stack-buffer-overflow on address 0x7fffffffcdc0 at pc 0x5555556a81b5 bp 0x7fffffffcd10 sp 0x7fffffffcd08 WRITE of size 8 at 0x7fffffffcdc0 thread T0 #0 0x5555556a81b4 in NXGetCollectedProperty nx-X11/programs/Xserver/hw/nxagent/compext/Compext.c:4124 #1 0x5555557d0488 in nxagentCollectPropertyEvent nx-X11/programs/Xserver/hw/nxagent/Clipboard.c:1202 #2 0x555555723340 in nxagentHandleCollectPropertyEvent nx-X11/programs/Xserver/hw/nxagent/Events.c:3923 #3 0x55555571d4db in nxagentHandleProxyEvent nx-X11/programs/Xserver/hw/nxagent/Events.c:3007 ArcticaProject#4 0x55555571bb92 in nxagentHandleClientMessageEvent nx-X11/programs/Xserver/hw/nxagent/Events.c:2595 ArcticaProject#5 0x555555717dfc in nxagentDispatchEvents nx-X11/programs/Xserver/hw/nxagent/Events.c:1827 ArcticaProject#6 0x555555750813 in nxagentBlockHandler nx-X11/programs/Xserver/hw/nxagent/Handlers.c:437 ArcticaProject#7 0x5555556c1b5d in BlockHandler nx-X11/programs/Xserver/dix/dixutils.c:403 ArcticaProject#8 0x5555556d47ff in WaitForSomething nx-X11/programs/Xserver/os/WaitFor.c:232 ArcticaProject#9 0x555555665b22 in Dispatch nx-X11/programs/Xserver/hw/nxagent/NXdispatch.c:365 ArcticaProject#10 0x5555555ed760 in main nx-X11/programs/Xserver/dix/main.c:350 ArcticaProject#11 0x7ffff604909a in __libc_start_main ../csu/libc-start.c:308 ArcticaProject#12 0x5555555edc09 in _start (nx-X11/programs/Xserver/nxagent+0x99c09) Address 0x7fffffffcdc0 is located in stack of thread T0 at offset 32 in frame #0 0x5555557d0324 in nxagentCollectPropertyEvent nx-X11/programs/Xserver/hw/nxagent/Clipboard.c:1190 This frame has 5 object(s): [32, 36) 'atomReturnType' <== Memory access at offset 32 partially overflows this variable [96, 100) 'resultFormat' [160, 168) 'ulReturnItems' [224, 232) 'ulReturnBytesLeft' [288, 296) 'pszReturnData' HINT: this may be a false positive if your program uses some custom stack unwind mechanism, swapcontext or vfork (longjmp and C++ exceptions *are* supported) SUMMARY: AddressSanitizer: stack-buffer-overflow nx-X11/programs/Xserver/hw/nxagent/compext/Compext.c:4124 in NXGetCollectedProperty ...
Direct leak of 3 byte(s) in 1 object(s) allocated from: #0 0xb79e85d4 in __interceptor_malloc (/lib/i386-linux-gnu/libasan.so.5+0xeb5d4) #1 0xb770b635 in copystring /home/uli/work/nx/nx-libs/nx-X11/lib/src/ConnDis.c:96 #2 0xb770ba56 in _X11TransConnectDisplay /home/uli/work/nx/nx-libs/nx-X11/lib/src/ConnDis.c:229 #3 0xb776b4fd in XOpenDisplay /home/uli/work/nx/nx-libs/nx-X11/lib/src/OpenDis.c:215 ArcticaProject#4 0x63e2fd in nxagentInternalOpenDisplay /home/uli/work/nx/nx-libs/nx-X11/programs/Xserver/hw/nxagent/Display.c:608 ArcticaProject#5 0x63fa03 in nxagentOpenDisplay /home/uli/work/nx/nx-libs/nx-X11/programs/Xserver/hw/nxagent/Display.c:1140 ArcticaProject#6 0x694b5a in InitOutput /home/uli/work/nx/nx-libs/nx-X11/programs/Xserver/hw/nxagent/Init.c:305 ArcticaProject#7 0x5f7b11 in main /home/uli/work/nx/nx-libs/nx-X11/programs/Xserver/dix/main.c:278 ArcticaProject#8 0xb6f04b40 in __libc_start_main ../csu/libc-start.c:308 I have not investigated the exact location where an XFree() was missing but added multiple Xfree() calls whereever appropriate. Fixes ArcticaProject#951
Direct leak of 3 byte(s) in 1 object(s) allocated from: #0 0xb79e85d4 in __interceptor_malloc (/lib/i386-linux-gnu/libasan.so.5+0xeb5d4) #1 0xb770b635 in copystring /home/uli/work/nx/nx-libs/nx-X11/lib/src/ConnDis.c:96 #2 0xb770ba56 in _X11TransConnectDisplay /home/uli/work/nx/nx-libs/nx-X11/lib/src/ConnDis.c:229 #3 0xb776b4fd in XOpenDisplay /home/uli/work/nx/nx-libs/nx-X11/lib/src/OpenDis.c:215 ArcticaProject#4 0x63e2fd in nxagentInternalOpenDisplay /home/uli/work/nx/nx-libs/nx-X11/programs/Xserver/hw/nxagent/Display.c:608 ArcticaProject#5 0x63fa03 in nxagentOpenDisplay /home/uli/work/nx/nx-libs/nx-X11/programs/Xserver/hw/nxagent/Display.c:1140 ArcticaProject#6 0x694b5a in InitOutput /home/uli/work/nx/nx-libs/nx-X11/programs/Xserver/hw/nxagent/Init.c:305 ArcticaProject#7 0x5f7b11 in main /home/uli/work/nx/nx-libs/nx-X11/programs/Xserver/dix/main.c:278 ArcticaProject#8 0xb6f04b40 in __libc_start_main ../csu/libc-start.c:308 I have not investigated the exact location where an XFree() was missing but added multiple Xfree() calls whereever appropriate. Fixes ArcticaProject#951
Until now, nxagent uses a hard-coded version string internally that is set to "3.5.0" in nx-X11/programs/Xserver/hw/nxagent/Init.c.
This change picks the version number from /VERSION, populates nx-X11/config/cf/nxversion.def with it and propagates it through to the nxagent's Imakefile.