https://bugs.kde.org/show_bug.cgi?id=493433
Mark Wielaard <m...@klomp.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
Summary|Add a new fds only mode to |Add a new fds only mode to
|--track-fds |--track-fds (--modify-fds)
--- Comment #3 from Mark Wielaard <m...@klomp.org> ---
Nitpick:
Bool VG_(clo_run_cxx_freeres) = True;
UInt VG_(clo_track_fds) = 0;
+UInt VG_(clo_modify_fds) = 0;
Bool VG_(clo_show_below_main)= False;
Bool VG_(clo_keep_debuginfo) = False;
The = signs don't line up.
+ (not yet seem before) file descriptor. */
s/seem/seen/
@@ -5897,12 +5903,13 @@ PRE(sys_openat)
POST(sys_openat)
{
vg_assert(SUCCESS);
+ POST_newFd_RES;
if (!ML_(fd_allowed)(RES, "openat", tid, True)) {
VG_(close)(RES);
SET_STATUS_Failure( VKI_EMFILE );
} else {
if (VG_(clo_track_fds))
- ML_(record_fd_open_with_given_name)(tid, RES, (HChar*)(Addr)ARG2);
+ ML_(record_fd_open_with_given_name)(tid, RES, (HChar*)(Addr)ARG2);
}
}
Unnecessary (and wrong) whitespace indentation change.
+extern UInt VG_(clo_modify_fds);
Needs comment what the values are/mean.
--- /dev/null
+++ b/none/tests/track_new.stderr.exp
@@ -0,0 +1,12 @@
+File descriptor 1020 was closed already
+ Previously closed
+ at 0x........: close (in /...libc...)
+ by 0x........: main (track_new.c:11)
That (1020) seems an oddly specific fd number.
+ Originally opened
+ at 0x........: open (in /...libc...)
+ by 0x........: main (track_new.c:8)
+ at 0x........: write (in /...libc...)
+ by 0x........: __printf_buffer_flush_dprintf (in /...libc...)
+ by 0x........: __vdprintf_internal (in /...libc...)
+ by 0x........: dprintf (in /...libc...)
+ by 0x........: main (track_new.c:17)
The __ functions might be different on different glibc versions/arches?
--- /dev/null
+++ b/none/tests/track_new.stdout.exp
@@ -0,0 +1,2 @@
+got foobar.txt as: 1020
+got foobad.txt as: 1019
Again oddly specific fd numbers.
Given the new option/argument I would have expected some updates to the
./none/tests/cmdline*vgtests?
There should probably some documentation that this is against POSIX which
guarantees a new file descriptor is always the lowest possible number.
POST_newFd_RES works for those syscalls that return the new fd as result (RES)
of the syscall.
What about other syscalls/fcntls that return a new fd some other way?
grepping for record_fd_open I think I spot some syscalls missing:
sys_inotify_init, sys_inotify_init1, sys_mq_open, timerfd_create, pipe[2], ...
pipe2 is interesting since it returns 2 fds.
Should all these other syscalls also hava fd adjustments?
--
You are receiving this mail because:
You are watching all bug changes.
