| Commit message (Collapse) | Author | Age | Files | Lines |
| |
|
| |
|
|
|
|
| |
While at it create and use the freeDepths() helper function.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
commit 211d4c2d353b5e379716484055a3f58235ea65f4
Author: Chris Wilson <chris@chris-wilson.co.uk>
Date: Wed Dec 14 15:55:22 2011 +0000
render: Propagate allocation failure from createSourcePicture()
All the callers were already checking for failure, except that
createSourcePicture() itself was failing to check whether it
successfully allocated the Picture.
[ajax: Rebase, fix line wrap of preceding line]
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Reviewed-by: Jeremy Huddleston <jeremyhu@apple.com>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
==12976==ERROR: LeakSanitizer: detected memory leaks
Direct leak of 6 byte(s) in 1 object(s) allocated from:
#0 0x7f510b3ac810 in strdup (/usr/lib/x86_64-linux-gnu/libasan.so.5+0x3a810)
#1 0x559ca29c5035 in nxagentKeyboardProc /home/uli/work/nx/ArcticaProject/nx-libs/nx-X11/programs/Xserver/hw/nxagent/Keyboard.c:866
#2 0x7a29bff07 (<unknown module>)
Direct leak of 1 byte(s) in 1 object(s) allocated from:
#0 0x7f510b3ac810 in strdup (/usr/lib/x86_64-linux-gnu/libasan.so.5+0x3a810)
#1 0x559ca29c509a in nxagentKeyboardProc /home/uli/work/nx/ArcticaProject/nx-libs/nx-X11/programs/Xserver/hw/nxagent/Keyboard.c:870
#2 0x7a29bff07 (<unknown module>)
Direct leak of 1 byte(s) in 1 object(s) allocated from:
#0 0x7f510b3ac810 in strdup (/usr/lib/x86_64-linux-gnu/libasan.so.5+0x3a810)
#1 0x559ca29c507f in nxagentKeyboardProc /home/uli/work/nx/ArcticaProject/nx-libs/nx-X11/programs/Xserver/hw/nxagent/Keyboard.c:869
#2 0x7a29bff07 (<unknown module>)
SUMMARY: AddressSanitizer: 8 byte(s) leaked in 3 allocation(s).
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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.
|
| |
|
| |
|
| |
|
| |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
==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)
|
|
|
|
|
|
|
| |
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)
|
|
|
|
| |
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
|
|
|
|
|
|
| |
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.
|
| |
|
| |
|
| |
|
| |
|
|
|
|
| |
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?
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
|
|
|
|
|
|
|
|
| |
CheckMotion() had been commented in
add881931f2e702fb1952f4e1baba04b3dc536ee as it looked identical to the
version from dix/events.c except for some commented code. But this
based (probably) on a thinko - code that had been disabled by NX
became active again this way. Fix this by removing the comments and
by adding #ifdef/else to emphasize the difference.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
As done in these commits:
commit 6583477035234e23ead2fad9db7a07e5862447a4
Author: Nicolai Hähnle <nhaehnle@gmail.com>
Date: Sat May 23 13:35:24 2009 +0200
Remove reference to non-existing requestLog and requestLogIndex
These fields were removed in 252ec504817e05b185e4896a2d899e9c00b8aeef.
Signed-off-by: Nicolai Haehnle <nhaehnle@gmail.com>
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
commit 252ec504817e05b185e4896a2d899e9c00b8aeef
Author: Adam Jackson <ajax@redhat.com>
Date: Mon Mar 30 15:18:30 2009 -0400
Document which bits of ClientRec are currently unused
|
| |
|
|
|
|
| |
nxagent does not react on that anyway (see xkb/xkbDflts.h)
|
| |
|