Commit graph

4 commits

Author SHA1 Message Date
Jeppe Odgaard f74f309ec7 valgrind: Update POSIX soc no cpu cleanup suppression
Add `possible` to match-leak-kinds to prevent false positives caused by
POSIX soc no cpu cleanup.

The leak can be reproduced by adding CONFIG_NETWORKING=y to
tests/lib/cpp/libcxx/prj.conf and run twister:
twister -p native_sim -s tests/lib/cpp/libcxx/cpp.libcxx.host
--enable-valgrind

Signed-off-by: Jeppe Odgaard <jeppe.odgaard@prevas.dk>
2023-11-29 15:33:49 +01:00
Alberto Escolar Piedras 04a16f21e4 valgrind: Update suppression file to align with updated POSIX arch
Things have moved around so we need to update the
suppression file so the callstack and types of
leaks valgrind reports still match.

Signed-off-by: Alberto Escolar Piedras <alberto.escolar.piedras@nordicsemi.no>
2023-07-05 07:01:19 -04:00
Alberto Escolar Piedras 2092645736 lvgl: Suppress memory leak errors detected by valgrind
The lvgl library is configured in some tests to use
the libC malloc to allocate heap. In native_posix this
ends up in the underlying OS heap, which cannot be safely
freed in general when the program finnishes, and
ends up being reported by valgrind as leaked on exit. See
https://github.com/zephyrproject-rtos/zephyr/pull/18471
for a longer discussion.

Instead of trying to fix the leak, let's just accept it
but suppress the errors so it does not confuse other
developers

Signed-off-by: Alberto Escolar Piedras <alpi@oticon.com>
2019-10-21 12:26:35 -07:00
Alberto Escolar Piedras ace7bf9508 valgrind: Add error supression file for POSIX arch
Added a valgrind error supression file which can be used when
running in the POSIX arch.

So far we are supressing 2 types of errors:
* One very normal in glibc, which will be triggered in the nrf52_bsim
* 2 due to the posix arch prioritizing terminating fast over terminating
cleanly. The posix arch, when posix_core_clean_up() is called, will
pthread_cancel all Zephyr threads. But it will NOT wait for them to
finnish, in case any of them was hung or there is any other problem
which would prevent it. Therefore, depending on the execution, some
times the threads will be still lingering when the main thread exits
Somethign similar applies to posix_soc_clean_up().
These 2 are not errors, but conscious choices => Therefore we
supress them

Signed-off-by: Alberto Escolar Piedras <alpi@oticon.com>
2018-12-21 21:07:18 +01:00