On Wed, Jun 30, 2021 at 05:49:41PM +0200, Martin Kletzander wrote: > On Wed, Jun 30, 2021 at 05:11:45PM +0200, Martin Kletzander wrote: > >- Both openSUSE builds are failing to run check-valgrind and it looks > > like it might be unrelated to libnbd, although it would be nice for > > someone else to confirm that. For now I have disabled check-valgrind > > on those platforms in my branch. > > > >- Similarly to openSUSE Ubuntu 20.04 fails in valgrind tests, but > > somewhere down the GnuTLS rabbit hole, which I presume is unrelated > > too, so I disabled check-valgrind on that one as well. > > > >I will send the patches once they are cleaned up, but I wanted to let > >everyone know what the current status is because eliminating all random > >issues is essential to properly consuming CI results. > > > > I forgot to mention the pipeline with all the errors (before the > check-valgrind skips) is here: > > https://gitlab.com/nertpinx/libnbd/-/pipelines/329661257
This one: https://gitlab.com/nertpinx/libnbd/-/jobs/1389193576 FAIL: dlopen The actual failure is this memory leak: ==17953== 4,096 bytes in 1 blocks are still reachable in loss record 4 of 4 ==17953== at 0x4C2E2DF: malloc (in /usr/lib64/valgrind/vgpreload_memcheck-amd 64-linux.so) ==17953== by 0x52CFEFB: _IO_file_doallocate (in /lib64/libc-2.26.so) ==17953== by 0x52DF0A8: _IO_doallocbuf (in /lib64/libc-2.26.so) ==17953== by 0x52DDC67: _IO_file_overflow@@GLIBC_2.2.5 (in /lib64/libc-2.26.so) ==17953== by 0x52DCCDE: _IO_file_xsputn@@GLIBC_2.2.5 (in /lib64/libc-2.26.so) ==17953== by 0x52AFCBA: vfprintf (in /lib64/libc-2.26.so) ==17953== by 0x52B88D5: printf (in /lib64/libc-2.26.so) ==17953== by 0x400ACE: thread_start (dlopen.c:117) ==17953== by 0x50474F8: start_thread (in /lib64/libpthread-2.26.so) ==17953== by 0x5359ECE: clone (in /lib64/libc-2.26.so) It looks benign so the fix would be to add a suppression to libnbd.git/valgrind/glibc.suppressions, probably something like this (untested): { glibc_6 Memcheck:Leak fun:malloc fun:_IO_file_doallocate } --- https://gitlab.com/nertpinx/libnbd/-/jobs/1389193577 This has dozens of failures in the OCaml tests. Most but not all of them are like this: ==20650== 16 bytes in 1 blocks are still reachable in loss record 1 of 38 ==20650== at 0x483E7B5: malloc (in /usr/libexec/valgrind/vgpreload_memcheck-amd64-linux.so) ==20650== by 0x47239C: caml_stat_alloc_noexc (memory.c:818) ==20650== by 0x47239C: caml_stat_alloc (memory.c:840) ==20650== by 0x485BCD: caml_register_custom_operations (custom.c:121) ==20650== by 0x485BCD: caml_init_custom_operations (custom.c:163) ==20650== by 0x48BE46: caml_startup_common (startup_nat.c:132) ==20650== by 0x48C05A: caml_startup_exn (startup_nat.c:163) ==20650== by 0x48C05A: caml_startup (startup_nat.c:168) ==20650== by 0x48C05A: caml_main (startup_nat.c:175) ==20650== by 0x430CEB: main (main.c:41) There's already a suppression for something similar (ocaml_heap_leak_5), but it probably needs to be adjusted slightly for the different OCaml compiler being used by SUSE. This leads us to the general problem with attempting to run valgrind tests across lots of different distros: We're going to be forever chasing minor differences in versions of supporting software (glibc, OCaml, gnutls, etc.) --- https://gitlab.com/nertpinx/libnbd/-/jobs/1389193579 Multiple memory leaks in getaddrinfo. I'm going to guess that Ubuntu uses a different NSS configuration from Fedora and so NSS plugin they're using is leaky. I think a suppression covering getaddrinfo -> ... -> malloc would be too broad since it would suppress valid errors eg. where we didn't call freeaddrinfo on all paths. Fun ... Rich. -- Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones Read my programming and virtualization blog: http://rwmj.wordpress.com virt-df lists disk usage of guests without needing to install any software inside the virtual machine. Supports Linux and Windows. http://people.redhat.com/~rjones/virt-df/ _______________________________________________ Libguestfs mailing list Libguestfs@redhat.com https://listman.redhat.com/mailman/listinfo/libguestfs
