Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

meson: unbreak if glamor isn't explicitly enabled #8

Merged
merged 1 commit into from
Dec 1, 2020
Merged

meson: unbreak if glamor isn't explicitly enabled #8

merged 1 commit into from
Dec 1, 2020

Conversation

jbeich
Copy link
Contributor

@jbeich jbeich commented Dec 1, 2020

Regressed in 0.6.0. See error log.

hw/kdrive/arcan/meson.build:16:0: ERROR: Unknown variable "glamor".
@letoram letoram merged commit d4fe0ae into letoram:master Dec 1, 2020
letoram pushed a commit that referenced this pull request Apr 15, 2021
A change during the 1.20 development cycle resulted in fbconfigs being walked
and deallocated individually during __glXScreenDestroy.  This change
now avoids a use-after-free caused by that change.

==50859==ERROR: AddressSanitizer: heap-use-after-free on address 0x00010d3819c8 at pc 0x0001009d4230 bp 0x00016feca7a0 sp 0x00016feca798
READ of size 8 at 0x00010d3819c8 thread T5
    #0 0x1009d422c in __glXScreenDestroy glxscreens.c:448
    #1 0x10091cc98 in __glXAquaScreenDestroy indirect.c:510
    #2 0x1009d2734 in glxCloseScreen glxscreens.c:169
    #3 0x100740a24 in dix_main main.c:325
    #4 0x10023ed50 in server_thread quartzStartup.c:65
    #5 0x199ae7fd0 in _pthread_start+0x13c (libsystem_pthread.dylib:arm64e+0x6fd0)
    #6 0x199ae2d38 in thread_start+0x4 (libsystem_pthread.dylib:arm64e+0x1d38)

0x00010d3819c8 is located 200 bytes inside of 12800-byte region [0x00010d381900,0x00010d384b00)
freed by thread T5 here:
    #0 0x101477ba8 in wrap_free+0x98 (libclang_rt.asan_osx_dynamic.dylib:arm64e+0x3fba8)
    #1 0x1009d4240 in __glXScreenDestroy glxscreens.c:449
    #2 0x10091cc98 in __glXAquaScreenDestroy indirect.c:510
    #3 0x1009d2734 in glxCloseScreen glxscreens.c:169
    #4 0x100740a24 in dix_main main.c:325
    #5 0x10023ed50 in server_thread quartzStartup.c:65
    #6 0x199ae7fd0 in _pthread_start+0x13c (libsystem_pthread.dylib:arm64e+0x6fd0)
    #7 0x199ae2d38 in thread_start+0x4 (libsystem_pthread.dylib:arm64e+0x1d38)

previously allocated by thread T5 here:
    #0 0x101477e38 in wrap_calloc+0x9c (libclang_rt.asan_osx_dynamic.dylib:arm64e+0x3fe38)
    #1 0x100925a40 in __glXAquaCreateVisualConfigs visualConfigs.c:116
    #2 0x10091cb24 in __glXAquaScreenProbe+0x224 (X11.bin:arm64+0x100730b24)
    #3 0x1009cd840 in xorgGlxServerInit glxext.c:528
    #4 0x10074539c in _CallCallbacks dixutils.c:743
    #5 0x100932a70 in CallCallbacks callback.h:83
    #6 0x100932478 in GlxExtensionInit vndext.c:244
    #7 0x10020a364 in InitExtensions miinitext.c:267
    #8 0x10073fe7c in dix_main main.c:197
    #9 0x10023ed50 in server_thread quartzStartup.c:65
    #10 0x199ae7fd0 in _pthread_start+0x13c (libsystem_pthread.dylib:arm64e+0x6fd0)
    #11 0x199ae2d38 in thread_start+0x4 (libsystem_pthread.dylib:arm64e+0x1d38)

Regressed-in: 4b0a3cb
CC: Giuseppe Bilotta <giuseppe.bilotta@gmail.com>
Signed-off-by: Jeremy Huddleston Sequoia <jeremyhu@apple.com>
letoram pushed a commit that referenced this pull request Apr 17, 2022
This fixes access to freed heap memory via dev->master. E.g. when
running BarrierNotify.ReceivesNotifyEvents/7 test from
xorg-integration-tests:

==24736==ERROR: AddressSanitizer: heap-use-after-free on address
0x619000065020 at pc 0x55c450e2b9cf bp 0x7fffc532fd20 sp 0x7fffc532fd10
READ of size 4 at 0x619000065020 thread T0
    #0 0x55c450e2b9ce in GetMaster ../../../dix/devices.c:2722
    #1 0x55c450e9d035 in IsFloating ../../../dix/events.c:346
    #2 0x55c4513209c6 in GetDeviceUse ../../../Xi/xiquerydevice.c:525
../../../Xi/xichangehierarchy.c:95
    #4 0x55c450e3455c in RemoveDevice ../../../dix/devices.c:1204
../../../hw/xfree86/common/xf86Xinput.c:1142
    #6 0x55c450e17b04 in CloseDeviceList ../../../dix/devices.c:1038
    #7 0x55c450e1de85 in CloseDownDevices ../../../dix/devices.c:1068
    #8 0x55c450e837ef in dix_main ../../../dix/main.c:302
    #9 0x55c4517a8d93 in main ../../../dix/stubmain.c:34
(/lib/x86_64-linux-gnu/libc.so.6+0x28564)
    #11 0x55c450d0113d in _start (/usr/lib/xorg/Xorg+0x117713d)

0x619000065020 is located 160 bytes inside of 912-byte region
[0x619000064f80,0x619000065310)
freed by thread T0 here:
(/usr/lib/x86_64-linux-gnu/libasan.so.5+0x10d7cf)
    #1 0x55c450e19f1c in CloseDevice ../../../dix/devices.c:1014
    #2 0x55c450e343a4 in RemoveDevice ../../../dix/devices.c:1186
../../../hw/xfree86/common/xf86Xinput.c:1142
    #4 0x55c450e17b04 in CloseDeviceList ../../../dix/devices.c:1038
    #5 0x55c450e1de85 in CloseDownDevices ../../../dix/devices.c:1068
    #6 0x55c450e837ef in dix_main ../../../dix/main.c:302
    #7 0x55c4517a8d93 in main ../../../dix/stubmain.c:34
(/lib/x86_64-linux-gnu/libc.so.6+0x28564)

previously allocated by thread T0 here:
(/usr/lib/x86_64-linux-gnu/libasan.so.5+0x10ddc6)
    #1 0x55c450e1c57b in AddInputDevice ../../../dix/devices.c:259
    #2 0x55c450e34840 in AllocDevicePair ../../../dix/devices.c:2755
    #3 0x55c45130318f in add_master ../../../Xi/xichangehierarchy.c:152
../../../Xi/xichangehierarchy.c:465
    #5 0x55c4512cb9f5 in ProcIDispatch ../../../Xi/extinit.c:390
    #6 0x55c450e6a92b in Dispatch ../../../dix/dispatch.c:551
    #7 0x55c450e834b7 in dix_main ../../../dix/main.c:272
    #8 0x55c4517a8d93 in main ../../../dix/stubmain.c:34
(/lib/x86_64-linux-gnu/libc.so.6+0x28564)

The problem is caused by dev->master being not reset when disabling the
device, which then causes dangling pointer when the master device itself
is being deleted when exiting whole server.

Note that RecalculateMasterButtons() requires dev->master to be still
valid, so we can reset it only at the end of function.

Signed-off-by: Povilas Kanapickas <povilas@radix.lt>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants