On 30/03/2024 08:31:10+0000, Richard Purdie wrote:
> On Thu, 2024-03-28 at 22:50 -0700, Khem Raj wrote:
> > These tests have been fixed in prior to 3.22 release
> >
> > Signed-off-by: Khem Raj <[email protected]>
> > ---
> > meta/recipes-devtools/valgrind/valgrind_3.22.0.bb | 6 ------
> > 1 file changed, 6 deletions(-)
>
> https://autobuilder.yoctoproject.org/typhoon/#/builders/81/builds/6452/steps/13/logs/stdio
> https://autobuilder.yoctoproject.org/typhoon/#/builders/82/builds/6257/steps/13/logs/stdio
>
> Failed ptests:
> {'valgrind': ['memcheck/tests/leak_cpp_interior',
> 'drd/tests/pth_mutex_signal']}
>
> so they're not fixed.
>
Failed test details...
drd/tests/pth_mutex_signal.stderr.diff
************
--- pth_mutex_signal.stderr.exp
+++ pth_mutex_signal.stderr.out
@@ -2,14 +2,34 @@
mutex initialized
thread attributes initialized
thread created
-sleeping
-signalling
-sleeping
-nullHandler running
-unlocking
-contender locked mutex
-contender unlocking mutex
-contender unlocked mutex
-joining thread
-ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 0 from 0)
+Process terminating with default action of signal 6 (SIGABRT)
+ at 0x........: __pthread_kill_implementation (pthread_kill.c:?)
+ by 0x........: raise (raise.c:?)
+ by 0x........: abort (abort.c:?)
+ by 0x........: __libc_message_impl.cold (libc_fatal.c:?)
+ by 0x........: __libc_fatal (libc_fatal.c:?)
+ by 0x........: futex_fatal_error (futex-internal.h:87)
+ by 0x........: __futex_lock_pi64 (futex-internal.c:203)
+ by 0x........: __pthread_mutex_lock_full (pthread_mutex_lock.c:?)
+ by 0x........: pthread_mutex_lock (drd_pthread_intercepts.c:?)
+ by 0x........: contender_start (pth_mutex_signal.c:?)
+ by 0x........: vgDrd_thread_wrapper (drd_pthread_intercepts.c:?)
+ by 0x........: start_thread
+ by 0x........: clone (in /...libc...)
+Thread 2:
+Destroying locked mutex: mutex 0x........, recursion count 1, owner 1.
+ at 0x........: __libc_write (write.c:?)
+ by 0x........: write (write.c:?)
+ by 0x........: _IO_file_write@@GLIBC_2.2.5 (fileops.c:?)
+ by 0x........: new_do_write (fileops.c:?)
+ by 0x........: _IO_new_file_xsputn (fileops.c:?)
+ by 0x........: _IO_file_xsputn@@GLIBC_2.2.5 (fileops.c:?)
+ by 0x........: fwrite (iofwrite.c:?)
+ by 0x........: main (pth_mutex_signal.c:?)
+mutex 0x........ was first observed at:
+ at 0x........: pthread_mutex_init (drd_pthread_intercepts.c:?)
+ by 0x........: main (pth_mutex_signal.c:?)
+
+
+ERROR SUMMARY: 1 errors from 1 contexts (suppressed: 0 from 0)
Failed test details...
memcheck/tests/leak_cpp_interior.stderr.diff
************
--- leak_cpp_interior.stderr.exp
+++ leak_cpp_interior.stderr.out
@@ -1,4 +1,7 @@
+Conditional jump or move depends on uninitialised value(s)
+ ...
+
valgrind output will go to log
VALGRIND_DO_LEAK_CHECK
x bytes in 1 blocks are definitely lost in loss record ... of ...
@@ -35,10 +38,10 @@
LEAK SUMMARY:
definitely lost: x (+0) bytes in 1 (+0) blocks
indirectly lost: 0 (+0) bytes in 0 (+0) blocks
- possibly lost: x (-x) bytes in 5 (+1) blocks
- still reachable: x (+x) bytes in 3 (-1) blocks
+ possibly lost: x (-x) bytes in 4 (+0) blocks
+ still reachable: x (+x) bytes in 4 (+0) blocks
of which reachable via heuristic:
- newarray : x (+x) bytes in 1 (+1) blocks
+ newarray : x (+x) bytes in 2 (+2) blocks
multipleinheritance: 0 (-x) bytes in 0 (-2) blocks
To see details of leaked memory, give 'full' arg to leak_check
@@ -46,11 +49,11 @@
LEAK SUMMARY:
definitely lost: x (+0) bytes in 1 (+0) blocks
indirectly lost: 0 (+0) bytes in 0 (+0) blocks
- possibly lost: x (-x) bytes in 5 (+0) blocks
- still reachable: x (+x) bytes in 3 (+0) blocks
+ possibly lost: x (+x) bytes in 5 (+1) blocks
+ still reachable: x (-x) bytes in 3 (-1) blocks
of which reachable via heuristic:
length64 : x (+x) bytes in 1 (+1) blocks
- newarray : 0 (-x) bytes in 0 (-1) blocks
+ newarray : 0 (-x) bytes in 0 (-2) blocks
To see details of leaked memory, give 'full' arg to leak_check
leak_check summary heuristics stdstring
@@ -133,5 +136,6 @@
All heap blocks were freed -- no leaks are possible
+Use --track-origins=yes to see where uninitialised values come from
--
Alexandre Belloni, co-owner and COO, Bootlin
Embedded Linux and Kernel engineering
https://bootlin.com
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#197656):
https://lists.openembedded.org/g/openembedded-core/message/197656
Mute This Topic: https://lists.openembedded.org/mt/105211846/21656
Group Owner: [email protected]
Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub
[[email protected]]
-=-=-=-=-=-=-=-=-=-=-=-
