| Commit message (Collapse) | Author | Age | Files | Lines |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
#4 0x559dafcbd5a5 in ProcRenderDispatch /work/nx-libs/nx-X11/programs/Xserver/hw/nxagent/NXrender.c:1689
#5 0x559dafcbc4ea in Dispatch /work/nx-libs/nx-X11/programs/Xserver/hw/nxagent/NXdispatch.c:476
#6 0x559dafc4e9b0 in main /work/nx-libs/nx-X11/programs/Xserver/dix/main.c:353
#7 0x7f2708e1d09a in __libc_start_main ../csu/libc-start.c:308
#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.
|
| |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
==10226== 3,337 bytes in 1 blocks are definitely lost in loss record 295 of 307
==10226== at 0x483577F: malloc (vg_replace_malloc.c:299)
==10226== by 0x6281DB9: strdup (strdup.c:42)
==10226== by 0x2ABA9E: __glXClientInfo (glxcmds.c:2170)
==10226== by 0x17CA3E: __glXDispatch (NXglxext.c:128)
==10226== by 0x16EE77: Dispatch (NXdispatch.c:476)
==10226== by 0x14DCE0: main (main.c:353)
There's no point in trying to free cl->* after memset(0).
This one is a bug that is found identically in xorg upstream and has
only been fixed during rework of the whole client resource freeing
stuff. So we fix it in glxext.c.
|
| |
|
| |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Fix these memory leaks:
==30021== 128 bytes in 1 blocks are definitely lost in loss record 230 of 302
==30021== at 0x483577F: malloc (vg_replace_malloc.c:299)
==30021== by 0x2EF89C: init_visuals (xf86glx.c:390)
==30021== by 0x2EF89C: __MESA_initVisuals (xf86glx.c:541)
==30021== by 0x17C922: GlxInitVisuals (glxext.c:317)
==30021== by 0x218E73: fbInitVisuals (fbcmap.c:668)
==30021== by 0x20BEB1: fbFinishScreenInit (fbscreen.c:229)
==30021== by 0x20C275: fbScreenInit (fbscreen.c:273)
==30021== by 0x1E0317: nxagentOpenScreen (Screen.c:1357)
==30021== by 0x16D848: AddScreen (dispatch.c:4171)
==30021== by 0x1DB7FF: InitOutput (Init.c:396)
==30021== by 0x14DB12: main (main.c:279)
==30021==
==30021== 3,072 (192 direct, 2,880 indirect) bytes in 1 blocks are definitely lost in loss record 290 of 302
==30021== at 0x483577F: malloc (vg_replace_malloc.c:299)
==30021== by 0x2CCCC7: _gl_context_modes_create (glcontextmodes.c:364)
==30021== by 0x2EF87C: init_visuals (xf86glx.c:381)
==30021== by 0x2EF87C: __MESA_initVisuals (xf86glx.c:541)
==30021== by 0x17C922: GlxInitVisuals (glxext.c:317)
==30021== by 0x218E73: fbInitVisuals (fbcmap.c:668)
==30021== by 0x20BEB1: fbFinishScreenInit (fbscreen.c:229)
==30021== by 0x20C275: fbScreenInit (fbscreen.c:273)
==30021== by 0x1E0317: nxagentOpenScreen (Screen.c:1357)
==30021== by 0x16D848: AddScreen (dispatch.c:4171)
==30021== by 0x1DB7FF: InitOutput (Init.c:396)
==30021== by 0x14DB12: main (main.c:279)
The problem here is that GlxInitVisuals is called twice. First via
fbScreenInit and then again via nxagentInitGlxExtension. We remove the
first one to ensure the code in nxagenOpenScreen works as initially
intended.
There's an xorg upstream patch that does the same
(7d74690536b64f7b8e8036507ab7790807349c50), but it also cleans up
other stuff we do not even have in out source (yet?).
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
==12280== 0 bytes in 5 blocks are definitely lost in loss record 1 of 304
==12280== at 0x483577F: malloc (vg_replace_malloc.c:299)
==12280== by 0x2EFC29: init_visuals (xf86glx.c:489)
==12280== by 0x2EFC29: __MESA_initVisuals (xf86glx.c:540)
==12280== by 0x17C902: GlxInitVisuals (glxext.c:317)
==12280== by 0x218C03: fbInitVisuals (fbcmap.c:668)
==12280== by 0x20BC41: fbFinishScreenInit (fbscreen.c:229)
==12280== by 0x20C005: fbScreenInit (fbscreen.c:273)
==12280== by 0x1E024C: nxagentOpenScreen (Screen.c:1356)
==12280== by 0x16D828: AddScreen (dispatch.c:4171)
==12280== by 0x1DB7DF: InitOutput (Init.c:396)
==12280== by 0x14DB12: main (main.c:279)
==12280==
==12280== 64 bytes in 2 blocks are definitely lost in loss record 223 of 304
==12280== at 0x483577F: malloc (vg_replace_malloc.c:299)
==12280== by 0x2EFA05: init_visuals (xf86glx.c:489)
==12280== by 0x2EFA05: __MESA_initVisuals (xf86glx.c:540)
==12280== by 0x17C902: GlxInitVisuals (glxext.c:317)
==12280== by 0x218C03: fbInitVisuals (fbcmap.c:668)
==12280== by 0x20BC41: fbFinishScreenInit (fbscreen.c:229)
==12280== by 0x20C005: fbScreenInit (fbscreen.c:273)
==12280== by 0x1E024C: nxagentOpenScreen (Screen.c:1356)
==12280== by 0x16D828: AddScreen (dispatch.c:4171)
==12280== by 0x1DB7DF: InitOutput (Init.c:396)
==12280== by 0x14DB12: main (main.c:279)
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Fixes these two memory leaks identified by valgrind:
==28336== 32 (8 direct, 24 indirect) bytes in 1 blocks are definitely lost in loss record 180 of 308
==28336== at 0x48356AF: malloc (vg_replace_malloc.c:298)
==28336== by 0x4837DE7: realloc (vg_replace_malloc.c:826)
==28336== by 0x1AE322: AllocateDevicePrivate (privates.c:439)
==28336== by 0x27527B: XkbSetExtension (xkbActions.c:72)
==28336== by 0x198E9B: _RegisterPointerDevice (devices.c:361)
==28336== by 0x1DBA35: InitInput (Init.c:440)
==28336== by 0x14DBD6: main (main.c:303)
==28336==
==28336== 32 (8 direct, 24 indirect) bytes in 1 blocks are definitely lost in loss record 181 of 308
==28336== at 0x48356AF: malloc (vg_replace_malloc.c:298)
==28336== by 0x4837DE7: realloc (vg_replace_malloc.c:826)
==28336== by 0x1AE322: AllocateDevicePrivate (privates.c:439)
==28336== by 0x27527B: XkbSetExtension (xkbActions.c:72)
==28336== by 0x198F1B: _RegisterKeyboardDevice (devices.c:384)
==28336== by 0x1DBA3D: InitInput (Init.c:441)
==28336== by 0x14DBD6: main (main.c:303)
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This patch is not necessary at the current code level. But when xkb
code introduced the dev->key check Xorg upstream missed that. So we
backport it now to skip that trap when updating xkb code.
Author: Alan Coopersmith <alan.coopersmith@sun.com>
Date: Mon Jan 4 18:21:54 2010 -0800
CloseDevice: call XkbRemoveResourceClient before freeing key class struct
XkbRemoveResourceClient() returns immediately if dev->key is NULL.
CloseDevice calls XkbRemoveResourceClient until it removes all resources.
If we free dev->key and NULL it before XkbRemoveResourceClient, then
infinite loop ensues, and the server appears to hang on exit or crash.
Signed-off-by: Alan Coopersmith <alan.coopersmith@sun.com>
Reviewed-by: Peter Hutterer <peter.hutterer@who-t.net>
Reviewed-by: Daniel Stone <daniel@fooishbar.org>
Signed-off-by: Keith Packard <keithp@keithp.com>
Backported-to-NX-by: Ulrich Sibiller <uli42@gmx.de>
|
|
|
|
|
|
|
| |
While trying to properly free memory allocated by XKB I accidently
called nxagentFreeKeyboardDeviceData twice and noticed it would cause
a segfault here. As the other pointers are also nullified after
being freed let's just do it here, too.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Fixes ArcticaProject/nx-libs#598
In nxagentOpenScreen we first initialized the RRExtension for the
screen and then replaced pScreen->CloseScreen by
nxagentCloseScreen. This resulted in RandR's RRCloseScreen (and any
other CloseScreen procedure installed by extensions) being no longer
called.
Moving RandR init after configuring pScreen->CloseScreen ensures the
correct calling cascade:
RRCloseScreen -> nxagentCloseScreen ->fbCloseScreen (called explicitly
by nxagentCloseScreen).
Which in turn will fix this memory leak:
==9688== 328 (312 direct, 16 indirect) bytes in 1 blocks are definitely lost in loss record 271 of 319
==9688== at 0x4837B65: calloc (vg_replace_malloc.c:752)
==9688== by 0x4ED2C6: RRScreenInit (randr.c:329)
==9688== by 0x1F2B18: nxagentInitRandRExtension (Extensions.c:122)
==9688== by 0x1DEAFF: nxagentOpenScreen (Screen.c:1409)
==9688== by 0x16D7F8: AddScreen (dispatch.c:4257)
==9688== by 0x1DA0CF: InitOutput (Init.c:397)
==9688== by 0x14DCC2: main (main.c:280)
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
fixes a memory leak:
==19074== 2 bytes in 1 blocks are definitely lost in loss record 8 of 313
==19074== at 0x483577F: malloc (vg_replace_malloc.c:299)
==19074== by 0x1FD83D: fbAllocatePrivates (fballpriv.c:79)
==19074== by 0x20A666: fbSetupScreen (fbscreen.c:110)
==19074== by 0x20A666: fbScreenInit (fbscreen.c:300)
==19074== by 0x1DEA4C: nxagentOpenScreen (Screen.c:1356)
==19074== by 0x16D7F8: AddScreen (dispatch.c:4257)
==19074== by 0x1DA0CF: InitOutput (Init.c:397)
==19074== by 0x14DCC2: main (main.c:280)
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Backport of this commit:
commit b2167015043a458e9cf93b827b43eb5b7c552ce9
Author: Giuseppe Bilotta <giuseppe.bilotta@gmail.com>
Date: Sat Nov 4 23:06:27 2017 +0100
xkb: initialize tsyms
This fixes some “Conditional jump depends on uninitialized value(s)”
errors spotted by valgrind.
Reviewed-by: Eric Engestrom <eric.engestrom@imgtec.com>
Signed-off-by: Giuseppe Bilotta <giuseppe.bilotta@gmail.com>
|
|
|
|
| |
by adding [] around values as almost everywhere
|
| |
|
|
|
|
|
| |
was in inital version of 6ce9fb5f2875754f97035d3338b3d0e1d20169ae but got lost
during some rebasing/cherry-picking preceeding the pull request.
|
|
|
|
|
| |
Window.c:3827:46: warning: array subscript 128 is above array bounds of ‘StoringPixmapRec *[128]’ {aka ‘struct <anonymous> *[128]’} [-Warray-bounds]
i, (void *) nxagentBSPixmapList[i]);
|
|
|
|
| |
format was broken, would not compile
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
commit 57e872301f5e836be2efb8f952f9c9711650b447
Author: Adam Jackson <ajax@redhat.com>
Date: Thu Apr 5 13:07:09 2018 -0400
mi: Hush an almost certainly bogus warning
In file included from ../mi/miexpose.c:83:
../mi/miexpose.c: In function ‘miHandleExposures’:
../include/regionstr.h:174:22: warning: ‘expBox.y2’ may be used uninitialized in this function [-Wmaybe-uninitialized]
(_pReg)->extents = *(_pBox);
~~~~~~~~~~~~~~~~~^~~~~~~~~~
../mi/miexpose.c:139:12: note: ‘expBox.y2’ was declared here
BoxRec expBox;
^~~~~~
etc. It's initialized if (extents), and then only read if (extents),
but gcc doesn't seem to figure that out. Whatever, bzero it to be
explicit.
Signed-off-by: Adam Jackson <ajax@redhat.com>
Acked-by: Keith Packard <keithp@keithp.com>
|
|
|
|
|
|
| |
They were just aliases to already existing defines and were not used
stringently. So we had mix of aliased and non-aliased uses which is
confusing when trying to understand the code...
|
|
|
|
|
|
|
|
|
|
|
| |
This was eventually replaced by nxagentAddConfiguredWindow(pWin,
CW_Map) some lines below which is just leading to the same code being
executed some time later.
(nxagentAddConfiguredWindow() will add a window to a
list. nxagentFlushConfiguredWindow() is called at certain points to
update all windows in that list in one go. "update" here means calling
XConfigureWindow() or XMapWindow() on the real display.)
|
|
|
|
|
|
|
|
|
|
|
|
| |
NXwindow.c:265:27: warning: ‘%d’ directive writing between 1 and 11 bytes into a region of size 10 [-Wformat-overflow=]
sprintf(artsd_port,"%d", nPort);
^~
NXwindow.c:265:26: note: directive argument in the range [-2147476648, 2147483647]
sprintf(artsd_port,"%d", nPort);
^~~~
NXwindow.c:265:7: note: ‘sprintf’ output between 2 and 12 bytes into a destination of size 10
sprintf(artsd_port,"%d", nPort);
^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
We are not using any alloc function that respects that variable, so
lets drop it. Backport of this commit:
commit 0ce61e21d6d7dcca0090e319bbcdb678570f2c3f
Author: Adam Jackson <ajax@redhat.com>
Date: Fri Oct 3 16:05:19 2008 -0400
Remove the Must_have_memory hack.
Also remove an astonishing amount of misunderstanding of how casts work.
|
|\
| |
| |
| | |
Attributes GH PR #814: https://github.com/ArcticaProject/nx-libs/pull/814
|
| | |
|
| | |
|
| | |
|
|/ |
|
|\
| |
| |
| | |
Attributes GH PR #812: https://github.com/ArcticaProject/nx-libs/pull/812
|
| |
| |
| |
| | |
The only left function is identical to the one in mi/miexpose.c.
|
| |
| |
| |
| |
| | |
We do not even know what theme this is and it is probably not relevant
nowadays.
|
| | |
|
| |
| |
| |
| |
| |
| |
| |
| |
| | |
miPaintWindow() was identical to the version in miexpose.c except
for some unitialized variable fixes. As these also should be in
upstream code we add them there (Note: Xorg never fixed this but
totally rewrote the miPaintWindow() later on.)
This allows us to totally drop our special version of miPaintWindow().
|
|/
|
|
|
| |
It is (functionally) identical to our code, so why have
duplicate code?
|
|\
| |
| |
| | |
Attributes GH PR #813: https://github.com/ArcticaProject/nx-libs/pull/813
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
|/ |
|
|\
| |
| |
| | |
Attributes GH PR #810: https://github.com/ArcticaProject/nx-libs/pull/810
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
Not sure how it came to this situation, but the following commit is
partly contained in our version of the code. Some lines had not been
removed, tough...
commit c80c41767eb101e9dbd8393d8cca7764b4e248a4
Author: Aaron Plattner <aplattner@nvidia.com>
Date: Mon Oct 25 22:01:32 2010 -0700
os: Fix BigReq ignoring when another request is pending
Commit cf88363db0ebb42df7cc286b85d30d7898aea840 fixed the handling of
BigReq requests that are way too large and handles the case where the
read() syscall returns a short read. However, it neglected to handle
the case where it returns a long read, which happens when the client
has another request in the queue after the bogus large one.
Handle the long read case by subtracting the smaller of 'needed' and
'gotnow' from oci->ignoreBytes. If needed < gotnow, simply subtract
the two, leaving gotnow equal to the number of extra bytes read.
Since the code immediately following the (oci->ignoreBytes > 0) block
tries to handle the next request, advance oci->bufptr immediately
instead of setting oci->lenLastReq and letting the next call to
ReadRequestFromClient do it.
Fixes the XTS pChangeKeyboardMapping-3 test.
CASES TESTS PASS UNSUP UNTST NOTIU WARN FIP FAIL UNRES UNIN ABORT
-Xproto 122 389 367 2 19 0 0 0 1 0 0 0
+Xproto 122 389 368 2 19 0 0 0 0 0 0 0
Signed-off-by: Aaron Plattner <aplattner@nvidia.com>
Reviewed-by: Adam Jackson <ajax@redhat.com>
Signed-off-by: Keith Packard <keithp@keithp.com>
|