| Commit message (Collapse) | Author | Age | Files | Lines |
... | |
| | |
|
| | |
|
| | |
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
"warning: declaration of '<something>' shadows a member of 'this'
This shows up in gcc 4.8.5 and has been fixed in gcc 5.0, see
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=57709
Change the variable names anyway to be on the safe side.
Fixes ArcticaProject/nx-libs#958
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
In file included from Proxy.h:39:0,
from ServerProxy.h:32,
from ServerProxy.cpp:36:
Channel.h: In member function 'int Channel::handleEncodeIdentity(EncodeBuffer&, ChannelCache*, MessageStore*, const unsigned char*, unsigned int, int)':
Channel.h:369:3: warning: declaration of 'bigEndian' shadows a member of 'this' [-Wshadow]
{
^
Channel.h: In member function 'int Channel::handleDecodeIdentity(DecodeBuffer&, ChannelCache*, MessageStore*, unsigned char*&, unsigned int&, int, WriteBuffer*)':
Channel.h:378:3: warning: declaration of 'bigEndian' shadows a member of 'this' [-Wshadow]
{
^
RHEL7's g++ 4.8.5 reports this while Debian's g++ 10.2.0-15 does
not. This is described in
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=57709 and fixed in gcc
5.0.
Rename the variables anyway to be on the safe side.
Fixes ArcticaProject/nx-libs#956
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
*** ERROR: ambiguous python shebang in /usr/bin/nxdialog: #!/usr/bin/env
python. Change it to python3 (or python2) explicitly.
Fedora offers a pythfix.py but I could not test with that so I simply
used sed...
Fixes ArcticaProject/nx-libs#955
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
|\ \
| |/
|/|
| |
| |
| |
| | |
into 3.6.x
Attributes GH PR #961: https://github.com/ArcticaProject/nx-libs/pull/961
Approved by Ulrich Sibiller <uli42@gmx.de>, Tue, 03 Nov 2020 08:14:04 -0800
|
| | |
|
|/
|
|
| |
(better macro name).
|
|\
| |
| |
| | |
Attributes GH PR #949: https://github.com/ArcticaProject/nx-libs/pull/949
|
|/
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
==15332== 2,500 (96 direct, 2,404 indirect) bytes in 6 blocks are definitely lost in loss record 324 of 342
==15332== at 0x4C2DB8F: malloc (in /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so)
==15332== by 0x5748B9E: FontFileStartListFonts (in /usr/lib/x86_64-linux-gnu/libXfont.so.1.4.1)
==15332== by 0x5748C4A: FontFileStartListFontsAndAliases (in /usr/lib/x86_64-linux-gnu/libXfont.so.1.4.1)
==15332== by 0x42859A: nxdoListFontsAndAliases (NXdixfonts.c:1163)
==15332== by 0x42C0E0: nxOpenFont (NXdixfonts.c:1541)
==15332== by 0x43392E: ProcOpenFont (NXdispatch.c:902)
==15332== by 0x434585: Dispatch (NXdispatch.c:482)
==15332== by 0x40EF77: main (main.c:355)
FontFileStartListFonts[AndAliases]() allocates some private data. This
data is used by subsequent calls of FontFileListNextFontOrAlias() in a
loop. (Only) the last call to that function will free() the private
data and return with BadFontName. FontFileListNextFontOrAlias() is
the only libXfont function that free()s the private data.
In nxagent the loop is exited as soon as a font exists both locally
and remote. Therefore the private data would never be free()d.
Solution: do not break the loop but store the first matching result
and let the loop run to the end, ignoring all following results.
Disadvantage: this can mean hundreds of extra iterations for
nothing. I have done no investigation of the time penalty this might
cause.
Unfortunately this is the only clean way I have found so far.
An unclean solution has also been implemented. It can be activated by
defining BREAK_XFONT_LOOP. In that case the private data is handled in
nxagent by taking assumptions about its structure (taken from the
libXfont source). That will break if libXfont changes its internal
handling of the private. Therefore it is discouraged.
An third alternative would be to drop using libXfont from the
system. Instead fork libXfont to the nx-libs tree, add some patches
link to that library statically.
Fixes ArcticaProject/nx-libs#586
|
|\
| |
| |
| | |
Attributes GH PR #952: https://github.com/ArcticaProject/nx-libs/pull/952
|
|/
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
#4 0x63e2fd in nxagentInternalOpenDisplay /home/uli/work/nx/nx-libs/nx-X11/programs/Xserver/hw/nxagent/Display.c:608
#5 0x63fa03 in nxagentOpenDisplay /home/uli/work/nx/nx-libs/nx-X11/programs/Xserver/hw/nxagent/Display.c:1140
#6 0x694b5a in InitOutput /home/uli/work/nx/nx-libs/nx-X11/programs/Xserver/hw/nxagent/Init.c:305
#7 0x5f7b11 in main /home/uli/work/nx/nx-libs/nx-X11/programs/Xserver/dix/main.c:278
#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/nx-libs#951
|
|\
| |
| | |
fix spec file
|
|/
|
|
|
|
| |
doc file path for nxdialog was wrong
Fixes ArcticaProject/nx-libs#959
|
|\
| |
| |
| | |
Attributes GH PR #940: https://github.com/ArcticaProject/nx-libs/pull/940
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| |
| |
| |
| |
| | |
Setting nxagentDefaultWindow[pScreen->myNum] is pointless because it is
overwritten in the next code block...
|
| |
| |
| |
| |
| |
| |
| | |
setting a value for an attribute in the structure is pointless if you
do not set the valuemask accordingly. Adding the missing valuemask
code here would also be pointless because the valuemask is set to a fixed
value later on. Therefore we can drop this code here.
|
| | |
|
| |
| |
| |
| | |
new code is easier to read
|
| | |
|
| | |
|
| | |
|
| |
| |
| |
| | |
and not as a "private" window like all others.
|
| | |
|
| | |
|
| | |
|
| | |
|
| |
| |
| |
| | |
We are not using it anywhere so let's disable it via a macro for now.
|
| | |
|
| | |
|
| | |
|
| |
| |
| |
| |
| |
| | |
This only happened with certain window managers like mutter.
Fixes ArcticaProject/nx-libs#925
|
| | |
|
|/
|
|
|
|
|
| |
Not really sure why I introduced the client check years ago. Grabbed is
grabbed, so I don't see a reason implementing it this way.
Fixes ArcticaProject/nx-libs#925.
|
|\
| |
| |
| | |
Attributes GH PR #942: https://github.com/ArcticaProject/nx-libs/pull/942
|
|/
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
#4 0x55555571bb92 in nxagentHandleClientMessageEvent nx-X11/programs/Xserver/hw/nxagent/Events.c:2595
#5 0x555555717dfc in nxagentDispatchEvents nx-X11/programs/Xserver/hw/nxagent/Events.c:1827
#6 0x555555750813 in nxagentBlockHandler nx-X11/programs/Xserver/hw/nxagent/Handlers.c:437
#7 0x5555556c1b5d in BlockHandler nx-X11/programs/Xserver/dix/dixutils.c:403
#8 0x5555556d47ff in WaitForSomething nx-X11/programs/Xserver/os/WaitFor.c:232
#9 0x555555665b22 in Dispatch nx-X11/programs/Xserver/hw/nxagent/NXdispatch.c:365
#10 0x5555555ed760 in main nx-X11/programs/Xserver/dix/main.c:350
#11 0x7ffff604909a in __libc_start_main ../csu/libc-start.c:308
#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
...
|