aboutsummaryrefslogtreecommitdiff
path: root/nx-X11/programs/Xserver
Commit message (Collapse)AuthorAgeFilesLines
* fb: fix memory leak in fbOverlayFinishScreenInitUlrich Sibiller2019-06-221-2/+6
| | | | | | | | | | | | commit 2aa935bc5cc1e2d5365a97b8c5bb3d33eb5fc758 Author: Tiago Vignatti <tiago.vignatti@nokia.com> Date: Fri Mar 25 22:10:55 2011 +0200 fb: fix memory leak in fbOverlayFinishScreenInit Signed-off-by: Tiago Vignatti <tiago.vignatti@nokia.com> Reviewed-by: Nicolas Peninguy <nico@lostgeeks.org> Reviewed-by: Peter Hutterer <peter.hutterer@who-t.net>
* dix/dispatch: fix a small memory leakUlrich Sibiller2019-06-221-0/+3
|
* Keyboard.c: fix three memory leaksUlrich Sibiller2019-06-221-0/+4
| | | | | | | | | | | | | | | | | | | | | ==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).
* glyph.c: fix a read beyond end of heap bufferUlrich Sibiller2019-06-222-0/+63
| | | | | | | | | | | | | | | | | | | | | | | | | | | 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.
* Font.c: code simplificationsUlrich Sibiller2019-06-191-20/+9
|
* various scope improvementsUlrich Sibiller2019-06-198-107/+50
|
* glxext.c: fix another memory leakUlrich Sibiller2019-06-191-3/+1
| | | | | | | | | | | | | | | | ==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.
* Screen.c: more debug outputUlrich Sibiller2019-06-191-1/+4
|
* Extension.c: code simplificationsUlrich Sibiller2019-06-191-8/+3
|
* Events.c: use designated initializer in nxagentDeactivatePointerGrabUlrich Sibiller2019-06-191-15/+17
|
* mi/miinitext.c: fix memleaks: remove (double) glx initializationUlrich Sibiller2019-06-191-4/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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?).
* Screen.c: fix another memory leakUlrich Sibiller2019-06-191-4/+12
| | | | | | | | | | | | | | | | | | | | | | | | | | | | ==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)
* Fix memleaks: Free devPrivates of devices on shutdownUlrich Sibiller2019-06-192-3/+17
| | | | | | | | | | | | | | | | | | | | | | 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)
* CloseDevice: call XkbRemoveResourceClient before freeing key class structUlrich Sibiller2019-06-191-5/+8
| | | | | | | | | | | | | | | | | | | | | | | | 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>
* Keyboard.c: nullify freed pointersUlrich Sibiller2019-06-191-7/+11
| | | | | | | 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.
* Screen.c: Fix: make sure RRCloseScreen is being calledUlrich Sibiller2019-06-191-7/+7
| | | | | | | | | | | | | | | | | | | | | | | | | | | 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)
* Screen.c: correctly free stuff in nxagentCloseScreenUlrich Sibiller2019-06-191-3/+15
| | | | | | | | | | | | | | 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)
* xkb: initialize tsymsUlrich Sibiller2019-06-191-1/+1
| | | | | | | | | | | | | | | | 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>
* Rootless.c: improve TEST/WARN/DEBUG outoutUlrich Sibiller2019-06-191-36/+36
| | | | by adding [] around values as almost everywhere
* Pixmap.c: fix comment phrasing/spellingUlrich Sibiller2019-06-191-2/+2
|
* Window.c: add missing comment about nxagentConfiguredWindowListUlrich Sibiller2019-06-191-0/+6
| | | | | was in inital version of 6ce9fb5f2875754f97035d3338b3d0e1d20169ae but got lost during some rebasing/cherry-picking preceeding the pull request.
* dix/window.c: fix compiler warningUlrich Sibiller2019-06-191-10/+8
| | | | | 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]);
* NXshm.c: remove left-overs from patchUlrich Sibiller2019-06-121-3/+3
| | | | format was broken, would not compile
* miwindow.c: add hint to Red Hat Bugzilla + fixUlrich Sibiller2019-06-121-0/+1
|
* mi: Hush an almost certainly bogus warningUlrich Sibiller2019-06-121-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | 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>
* Window.c: Drop defines CWParent and CWStackingOrderUlrich Sibiller2019-06-122-17/+14
| | | | | | 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...
* Window.c: remove leftover (commented) codeUlrich Sibiller2019-06-121-14/+0
| | | | | | | | | | | 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: fix compiler warningUlrich Sibiller2019-06-121-1/+1
| | | | | | | | | | | | 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); ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
* Remove the Must_have_memory hack.Ulrich Sibiller2019-06-127-37/+15
| | | | | | | | | | | | | 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.
* NXdispatch.c: use upstream version of ProcSetSelectionOwnerUlrich Sibiller2019-06-112-99/+0
|
* NXdispatch.c: Use Callback instead of a modified functionUlrich Sibiller2019-06-112-9/+9
|
* Add nxagentSetSelectionCallbackUlrich Sibiller2019-06-111-0/+69
|
* Add nxagentExternalClipboardEventTrapUlrich Sibiller2019-06-113-0/+28
|
* NXmiexpose.c: drop file altogetherUlrich Sibiller2019-06-115-210/+2
| | | | The only left function is identical to the one in mi/miexpose.c.
* Window.c/NXmiexpose.c: remove hack for certain WM themeUlrich Sibiller2019-06-112-33/+1
| | | | | We do not even know what theme this is and it is probably not relevant nowadays.
* NXmiexpose.c: mark NX changesUlrich Sibiller2019-06-111-4/+5
|
* NXmiexpose.c: use upstream version of miPaintWindows()Ulrich Sibiller2019-06-112-273/+2
| | | | | | | | | 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().
* NXmiexpose.c: use upstream miHandleExposures()Ulrich Sibiller2019-06-112-276/+0
| | | | | It is (functionally) identical to our code, so why have duplicate code?
* Window.c: comment on the purpose of some functionsUlrich Sibiller2019-06-111-8/+166
|
* Events.c: add debug outputUlrich Sibiller2019-06-111-0/+7
|
* Clipboard.c: more debugging outputUlrich Sibiller2019-06-111-1/+17
|
* Clipboard.c: Scope improvementsUlrich Sibiller2019-06-111-5/+2
|
* Clipboard.c: fix wrong variable being printedUlrich Sibiller2019-06-111-1/+1
|
* Screen.c: more TEST outputUlrich Sibiller2019-06-111-5/+10
|
* Screen.c: use consistent spacing on pointer referencesUlrich Sibiller2019-06-111-4/+4
|
* Screen.c: whitespace/formatting fixesUlrich Sibiller2019-06-111-21/+22
|
* Screen.c: report both created windows (and with the right name)Ulrich Sibiller2019-06-111-4/+9
|
* Window.c: fix: report correct window on icon window creationUlrich Sibiller2019-06-111-2/+2
|
* os: fix BigReq ignoring when another request is pendingUlrich Sibiller2019-06-111-2/+0
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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>
* render/glyph.c: add missing usage_hintUlrich Sibiller2019-06-111-1/+2
| | | | was missing in 8b5bb2cdafe5f7bd77826a1fd28f07b7329be899
generated by cgit v1.2.3 (git 2.25.1) at 2024-11-16 16:31:22 +0000