New --track-fds=new option expected behaviour

Alexandra Petlanova Hajkova <[email protected]> Thu, 19 Dec 2024 13:39:52 +0100
Newsgroups gmane.comp.debugging.valgrind
Message-ID <CAJVr-EPQHAw6=pDNwk-gdBGjKsP783uYDsT9M=AoPM2POzctbA@mail.gmail.com>
--===============7027873832459098512==
Content-Type: multipart/alternative; boundary="000000000000df1c1006299ee7a2"

--000000000000df1c1006299ee7a2
Content-Type: text/plain; charset="UTF-8"

Hi,

I'm trying to add a new option for the --track-fds.
https://bugs.kde.org/show_bug.cgi?id=493433

Normally a newly recreated file descriptor gets the lowest available
number.
This might cause old file descriptor numbers to be reused and hide bad file
descriptor accesses (because the old number is new again). When using
--track-fds=new, the highest available file descriptor will be returned
opposed
to the lowest.

The question is, how should the new 'new' option work with the other
track-fds
options. --track-fds=yes will show still opened file descriptors excluding
stdin/out/err,
while --track-fds=all will show all the open fds, including the standard
ones.

I think, when --track-fds=new is specified, what's expected is only
returning the
highest available fd instead of the lowest available one. This means, if
you also
want to track file descriptors, you should use --track-fds=new,yes. But I'm
not
sure how to deal with 'all' here. I think it's not right 'new' should be
enabled
in a case of --track-fds=all. I propose to have 'new' as a completely
separate option.
This means, if I want to track *all* the opened file descriptors (including
the standard ones)
and also to be getting the highest file descriptors available when
opening/creating them, I'll
need to use --track-fds=new,all.

The other question is, how should the new option be called? Is "new" a good
name for it? Other options could be --track-fds=high or even
--track-fds=random.

Another option that should be added is "bad".
https://bugs.kde.org/show_bug.cgi?id=493434
Currently --track-fds=yes or --track-fds=all report both bad usage and
never closed file
descriptors. Sometimes users are only interested in bad file descriptor
usage errors, but
don't care about never close file descriptors.  Instead of making them
create suppressions
 for the never closed file descriptors we could have an --track-fds=bad mod
that only reports
 errors on bad usage. I think the "bad" option should also be independent
of "all" in the
same fashion I proposed "new" to be.

Another possibility would be to to keep --track-fds=[yes,no,all] and add
new --track-bad-fds=yes,
--track-leaky-fds=yes and --track-high-fds=yes.

I'm open to any suggestions.

Thank you,
Alexandra

--000000000000df1c1006299ee7a2
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><div>Hi,</div><div><font size=3D"2"><br></font></div><div>=
<font size=3D"2">I&#39;m trying to add a new option for the --track-fds. <b=
r></font></div><div><font size=3D"2"><a href=3D"https://bugs.kde.org/show_b=
ug.cgi?id=3D493433" target=3D"_blank">https://bugs.kde.org/show_bug.cgi?id=
=3D493433</a></font></div><div><font size=3D"2"><br></font></div><div><font=
 size=3D"2">Normally a newly recreated file descriptor gets the lowest avai=
lable number.=C2=A0</font></div><div><font size=3D"2">This might cause old =
file descriptor numbers to be reused and hide bad file=C2=A0</font></div><d=
iv><font size=3D"2">descriptor accesses (because the old number is new agai=
n). When using</font></div><div><font size=3D"2">--track-fds=3Dnew, the hig=
hest available file descriptor will be returned opposed</font></div><div><f=
ont size=3D"2">to the lowest.</font></div><div><font size=3D"2"><br></font>=
</div><div><font size=3D"2">The question is, how should the new &#39;new&#3=
9; option work with the other track-fds</font></div><div><font size=3D"2">o=
ptions. </font>--track-fds=3Dyes will show still opened file descriptors ex=
cluding stdin/out/err,</div><div>while --track-fds=3Dall will show all the =
open fds, including the standard ones.</div><div><br></div><div>I think, wh=
en --track-fds=3Dnew is specified, what&#39;s expected is only returning th=
e <br></div><div>highest available fd instead of the lowest available one. =
This means, if you also</div><div>want to track file descriptors, you shoul=
d use --track-fds=3Dnew,yes. But I&#39;m not</div><div>sure how to deal wit=
h &#39;all&#39; here. I think it&#39;s not right &#39;new&#39; should be en=
abled <br></div><div>in a case of --track-fds=3Dall. I propose to have &#39=
;new&#39; as a completely separate option.</div><div>This means, if I want =
to track *all* the opened file descriptors (including the standard ones)</d=
iv><div>and also to be getting the highest file descriptors available when =
opening/creating them, I&#39;ll</div><div>need to use --track-fds=3Dnew,all=
.</div><div><br></div><div>The other question is, how should the new option=
 be called? Is &quot;new&quot; a good <br></div><div>name for it? Other opt=
ions could be --track-fds=3Dhigh or even --track-fds=3Drandom.</div><div><b=
r></div><div>Another option that should be added is &quot;bad&quot;.</div><=
div><a href=3D"https://bugs.kde.org/show_bug.cgi?id=3D493434">https://bugs.=
kde.org/show_bug.cgi?id=3D493434</a><br></div><div>Currently --track-fds=3D=
yes or --track-fds=3Dall report both bad usage and never closed file<br>des=
criptors. Sometimes users are only interested in bad file descriptor usage =
errors, but <br>don&#39;t care about never close file descriptors.=C2=A0 In=
stead of making them create suppressions</div><div>=C2=A0for the never clos=
ed file descriptors we could have an --track-fds=3Dbad mod that only report=
s</div><div>=C2=A0errors on bad usage. I think the &quot;bad&quot; option s=
hould also be independent of &quot;all&quot; in the</div><div>same fashion =
I proposed &quot;new&quot; to be.</div><div><br></div><div>Another possibil=
ity would be to to keep --track-fds=3D[yes,no,all] and add new --track-bad-=
fds=3Dyes,=C2=A0</div><div>--track-leaky-fds=3Dyes and --track-high-fds=3Dy=
es.<br></div><div><br></div><div>I&#39;m open to any suggestions.</div><div=
><br></div><div>Thank you,</div><div>Alexandra</div></div>

--000000000000df1c1006299ee7a2--



--===============7027873832459098512==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline


--===============7027873832459098512==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Valgrind-users mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/valgrind-users

--===============7027873832459098512==--