On Sat, Jul 24, 2021 at 06:53:21PM +0200, Robert-André Mauchin wrote: > Hi, > > Following the mass rebuild, the package utox stopped building on s390x. > The following test is failing, with a message regarding a memory leak: > > > + /usr/bin/ctest --output-on-failure --force-new-ctest-process -j3 > Test project /builddir/build/BUILD/uTox-0.18.1/redhat-linux-build > Start 1: test_chatlog > Start 2: test_chrono > 1/2 Test #1: test_chatlog ..................... Passed 0.01 sec > 2/2 Test #2: test_chrono ......................***Failed 0.15 sec > Running suite(s): Chrono > ================================================================= > ==2406587==ERROR: LeakSanitizer: detected memory leaks > Direct leak of 24 byte(s) in 1 object(s) allocated from: > #0 0x3ff9e73034d in __interceptor_malloc (/lib64/libasan.so.6+0xb034d) > #1 0x3ff9e584945 in emalloc (/lib64/libcheck.so.0+0x4945) > Indirect leak of 8 byte(s) in 1 object(s) allocated from: > #0 0x3ff9e73034d in __interceptor_malloc (/lib64/libasan.so.6+0xb034d) > #1 0x3ff9e584945 in emalloc (/lib64/libcheck.so.0+0x4945) > SUMMARY: AddressSanitizer: 32 byte(s) leaked in 2 allocation(s). > ================================================================= > ==2406590==ERROR: LeakSanitizer: detected memory leaks > Direct leak of 24 byte(s) in 1 object(s) allocated from: > #0 0x3ff9e73034d in __interceptor_malloc (/lib64/libasan.so.6+0xb034d) > #1 0x3ff9e584945 in emalloc (/lib64/libcheck.so.0+0x4945) > Indirect leak of 8 byte(s) in 1 object(s) allocated from: > #0 0x3ff9e73034d in __interceptor_malloc (/lib64/libasan.so.6+0xb034d) > #1 0x3ff9e584945 in emalloc (/lib64/libcheck.so.0+0x4945) > SUMMARY: AddressSanitizer: 32 byte(s) leaked in 2 allocation(s). > 0%: Checks: 2, Failures: 0, Errors: 2 > > What I am not sure about is if the problem comes from utox itself, or if this > is an issue with libcheck or libasan? > Can someone provide me with some input? I'm surprised it's using ASAN on a downstream build. Looks like this is something upstream have enabled by default: https://github.com/uTox/uTox/blob/ce4b44a10b5a9866f4be852b8dcbcb264ab6cd01/CMakeLists.txt#L71 Don't get me wrong here - I love valgrind, ASAN etc. But we only use them on upstream developer machines and in upstream CI. There's just too much potential for an environmental change (like a small change in a dependent library, or an unusual arch) to break the downstream build. I'd suggest changing the cmake line to turn ASAN off -- the bug above should "go away" -- and file an issue upstream to let them know there's a memory leak on s390x. (s390x is the only big endian arch which might be relevant.) Rich. -- Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones Read my programming and virtualization blog: http://rwmj.wordpress.com virt-top is 'top' for virtual machines. Tiny program with many powerful monitoring features, net stats, disk stats, logging, etc. http://people.redhat.com/~rjones/virt-top _______________________________________________ devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@xxxxxxxxxxxxxxxxxxxxxxx Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
