I ran ./readprofile --help directly and it seems there is a memory leak there:

=================================================================
==24788==ERROR: LeakSanitizer: detected memory leaks
Direct leak of 32 byte(s) in 1 object(s) allocated from:
    #0 0x4c2923 in malloc /tmp/final/llvm.src/projects/compiler-rt/lib/asan/asan_malloc_linux.cc:146:3
    #1 0x4f397b in xmalloc /home/travis/build/karelzak/util-linux/./include/xalloc.h:36:14
    #2 0x4f397b in boot_uname_r_str /home/travis/build/karelzak/util-linux/sys-utils/readprofile.c:94
    #3 0x4f354a in usage /home/travis/build/karelzak/util-linux/sys-utils/readprofile.c:113:62
    #4 0x7f4c1375fb96 in __libc_start_main (/lib/x86_64-linux-gnu/libc.so.6+0x21b96)
SUMMARY: AddressSanitizer: 32 byte(s) leaked in 1 allocation(s).

Note that we do not do free-before-exit. It's pretty common to call exit() or err() without care about the previous allocation. This is expected and fine.

The memory leak is mostly important in libs and library sample/test programs. It means you have to be careful about asan or valgrind results interpretation.

It's pretty common to call exit() or err() without care about the previous allocation

I agree that it's common in general but once projects start running their testsuites under ASan it is usually much easier to fix memory leaks instead of trying to figure out how to ignore some of them.

It means you have to be careful about asan or valgrind results interpretation.

Given that in #1075 I simply ran all the tests on Ubuntu Bionic without changing anything it looks like make_checkusage isn't exactly compatible with ASan. I can add detect_leaks=0 there but I think it's a slippery slope.

Well, we have in our hands what binaries will be probed for memory-leak in the test suite and I don't think we have to apply the same compile flags to all stuff :-) I really want to avoid storm of free() patches just to keep CI happy.

The question is if make_checkusage() makes sense -- IMHO things from tools/ are mostly designed for manual execution. For serious automatic tests it would be better to have something robust in tests/.

It would be nice to clean up it and select what we need.

OK, closing.