Pull the container from a source without a rate limit
Suggested by Daniel Stone <daniels@collabora.com>
Signed-off-by: Derek Foreman <derek.foreman@collabora.com>
This is the first step towards removing wl_shell support.
Add an option so that users can toggle support for the deprecated
wl_shell protocol. This lets users test their clients to make sure
they work fine without wl_shell.
The option is set to false by default.
Signed-off-by: Simon Ser <contact@emersion.fr>
If a given wl_surface already has a role (e.g. cursor or subsurface),
there is nothing you can do with an xdg_surface which won't raise an
error, apart from destroying it.
As of wayland/wayland-protocols@11fecf080860 this is now explicitly
specified to be illegal, so disallow it within libweston-desktop. This
avoids us tying ourselves in knots with surface-private ownership.
Signed-off-by: Daniel Stone <daniels@collabora.com>
It's illegal to create an xdg_surface for a surface which already has a
buffer attached to it. We check for this, but only after we've created
our weston_desktop_surface; this simply avoids creating the internal
tracking structure when we're only going to destroy it after posting the
error.
Signed-off-by: Daniel Stone <daniels@collabora.com>
Conditionally build support when libdrm is at least 2.4.107 to make use
of it. Plug it in when printing out the buffer information.
With this in, we add a hard dependecy for libweston to link against
libdrm.
Signed-off-by: Marius Vlad <marius.vlad@collabora.com>
asprintf() has the problem that it leaves *strp undefined when it
fails. Here is a simple wrapper that ensures NULL if asprintf() fails,
which is much more convenient to use.
This will be useful in future patches, where one needs to return error
messages from maybe failing functions, and more.
Signed-off-by: Pekka Paalanen <pekka.paalanen@collabora.com>
Potential failures when creating the EGL image could cause an incorrect
number of num images (num_planes > num_images). With this change
egl_image_unref() requires an additional check to avoid any potential NULL
derefs when cleaning up. We do it straight in egl_image_unref() instead
of adding guards all over the necessary parts.
Signed-off-by: Marius Vlad <marius.vlad@collabora.com>
As observed on some platforms, importing known DMA buffers can cause
failures, leading to an attempt of destroyng an EGL image not set. This patch
resets the num_images such that loop becomes inert when destroying the
DMA buffer, and avoids passing an egl image to it.
The initial import doesn't have this issue as it sets the num_images in
case it succeeds. This also corrects the assumption that the num_images
were 0 at that point which, if the initial import succeded, was actually set
to 1.
Signed-off-by: Marius Vlad <marius.vlad@collabora.com>
The wayland.c actually include 'xdg-shell-client-protocol.h' instead of
the server one, so fix it. Otherwise, it's possible to get build failure
due to race condition.
Signed-off-by: Chen Qi <Qi.Chen@windriver.com>
Signed-off-by: Daniel Stone <daniels@collabora.com>
[daniels: Found in OpenEmbedded/Yocto source.]
The value of the `path` parameter is executed right before
wl_display_run.
The `watch` parameter is meant for things like tests using
the headless backend and the kiosk shell.
Fixes https://gitlab.freedesktop.org/wayland/weston/-/issues/171
Signed-off-by: Alvarito050506 <donfrutosgomez@gmail.com>
warning: Tag 'TCL_SUBST' at line 250 of file '/home/pq/build/weston-meson/doc/sphinx/doxygen.ini' has become obsolete.
To avoid this warning please remove this line from your configuration file or upgrade it using "doxygen -u"
warning: Tag 'COLS_IN_ALPHA_INDEX' at line 1094 of file '/home/pq/build/weston-meson/doc/sphinx/doxygen.ini' has become obsolete.
To avoid this warning please remove this line from your configuration file or upgrade it using "doxygen -u"
warning: Tag 'PERL_PATH' at line 2159 of file '/home/pq/build/weston-meson/doc/sphinx/doxygen.ini' has become obsolete.
To avoid this warning please remove this line from your configuration file or upgrade it using "doxygen -u"
warning: Tag 'MSCGEN_PATH' at line 2181 of file '/home/pq/build/weston-meson/doc/sphinx/doxygen.ini' has become obsolete.
To avoid this warning please remove this line from your configuration file or upgrade it using "doxygen -u"
Observed with Doxygen 1.9.1 in Debian Bullseye.
Signed-off-by: Pekka Paalanen <pekka.paalanen@collabora.com>
Fixes a minor leak due to launcher-libseatd:
Direct leak of 32 byte(s) in 1 object(s) allocated from:
#0 0x7f15664e5037 in calloc (/usr/lib/x86_64-linux-gnu/libasan.so.6+0xaa037)
#1 0x7f156305c59f in zalloc ../include/libweston/zalloc.h:38
#2 0x7f156305c99b in seat_open_device ../libweston/launcher-libseat.c:114
#3 0x7f1563056341 in weston_launcher_open ../libweston/launcher-util.c:79
#4 0x7f156302f1e2 in drm_device_is_kms ../libweston/backend-drm/drm.c:2616
#5 0x7f156302f751 in find_primary_gpu ../libweston/backend-drm/drm.c:2715
#6 0x7f15630309a5 in drm_backend_create ../libweston/backend-drm/drm.c:2970
#7 0x7f15630317ab in weston_backend_init ../libweston/backend-drm/drm.c:3162
#8 0x7f1566025b61 in weston_compositor_load_backend ../libweston/compositor.c:8201
#9 0x7f156640cb9e in load_drm_backend ../compositor/main.c:2596
#10 0x7f156641193c in load_backend ../compositor/main.c:3079
#11 0x7f1566413cc3 in wet_main ../compositor/main.c:3356
#12 0x562ba484b179 in main ../compositor/executable.c:33
#13 0x7f156624fcc9 in __libc_start_main ../csu/libc-start.c:308
But also use the launcher interface to actually close the DRM fd, in
mirror to what weston_launcher_open() does.
Signed-off-by: Marius Vlad <marius.vlad@collabora.com>
This fixes all ASan reported leaks in this test.
This test program has several tests named *_multiple that just run
another test function 30 times. Previously without cleanup all the
created clients would be left lingering, but now they are torn down. Ths
might cause a change in test behaviour, although that was never the
intention:
> It is intentional to run it so many times, but it is not intentional
> to run a hundred clients at a time. The problem is that currently we
> have no destroy function for client. However, the clients do not run
> simultaneously but serially, so the effect should be the same as if
> we'd destroy them (after the client finishes its body, it just 'is'
> and does nothing until the process exits)
- the original review discussion in
https://lists.freedesktop.org/archives/wayland-devel/2015-March/020957.html
The intention for the repeat testing is that as the Weston instance
remains from test to another, each test needs to undo its changes to the
devices. Failing to correcntly undo would accumulate devices.
Signed-off-by: Pekka Paalanen <pekka.paalanen@collabora.com>
Fixes all ASan reported leaks.
The manual touch release is slightly awkward as we need to open-code a
part of input_destroy() to avoid double-freeing pointer->wl_touch.
Signed-off-by: Pekka Paalanen <pekka.paalanen@collabora.com>
Not printing these will drop 7980 lines or roughly 350 kB from the test
logs. Now I don't have scroll through them all, and I don't have to
watch them if I run this test manually.
These prints were useful when developing the test, but we don't need
them printed in CI all the time. Printing the final count should be
enough.
Signed-off-by: Pekka Paalanen <pekka.paalanen@collabora.com>
Now that GL-renderer and color manager implement linear light blending
for sRGB EOTF, add a test case to verify the result is expected.
As noted in test comments, this new tests is quite powerful in ensuring
the whole linear light pipeline is working correctly with 1D LUTs in
GL-renderer. This test will even catch smashing source_lut.scale = 1.0f
and source_lut.offset = 0.0f which would result in wrong texture sample
positions for LUT data.
As the assumption is that by default content and outputs are in sRGB
color space, this test should not need fix-ups or become stale when more
color management features are implemented.
The sRGB EOTF can be found in:
http://www.color.org/sRGB.pdf (beware, typos)
https://www.w3.org/Graphics/Color/srgbhttps://www.khronos.org/registry/DataFormat/specs/1.3/dataformat.1.3.html#TRANSFER_SRGB
Note on AMD Polaris 11 error threshold: this is quite likely due to
using fp16 format shadow framebuffer and GCN fp32 to fp16 conversion
instruction rounding mode. When using fp32 shadow framebuffer, the error
glitch is not present and the threshold could be significantly lower.
Signed-off-by: Pekka Paalanen <pekka.paalanen@collabora.com>
Instead of checking just the monotonicity of the blending results, this
changes the alpha-blending test to compute the reference blend result
itself and then comparing to the compositor result. This way we can be
sure that the compositor implements the exact correct formula and not
something that just looks nice, as verifying the reference images are
actually correct is hard.
The reference image is renamed to follow the fact that this is not
primarily a monotonicity test anymore. The reference image is also
redundant, but I think it has documentary value.
The #if 0'd block of code was very useful in figuring out blending
errors in a future test case, so it is included here. I have a feeling
we are going to need it again.
Signed-off-by: Pekka Paalanen <pekka.paalanen@collabora.com>
Refactor the alpha-blending test to allow using all three images
foreground, background, and screenshot in a future new verification
function.
This is a pure refactoring, no change in behavior.
Signed-off-by: Pekka Paalanen <pekka.paalanen@collabora.com>
Initialize LittleCMS and use it to generate the sRGB EOTF and inverse
curves. Use these curves to define the blending color space as optical
(linear) sRGB by assuming that both content and output color spaces are
sRGB.
As a consequence, this causes Weston to do "gamma correct blending", as
in, blend in light linear space which should avoid distorting colors in
alpha gradients, when color-lcms is active.
This makes use of the 3x1D LUT support added in gl-renderer earlier, and
shows how the color manager is responsible for re-using existing color
transformation objects.
Co-authored-by: Vitaly Prosyak <vitaly.prosyak@amd.com>
Signed-off-by: Vitaly Prosyak <vitaly.prosyak@amd.com>
Signed-off-by: Pekka Paalanen <pekka.paalanen@collabora.com>
Use the blending to output color space transformation when blitting from
the shadow to a framebuffer.
This allows the blending and output color spaces to differ as long as
shadow is used, in case a backend does not off-load the color
transformation.
Signed-off-by: Pekka Paalanen <pekka.paalanen@collabora.com>
Use the sRGB to output color space transformation when blitting the
borders (decorations) into an output window (nested compositor).
Nested output does not need to be sRGB anymore, as far as the
decorations are concerned.
Signed-off-by: Pekka Paalanen <pekka.paalanen@collabora.com>
Use the sRGB to blending color space transformation for the censoring
color fill and triangle fan debug drawings.
This removes the assert that the output's blending space is (non-linear)
sRGB.
Signed-off-by: Pekka Paalanen <pekka.paalanen@collabora.com>
This makes weston_color_transform object be able to express
three-channel one-dimensional look-up table transformations. They are
useful for applying EOTF and EOTF^-1 mapping, or, gamma curves. They
will also be useful in optimizing a following 3D LUT tap distribution
once support for 3D LUT is added.
The code added here translates from the lut_3x1d fill_in() interface to
a GL texture to be used with SHADER_COLOR_CURVE_LUT_3x1D for
weston_surfaces.
It demonstrates how renderer data is attached to weston_color_transform
and cached.
GL_OES_texture_float_linear is required to be able to use bilinear
texture filtering with 32-bit floating-point textures, used for the LUT.
As the size of the LUT depends on what implements it, lut_3x1d fill_in()
interface is a callback to the color management component to ask for an
arbitrary size. For GL-renderer this is not important as it can easily
realize any LUT size, but when DRM-backend wants to offload the EOTF^-1
mapping to KMS (GAMMA_LUT), the LUT size comes from KMS.
Nothing actually implements lut_3x1d fill_in() yet, that will come in a
later patch.
Signed-off-by: Pekka Paalanen <pekka.paalanen@collabora.com>
This adds shader support for using a three-channel one-dimensional
look-up table for de/encoding input colors. This operation will be useful
for applying EOTF or its inverse, in other words, gamma curves. It will
also be useful in optimizing a following 3D LUT tap distribution once
support for 3D LUT is added.
Even though called three-channel and one-dimensional, it is actually
implemented as a one-channel two-dimensional texture with four rows.
Each row corresponds to a source color channel except the fourth one is
unused. The reason for having the fourth row is to get texture
coordinates in 1/8 steps instead of 1/6 steps. 1/6 may would not be
exact in floating- or fixed-point arithmetic and might perhaps risk
unintended results from bilinear texture filtering when we want linear
filtering only in x but not in y texture coordinates. I may be paranoid.
The LUT is applied on source colors after they have been converted to
straight RGB. It cannot be applied with pre-multiplied alpha. A LUT can
be used for both applying EOTF to go from source color space to blending
color space, and EOTF^-1 to go from blending space to output
(electrical) space. However, this type of LUT cannot do color space
conversions.
For now, this feature is hardcoded to off everywhere, to be enabled in
following patches.
Signed-off-by: Pekka Paalanen <pekka.paalanen@collabora.com>
Always when supported, make the fragment shader default floating point
precision high. The medium precision is roughly like half-floats, which
can be surprisingly bad. High precision does not reach even normal
32-bit float precision (by specification), but it's better. GL ES
implementations are allowed to exceed the minimum precision requirements
given in the specification.
This is an advance attempt to avoid nasty surprises from poor shader
precision.
Signed-off-by: Pekka Paalanen <pekka.paalanen@collabora.com>
Add a new shader requirements bit input_is_premult which says whether
the texture sampling results in premultiplied alpha or not. Currently
this can be deduced fully from the shader texture variant, but in the
future there might a protocol extension to explicitly control it. Hence
the need for a new bit.
yuva2rgba() is changed to produce straight alpha always. This makes
sample_input_texture() sometimes produce straight or premultiplied
alpha. The input_is_premult bit needs to match sample_input_texture()
behavior. Doing this should save three multiplications in the shader for
straight alpha formats.
Signed-off-by: Pekka Paalanen <pekka.paalanen@collabora.com>
Found by ASan, several leaks like:
Direct leak of 48 byte(s) in 2 object(s) allocated from:
#0 0x7f35fdc9c518 in calloc (/lib/x86_64-linux-gnu/libasan.so.5+0xe9518)
#1 0x55a77d6a4c6a in zalloc ../../git/weston/include/libweston/zalloc.h:38
#2 0x55a77d6a748e in create_shm_buffer ../../git/weston/tests/weston-test-client-helper.c:459
#3 0x55a77d6a78cd in create_shm_buffer_a8r8g8b8 ../../git/weston/tests/weston-test-client-helper.c:499
#4 0x55a77d6a4145 in surface_commit_color ../../git/weston/tests/pointer-shot-test.c:89
#5 0x55a77d6a4542 in pointer_cursor_retains_committed_buffer_after_reenter ../../git/weston/tests/pointer-shot-test.c:135
#6 0x55a77d6a4207 in wrappointer_cursor_retains_committed_buffer_after_reenter ../../git/weston/tests/pointer-shot-test.c:98
#7 0x55a77d6b15c2 in run_test ../../git/weston/tests/weston-test-runner.c:162
#8 0x55a77d6b1c63 in run_case ../../git/weston/tests/weston-test-runner.c:277
#9 0x55a77d6b1a09 in for_each_test_case ../../git/weston/tests/weston-test-runner.c:235
#10 0x55a77d6b1eeb in testsuite_run ../../git/weston/tests/weston-test-runner.c:311
#11 0x7f35f9510b6b in client_thread_routine ../../git/weston/tests/weston-test.c:479
#12 0x7f35fd7a4fa2 in start_thread /build/glibc-vjB4T1/glibc-2.28/nptl/pthread_create.c:486
#13 0x7f35fd8c64ce in clone (/lib/x86_64-linux-gnu/libc.so.6+0xf94ce)
Now this test has no more leaks.
Signed-off-by: Pekka Paalanen <pekka.paalanen@collabora.com>
Fixes all the leaks reported by ASan in this test.
The manual pointer release in
pointer_timestamps_stop_after_client_releases_wl_pointer is slightly
awkward as we need to open-code a part of input_destroy() to avoid
double-freeing pointer->wl_pointer.
Signed-off-by: Pekka Paalanen <pekka.paalanen@collabora.com>
Fixes all the leaks reported by ASan in this test.
The manual keyboard release in
keyboard_timestamps_stop_after_client_releases_wl_keyboard is slightly
awkward as we need to open-code a part of input_destroy() to avoid
double-freeing keyboard->wl_keyboard.
Signed-off-by: Pekka Paalanen <pekka.paalanen@collabora.com>
Found by ASan:
Direct leak of 30 byte(s) in 1 object(s) allocated from:
#0 0x7f4dcf029810 in strdup (/lib/x86_64-linux-gnu/libasan.so.5+0x3a810)
#1 0x7f4dcefd2143 in handle_option ../../git/weston/shared/option-parser.c:56
#2 0x7f4dcefd2473 in long_option ../../git/weston/shared/option-parser.c:84
#3 0x7f4dcefd2bb6 in parse_options ../../git/weston/shared/option-parser.c:175
#4 0x7f4dcefc7b0d in wet_main ../../git/weston/compositor/main.c:3229
#5 0x5593dfa38ffd in execute_compositor ../../git/weston/tests/weston-test-fixture-compositor.c:432
#6 0x5593dfa3ca69 in weston_test_harness_execute_as_client ../../git/weston/tests/weston-test-runner.c:528
#7 0x5593dfa2e511 in fixture_setup ../../git/weston/tests/ivi-shell-app-test.c:139
#8 0x5593dfa2e596 in fixture_setup_run_ ../../git/weston/tests/ivi-shell-app-test.c:141
#9 0x5593dfa3d01e in main ../../git/weston/tests/weston-test-runner.c:661
#10 0x7f4dcec2d09a in __libc_start_main ../csu/libc-start.c:308
#11 0x5593dfa2d769 in _start (/home/pq/build/weston-meson/tests/test-ivi-shell-app+0xd769)
when running
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-ivi-shell-app
Signed-off-by: Pekka Paalanen <pekka.paalanen@collabora.com>
Fixes ASan reported leaks:
Direct leak of 88 byte(s) in 1 object(s) allocated from:
#0 0x7fcdc7382518 in calloc (/lib/x86_64-linux-gnu/libasan.so.5+0xe9518)
#1 0x7fcdc2d902f3 in zalloc ../../git/weston/include/libweston/zalloc.h:38
#2 0x7fcdc2d91cc2 in weston_desktop_xwayland_init ../../git/weston/libweston-desktop/xwayland.c:410
#3 0x7fcdc2d89aef in weston_desktop_create ../../git/weston/libweston-desktop/libweston-desktop.c:87
#4 0x7fcdc2db7300 in wet_shell_init ../../git/weston/ivi-shell/ivi-shell.c:642
#5 0x7fcdc7261de5 in wet_load_shell ../../git/weston/compositor/main.c:956
#6 0x7fcdc7272baa in wet_main ../../git/weston/compositor/main.c:3410
#7 0x55e12a669e29 in execute_compositor ../../git/weston/tests/weston-test-fixture-compositor.c:432
#8 0x55e12a66d85d in weston_test_harness_execute_as_client ../../git/weston/tests/weston-test-runner.c:528
#9 0x55e12a65dc48 in fixture_setup ../../git/weston/tests/ivi-layout-test-client.c:48
#10 0x55e12a65dcca in fixture_setup_run_ ../../git/weston/tests/ivi-layout-test-client.c:50
#11 0x55e12a66de12 in main ../../git/weston/tests/weston-test-runner.c:661
#12 0x7fcdc6ed709a in __libc_start_main ../csu/libc-start.c:308
#13 0x55e12a65d769 in _start (/home/pq/build/weston-meson/tests/test-ivi-layout-client+0xd769)
Indirect leak of 152 byte(s) in 1 object(s) allocated from:
#0 0x7fcdc7382518 in calloc (/lib/x86_64-linux-gnu/libasan.so.5+0xe9518)
#1 0x7fcdc2d89811 in zalloc ../../git/weston/include/libweston/zalloc.h:38
#2 0x7fcdc2d8992d in weston_desktop_create ../../git/weston/libweston-desktop/libweston-desktop.c:65
#3 0x7fcdc2db7300 in wet_shell_init ../../git/weston/ivi-shell/ivi-shell.c:642
#4 0x7fcdc7261de5 in wet_load_shell ../../git/weston/compositor/main.c:956
#5 0x7fcdc7272baa in wet_main ../../git/weston/compositor/main.c:3410
#6 0x55e12a669e29 in execute_compositor ../../git/weston/tests/weston-test-fixture-compositor.c:432
#7 0x55e12a66d85d in weston_test_harness_execute_as_client ../../git/weston/tests/weston-test-runner.c:528
#8 0x55e12a65dc48 in fixture_setup ../../git/weston/tests/ivi-layout-test-client.c:48
#9 0x55e12a65dcca in fixture_setup_run_ ../../git/weston/tests/ivi-layout-test-client.c:50
#10 0x55e12a66de12 in main ../../git/weston/tests/weston-test-runner.c:661
#11 0x7fcdc6ed709a in __libc_start_main ../csu/libc-start.c:308
#12 0x55e12a65d769 in _start (/home/pq/build/weston-meson/tests/test-ivi-layout-client+0xd769)
Indirect leak of 72 byte(s) in 1 object(s) allocated from:
#0 0x7fcdc7382518 in calloc (/lib/x86_64-linux-gnu/libasan.so.5+0xe9518)
#1 0x7fcdc2d8a5ae in zalloc ../../git/weston/include/libweston/zalloc.h:38
#2 0x7fcdc2d8a89e in weston_desktop_client_create ../../git/weston/libweston-desktop/client.c:108
#3 0x7fcdc2d91d2a in weston_desktop_xwayland_init ../../git/weston/libweston-desktop/xwayland.c:415
#4 0x7fcdc2d89aef in weston_desktop_create ../../git/weston/libweston-desktop/libweston-desktop.c:87
#5 0x7fcdc2db7300 in wet_shell_init ../../git/weston/ivi-shell/ivi-shell.c:642
#6 0x7fcdc7261de5 in wet_load_shell ../../git/weston/compositor/main.c:956
#7 0x7fcdc7272baa in wet_main ../../git/weston/compositor/main.c:3410
#8 0x55e12a669e29 in execute_compositor ../../git/weston/tests/weston-test-fixture-compositor.c:432
#9 0x55e12a66d85d in weston_test_harness_execute_as_client ../../git/weston/tests/weston-test-runner.c:528
#10 0x55e12a65dc48 in fixture_setup ../../git/weston/tests/ivi-layout-test-client.c:48
#11 0x55e12a65dcca in fixture_setup_run_ ../../git/weston/tests/ivi-layout-test-client.c:50
#12 0x55e12a66de12 in main ../../git/weston/tests/weston-test-runner.c:661
#13 0x7fcdc6ed709a in __libc_start_main ../csu/libc-start.c:308
#14 0x55e12a65d769 in _start (/home/pq/build/weston-meson/tests/test-ivi-layout-client+0xd769)
Signed-off-by: Pekka Paalanen <pekka.paalanen@collabora.com>
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>
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>
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>
Derek Foreman
John Good
Simon Ser
Daniel Stone
Marius Vlad
Pekka Paalanen
Chen Qi
Alvarito050506
Leandro Ribeiro