Summary: | Valgrind's private fds are not hidden from user process | ||
---|---|---|---|
Product: | [Developer tools] valgrind | Reporter: | Dan Kegel <dank> |
Component: | general | Assignee: | Julian Seward <jseward> |
Status: | RESOLVED INTENTIONAL | ||
Severity: | wishlist | CC: | njn, tom |
Priority: | NOR | ||
Version: | unspecified | ||
Target Milestone: | --- | ||
Platform: | Compiled Sources | ||
OS: | Linux | ||
Latest Commit: | Version Fixed In: | ||
Sentry Crash Report: |
Description
Dan Kegel
2009-05-06 00:53:58 UTC
> Turns out we were looping over all open file descriptors, as reported by the
> system, and some of those were valgrind's!
By "reported by the system", you mean you were looking at /dev/fd? Ie. the problem is there's an inconsistency between what's seen in /dev/fd (where the Valgrind fds are visible) and what getrlimit() returns (where the Valgrind fds are effectively hidden)?
That's right. If valgrind's fds were hidden from /dev/fd (or /proc/self/fd on linux) as well, we wouldn't have had to change our program to work around them. It's not like this is a huge deal for us, but if somebody didn't have freedom to change their code, it could be a real bear. Masking out directory entries would be a lot of work for fairly small gain so I'm not sure it's worth it personally. The traditional way of looping over all the file descriptors on Unix systems is simply to loop from zero to the rlimit (which we do adjust as you say) rather than doing funny business with /dev/fd which is highly non-portable. Then go ahead and mark LATER or WONTFIX or something (I don't know what KDE uses in its bugzilla). Maybe this bug report will help the next guy who stumbles into this. I'll mark it WONTFIX. Valgrind tries to provide a faithful emulation of the underlying environment, but there will always be some infelicities, and I agree with Tom that the cost/benefit ratio on this one isn't good. Thanks for the report, though. |