Tag:
Branch:
Tree:
b0ed4a2e3b
dev
${ noResults }
7719 Commits (b0ed4a2e3b16e14df395f854b905a37aea5d9924)
Author | SHA1 | Message | Date |
---|---|---|---|
Pekka Paalanen | 2dcc79f58e |
tests: add destroy listener in ivi-layout test plugin
Fixes ASan reported leak: Direct leak of 136 byte(s) in 1 object(s) allocated from: #0 0x7ff60173c518 in calloc (/lib/x86_64-linux-gnu/libasan.so.5+0xe9518) #1 0x7ff5fcfed3fa in zalloc ../../git/weston/include/libweston/zalloc.h:38 #2 0x7ff5fcfed8bf in wet_module_init ../../git/weston/tests/ivi-layout-test-plugin.c:196 #3 0x7ff60161bd81 in wet_load_module ../../git/weston/compositor/main.c:941 #4 0x7ff60161c165 in load_modules ../../git/weston/compositor/main.c:1012 #5 0x7ff60162ced9 in wet_main ../../git/weston/compositor/main.c:3441 #6 0x559a98fd7d4c in execute_compositor ../../git/weston/tests/weston-test-fixture-compositor.c:432 #7 0x559a98fdb780 in weston_test_harness_execute_as_client ../../git/weston/tests/weston-test-runner.c:528 #8 0x559a98fcbc48 in fixture_setup ../../git/weston/tests/ivi-layout-test-client.c:48 #9 0x559a98fcbcca in fixture_setup_run_ ../../git/weston/tests/ivi-layout-test-client.c:50 #10 0x559a98fdbd35 in main ../../git/weston/tests/weston-test-runner.c:661 #11 0x7ff60129109a in __libc_start_main ../csu/libc-start.c:308 #12 0x559a98fcb769 in _start (/home/pq/build/weston-meson/tests/test-ivi-layout-client+0xd769) This also plugs the leak on wl_global_create() error path, though it cannot really be tested. Signed-off-by: Pekka Paalanen <pekka.paalanen@collabora.com> |
4 years ago |
Pekka Paalanen | fda3696ecf |
tests: fix leaks in ivi-layout-test-client
Everything here was systematically leaking client and iviapp. Discovered by ASan on ./tests/test-ivi-layout-client Signed-off-by: Pekka Paalanen <pekka.paalanen@collabora.com> |
4 years ago |
Pekka Paalanen | ca59c8e868 |
tests: fix leaks in internal-screenshot-test
Fixes all the ASan reported leaks in this test. Signed-off-by: Pekka Paalanen <pekka.paalanen@collabora.com> |
4 years ago |
Pekka Paalanen | d3acfd3b6b |
tests: fix leak in events
Fixes all the ASan reported leaks in this test. Signed-off-by: Pekka Paalanen <pekka.paalanen@collabora.com> |
4 years ago |
Leandro Ribeiro | 7c547e492c |
tests: fix leaks in drm-formats-test
Leak found running drm-formats-test with ASan: ==59454==ERROR: LeakSanitizer: detected memory leaks Direct leak of 24 byte(s) in 1 object(s) allocated from: #0 0x7f5302ff2459 in __interceptor_calloc /build/gcc/src/gcc/libsanitizer/asan/asan_malloc_linux.cpp:154 #1 0x7f5302e75e3a in zalloc ../include/libweston/zalloc.h:38 #2 0x7f5302e75e4e in weston_drm_format_array_create ../libweston/drm-formats.c:44 #3 0x7f5302e76e33 in weston_drm_format_array_intersect ../libweston/drm-formats.c:340 #4 0x559dc2d3c69f in intersect_arrays_same_content ../tests/drm-formats-test.c:391 #5 0x559dc2d3c317 in wrapintersect_arrays_same_content ../tests/drm-formats-test.c:376 #6 0x559dc2d409ec in run_test ../tests/weston-test-runner.c:162 #7 0x559dc2d410f2 in run_case ../tests/weston-test-runner.c:277 #8 0x559dc2d40e8b in for_each_test_case ../tests/weston-test-runner.c:235 #9 0x559dc2d4139b in testsuite_run ../tests/weston-test-runner.c:311 #10 0x559dc2d423c4 in weston_test_harness_execute_standalone ../tests/weston-test-runner.c:572 #11 0x559dc2d423f4 in fixture_setup_run_ ../tests/weston-test-runner.c:610 #12 0x559dc2d42887 in main ../tests/weston-test-runner.c:661 #13 0x7f5302c5eb24 in __libc_start_main (/usr/lib/libc.so.6+0x27b24) #14 0x559dc2d3642d in _start (/home/lele/weston/build/tests/test-drm-formats+0x642d) Direct leak of 24 byte(s) in 1 object(s) allocated from: #0 0x7f5302ff2459 in __interceptor_calloc /build/gcc/src/gcc/libsanitizer/asan/asan_malloc_linux.cpp:154 #1 0x7f5302e75e3a in zalloc ../include/libweston/zalloc.h:38 #2 0x7f5302e75e4e in weston_drm_format_array_create ../libweston/drm-formats.c:44 #3 0x559dc2d3bc7b in intersect_arrays ../tests/drm-formats-test.c:352 #4 0x559dc2d3b678 in wrapintersect_arrays ../tests/drm-formats-test.c:339 #5 0x559dc2d409ec in run_test ../tests/weston-test-runner.c:162 #6 0x559dc2d410f2 in run_case ../tests/weston-test-runner.c:277 #7 0x559dc2d40e8b in for_each_test_case ../tests/weston-test-runner.c:235 #8 0x559dc2d4139b in testsuite_run ../tests/weston-test-runner.c:311 #9 0x559dc2d423c4 in weston_test_harness_execute_standalone ../tests/weston-test-runner.c:572 #10 0x559dc2d423f4 in fixture_setup_run_ ../tests/weston-test-runner.c:610 #11 0x559dc2d42887 in main ../tests/weston-test-runner.c:661 #12 0x7f5302c5eb24 in __libc_start_main (/usr/lib/libc.so.6+0x27b24) #13 0x559dc2d3642d in _start (/home/lele/weston/build/tests/test-drm-formats+0x642d) Signed-off-by: Leandro Ribeiro <leandro.ribeiro@collabora.com> |
4 years ago |
Leandro Ribeiro | 0157591b34 |
libweston: do not forget to destroy temporary drm_format_array
Leak found running drm-formats-test with ASan: ==58755==ERROR: LeakSanitizer: detected memory leaks Direct leak of 24 byte(s) in 1 object(s) allocated from: #0 0x7fae74658459 in __interceptor_calloc /build/gcc/src/gcc/libsanitizer/asan/asan_malloc_linux.cpp:154 #1 0x7fae744dbe3a in zalloc ../include/libweston/zalloc.h:38 #2 0x7fae744dbe4e in weston_drm_format_array_create ../libweston/drm-formats.c:44 #3 0x7fae744dd2a2 in weston_drm_format_array_subtract ../libweston/drm-formats.c:410 #4 0x55723c67bed5 in subtract_arrays ../tests/drm-formats-test.c:487 #5 0x55723c67b6bb in wrapsubtract_arrays ../tests/drm-formats-test.c:467 #6 0x55723c67e9a9 in run_test ../tests/weston-test-runner.c:162 #7 0x55723c67f0af in run_case ../tests/weston-test-runner.c:277 #8 0x55723c67ee48 in for_each_test_case ../tests/weston-test-runner.c:235 #9 0x55723c67f358 in testsuite_run ../tests/weston-test-runner.c:311 #10 0x55723c680381 in weston_test_harness_execute_standalone ../tests/weston-test-runner.c:572 #11 0x55723c6803b1 in fixture_setup_run_ ../tests/weston-test-runner.c:610 #12 0x55723c680844 in main ../tests/weston-test-runner.c:661 #13 0x7fae742c4b24 in __libc_start_main (/usr/lib/libc.so.6+0x27b24) #14 0x55723c67442d in _start (/home/lele/weston/build/tests/test-drm-formats+0x642d) Direct leak of 24 byte(s) in 1 object(s) allocated from: #0 0x7fae74658459 in __interceptor_calloc /build/gcc/src/gcc/libsanitizer/asan/asan_malloc_linux.cpp:154 #1 0x7fae744dbe3a in zalloc ../include/libweston/zalloc.h:38 #2 0x7fae744dbe4e in weston_drm_format_array_create ../libweston/drm-formats.c:44 #3 0x7fae744dd2a2 in weston_drm_format_array_subtract ../libweston/drm-formats.c:410 #4 0x55723c67deca in subtract_arrays_modifier_invalid ../tests/drm-formats-test.c:613 #5 0x55723c67da3d in wrapsubtract_arrays_modifier_invalid ../tests/drm-formats-test.c:593 #6 0x55723c67e9a9 in run_test ../tests/weston-test-runner.c:162 #7 0x55723c67f0af in run_case ../tests/weston-test-runner.c:277 #8 0x55723c67ee48 in for_each_test_case ../tests/weston-test-runner.c:235 #9 0x55723c67f358 in testsuite_run ../tests/weston-test-runner.c:311 #10 0x55723c680381 in weston_test_harness_execute_standalone ../tests/weston-test-runner.c:572 #11 0x55723c6803b1 in fixture_setup_run_ ../tests/weston-test-runner.c:610 #12 0x55723c680844 in main ../tests/weston-test-runner.c:661 #13 0x7fae742c4b24 in __libc_start_main (/usr/lib/libc.so.6+0x27b24) #14 0x55723c67442d in _start (/home/lele/weston/build/tests/test-drm-formats+0x642d) Direct leak of 24 byte(s) in 1 object(s) allocated from: #0 0x7fae74658459 in __interceptor_calloc /build/gcc/src/gcc/libsanitizer/asan/asan_malloc_linux.cpp:154 #1 0x7fae744dbe3a in zalloc ../include/libweston/zalloc.h:38 #2 0x7fae744dbe4e in weston_drm_format_array_create ../libweston/drm-formats.c:44 #3 0x7fae744dd2a2 in weston_drm_format_array_subtract ../libweston/drm-formats.c:410 #4 0x55723c67c9c0 in subtract_arrays_same_content ../tests/drm-formats-test.c:521 #5 0x55723c67c55b in wrapsubtract_arrays_same_content ../tests/drm-formats-test.c:504 #6 0x55723c67e9a9 in run_test ../tests/weston-test-runner.c:162 #7 0x55723c67f0af in run_case ../tests/weston-test-runner.c:277 #8 0x55723c67ee48 in for_each_test_case ../tests/weston-test-runner.c:235 #9 0x55723c67f358 in testsuite_run ../tests/weston-test-runner.c:311 #10 0x55723c680381 in weston_test_harness_execute_standalone ../tests/weston-test-runner.c:572 #11 0x55723c6803b1 in fixture_setup_run_ ../tests/weston-test-runner.c:610 #12 0x55723c680844 in main ../tests/weston-test-runner.c:661 #13 0x7fae742c4b24 in __libc_start_main (/usr/lib/libc.so.6+0x27b24) #14 0x55723c67442d in _start (/home/lele/weston/build/tests/test-drm-formats+0x642d) Direct leak of 24 byte(s) in 1 object(s) allocated from: #0 0x7fae74658459 in __interceptor_calloc /build/gcc/src/gcc/libsanitizer/asan/asan_malloc_linux.cpp:154 #1 0x7fae744dbe3a in zalloc ../include/libweston/zalloc.h:38 #2 0x7fae744dbe4e in weston_drm_format_array_create ../libweston/drm-formats.c:44 #3 0x7fae744dd2a2 in weston_drm_format_array_subtract ../libweston/drm-formats.c:410 #4 0x55723c67d1b7 in subtract_arrays_exclusive_formats ../tests/drm-formats-test.c:552 #5 0x55723c67cb23 in wrapsubtract_arrays_exclusive_formats ../tests/drm-formats-test.c:529 #6 0x55723c67e9a9 in run_test ../tests/weston-test-runner.c:162 #7 0x55723c67f0af in run_case ../tests/weston-test-runner.c:277 #8 0x55723c67ee48 in for_each_test_case ../tests/weston-test-runner.c:235 #9 0x55723c67f358 in testsuite_run ../tests/weston-test-runner.c:311 #10 0x55723c680381 in weston_test_harness_execute_standalone ../tests/weston-test-runner.c:572 #11 0x55723c6803b1 in fixture_setup_run_ ../tests/weston-test-runner.c:610 #12 0x55723c680844 in main ../tests/weston-test-runner.c:661 #13 0x7fae742c4b24 in __libc_start_main (/usr/lib/libc.so.6+0x27b24) #14 0x55723c67442d in _start (/home/lele/weston/build/tests/test-drm-formats+0x642d) Direct leak of 24 byte(s) in 1 object(s) allocated from: #0 0x7fae74658459 in __interceptor_calloc /build/gcc/src/gcc/libsanitizer/asan/asan_malloc_linux.cpp:154 #1 0x7fae744dbe3a in zalloc ../include/libweston/zalloc.h:38 #2 0x7fae744dbe4e in weston_drm_format_array_create ../libweston/drm-formats.c:44 #3 0x7fae744dd2a2 in weston_drm_format_array_subtract ../libweston/drm-formats.c:410 #4 0x55723c67d8d5 in subtract_arrays_exclusive_modifiers ../tests/drm-formats-test.c:584 #5 0x55723c67d31d in wrapsubtract_arrays_exclusive_modifiers ../tests/drm-formats-test.c:561 #6 0x55723c67e9a9 in run_test ../tests/weston-test-runner.c:162 #7 0x55723c67f0af in run_case ../tests/weston-test-runner.c:277 #8 0x55723c67ee48 in for_each_test_case ../tests/weston-test-runner.c:235 #9 0x55723c67f358 in testsuite_run ../tests/weston-test-runner.c:311 #10 0x55723c680381 in weston_test_harness_execute_standalone ../tests/weston-test-runner.c:572 #11 0x55723c6803b1 in fixture_setup_run_ ../tests/weston-test-runner.c:610 #12 0x55723c680844 in main ../tests/weston-test-runner.c:661 #13 0x7fae742c4b24 in __libc_start_main (/usr/lib/libc.so.6+0x27b24) #14 0x55723c67442d in _start (/home/lele/weston/build/tests/test-drm-formats+0x642d) Indirect leak of 320 byte(s) in 5 object(s) allocated from: #0 0x7fae74658279 in __interceptor_malloc /build/gcc/src/gcc/libsanitizer/asan/asan_malloc_linux.cpp:145 #1 0x7fae74473bc3 in wl_array_add (/usr/lib/libwayland-client.so.0+0xabc3) #2 0x7fae74473c10 in wl_array_copy (/usr/lib/libwayland-client.so.0+0xac10) #3 0x7fae744dbfe0 in add_format_and_modifiers ../libweston/drm-formats.c:108 #4 0x7fae744dd389 in weston_drm_format_array_subtract ../libweston/drm-formats.c:418 #5 0x55723c67d1b7 in subtract_arrays_exclusive_formats ../tests/drm-formats-test.c:552 #6 0x55723c67cb23 in wrapsubtract_arrays_exclusive_formats ../tests/drm-formats-test.c:529 #7 0x55723c67e9a9 in run_test ../tests/weston-test-runner.c:162 #8 0x55723c67f0af in run_case ../tests/weston-test-runner.c:277 #9 0x55723c67ee48 in for_each_test_case ../tests/weston-test-runner.c:235 #10 0x55723c67f358 in testsuite_run ../tests/weston-test-runner.c:311 #11 0x55723c680381 in weston_test_harness_execute_standalone ../tests/weston-test-runner.c:572 #12 0x55723c6803b1 in fixture_setup_run_ ../tests/weston-test-runner.c:610 #13 0x55723c680844 in main ../tests/weston-test-runner.c:661 #14 0x7fae742c4b24 in __libc_start_main (/usr/lib/libc.so.6+0x27b24) #15 0x55723c67442d in _start (/home/lele/weston/build/tests/test-drm-formats+0x642d) Indirect leak of 256 byte(s) in 1 object(s) allocated from: #0 0x7fae74658652 in __interceptor_realloc /build/gcc/src/gcc/libsanitizer/asan/asan_malloc_linux.cpp:164 #1 0x7fae74473b76 in wl_array_add (/usr/lib/libwayland-client.so.0+0xab76) #2 0x7fae744dc19f in weston_drm_format_array_add_format ../libweston/drm-formats.c:166 #3 0x7fae744dbfb7 in add_format_and_modifiers ../libweston/drm-formats.c:104 #4 0x7fae744dd389 in weston_drm_format_array_subtract ../libweston/drm-formats.c:418 #5 0x55723c67d1b7 in subtract_arrays_exclusive_formats ../tests/drm-formats-test.c:552 #6 0x55723c67cb23 in wrapsubtract_arrays_exclusive_formats ../tests/drm-formats-test.c:529 #7 0x55723c67e9a9 in run_test ../tests/weston-test-runner.c:162 #8 0x55723c67f0af in run_case ../tests/weston-test-runner.c:277 #9 0x55723c67ee48 in for_each_test_case ../tests/weston-test-runner.c:235 #10 0x55723c67f358 in testsuite_run ../tests/weston-test-runner.c:311 #11 0x55723c680381 in weston_test_harness_execute_standalone ../tests/weston-test-runner.c:572 #12 0x55723c6803b1 in fixture_setup_run_ ../tests/weston-test-runner.c:610 #13 0x55723c680844 in main ../tests/weston-test-runner.c:661 #14 0x7fae742c4b24 in __libc_start_main (/usr/lib/libc.so.6+0x27b24) #15 0x55723c67442d in _start (/home/lele/weston/build/tests/test-drm-formats+0x642d) Indirect leak of 256 byte(s) in 1 object(s) allocated from: #0 0x7fae74658652 in __interceptor_realloc /build/gcc/src/gcc/libsanitizer/asan/asan_malloc_linux.cpp:164 #1 0x7fae74473b76 in wl_array_add (/usr/lib/libwayland-client.so.0+0xab76) #2 0x7fae744dc19f in weston_drm_format_array_add_format ../libweston/drm-formats.c:166 #3 0x7fae744dd3de in weston_drm_format_array_subtract ../libweston/drm-formats.c:426 #4 0x55723c67bed5 in subtract_arrays ../tests/drm-formats-test.c:487 #5 0x55723c67b6bb in wrapsubtract_arrays ../tests/drm-formats-test.c:467 #6 0x55723c67e9a9 in run_test ../tests/weston-test-runner.c:162 #7 0x55723c67f0af in run_case ../tests/weston-test-runner.c:277 #8 0x55723c67ee48 in for_each_test_case ../tests/weston-test-runner.c:235 #9 0x55723c67f358 in testsuite_run ../tests/weston-test-runner.c:311 #10 0x55723c680381 in weston_test_harness_execute_standalone ../tests/weston-test-runner.c:572 #11 0x55723c6803b1 in fixture_setup_run_ ../tests/weston-test-runner.c:610 #12 0x55723c680844 in main ../tests/weston-test-runner.c:661 #13 0x7fae742c4b24 in __libc_start_main (/usr/lib/libc.so.6+0x27b24) #14 0x55723c67442d in _start (/home/lele/weston/build/tests/test-drm-formats+0x642d) Indirect leak of 128 byte(s) in 2 object(s) allocated from: #0 0x7fae74658279 in __interceptor_malloc /build/gcc/src/gcc/libsanitizer/asan/asan_malloc_linux.cpp:145 #1 0x7fae74473bc3 in wl_array_add (/usr/lib/libwayland-client.so.0+0xabc3) #2 0x7fae74473c10 in wl_array_copy (/usr/lib/libwayland-client.so.0+0xac10) #3 0x7fae744dbfe0 in add_format_and_modifiers ../libweston/drm-formats.c:108 #4 0x7fae744dd389 in weston_drm_format_array_subtract ../libweston/drm-formats.c:418 #5 0x55723c67bed5 in subtract_arrays ../tests/drm-formats-test.c:487 #6 0x55723c67b6bb in wrapsubtract_arrays ../tests/drm-formats-test.c:467 #7 0x55723c67e9a9 in run_test ../tests/weston-test-runner.c:162 #8 0x55723c67f0af in run_case ../tests/weston-test-runner.c:277 #9 0x55723c67ee48 in for_each_test_case ../tests/weston-test-runner.c:235 #10 0x55723c67f358 in testsuite_run ../tests/weston-test-runner.c:311 #11 0x55723c680381 in weston_test_harness_execute_standalone ../tests/weston-test-runner.c:572 #12 0x55723c6803b1 in fixture_setup_run_ ../tests/weston-test-runner.c:610 #13 0x55723c680844 in main ../tests/weston-test-runner.c:661 #14 0x7fae742c4b24 in __libc_start_main (/usr/lib/libc.so.6+0x27b24) #15 0x55723c67442d in _start (/home/lele/weston/build/tests/test-drm-formats+0x642d) Indirect leak of 96 byte(s) in 3 object(s) allocated from: #0 0x7fae74658652 in __interceptor_realloc /build/gcc/src/gcc/libsanitizer/asan/asan_malloc_linux.cpp:164 #1 0x7fae74473b76 in wl_array_add (/usr/lib/libwayland-client.so.0+0xab76) #2 0x7fae744dd142 in modifiers_subtract ../libweston/drm-formats.c:384 #3 0x7fae744dd408 in weston_drm_format_array_subtract ../libweston/drm-formats.c:431 #4 0x55723c67bed5 in subtract_arrays ../tests/drm-formats-test.c:487 #5 0x55723c67b6bb in wrapsubtract_arrays ../tests/drm-formats-test.c:467 #6 0x55723c67e9a9 in run_test ../tests/weston-test-runner.c:162 #7 0x55723c67f0af in run_case ../tests/weston-test-runner.c:277 #8 0x55723c67ee48 in for_each_test_case ../tests/weston-test-runner.c:235 #9 0x55723c67f358 in testsuite_run ../tests/weston-test-runner.c:311 #10 0x55723c680381 in weston_test_harness_execute_standalone ../tests/weston-test-runner.c:572 #11 0x55723c6803b1 in fixture_setup_run_ ../tests/weston-test-runner.c:610 #12 0x55723c680844 in main ../tests/weston-test-runner.c:661 #13 0x7fae742c4b24 in __libc_start_main (/usr/lib/libc.so.6+0x27b24) #14 0x55723c67442d in _start (/home/lele/weston/build/tests/test-drm-formats+0x642d) Indirect leak of 64 byte(s) in 1 object(s) allocated from: #0 0x7fae74658652 in __interceptor_realloc /build/gcc/src/gcc/libsanitizer/asan/asan_malloc_linux.cpp:164 #1 0x7fae74473b76 in wl_array_add (/usr/lib/libwayland-client.so.0+0xab76) #2 0x7fae744dd142 in modifiers_subtract ../libweston/drm-formats.c:384 #3 0x7fae744dd408 in weston_drm_format_array_subtract ../libweston/drm-formats.c:431 #4 0x55723c67d8d5 in subtract_arrays_exclusive_modifiers ../tests/drm-formats-test.c:584 #5 0x55723c67d31d in wrapsubtract_arrays_exclusive_modifiers ../tests/drm-formats-test.c:561 #6 0x55723c67e9a9 in run_test ../tests/weston-test-runner.c:162 #7 0x55723c67f0af in run_case ../tests/weston-test-runner.c:277 #8 0x55723c67ee48 in for_each_test_case ../tests/weston-test-runner.c:235 #9 0x55723c67f358 in testsuite_run ../tests/weston-test-runner.c:311 #10 0x55723c680381 in weston_test_harness_execute_standalone ../tests/weston-test-runner.c:572 #11 0x55723c6803b1 in fixture_setup_run_ ../tests/weston-test-runner.c:610 #12 0x55723c680844 in main ../tests/weston-test-runner.c:661 #13 0x7fae742c4b24 in __libc_start_main (/usr/lib/libc.so.6+0x27b24) #14 0x55723c67442d in _start (/home/lele/weston/build/tests/test-drm-formats+0x642d) Indirect leak of 32 byte(s) in 1 object(s) allocated from: #0 0x7fae74658279 in __interceptor_malloc /build/gcc/src/gcc/libsanitizer/asan/asan_malloc_linux.cpp:145 #1 0x7fae74473bc3 in wl_array_add (/usr/lib/libwayland-client.so.0+0xabc3) #2 0x7fae744dc19f in weston_drm_format_array_add_format ../libweston/drm-formats.c:166 #3 0x7fae744dd3de in weston_drm_format_array_subtract ../libweston/drm-formats.c:426 #4 0x55723c67d8d5 in subtract_arrays_exclusive_modifiers ../tests/drm-formats-test.c:584 #5 0x55723c67d31d in wrapsubtract_arrays_exclusive_modifiers ../tests/drm-formats-test.c:561 #6 0x55723c67e9a9 in run_test ../tests/weston-test-runner.c:162 #7 0x55723c67f0af in run_case ../tests/weston-test-runner.c:277 #8 0x55723c67ee48 in for_each_test_case ../tests/weston-test-runner.c:235 #9 0x55723c67f358 in testsuite_run ../tests/weston-test-runner.c:311 #10 0x55723c680381 in weston_test_harness_execute_standalone ../tests/weston-test-runner.c:572 #11 0x55723c6803b1 in fixture_setup_run_ ../tests/weston-test-runner.c:610 #12 0x55723c680844 in main ../tests/weston-test-runner.c:661 #13 0x7fae742c4b24 in __libc_start_main (/usr/lib/libc.so.6+0x27b24) #14 0x55723c67442d in _start (/home/lele/weston/build/tests/test-drm-formats+0x642d) Indirect leak of 32 byte(s) in 1 object(s) allocated from: #0 0x7fae74658279 in __interceptor_malloc /build/gcc/src/gcc/libsanitizer/asan/asan_malloc_linux.cpp:145 #1 0x7fae74473bc3 in wl_array_add (/usr/lib/libwayland-client.so.0+0xabc3) #2 0x7fae744dc19f in weston_drm_format_array_add_format ../libweston/drm-formats.c:166 #3 0x7fae744dd3de in weston_drm_format_array_subtract ../libweston/drm-formats.c:426 #4 0x55723c67deca in subtract_arrays_modifier_invalid ../tests/drm-formats-test.c:613 #5 0x55723c67da3d in wrapsubtract_arrays_modifier_invalid ../tests/drm-formats-test.c:593 #6 0x55723c67e9a9 in run_test ../tests/weston-test-runner.c:162 #7 0x55723c67f0af in run_case ../tests/weston-test-runner.c:277 #8 0x55723c67ee48 in for_each_test_case ../tests/weston-test-runner.c:235 #9 0x55723c67f358 in testsuite_run ../tests/weston-test-runner.c:311 #10 0x55723c680381 in weston_test_harness_execute_standalone ../tests/weston-test-runner.c:572 #11 0x55723c6803b1 in fixture_setup_run_ ../tests/weston-test-runner.c:610 #12 0x55723c680844 in main ../tests/weston-test-runner.c:661 #13 0x7fae742c4b24 in __libc_start_main (/usr/lib/libc.so.6+0x27b24) #14 0x55723c67442d in _start (/home/lele/weston/build/tests/test-drm-formats+0x642d) Indirect leak of 32 byte(s) in 1 object(s) allocated from: #0 0x7fae74658279 in __interceptor_malloc /build/gcc/src/gcc/libsanitizer/asan/asan_malloc_linux.cpp:145 #1 0x7fae74473bc3 in wl_array_add (/usr/lib/libwayland-client.so.0+0xabc3) #2 0x7fae744dc19f in weston_drm_format_array_add_format ../libweston/drm-formats.c:166 #3 0x7fae744dd3de in weston_drm_format_array_subtract ../libweston/drm-formats.c:426 #4 0x55723c67c9c0 in subtract_arrays_same_content ../tests/drm-formats-test.c:521 #5 0x55723c67c55b in wrapsubtract_arrays_same_content ../tests/drm-formats-test.c:504 #6 0x55723c67e9a9 in run_test ../tests/weston-test-runner.c:162 #7 0x55723c67f0af in run_case ../tests/weston-test-runner.c:277 #8 0x55723c67ee48 in for_each_test_case ../tests/weston-test-runner.c:235 #9 0x55723c67f358 in testsuite_run ../tests/weston-test-runner.c:311 #10 0x55723c680381 in weston_test_harness_execute_standalone ../tests/weston-test-runner.c:572 #11 0x55723c6803b1 in fixture_setup_run_ ../tests/weston-test-runner.c:610 #12 0x55723c680844 in main ../tests/weston-test-runner.c:661 #13 0x7fae742c4b24 in __libc_start_main (/usr/lib/libc.so.6+0x27b24) #14 0x55723c67442d in _start (/home/lele/weston/build/tests/test-drm-formats+0x642d) Signed-off-by: Leandro Ribeiro <leandro.ribeiro@collabora.com> |
4 years ago |
Pekka Paalanen | 819054ceac |
tests: fix leaks in bad-buffer
Fixes all ASan reported leaks for this test. If frame_callback_wait_nofail() returns before the callback is handled, the callback is not destroyed automatically. This happens on a protocol error. This test intentionally triggers a protocol error. Signed-off-by: Pekka Paalanen <pekka.paalanen@collabora.com> |
4 years ago |
Pekka Paalanen | b0eb059818 |
tests: fix refname leaks
Reported by ASan. Direct leak of 1468 byte(s) in 48 object(s) allocated from: #0 0x7f20d7ae0330 in __interceptor_malloc (/lib/x86_64-linux-gnu/libasan.so.5+0xe9330) #1 0x7f20d76894b7 in _IO_vasprintf /build/glibc-vjB4T1/glibc-2.28/libio/vasprintf.c:73 #2 0x7f20d7a66827 in __interceptor_vasprintf (/lib/x86_64-linux-gnu/libasan.so.5+0x6f827) #3 0x7f20d7a66f76 in asprintf (/lib/x86_64-linux-gnu/libasan.so.5+0x6ff76) #4 0x5598e3fbcdfc in buffer_transform ../../git/weston/tests/buffer-transforms-test.c:122 #5 0x5598e3fc9add in run_test ../../git/weston/tests/weston-test-runner.c:162 #6 0x5598e3fca17e in run_case ../../git/weston/tests/weston-test-runner.c:277 #7 0x5598e3fc9f24 in for_each_test_case ../../git/weston/tests/weston-test-runner.c:235 #8 0x5598e3fca406 in testsuite_run ../../git/weston/tests/weston-test-runner.c:311 #9 0x7f20d3523b6b in client_thread_routine ../../git/weston/tests/weston-test.c:479 #10 0x7f20d75e8fa2 in start_thread /build/glibc-vjB4T1/glibc-2.28/nptl/pthread_create.c:486 #11 0x7f20d770a4ce in clone (/lib/x86_64-linux-gnu/libc.so.6+0xf94ce) Direct leak of 978 byte(s) in 42 object(s) allocated from: #0 0x7f26fed07330 in __interceptor_malloc (/lib/x86_64-linux-gnu/libasan.so.5+0xe9330) #1 0x7f26fe8b04b7 in _IO_vasprintf /build/glibc-vjB4T1/glibc-2.28/libio/vasprintf.c:73 #2 0x7f26fec8d827 in __interceptor_vasprintf (/lib/x86_64-linux-gnu/libasan.so.5+0x6f827) #3 0x7f26fec8df76 in asprintf (/lib/x86_64-linux-gnu/libasan.so.5+0x6ff76) #4 0x55989ba8c2bc in output_damage ../../git/weston/tests/output-damage-test.c:201 #5 0x55989ba8c0cb in wrapoutput_damage ../../git/weston/tests/output-damage-test.c:176 #6 0x55989ba99131 in run_test ../../git/weston/tests/weston-test-runner.c:162 #7 0x55989ba997d2 in run_case ../../git/weston/tests/weston-test-runner.c:277 #8 0x55989ba99578 in for_each_test_case ../../git/weston/tests/weston-test-runner.c:235 #9 0x55989ba99a5a in testsuite_run ../../git/weston/tests/weston-test-runner.c:311 #10 0x7f26fa57ab6b in client_thread_routine ../../git/weston/tests/weston-test.c:479 #11 0x7f26fe80ffa2 in start_thread /build/glibc-vjB4T1/glibc-2.28/nptl/pthread_create.c:486 #12 0x7f26fe9314ce in clone (/lib/x86_64-linux-gnu/libc.so.6+0xf94ce) Direct leak of 1696 byte(s) in 56 object(s) allocated from: #0 0x7f077107f330 in __interceptor_malloc (/lib/x86_64-linux-gnu/libasan.so.5+0xe9330) #1 0x7f0770c284b7 in _IO_vasprintf /build/glibc-vjB4T1/glibc-2.28/libio/vasprintf.c:73 #2 0x7f0771005827 in __interceptor_vasprintf (/lib/x86_64-linux-gnu/libasan.so.5+0x6f827) #3 0x7f0771005f76 in asprintf (/lib/x86_64-linux-gnu/libasan.so.5+0x6ff76) #4 0x563e6ae36dfc in output_transform ../../git/weston/tests/output-transforms-test.c:122 #5 0x563e6ae43add in run_test ../../git/weston/tests/weston-test-runner.c:162 #6 0x563e6ae4417e in run_case ../../git/weston/tests/weston-test-runner.c:277 #7 0x563e6ae43f24 in for_each_test_case ../../git/weston/tests/weston-test-runner.c:235 #8 0x563e6ae44406 in testsuite_run ../../git/weston/tests/weston-test-runner.c:311 #9 0x7f076ca26b6b in client_thread_routine ../../git/weston/tests/weston-test.c:479 #10 0x7f0770b87fa2 in start_thread /build/glibc-vjB4T1/glibc-2.28/nptl/pthread_create.c:486 #11 0x7f0770ca94ce in clone (/lib/x86_64-linux-gnu/libc.so.6+0xf94ce) Signed-off-by: Pekka Paalanen <pekka.paalanen@collabora.com> |
4 years ago |
Alexandros Frantzis | 10937feef8 |
backend-drm: Clear drm_output cursor_view when view is destroyed
The DRM backend uses changes in the cursor view memory address and surface damage to detect when it needs to re-upload to a cursor plane framebuffer. However, when a cursor view is destroyed and then recreated, e.g., when the pointer cursor surface is updated, the newly created view may have the same memory address as the just destroyed one. If no new cursor buffer is provided (because it was attached, committed and used previously) when this address reuse occurs, then there also isn't any updated surface damage and the backend doesn't update the cursor plane framebuffer at all. To fix this issue utilize the destroy signal to track when the cursor view is destroyed, and clear the cached cursor_view value in drm_output. After clearing the cached value, the next cursor view is always considered new and thus uploaded to the plane properly. Signed-off-by: Alexandros Frantzis <alexandros.frantzis@collabora.com> |
4 years ago |
Pekka Paalanen | f0c6104444 |
libweston: remove weston_output_set_renderer_shadow_buffer()
This is no longer used.
This was originally added in
|
4 years ago |
Pekka Paalanen | 478123b967 |
Revert "compositor: add weston.ini option use-renderer-shadow"
This reverts commit
|
4 years ago |
Pekka Paalanen | d2cfbff186 |
gl-renderer: use shadow framebuffer automatically
This creates the FP16 shadow framebuffer automatically if the color transformation from blending space to output space is not identity and the backend does not claim to implement it on the renderer's behalf. That makes the weston_output_set_renderer_shadow_buffer() API and use-renderer-shadow weston.ini option obsolete. To still cater for the one test that needs to enable the shadow framebuffer in spite of not needing it for color correct blending, the quirk it uses now also forces the shadow. Signed-off-by: Pekka Paalanen <pekka.paalanen@collabora.com> |
4 years ago |
Pekka Paalanen | 37fe6fde49 |
gl-renderer: define fragment shader compile_const
Compile time constants play an important role in keeping the shader programs fast. Introduce an informal annotation to mark compile time constants to make the shader code easier to reason with. This will make much more sense once functions with compile time constant parameters are added. Signed-off-by: Pekka Paalanen <pekka.paalanen@collabora.com> |
4 years ago |
Pekka Paalanen | 734c2278f9 |
gl-renderer: require GL ES 3.0 for color management
Trying to support GL ES 2.0 + extensions along with GL ES 3.0 for better control is becoming too complicated fast. In this patch you see the GL_RGBA vs. GL_RBA16F and GL_HALF_FLOAT vs. GL_HALF_FLOAT_OES paths. More such cases will come, e.g. GL_RED_EXT vs. GL_R32F. Make things simpler and require GL ES 3.0 + GL_EXT_color_buffer_half_float for all color management related functionality. If one doesn't have GL ES 3.0, all you lose is color management. Also, all extensions needed by color transformation operations are gathered under one boolean flag instead of having a flag per extension, again for simplicity. This makes the GL ES extension handling much easier. Signed-off-by: Pekka Paalanen <pekka.paalanen@collabora.com> |
4 years ago |
Pekka Paalanen | 401e190913 |
Revert "gl-renderer: Make dummy surface current after all outputs are gone"
This reverts commit
|
4 years ago |
Pekka Paalanen | 6d0aa8f0e9 |
gl-renderer: do not unbind the context on output destroy
If we make EGL_NO_CONTEXT current, all following GL calls are no-ops. This will be a problem when gl-renderer introduces gl_renderer_color_transform containing GL textures and needs to destroy them when weston_color_transform is destroyed. Mesa would print the the warning that glDeleteTextures is no-op. To fix this, keep our GL context current when destroying a GL output. In case EGL_KHR_surfaceless_context is not available, we must use dummy_surface. Signed-off-by: Pekka Paalanen <pekka.paalanen@collabora.com> |
4 years ago |
Pekka Paalanen | 21b8ad5a16 |
tests: ensure color-lcms plugin loads
This is a trivial smoke test to ensure that the color-lcms plugin is loadable. Signed-off-by: Pekka Paalanen <pekka.paalanen@collabora.com> |
4 years ago |
Pekka Paalanen | c87fa24059 |
compositor: add weston.ini option to enable color management
This new option allows loading the color-lcms plugin. Signed-off-by: Pekka Paalanen <pekka.paalanen@collabora.com> |
4 years ago |
Pekka Paalanen | 5e79dd4892 |
libweston: begin color-lcms plugin
This creates the color-lcms plugin that in the future will be using Little CMS as the color matching module, processing ICC profiles, and producing HDR tone mappings. Right now, this new plugin is functionally equivalent to the no-op color manager, except it already links to lcms2 and checks that the renderer supports color operations. Color-lcms is a libweston plugin that is loaded with explicit weston_compositor API. This does not currently allow loading alternative color manager plugins. External color manager plugins might be considered in the future when the libweston APIs around color management stabilize. This libweston plugin uses the same build option as the old cms-static Weston plugins, as they both need lcms2. The minimum version for lcms2 was chosen by what Debian Buster provides today and for no other reason. This plugin intends to support the Wayland CM&HDR protocol extension and hence sets supports_client_protocol to true. This will expose the protocol extension to clients when it gets implemented. Signed-off-by: Pekka Paalanen <pekka.paalanen@collabora.com> |
4 years ago |
Pekka Paalanen | 8fb23ed110 |
color: add from sRGB to blending color transformation
This is needed when the compositor produces any content internally: - the lines in triangle fan debug - the censoring color fill (unmet HDCP requirements) Solid color surfaces do not need this special-casing because weston_surface is supposed to carry color space information, which will get used in gl_shader_config_init_for_view(). This makes sure the internally produced graphics fit in, e.g on a monitor in HDR mode. For now, just ensure there is an identity transformation. Actual implementations in GL-renderer will follow later. Signed-off-by: Pekka Paalanen <pekka.paalanen@collabora.com> |
4 years ago |
Pekka Paalanen | cda3951a9a |
color: add from sRGB to output color transformation
This is needed when drawing anything internal directly to an output, like the borders/decorations in a nested compositor setup. This makes the assumption that the internal stuff starts in sRGB, which should be safe. As borders are never blended with other content, this should also be sufficient. This patch is a reminder that that path exists, rather than a real implementation. To be implemented when someone needs it. Signed-off-by: Pekka Paalanen <pekka.paalanen@collabora.com> |
4 years ago |
Pekka Paalanen | 1d2eee208c |
color: add output color transform API
This is the blending space to monitor space color transform. It needs to be implemented in the renderers, unless a backend sets from_blend_to_output_by_backend = true, in which case the backend does it and the renderer does not. The intention is that from_blend_to_output_by_backend can be toggled frame by frame to allow backends to react to dynamic change of output color profile. For now, renderers just assert that they don't need to do anything for output color transform. Signed-off-by: Pekka Paalanen <pekka.paalanen@collabora.com> |
4 years ago |
Pekka Paalanen | 90a5ffa097 |
libweston: introduce CMS component architecture
See: https://gitlab.freedesktop.org/wayland/weston/-/issues/467#note_814985 This starts building the framework required for implementing color management. The main new interface is struct weston_color_manager. This commit also adds a no-op color manager implementation, which is used if no other color manager is loaded. This no-op color manager simply provides identity color transforms for everything, so that Weston keeps running exactly like before. weston_color_manager interface is incomplete and will be extended later. Colorspace objects are not introduced in this commit. However, when client content colorspace and output colorspace definitions are combined, they will produce color transformations from client content to output blending space and from output blending space to output space. This commit introduces a placeholder struct for color transforms, weston_color_transform. Objects of this type are expected to be heavy to create and store, which is why they are designed to be shared as much as possible, ideally making their instances unique. As color transform description is intended to be generic in libweston core, renderers and backends are expected to derive their own state for each transform object as necessary. Creating and storing the derived state maybe be expensive as well, more the reason to re-use these objects as much as possible. E.g. GL-renderer might upload a 3D LUT into a texture and keep the texture around. DRM-backend might create a KMS blob for a LUT and keep that around. As a color transform depends on both the surface and the output, a transform object may need to be created for each unique pair of them. Therefore color transforms are referenced from weston_paint_node. As paint nodes exist for not just surface+output but surface+view+output triplets, the code ensures that all paint nodes (having different view) for the same surface+output have the same color transform state. As a special case, if weston_color_transform is NULL, it means identity transform. This short-circuits some checks and memory allocations, but it does mean we use a separate member on weston_paint_node to know if the color transform has been initialized or not. Color transformations are pre-created at the weston_output paint_node_z_order_list creation step. Currently the z order lists contain all views globally, which means we populate color transforms we may never need, e.g. a view is never shown on a particular output. This problem should get fixed naturally when z order lists are constructed "pruned" in the future: to contain only those paint nodes that actually contribute to the output's image. As nothing actually supports color transforms yet, both renderers and the DRM-backend assert that they only get identity transforms. This check has the side-effect that all surface-output pairs actually get a weston_surface_color_transform_ref even though it points to NULL weston_color_transform. This design is inspired by Sebastian Wick's Weston color management work. Co-authored-by: Sebastian Wick <sebastian@sebastianwick.net> Signed-off-by: Pekka Paalanen <pekka.paalanen@collabora.com> |
4 years ago |
Pekka Paalanen | da0f7ea4a7 |
gl-renderer: draw_view -> draw_paint_node
A following patch will need the paint node in gl_shader_config_init_for_view() for color transformations. While passing the paint node through, rename the functions to be more appropriate and get surface/view/output from the paint node. This is a pure refactoring with no functional change. Signed-off-by: Pekka Paalanen <pekka.paalanen@collabora.com> |
4 years ago |
Pekka Paalanen | 79885af165 |
pixman-renderer: draw_view -> draw_paint_node
A following patch will need the paint node in draw_view() for color transformations. While passing the paint node into draw_paint_node, also use the paint node. This is a pure refactoring with no functional change. Signed-off-by: Pekka Paalanen <pekka.paalanen@collabora.com> |
4 years ago |
Alexandros Frantzis | 6ee80ecc9d |
tests: Add shot test for pointer cursor behavior
Add a regression test to verify that the cursor image is correctly updated when setting a cursor surface with an already committed buffer from a previous pointer entry, without recommitting a cursor buffer for the current entry. Signed-off-by: Alexandros Frantzis <alexandros.frantzis@collabora.com> |
4 years ago |
Alexandros Frantzis | 4ea9be5193 |
tests: Store the pointer event serial
Store the pointer serial for events that provide one, so that it can be used by tests to send requests that require it (e.g., setting the cursor surface). Signed-off-by: Alexandros Frantzis <alexandros.frantzis@collabora.com> |
4 years ago |
Alexandros Frantzis | 28d66344a0 |
input: Use cursor surface dimensions to evaluate presence of content
When setting a cursor surface, use the surface dimensions, instead of the weston_surface buffer reference, to check if the surface has any content. A weston_surface without any buffer reference may in fact have a buffer which was committed in a previous pointer entry, dropped by weston_surface and now held only internally by the renderer. Without this fix, when a pointer enters a surface, the cursor image is not correctly updated if we set a cursor surface with an already committed buffer from a previous pointer entry, without recommitting the cursor buffer for the current entry. This can be seen, for example, in the experimental Wine Wayland driver which handles the cursor in a way that leads to the following scenario: Setup: cursor_surface.attach(buffer) & cursor_surface.commit() On first wl_pointer.enter: pointer.set_cursor(cursor_surface) compositor/renderer redraws wl_pointer.leave On second wl_pointer.enter: pointer.set_cursor(cursor_surface) When handling the second pointer.set_cursor() request the current code doesn't find a buffer attached to the cursor_surface (only the renderer now has a reference to it), so it doesn't update the respective view for the cursor. Signed-off-by: Alexandros Frantzis <alexandros.frantzis@collabora.com> |
4 years ago |
Michael Tretter | 16e3f27fc7 |
ivi-shell: bring back reference weston.ini
In commit
|
4 years ago |
Igor Matheus Andrade Torrente | bfcb1adc14 |
backend-drm: Drop support to non universal plane drivers
Remove all the backend code to support drivers without universal planes. From[1]: "The code needed to support kernels where DRM does not support uiniversal planes makes the DRM-backend a little more complicated, because it needs to create fake planes for primary and cursor. The lifetimes of the fake planes does not match the lifetime of "proper" planes, which is surprising." And since the universal planes left the experimetal flag in 2014[2] it is safe to remove the support now. [1] https://gitlab.freedesktop.org/wayland/weston/-/issues/427 [2] https://cgit.freedesktop.org/drm/drm-tip/commit/?id=c7dbc6c9ae5c3baa3be755a228a349374d043b5b Signed-off-by: Igor Matheus Andrade Torrente <igormtorrente@gmail.com> |
4 years ago |
Marius Vlad | 568d04ff11 |
weston-debug: Handle destruction of stream description
Memleak found by ASAN: Direct leak of 258 byte(s) in 8 object(s) allocated from: #0 0x7f3eedb6e817 in __interceptor_strdup (/usr/lib/x86_64-linux-gnu/libasan.so.6+0x57817) #1 0x55821ce5e6a5 in stream_alloc ../clients/weston-debug.c:94 #2 0x55821ce5e974 in stream_find ../clients/weston-debug.c:128 #3 0x55821ce5eb15 in debug_advertise ../clients/weston-debug.c:157 #4 0x7f3eed7b4d1c (/usr/lib/x86_64-linux-gnu/libffi.so.7+0x6d1c) Signed-off-by: Marius Vlad <marius.vlad@collabora.com> |
4 years ago |
Marius Vlad | cdeeb881a0 |
xwayland/window-manager: Handle weston_wm_window's name/class destruction
Memleak found by ASAN: Direct leak of 21 byte(s) in 1 object(s) allocated from: #0 0x7fe7a917fe8f in malloc (/usr/lib/x86_64-linux-gnu/libasan.so.6+0xa9e8f) #1 0x7fe7a9129874 (/usr/lib/x86_64-linux-gnu/libasan.so.6+0x53874) #2 0x7fe7a5a23469 in weston_wm_window_read_properties ../xwayland/window-manager.c:574 #3 0x7fe7a5a28d3b in weston_wm_handle_map_request ../xwayland/window-manager.c:1178 #4 0x7fe7a5a31660 in weston_wm_handle_event ../xwayland/window-manager.c:2291 #5 0x7fe7a8c261a1 in wl_event_loop_dispatch ../src/event-loop.c:1027 Signed-off-by: Marius Vlad <marius.vlad@collabora.com> |
4 years ago |
Marius Vlad | 4c7dbe6ab2 |
xwayland/window-manager: Handle theme destruction
Memleak found by ASAN: Direct leak of 40 byte(s) in 1 object(s) allocated from: #0 0x7fe7a917fe8f in malloc (/usr/lib/x86_64-linux-gnu/libasan.so.6+0xa9e8f) #1 0x7fe7a5a40736 in theme_create ../shared/cairo-util.c:419 #2 0x7fe7a5a3363c in weston_wm_create ../xwayland/window-manager.c:2619 #3 0x7fe7a5a2017e in weston_xwayland_xserver_loaded ../xwayland/launcher.c:313 #4 0x7fe7a90b4d14 in handle_sigusr1 ../compositor/xwayland.c:57 #5 0x7fe7a8c2585d in wl_event_source_signal_dispatch ../src/event-loop.c:685 #6 0x7ffcdb04ef6f ([stack]+0x1df6f) Signed-off-by: Marius Vlad <marius.vlad@collabora.com> |
4 years ago |
Samu Nuutamo | 58a2faf716 |
libinput-seat: update leds when a new device is added
Fix an issue where the keyboard leds will go out of sync when a new keyboard is connected. The issue can be easily reproduced by connecting two keyboards, enabling caps lock, and reconnecting one of the keyboards. Without the patch the leds on both keyboards will turn off while the actual caps lock state will stay enabled. Signed-off-by: Samu Nuutamo <samu.nuutamo@gmail.com> |
4 years ago |
Pekka Paalanen | 497d03edbf |
clients/keyboard: free input_panel_surface
Fixes ASan leak: Direct leak of 80 byte(s) in 1 object(s) allocated from: #0 0x7fe7791f4518 in calloc (/lib/x86_64-linux-gnu/libasan.so.5+0xe9518) #1 0x7fe779100892 in zalloc ../../git/wayland/src/wayland-private.h:232 #2 0x7fe779100892 in proxy_create ../../git/wayland/src/wayland-client.c:422 #3 0x7fe779100ede in create_outgoing_proxy ../../git/wayland/src/wayland-client.c:651 #4 0x7fe779100ede in wl_proxy_marshal_array_constructor_versioned ../../git/wayland/src/wayland-client.c:736 #5 0x7fe779101226 in wl_proxy_marshal_constructor ../../git/wayland/src/wayland-client.c:834 #6 0x56428c9bc578 in zwp_input_panel_v1_get_input_panel_surface protocol/input-method-unstable-v1-client-protocol.h:678 #7 0x56428c9c0bbb in set_toplevel ../../git/weston/clients/keyboard.c:965 #8 0x56428c9c0c8d in display_output_handler ../../git/weston/clients/keyboard.c:980 #9 0x56428c9ddead in display_handle_mode ../../git/weston/clients/window.c:5700 #10 0x7fe7786668ed in ffi_call_unix64 (/lib/x86_64-linux-gnu/libffi.so.6+0x68ed) #11 0x7fe7786662be in ffi_call (/lib/x86_64-linux-gnu/libffi.so.6+0x62be) #12 0x7fe779103fac in wl_closure_invoke ../../git/wayland/src/connection.c:1018 #13 0x7fe779100a48 in dispatch_event ../../git/wayland/src/wayland-client.c:1452 #14 0x7fe779101e43 in dispatch_queue ../../git/wayland/src/wayland-client.c:1598 #15 0x7fe779101e43 in wl_display_dispatch_queue_pending ../../git/wayland/src/wayland-client.c:1840 #16 0x56428c9e031c in handle_display_data ../../git/weston/clients/window.c:6211 #17 0x56428c9e2147 in display_run ../../git/weston/clients/window.c:6553 #18 0x56428c9c1559 in main ../../git/weston/clients/keyboard.c:1053 #19 0x7fe77885e09a in __libc_start_main ../csu/libc-start.c:308 #20 0x56428c9bc029 in _start (/home/pq/build/weston-meson/clients/weston-keyboard+0x19029) Signed-off-by: Pekka Paalanen <pekka.paalanen@collabora.com> |
4 years ago |
Pekka Paalanen | 2af436bb9c |
clients/window: clean up xkb compose data
This fixes ASan report: SUMMARY: AddressSanitizer: 151360 byte(s) leaked in 451 allocation(s). The leaks can be observed if you let weston-desktop-shell start fully before shutting down Weston. Many simple test suite tests are too fast to hit this, or do not even use desktop-shell. This clean-up code is copied from keyboard_handle_keymap(). Signed-off-by: Pekka Paalanen <pekka.paalanen@collabora.com> |
4 years ago |
Pekka Paalanen | 091b1554da |
shared/cairo-util: fix leak from load_cairo_surface()
Fixes ASan reported leaks: Direct leak of 256 byte(s) in 1 object(s) allocated from: #0 0x7f8266f2d330 in __interceptor_malloc (/lib/x86_64-linux-gnu/libasan.so.5+0xe9330) #1 0x7f8266c8589a (/lib/x86_64-linux-gnu/libpixman-1.so.0+0x5089a) #2 0x7f8266c4ea77 (/lib/x86_64-linux-gnu/libpixman-1.so.0+0x19a77) #3 0x55fa7818f8e8 in load_png ../../git/weston/shared/image-loader.c:297 #4 0x55fa7819039e in load_image ../../git/weston/shared/image-loader.c:423 #5 0x55fa78187b3e in load_cairo_surface ../../git/weston/shared/cairo-util.c:354 #6 0x55fa7815ff8a in background_draw ../../git/weston/clients/desktop-shell.c:779 #7 0x55fa7817b2c2 in widget_redraw ../../git/weston/clients/window.c:4520 #8 0x55fa7817b831 in surface_redraw ../../git/weston/clients/window.c:4578 #9 0x55fa7817b9a7 in idle_redraw ../../git/weston/clients/window.c:4607 #10 0x55fa78184ea4 in display_run ../../git/weston/clients/window.c:6527 #11 0x55fa781646fb in main ../../git/weston/clients/desktop-shell.c:1556 #12 0x7f826659709a in __libc_start_main ../csu/libc-start.c:308 #13 0x55fa7815c0a9 in _start (/home/pq/build/weston-meson/clients/weston-desktop-shell+0x120a9) Indirect leak of 8024 byte(s) in 1 object(s) allocated from: #0 0x7f8266f2d330 in __interceptor_malloc (/lib/x86_64-linux-gnu/libasan.so.5+0xe9330) #1 0x55fa7818f5e7 in load_png ../../git/weston/shared/image-loader.c:275 #2 0x55fa7819039e in load_image ../../git/weston/shared/image-loader.c:423 #3 0x55fa78187b3e in load_cairo_surface ../../git/weston/shared/cairo-util.c:354 #4 0x55fa7815ff8a in background_draw ../../git/weston/clients/desktop-shell.c:779 #5 0x55fa7817b2c2 in widget_redraw ../../git/weston/clients/window.c:4520 #6 0x55fa7817b831 in surface_redraw ../../git/weston/clients/window.c:4578 #7 0x55fa7817b9a7 in idle_redraw ../../git/weston/clients/window.c:4607 #8 0x55fa78184ea4 in display_run ../../git/weston/clients/window.c:6527 #9 0x55fa781646fb in main ../../git/weston/clients/desktop-shell.c:1556 #10 0x7f826659709a in __libc_start_main ../csu/libc-start.c:308 #11 0x55fa7815c0a9 in _start (/home/pq/build/weston-meson/clients/weston-desktop-shell+0x120a9) from the command ASAN_OPTIONS=fast_unwind_on_malloc=0,malloc_context_size=50 \ LSAN_OPTIONS=suppressions=/home/pq/git/weston/.gitlab-ci/leak-sanitizer.supp \ ./tests/test-viewporter test_viewporter_bad_source_rect by recording the pixman image as user data so it can be freed when the surface is destroyed. Signed-off-by: Pekka Paalanen <pekka.paalanen@collabora.com> |
4 years ago |
Lujin Wang | 928d3a0059 |
clients: Free output->make/model in output_destroy
== 8 bytes in 1 blocks are definitely lost in loss record 4 of 71 == at 0x48450F8: malloc (vg_replace_malloc.c:309) == by 0x500213F: strdup (strdup.c:42) == by 0x40A57F: display_handle_geometry (in weston-desktop-shell) == by 0x4864D27: ffi_call_SYSV (in libffi.so.6.0.4) == by 0x4865697: ffi_call (in libffi.so.6.0.4) == by 0x4880E07: wl_closure_invoke (connection.c:935) == by 0x487DD73: dispatch_event.isra.5 (wayland-client.c:1310) == by 0x487EF87: dispatch_queue (wayland-client.c:1456) == by 0x487EF87: wl_display_dispatch_queue_pending (wayland-client.c:1698) == by 0x4104E3: handle_display_data (in weston-desktop-shell) == by 0x40FE8F: display_run (in weston-desktop-shell) == by 0x405AB3: main (in weston-desktop-shell) Signed-off-by: Lujin Wang <luwang@nvidia.com> Signed-off-by: Pekka Paalanen <pekka.paalanen@collabora.com> |
4 years ago |
Pekka Paalanen | 719ca87399 |
desktop-shell: clean up shell_output better
This fixes the following ASan detected leaks: Direct leak of 88 byte(s) in 1 object(s) allocated from: #0 0x7f8c3455f330 in __interceptor_malloc (/lib/x86_64-linux-gnu/libasan.so.5+0xe9330) #1 0x7f8c33c60906 in wl_event_loop_add_timer ../../git/wayland/src/event-loop.c:571 #2 0x7f8c2ff98f46 in shell_fade_init ../../git/weston/desktop-shell/shell.c:4211 #3 0x7f8c2ff9e1da in wet_shell_init ../../git/weston/desktop-shell/shell.c:5266 #4 0x7f8c3443ede5 in wet_load_shell ../../git/weston/compositor/main.c:956 #5 0x7f8c3444fdb9 in wet_main ../../git/weston/compositor/main.c:3434 #6 0x55878ad3bfc6 in execute_compositor ../../git/weston/tests/weston-test-fixture-compositor.c:432 #7 0x55878ad3f9fa in weston_test_harness_execute_as_client ../../git/weston/tests/weston-test-runner.c:528 #8 0x55878ad2fbd6 in fixture_setup ../../git/weston/tests/viewporter-test.c:46 #9 0x55878ad2fc58 in fixture_setup_run_ ../../git/weston/tests/viewporter-test.c:48 #10 0x55878ad3ffaf in main ../../git/weston/tests/weston-test-runner.c:661 #11 0x7f8c340b409a in __libc_start_main ../csu/libc-start.c:308 #12 0x55878ad2f769 in _start (/home/pq/build/weston-meson/tests/test-viewporter+0xc769) Indirect leak of 856 byte(s) in 1 object(s) allocated from: #0 0x7f8c3455f518 in calloc (/lib/x86_64-linux-gnu/libasan.so.5+0xe9518) #1 0x7f8c33c99b73 in zalloc ../../git/weston/include/libweston/zalloc.h:38 #2 0x7f8c33c9cfb1 in weston_surface_create ../../git/weston/libweston/compositor.c:574 #3 0x7f8c2ff98230 in shell_fade_create_surface_for_output ../../git/weston/desktop-shell/shell.c:4059 #4 0x7f8c2ff98df6 in shell_fade_init ../../git/weston/desktop-shell/shell.c:4202 #5 0x7f8c2ff9e1da in wet_shell_init ../../git/weston/desktop-shell/shell.c:5266 #6 0x7f8c3443ede5 in wet_load_shell ../../git/weston/compositor/main.c:956 #7 0x7f8c3444fdb9 in wet_main ../../git/weston/compositor/main.c:3434 #8 0x55878ad3bfc6 in execute_compositor ../../git/weston/tests/weston-test-fixture-compositor.c:432 #9 0x55878ad3f9fa in weston_test_harness_execute_as_client ../../git/weston/tests/weston-test-runner.c:528 #10 0x55878ad2fbd6 in fixture_setup ../../git/weston/tests/viewporter-test.c:46 #11 0x55878ad2fc58 in fixture_setup_run_ ../../git/weston/tests/viewporter-test.c:48 #12 0x55878ad3ffaf in main ../../git/weston/tests/weston-test-runner.c:661 #13 0x7f8c340b409a in __libc_start_main ../csu/libc-start.c:308 #14 0x55878ad2f769 in _start (/home/pq/build/weston-meson/tests/test-viewporter+0xc769) Indirect leak of 608 byte(s) in 1 object(s) allocated from: #0 0x7f8c3455f518 in calloc (/lib/x86_64-linux-gnu/libasan.so.5+0xe9518) #1 0x7f8c33c99b73 in zalloc ../../git/weston/include/libweston/zalloc.h:38 #2 0x7f8c33c9bed5 in weston_view_create ../../git/weston/libweston/compositor.c:365 #3 0x7f8c2ff98251 in shell_fade_create_surface_for_output ../../git/weston/desktop-shell/shell.c:4063 #4 0x7f8c2ff98df6 in shell_fade_init ../../git/weston/desktop-shell/shell.c:4202 #5 0x7f8c2ff9e1da in wet_shell_init ../../git/weston/desktop-shell/shell.c:5266 #6 0x7f8c3443ede5 in wet_load_shell ../../git/weston/compositor/main.c:956 #7 0x7f8c3444fdb9 in wet_main ../../git/weston/compositor/main.c:3434 #8 0x55878ad3bfc6 in execute_compositor ../../git/weston/tests/weston-test-fixture-compositor.c:432 #9 0x55878ad3f9fa in weston_test_harness_execute_as_client ../../git/weston/tests/weston-test-runner.c:528 #10 0x55878ad2fbd6 in fixture_setup ../../git/weston/tests/viewporter-test.c:46 #11 0x55878ad2fc58 in fixture_setup_run_ ../../git/weston/tests/viewporter-test.c:48 #12 0x55878ad3ffaf in main ../../git/weston/tests/weston-test-runner.c:661 #13 0x7f8c340b409a in __libc_start_main ../csu/libc-start.c:308 #14 0x55878ad2f769 in _start (/home/pq/build/weston-meson/tests/test-viewporter+0xc769) They were found with: ASAN_OPTIONS=fast_unwind_on_malloc=0,malloc_context_size=50 \ LSAN_OPTIONS=suppressions=/home/pq/git/weston/.gitlab-ci/leak-sanitizer.supp \ ./tests/test-viewporter test_viewporter_double_create Turns out shell_destroy() had an open-coded and outdated copy of the tear-down sequence, so fixing the leaks in only handle_output_destroy() was not enough. Signed-off-by: Pekka Paalanen <pekka.paalanen@collabora.com> |
4 years ago |
Pekka Paalanen | 0d5e4ffb96 |
desktop-shell: rename output_listener to shell_output
Most other places call a variable like this 'shell_output', so let's do that here too. The old name was really confusing. Signed-off-by: Pekka Paalanen <pekka.paalanen@collabora.com> |
4 years ago |
Pekka Paalanen | abd7292969 |
desktop-shell: destroy weston_desktop
Plugs ASan reported leaks: Direct leak of 88 byte(s) in 1 object(s) allocated from: #0 0x7f338f70a518 in calloc (/lib/x86_64-linux-gnu/libasan.so.5+0xe9518) #1 0x7f338afe22f3 in zalloc ../../git/weston/include/libweston/zalloc.h:38 #2 0x7f338afe3cc2 in weston_desktop_xwayland_init ../../git/weston/libweston-desktop/xwayland.c:410 #3 0x7f338afdbaef in weston_desktop_create ../../git/weston/libweston-desktop/libweston-desktop.c:87 #4 0x7f338b148d39 in wet_shell_init ../../git/weston/desktop-shell/shell.c:5224 #5 0x7f338f5e9de5 in wet_load_shell ../../git/weston/compositor/main.c:956 #6 0x7f338f5fadb9 in wet_main ../../git/weston/compositor/main.c:3434 #7 0x5646d2392fc6 in execute_compositor ../../git/weston/tests/weston-test-fixture-compositor.c:432 #8 0x5646d23969fa in weston_test_harness_execute_as_client ../../git/weston/tests/weston-test-runner.c:528 #9 0x5646d2386bd6 in fixture_setup ../../git/weston/tests/viewporter-test.c:46 #10 0x5646d2386c58 in fixture_setup_run_ ../../git/weston/tests/viewporter-test.c:48 #11 0x5646d2396faf in main ../../git/weston/tests/weston-test-runner.c:661 #12 0x7f338f25f09a in __libc_start_main ../csu/libc-start.c:308 #13 0x5646d2386769 in _start (/home/pq/build/weston-meson/tests/test-viewporter+0xc769) Indirect leak of 152 byte(s) in 1 object(s) allocated from: #0 0x7f338f70a518 in calloc (/lib/x86_64-linux-gnu/libasan.so.5+0xe9518) #1 0x7f338afdb811 in zalloc ../../git/weston/include/libweston/zalloc.h:38 #2 0x7f338afdb92d in weston_desktop_create ../../git/weston/libweston-desktop/libweston-desktop.c:65 #3 0x7f338b148d39 in wet_shell_init ../../git/weston/desktop-shell/shell.c:5224 #4 0x7f338f5e9de5 in wet_load_shell ../../git/weston/compositor/main.c:956 #5 0x7f338f5fadb9 in wet_main ../../git/weston/compositor/main.c:3434 #6 0x5646d2392fc6 in execute_compositor ../../git/weston/tests/weston-test-fixture-compositor.c:432 #7 0x5646d23969fa in weston_test_harness_execute_as_client ../../git/weston/tests/weston-test-runner.c:528 #8 0x5646d2386bd6 in fixture_setup ../../git/weston/tests/viewporter-test.c:46 #9 0x5646d2386c58 in fixture_setup_run_ ../../git/weston/tests/viewporter-test.c:48 #10 0x5646d2396faf in main ../../git/weston/tests/weston-test-runner.c:661 #11 0x7f338f25f09a in __libc_start_main ../csu/libc-start.c:308 #12 0x5646d2386769 in _start (/home/pq/build/weston-meson/tests/test-viewporter+0xc769) Indirect leak of 72 byte(s) in 1 object(s) allocated from: #0 0x7f338f70a518 in calloc (/lib/x86_64-linux-gnu/libasan.so.5+0xe9518) #1 0x7f338afdc5ae in zalloc ../../git/weston/include/libweston/zalloc.h:38 #2 0x7f338afdc89e in weston_desktop_client_create ../../git/weston/libweston-desktop/client.c:108 #3 0x7f338afe3d2a in weston_desktop_xwayland_init ../../git/weston/libweston-desktop/xwayland.c:415 #4 0x7f338afdbaef in weston_desktop_create ../../git/weston/libweston-desktop/libweston-desktop.c:87 #5 0x7f338b148d39 in wet_shell_init ../../git/weston/desktop-shell/shell.c:5224 #6 0x7f338f5e9de5 in wet_load_shell ../../git/weston/compositor/main.c:956 #7 0x7f338f5fadb9 in wet_main ../../git/weston/compositor/main.c:3434 #8 0x5646d2392fc6 in execute_compositor ../../git/weston/tests/weston-test-fixture-compositor.c:432 #9 0x5646d23969fa in weston_test_harness_execute_as_client ../../git/weston/tests/weston-test-runner.c:528 #10 0x5646d2386bd6 in fixture_setup ../../git/weston/tests/viewporter-test.c:46 #11 0x5646d2386c58 in fixture_setup_run_ ../../git/weston/tests/viewporter-test.c:48 #12 0x5646d2396faf in main ../../git/weston/tests/weston-test-runner.c:661 #13 0x7f338f25f09a in __libc_start_main ../csu/libc-start.c:308 #14 0x5646d2386769 in _start (/home/pq/build/weston-meson/tests/test-viewporter+0xc769) Oops. Signed-off-by: Pekka Paalanen <pekka.paalanen@collabora.com> |
4 years ago |
Pekka Paalanen | ef4d5c4086 |
tests: clean up after viewporter-test
Clean up after each test to avoid ASan reporting leaks. At few points client_roundtrip() is replaced with client_destroy() because the latter does a final roundtrip anyway. Signed-off-by: Pekka Paalanen <pekka.paalanen@collabora.com> |
4 years ago |
Pekka Paalanen | ed6df8ed1c |
tests: allow client_destroy() after expect_protocol_error()
expect_protocol_error() ensures that the connection has failed in the expected way. To satisfy ASan leak detection, we still need to tear down everything, including call client_destroy(). client_destroy() needs to check that tear-down does not cause protocol errors, so it does one last roundtrip that checks that is succeeds. But if the connection is already down in an expected way, this roundtrip cannot succeed and must be skipped. Also moves the roundtrip under 'if (wl_display)', assuming the 'if' is there for a reason - but obviously that reason was never used as it would have crashed. Signed-off-by: Pekka Paalanen <pekka.paalanen@collabora.com> |
4 years ago |
Pekka Paalanen | 6ae243f91e |
Add leak sanitizer suppressions
ASan will detect leaks also outside of the code we build, and sometimes that external code leaks and we cannot work around it. Then we need to suppress the leak reports to make our own ASan testing succeed. This commit only introduces the suppressions file, making use of it CI is for another time. This file is useful for manual targeted testing as below. Start by suppressing two functions what weston-keyboard client ends up calling, suppressing leak reports like these: Indirect leak of 96 byte(s) in 3 object(s) allocated from: #0 0x7fc109c3d518 in calloc (/lib/x86_64-linux-gnu/libasan.so.5+0xe9518) #1 0x7fc109083d18 (/lib/x86_64-linux-gnu/libfontconfig.so.1+0x20d18) #2 0x7fc1090849a7 in FcPatternDuplicate (/lib/x86_64-linux-gnu/libfontconfig.so.1+0x219a7) #3 0x7fc109adf93e (/lib/x86_64-linux-gnu/libcairo.so.2+0xbb93e) #4 0x7fc109adfc8d (/lib/x86_64-linux-gnu/libcairo.so.2+0xbbc8d) #5 0x7fc109aa02e7 in cairo_toy_font_face_create (/lib/x86_64-linux-gnu/libcairo.so.2+0x7c2e7) #6 0x7fc109aa856c in cairo_select_font_face (/lib/x86_64-linux-gnu/libcairo.so.2+0x8456c) #7 0x5603cb49a06a in redraw_handler ../../git/weston/clients/keyboard.c:378 #8 0x5603cb4b506b in widget_redraw ../../git/weston/clients/window.c:4520 #9 0x5603cb4b55da in surface_redraw ../../git/weston/clients/window.c:4578 #10 0x5603cb4b5750 in idle_redraw ../../git/weston/clients/window.c:4607 #11 0x5603cb4bebe3 in display_run ../../git/weston/clients/window.c:6525 #12 0x5603cb49e55d in main ../../git/weston/clients/keyboard.c:1054 #13 0x7fc1092a709a in __libc_start_main ../csu/libc-start.c:308 #14 0x5603cb499019 in _start (/home/pq/build/weston-meson/clients/weston-keyboard+0x19019) Indirect leak of 528 byte(s) in 51 object(s) allocated from: #0 0x7fc109b8e810 in strdup (/lib/x86_64-linux-gnu/libasan.so.5+0x3a810) #1 0x7fc109082fc4 in FcValueSave (/lib/x86_64-linux-gnu/libfontconfig.so.1+0x1ffc4) #2 0x7fc109083d2e (/lib/x86_64-linux-gnu/libfontconfig.so.1+0x20d2e) #3 0x7fc1090852c7 (/lib/x86_64-linux-gnu/libfontconfig.so.1+0x222c7) #4 0x7fc10908c28b (/lib/x86_64-linux-gnu/libfontconfig.so.1+0x2928b) #5 0x7fc108603a15 (/lib/x86_64-linux-gnu/libexpat.so.1+0xba15) #6 0x7fc1086044bb (/lib/x86_64-linux-gnu/libexpat.so.1+0xc4bb) #7 0x7fc108601f8a (/lib/x86_64-linux-gnu/libexpat.so.1+0x9f8a) #8 0x7fc108602e7a (/lib/x86_64-linux-gnu/libexpat.so.1+0xae7a) #9 0x7fc108606a37 in XML_ParseBuffer (/lib/x86_64-linux-gnu/libexpat.so.1+0xea37) #10 0x7fc10908a0fa (/lib/x86_64-linux-gnu/libfontconfig.so.1+0x270fa) #11 0x7fc10908a519 (/lib/x86_64-linux-gnu/libfontconfig.so.1+0x27519) #12 0x7fc10908a73a (/lib/x86_64-linux-gnu/libfontconfig.so.1+0x2773a) #13 0x7fc10908b48f (/lib/x86_64-linux-gnu/libfontconfig.so.1+0x2848f) #14 0x7fc108603a15 (/lib/x86_64-linux-gnu/libexpat.so.1+0xba15) #15 0x7fc1086044bb (/lib/x86_64-linux-gnu/libexpat.so.1+0xc4bb) #16 0x7fc108601f8a (/lib/x86_64-linux-gnu/libexpat.so.1+0x9f8a) #17 0x7fc108602e7a (/lib/x86_64-linux-gnu/libexpat.so.1+0xae7a) #18 0x7fc108606a37 in XML_ParseBuffer (/lib/x86_64-linux-gnu/libexpat.so.1+0xea37) #19 0x7fc10908a0fa (/lib/x86_64-linux-gnu/libfontconfig.so.1+0x270fa) #20 0x7fc10908a519 (/lib/x86_64-linux-gnu/libfontconfig.so.1+0x27519) #21 0x7fc10907c4b3 (/lib/x86_64-linux-gnu/libfontconfig.so.1+0x194b3) #22 0x7fc10907c715 (/lib/x86_64-linux-gnu/libfontconfig.so.1+0x19715) #23 0x7fc10906e8e6 (/lib/x86_64-linux-gnu/libfontconfig.so.1+0xb8e6) #24 0x7fc109070928 in FcConfigSubstituteWithPat (/lib/x86_64-linux-gnu/libfontconfig.so.1+0xd928) #25 0x7fc109ae2d6b (/lib/x86_64-linux-gnu/libcairo.so.2+0xbed6b) #26 0x7fc109a8aba2 in cairo_scaled_font_create (/lib/x86_64-linux-gnu/libcairo.so.2+0x66ba2) #27 0x7fc109a50d1d (/lib/x86_64-linux-gnu/libcairo.so.2+0x2cd1d) #28 0x7fc109a53be0 (/lib/x86_64-linux-gnu/libcairo.so.2+0x2fbe0) #29 0x7fc109a4c1df (/lib/x86_64-linux-gnu/libcairo.so.2+0x281df) #30 0x7fc109aa8dab in cairo_text_extents (/lib/x86_64-linux-gnu/libcairo.so.2+0x84dab) #31 0x5603cb499af3 in draw_key ../../git/weston/clients/keyboard.c:329 #32 0x5603cb49a30c in redraw_handler ../../git/weston/clients/keyboard.c:392 #33 0x5603cb4b506b in widget_redraw ../../git/weston/clients/window.c:4520 #34 0x5603cb4b55da in surface_redraw ../../git/weston/clients/window.c:4578 #35 0x5603cb4b5750 in idle_redraw ../../git/weston/clients/window.c:4607 #36 0x5603cb4bebe3 in display_run ../../git/weston/clients/window.c:6525 #37 0x5603cb49e55d in main ../../git/weston/clients/keyboard.c:1054 #38 0x7fc1092a709a in __libc_start_main ../csu/libc-start.c:308 #39 0x5603cb499019 in _start (/home/pq/build/weston-meson/clients/weston-keyboard+0x19019) With the command line ASAN_OPTIONS=fast_unwind_on_malloc=0,malloc_context_size=50 \ LSAN_OPTIONS=suppressions=/home/pq/git/weston/.gitlab-ci/leak-sanitizer.supp \ ./tests/test-viewporter test_viewporter_double_create Suppressions used: count bytes template 5 357 cairo_select_font_face 130 9104 cairo_text_extents Signed-off-by: Pekka Paalanen <pekka.paalanen@collabora.com> |
4 years ago |
Pekka Paalanen | c8c53bafd3 |
clients/window: destroy remaining globals
Destroy the remaining globals on exit. Fixes a bunch of leaks reported by ASan. Signed-off-by: Pekka Paalanen <pekka.paalanen@collabora.com> |
4 years ago |
Pekka Paalanen | 1e08a81c43 |
clients/window: move code into global_destroy()
Another patch will want to call global_destroy() too. Pure refactoring, no functional change. Signed-off-by: Pekka Paalanen <pekka.paalanen@collabora.com> |
4 years ago |
Pekka Paalanen | d9b949d8b9 |
keyboard: free stuff on exit
This fixes a bunch of leaks when trying to run a Weston test with desktop-shell, which spawns weston-keyboard. Signed-off-by: Pekka Paalanen <pekka.paalanen@collabora.com> |
4 years ago |
Pekka Paalanen | 1f3e9045ad |
clients/window: fix leaks on start-up failure
Trying to run viewporter-test with ASan leak checking, weston-desktop-shell helper client reports many leaks, because the compositor quits before the client can start. Hence the wl_display_roundtrip() fails. Clean up by calling display_destroy() when wl_display_roundtrip() fails. It's late enough that all kinds of things may have been allocated, so a special local tear-down path is not feasible. To make that work, display_destroy() must handle many things that might be NULL which normally aren't. Also display_create() needs to initialize lists early enough so that cleaning them up works. Signed-off-by: Pekka Paalanen <pekka.paalanen@collabora.com> |
4 years ago |
Simon Ser | 992ee045f1 |
clients/window: atomically update pointer cursor
Currently, Weston clients update the pointer cursor by first issuing a wl_surface.commit request to update the buffer, then a wl_pointer.set_cursor request to update the hotspot. This causes an issue because buffer and hotspot aren't updated atomically: in-between the two requests, the buffer is new but the hotspot is old. To fix this issue, create a new surface each time the cursor is updated. Signed-off-by: Simon Ser <contact@emersion.fr> |
4 years ago |
Pekka Paalanen | 7514bf7e45 |
tests: proper weston_test_surface_create()
struct weston_test_surface in the test harness' compositor plugin had no tear down code, which lead to ASan report on alpha-blending test: Direct leak of 64 byte(s) in 2 object(s) allocated from: #0 0x7f8931f10330 in __interceptor_malloc (/lib/x86_64-linux-gnu/libasan.so.5+0xe9330) #1 0x7f892d934425 in move_surface ../../git/weston/tests/weston-test.c:181 #2 0x7f893159d8ed in ffi_call_unix64 (/lib/x86_64-linux-gnu/libffi.so.6+0x68ed) While at it, let's do this properly for once: - put the creation in a new function - hook up to the weston_surface destroy signal so this actually gets freed (fixes the leak) - check that we don't overwrite another surface role - check that committed_private actually is ours - set the surface label func so it gets properly listed in debugs and traces - use the proper surface role setup call, so no-one stomps on anyones toes if a test makes a mistake by using a wrong wl_surface Signed-off-by: Pekka Paalanen <pekka.paalanen@collabora.com> |
4 years ago |