| Commit message (Collapse) | Author | Age | Files | Lines |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
rep->generic.sequenceNumber is of type CARD16
state->sequence is of type unsigned long
Converting state->sequence to an int as it has been done since the
first version of nxcomp I know of (1.3.0-18 from 2003) is wrong here
because for numbers > INT_MAX this will result in a negative number,
which, after applying the 16bit modulo, will not match
rep->generic.sequenceNumber.
Example with numbers:
CARD16 c = 24565
unsigned long u = 3179110389
c % 65536 = 24565
u % 65536 = 24565
(int)(u) = -1115856907
(int)(u) % 65536 = -40971
-40971 will not match 24565
To fix this we need to ensure the number stays positive. We use CARD16
for this to match the type in the request which is a 16bit number. On
my system CARD16 is unsigned short which is guaranteed to contain _at
least_ the 0-65,535 range. As there is no upper limit of the range we
cannot drop the modulo because we need this value to be 16bit and not
more.
Thanks to Norm Green for providing log after log until we could
finally identify the reason for him seeing "Xlib: unexpected async
reply (sequence 0x94b01439)!" when pasting stopped working.
|
|
|
|
|
| |
An X reply contains a type which is X_Reply or X_Error. This is not an
opcode which is used when installing the handler.
|
|
|
|
| |
Should help in debugging "unexpected async reply" problems
|
| |
|
| |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
rep->generic.sequenceNumber is of type CARD16
state->sequence is of type unsigned long
Converting state->sequence to an int as it has been done since the
first version of nxcomp I know of (1.3.0-18 from 2003) is wrong here
because for numbers > INT_MAX this will result in a negative number,
which, after applying the 16bit modulo, will not match
rep->generic.sequenceNumber.
Example with numbers:
CARD16 c = 24565
unsigned long u = 3179110389
c % 65536 = 24565
u % 65536 = 24565
(int)(u) = -1115856907
(int)(u) % 65536 = -40971
-40971 will not match 24565
To fix this we need to ensure the number stays positive. We use CARD16
for this to match the type in the request which is a 16bit number. On
my system CARD16 is unsigned short which is guaranteed to contain _at
least_ the 0-65,535 range. As there is no upper limit of the range we
cannot drop the modulo because we need this value to be 16bit and not
more.
Thanks to Norm Green for providing log after log until we could
finally identify the reason for him seeing "Xlib: unexpected async
reply (sequence 0x94b01439)!" when pasting stopped working.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Png.c: In function ‘PngWriteData’:
Png.c:603:38: warning: declaration of ‘png_ptr’ shadows a global declaration [-Wshadow]
603 | static void PngWriteData(png_structp png_ptr, png_bytep data, png_size_t length)
| ~~~~~~~~~~~~^~~~~~~
Png.c:77:13: note: shadowed declaration is here
77 | png_structp png_ptr;
| ^~~~~~~
Png.c: In function ‘PngFlushData’:
Png.c:610:38: warning: declaration of ‘png_ptr’ shadows a global declaration [-Wshadow]
610 | static void PngFlushData(png_structp png_ptr)
| ~~~~~~~~~~~~^~~~~~~
Png.c:77:13: note: shadowed declaration is here
77 | png_structp png_ptr;
| ^~~~~~~
|
| |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
...
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Clean.c: In function ‘CleanZImage’:
Clean.c:141:23: warning: declaration of ‘j’ shadows a previous local [-Wshadow=local]
register int i, j;
^
Clean.c:88:16: note: shadowed declaration is here
unsigned int j;
^
Clean.c: In function ‘CopyAndCleanImage’:
Clean.c:239:22: warning: declaration of ‘i’ shadows a previous local [-Wshadow=compatible-local]
register int i;
^
Clean.c:192:16: note: shadowed declaration is here
register int i;
^
Clean.c:324:13: warning: declaration of ‘i’ shadows a previous local [-Wshadow=compatible-local]
int i;
^
Clean.c:192:16: note: shadowed declaration is here
register int i;
^
|
| |
|
| |
|
|
|
|
|
|
|
|
| |
Move allocation of image_index close before first_use. This way we do
not need to free it if previous step fail. And we cannot forget that
free() call.
While at it replace malloc+memset by calloc.
|
|
|
|
| |
913fcf1a74426725f14380dd5b34286a21c37ab7.
|
| |
|
| |
|
| |
|
|
|
|
|
|
| |
are directly available.
Especially don't add linking flags willy-nilly.
|
| |
|
| |
|
| |
|
| |
|
|
includes at build time.
Fixes ArcticaProject/nx-libs#276.
|