Skip to content
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

Merged
merged 2 commits into from
Feb 17, 2015

Conversation

sunweaver
Copy link
Member

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.

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)

Copy link
Member

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?

Copy link
Member

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}"

@mikedep333
Copy link
Contributor

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:
http://cgit.freedesktop.org/xorg/xserver/commit/?id=3a06faf3fcdb7451125a46181f9152e8e59e9770&utm_source=anzwix
http://cgit.freedesktop.org/xorg/xserver/tree/hw/xfree86/common/xorgVersion.h?id=xorg-server-1.17.1

In particular, note that they use:
XORG_VERSION_MAJOR
XORG_VERSION_MINOR
XORG_VERSION_PATCH
XORG_VERSION_SNAP
(Although I agree that major, minor, micro, and patch is more intuitive.)

@Ionic
Copy link
Member

Ionic commented Feb 17, 2015

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.

@mikedep333
Copy link
Contributor

Understood, I will continue reviewing.

@mikedep333
Copy link
Contributor

I need to learn make syntax better. Based on my review, this looks OK to me.

@Ionic
Copy link
Member

Ionic commented Feb 17, 2015

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...

@sunweaver
Copy link
Member Author

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

@sunweaver
Copy link
Member Author

... I will rebase the new commits with commit 0e341f5 before merging...

@sunweaver
Copy link
Member Author

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.
sunweaver added a commit that referenced this pull request Feb 17, 2015
Make nxagent aware of its NX'ish version string (and number).
@sunweaver sunweaver merged commit c910bf7 into ArcticaProject:3.6.x Feb 17, 2015
@sunweaver sunweaver deleted the feature/nxagent-version-v2 branch April 21, 2015 18:35
@sunweaver sunweaver added this to the 3.6.0.x milestone May 16, 2015
uli42 referenced this pull request in uli42/nx-libs Jun 19, 2019
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.
uli42 referenced this pull request in uli42/nx-libs Jun 21, 2019
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.
sunweaver referenced this pull request in uli42/nx-libs Jun 22, 2019
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.
uli42 referenced this pull request in uli42/nx-libs Oct 2, 2020
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
...
@uli42 uli42 mentioned this pull request Oct 7, 2020
sunweaver referenced this pull request in uli42/nx-libs Oct 17, 2020
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
...
@uli42 uli42 mentioned this pull request Oct 18, 2020
uli42 referenced this pull request in uli42/nx-libs Oct 18, 2020
 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
sunweaver referenced this pull request in uli42/nx-libs Nov 3, 2020
 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
@uli42 uli42 mentioned this pull request Mar 2, 2021
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants