Version: valgrind-3.10.1 When file descriptor tracking is enabled (--track-fds=yes), and Valgrind does detect a file descriptor leak, it seems to me that it should return the error exit code set with --error-exitcode, but it doesn't, it returns zero.
Hi Valgrind architects, I have implemented a fix for this bug / feature request - my patch generates proper errors using VG_(unique_error). These can then influence the error count and exit code, and can also be suppressed. Since "track-fds" is part of coregrind, this involves resurrecting CoreErrors and adding functions for the error parts of the tool interface to the core. These new functions redirect CoreErrors to the correct part of the core. i.e. Adding to m_errormgr.c: core_before_pp_Error() core_get_error_name() core_update_extra() core_pp_Error() core_eq_Error() core_recognised_suppression() core_read_extra_suppression_info() core_get_extra_suppression_info() These functions then redirect track-fds errors to functions in syswrap-generic.c Is this scheme acceptable? I will attach a patch for this shortly.
Just checked that this is still an issue with 3.21: $ cat /tmp/leak.c && gcc -g -o /tmp/leak.exe /tmp/leak.c && valgrind --version && valgrind --quiet --error-exitcode=2 --track-fds=yes /tmp/leak.exe ; echo $? #include <stdio.h> int main() { fopen("/tmp/leak.c", "r"); } valgrind-3.21.0 ==1538349== FILE DESCRIPTORS: 4 open (3 std) at exit. ==1538349== Open file descriptor 3: /tmp/leak.c ==1538349== at 0x4967F35: open (open64.c:41) ==1538349== by 0x48F0705: _IO_file_open (fileops.c:188) ==1538349== by 0x48F08CA: _IO_file_fopen@@GLIBC_2.2.5 (fileops.c:280) ==1538349== by 0x48E4BCC: __fopen_internal (iofopen.c:75) ==1538349== by 0x401138: main (leak.c:2) ==1538349== ==1538349== 0
(In reply to Evan Hunter from comment #1) > Hi Valgrind architects, > > I have implemented a fix for this bug / feature request - my patch generates > proper errors using VG_(unique_error). > These can then influence the error count and exit code, and can also be > suppressed. > > Since "track-fds" is part of coregrind, this involves resurrecting > CoreErrors > and adding functions for the error parts of the tool interface to the core. > These new functions redirect CoreErrors to the correct part of the core. > i.e. Adding to m_errormgr.c: > core_before_pp_Error() > core_get_error_name() > core_update_extra() > core_pp_Error() > core_eq_Error() > core_recognised_suppression() > core_read_extra_suppression_info() > core_get_extra_suppression_info() > > These functions then redirect track-fds errors to functions in > syswrap-generic.c > > Is this scheme acceptable? > > I will attach a patch for this shortly. I think it's a good idea. Do you happen to still have a patch regarding this issue? Thank you, Alexandra
bug #328563 has an attachment that implements this
commit 34e9e4957ada1ba0a51266faee23f61724935fcb Author: Mark Wielaard <mark@klomp.org> Date: Wed Mar 20 01:44:23 2024 -0400 Add core errors and use them to implement file descriptor tracker All the tool error callbacks now have a core error equivalent. core errors are negative (while tool errors are positive). There are two new ones for tracking issues with file descriptors. FdBadClose (-2) and FdNotClosed (-3). Add following core error functions with delegates to file descriptor specific functions (implemented in syswrap-generic): - core_eq_Error (fd_eq_Error) Compares core errors to detect duplicates - core_before_pp_Error (fd_before_pp_Error) Currently prints nothing for known core errors and exists with FATAL for unknown core errors - core_pp_Error (fd_pp_Error) For FdBadClose prints the backtraces for the file descriptor was opened, where it was originally closed and where it was closed again. For FdNotClosed prints where the file descriptor was opened. - core_update_extra (fd_update_extra) Returns the size of the BadCloseExtra or FdNotClosedExtra struct which data needs to be saved (the fd number, pathname/description and previous backtraces). We now accept the error (ExeContext) where to be NULL. This is necessary for reporting not closed file descriptors when the descriptor is inherited from the parent (so wasn't actually created and doesn't have a 'where' in the current process code). All the testcases still pass since the (stderr) output is the same. But now they count as "real" errors. And so --error-exitcode does now also work for file descriptor errors or leaks. https://bugs.kde.org/show_bug.cgi?id=362680 Co-authored-by: Alexandra Hájková <ahajkova@redhat.com>
*** Bug 482358 has been marked as a duplicate of this bug. ***