Home > OS >  Valgrind exitcode = 0 regardles on errors with --error-exitcode set to nonzero
Valgrind exitcode = 0 regardles on errors with --error-exitcode set to nonzero

Time:03-03

I am using valgrind 3.15 and 3.17. I am running valgrind in a job in a gitlab-CI pipeline and I want the pipeline to fail, if there are any leaks or memory problems.

I can show it on ls, which is leaky:

$ valgrind --leak-check=full --show-leak-kinds=all --track-origins=yes --error-exitcode=1 ls && echo no failure
==535364== Memcheck, a memory error detector
==535364== Copyright (C) 2002-2017, and GNU GPL'd, by Julian Seward et al.
==535364== Using Valgrind-3.17.0 and LibVEX; rerun with -h for copyright info
==535364== Command: ls
==535364== 
25_s1.pcap.log
==535364== 
==535364== HEAP SUMMARY:
==535364==     in use at exit: 20,351 bytes in 8 blocks
==535364==   total heap usage: 45 allocs, 37 frees, 59,906 bytes allocated
==535364== 
==535364== 15 bytes in 1 blocks are still reachable in loss record 1 of 8
==535364==    at 0x4843839: malloc (in /usr/libexec/valgrind/vgpreload_memcheck-amd64-linux.so)
==535364==    by 0x11F4FE: ??? (in /usr/bin/ls)
==535364==    by 0x1136D4: ??? (in /usr/bin/ls)
==535364==    by 0x11586E: ??? (in /usr/bin/ls)
==535364==    by 0x10D434: ??? (in /usr/bin/ls)
==535364==    by 0x48E2FCF: __libc_start_call_main (libc_start_call_main.h:58)
==535364==    by 0x48E307C: __libc_start_main@@GLIBC_2.34 (libc-start.c:409)
==535364==    by 0x10E83D: ??? (in /usr/bin/ls)
==535364==    by 0x1FFEFFFEE7: ???
==535364==    by 0x1B: ???
==535364== 
==535364== 24 bytes in 1 blocks are still reachable in loss record 2 of 8
==535364==    at 0x4843839: malloc (in /usr/libexec/valgrind/vgpreload_memcheck-amd64-linux.so)
==535364==    by 0x11F37C: ??? (in /usr/bin/ls)
==535364==    by 0x110AF8: ??? (in /usr/bin/ls)
==535364==    by 0x1156B8: ??? (in /usr/bin/ls)
==535364==    by 0x10D434: ??? (in /usr/bin/ls)
==535364==    by 0x48E2FCF: __libc_start_call_main (libc_start_call_main.h:58)
==535364==    by 0x48E307C: __libc_start_main@@GLIBC_2.34 (libc-start.c:409)
==535364==    by 0x10E83D: ??? (in /usr/bin/ls)
==535364==    by 0x1FFEFFFEE7: ???
==535364==    by 0x1B: ???
==535364== 
==535364== 24 bytes in 1 blocks are still reachable in loss record 3 of 8
==535364==    at 0x4843839: malloc (in /usr/libexec/valgrind/vgpreload_memcheck-amd64-linux.so)
==535364==    by 0x11F37C: ??? (in /usr/bin/ls)
==535364==    by 0x110765: ??? (in /usr/bin/ls)
==535364==    by 0x11519F: ??? (in /usr/bin/ls)
==535364==    by 0x10D434: ??? (in /usr/bin/ls)
==535364==    by 0x48E2FCF: __libc_start_call_main (libc_start_call_main.h:58)
==535364==    by 0x48E307C: __libc_start_main@@GLIBC_2.34 (libc-start.c:409)
==535364==    by 0x10E83D: ??? (in /usr/bin/ls)
==535364==    by 0x1FFEFFFEE7: ???
==535364==    by 0x1B: ???
==535364== 
==535364== 48 bytes in 1 blocks are still reachable in loss record 4 of 8
==535364==    at 0x4843749: malloc (in /usr/libexec/valgrind/vgpreload_memcheck-amd64-linux.so)
==535364==    by 0x11F3A9: ??? (in /usr/bin/ls)
==535364==    by 0x110944: ??? (in /usr/bin/ls)
==535364==    by 0x11519F: ??? (in /usr/bin/ls)
==535364==    by 0x10D434: ??? (in /usr/bin/ls)
==535364==    by 0x48E2FCF: __libc_start_call_main (libc_start_call_main.h:58)
==535364==    by 0x48E307C: __libc_start_main@@GLIBC_2.34 (libc-start.c:409)
==535364==    by 0x10E83D: ??? (in /usr/bin/ls)
==535364==    by 0x1FFEFFFEE7: ???
==535364==    by 0x1B: ???
==535364== 
==535364== 56 bytes in 1 blocks are still reachable in loss record 5 of 8
==535364==    at 0x4843839: malloc (in /usr/libexec/valgrind/vgpreload_memcheck-amd64-linux.so)
==535364==    by 0x11F4B8: ??? (in /usr/bin/ls)
==535364==    by 0x11DD00: ??? (in /usr/bin/ls)
==535364==    by 0x10D201: ??? (in /usr/bin/ls)
==535364==    by 0x48E2FCF: __libc_start_call_main (libc_start_call_main.h:58)
==535364==    by 0x48E307C: __libc_start_main@@GLIBC_2.34 (libc-start.c:409)
==535364==    by 0x10E83D: ??? (in /usr/bin/ls)
==535364==    by 0x1FFEFFFEE7: ???
==535364==    by 0x1B: ???
==535364== 
==535364== 56 bytes in 1 blocks are still reachable in loss record 6 of 8
==535364==    at 0x4843839: malloc (in /usr/libexec/valgrind/vgpreload_memcheck-amd64-linux.so)
==535364==    by 0x11F4B8: ??? (in /usr/bin/ls)
==535364==    by 0x11DD00: ??? (in /usr/bin/ls)
==535364==    by 0x10D25D: ??? (in /usr/bin/ls)
==535364==    by 0x48E2FCF: __libc_start_call_main (libc_start_call_main.h:58)
==535364==    by 0x48E307C: __libc_start_main@@GLIBC_2.34 (libc-start.c:409)
==535364==    by 0x10E83D: ??? (in /usr/bin/ls)
==535364==    by 0x1FFEFFFEE7: ???
==535364==    by 0x1B: ???
==535364== 
==535364== 128 bytes in 1 blocks are still reachable in loss record 7 of 8
==535364==    at 0x4843839: malloc (in /usr/libexec/valgrind/vgpreload_memcheck-amd64-linux.so)
==535364==    by 0x1203C9: ??? (in /usr/bin/ls)
==535364==    by 0x10D355: ??? (in /usr/bin/ls)
==535364==    by 0x48E2FCF: __libc_start_call_main (libc_start_call_main.h:58)
==535364==    by 0x48E307C: __libc_start_main@@GLIBC_2.34 (libc-start.c:409)
==535364==    by 0x10E83D: ??? (in /usr/bin/ls)
==535364==    by 0x1FFEFFFEE7: ???
==535364==    by 0x1B: ???
==535364== 
==535364== 20,000 bytes in 1 blocks are still reachable in loss record 8 of 8
==535364==    at 0x4843839: malloc (in /usr/libexec/valgrind/vgpreload_memcheck-amd64-linux.so)
==535364==    by 0x11F37C: ??? (in /usr/bin/ls)
==535364==    by 0x10D3C6: ??? (in /usr/bin/ls)
==535364==    by 0x48E2FCF: __libc_start_call_main (libc_start_call_main.h:58)
==535364==    by 0x48E307C: __libc_start_main@@GLIBC_2.34 (libc-start.c:409)
==535364==    by 0x10E83D: ??? (in /usr/bin/ls)
==535364==    by 0x1FFEFFFEE7: ???
==535364==    by 0x1B: ???
==535364== 
==535364== LEAK SUMMARY:
==535364==    definitely lost: 0 bytes in 0 blocks
==535364==    indirectly lost: 0 bytes in 0 blocks
==535364==      possibly lost: 0 bytes in 0 blocks
==535364==    still reachable: 20,351 bytes in 8 blocks
==535364==         suppressed: 0 bytes in 0 blocks
==535364== 
==535364== For lists of detected and suppressed errors, rerun with: -s
==535364== ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 0 from 0)
no failure

What am I doing wrong? Do I miss any configuration? Does it have any hidden rule? (like the leaks should be shown, but they are).

CodePudding user response:

By default, only definite and possible leaks are considered as errors. You can use e.g. --errors-for-leak-kinds=all to have all leak kinds considered as errors:

    --errors-for-leak-kinds=kind1,kind2,..  which leak kinds are errors?
                                        [definite,possible]
    where kind is one of:
      definite indirect possible reachable all none
  • Related