yeah drop it for now. I need to check x86 results with gcc On Sun, Mar 31, 2024 at 1:24 AM Alexandre Belloni <[email protected]> wrote: > > 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 (#197657): https://lists.openembedded.org/g/openembedded-core/message/197657 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]] -=-=-=-=-=-=-=-=-=-=-=-
