]> git.ipfire.org Git - thirdparty/valgrind.git/commit
Add --modify-fds=[no|high] option
authorAlexandra Hájková <ahajkova@redhat.com>
Wed, 20 Nov 2024 17:00:47 +0000 (12:00 -0500)
committerMark Wielaard <mark@klomp.org>
Wed, 16 Apr 2025 14:39:06 +0000 (16:39 +0200)
commit4c78562419ce2c9b6a21a3c9dfc9bf90638c9649
tree9c5c54b5ba3e9ded8f0d34796584e52def3b2574
parent3149c9ff090c2290309419b09708a9b80481ede3
Add --modify-fds=[no|high] option

Normally a newly recreated file descriptor gets the lowest number
available. This might cause old file descriptor numbers to be reused
and hides bad file descriptor accesses (because the old number is
new again).

When enabled, when the program opens a new file descriptor,
the highest available file descriptor is returned instead of the
lowest one.

Add the none/tests/track_new.stderr.exp test to test this new option.

Adjust none/tests/filter_fdleak to filter the track_new.vgtest,
removing some internal glibc functions from the backtraces and remove
symbol versioning. The output of the use_after_close test also had to
be adjusted. Also adjust the none/tests/cmdline1 and
none/tests/cmdline2 output as the new --modify-fds=no|high is
displayed.

https://bugs.kde.org/show_bug.cgi?id=493433
17 files changed:
coregrind/m_main.c
coregrind/m_options.c
coregrind/m_syswrap/priv_syswrap-generic.h
coregrind/m_syswrap/syswrap-generic.c
coregrind/m_syswrap/syswrap-linux.c
docs/xml/manual-core.xml
include/pub_tool_options.h
none/tests/Makefile.am
none/tests/cmdline1.stdout.exp
none/tests/cmdline2.stdout.exp
none/tests/filter_fdleak
none/tests/track_new.c [new file with mode: 0644]
none/tests/track_new.stderr.exp [new file with mode: 0644]
none/tests/track_new.stderr.exp.debian32 [new file with mode: 0644]
none/tests/track_new.stdout.exp [new file with mode: 0644]
none/tests/track_new.vgtest [new file with mode: 0644]
none/tests/use_after_close.stderr.exp