| Commit message (Collapse) | Author | Age | Files | Lines |
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
|
|
|
|
|
|
|
|
| |
With the removal of the Ipaq code there's no path anymore to open the
onscreen keyboard. Also nxkbd is not available and we do not have
tested that feature with any onscreen keyboard yet. So there's no
point in integrating that code.
Fixes ArcticaProject/nx-libs#405
|
|
|
|
| |
Did we ever provide a binary?
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This is a bit weird, I'd expect far more places where the compiler
could complain about Window vs Window64... But it does not.
Screen.c:306:32: warning: passing argument 3 of ‘XQueryTree’ from incompatible pointer type [-Wincompatible-pointer-types]
if (XQueryTree(d, candidate, &root, &parent, &children, &num_children))
^~~~~
In file included from Screen.c:60:
Agent.h:85:25: note: expected ‘Window64 *’ {aka ‘long unsigned int *’} but argument is of type ‘Window *’ {aka ‘unsigned int *’}
#define Window Window64
../../../../exports/include/nx-X11/Xlib.h:3041:5: note: in expansion of macro ‘Window’
Window* /* root_return */,
|
| |
|
| |
|
|
|
|
|
|
|
|
| |
This fixes problems with kwin and compiz when using the
switch-all-screens keystroke. The fullscreen would appear shortly and
then vanish again.
Fixes ArcticaProject/nx-libs#458
|
| |
|
| |
|
| |
|
|
|
|
|
|
|
| |
We can only free the xkbDevicePrivate because we do not know the
details of any other (possible) extension. So let's limit to that one
private for now and call the new xkbFreePrivates from dix (where such
a function is completely missing).
|
| |
|
|
|
|
| |
[Keyboard.c:559]: (error) Shifting signed 32-bit value by 31 bits is undefined behaviour
|
| |
|
| |
|
|
|
|
|
|
|
|
| |
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.
|
| |
|
|
|
|
| |
Otherwise it will (falsely) report "Memory pointed to by 'sessionpath' is freed twice."
|
| |
|
| |
|
|
|
|
| |
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)
|