https://bugs.kde.org/show_bug.cgi?id=331311
--- Comment #11 from Mark Wielaard <[email protected]> --- (In reply to Alexandra Hajkova from comment #10) > Created attachment 184468 [details] > patch We discussed this on irc already and I am happy with the patch. Maybe add a comment in the testcase why we are expecting 0, 1, 2 and 3. (Because those are the stdin/out/err and the opendir file descriptor.) But we also discussed an odd corner case. We might filter out all entries and return zero, indicating there are no more entries in the directory. On irc I said this couldn't happen, or would only happen to the entries at the end, and so returning zero would always be correct (end of directory). My assumptions for this not happening were: - All valgrind file descriptors are "high" >= VG_(fd_soft_limit). - Even the log/xml_output_sinks are because they are moved there by coregrind/m_libcprint.c (finalize_sink_fd) (So the fd == VG_(log_output_sink).fd || fd == VG_(xml_output_sink).fd checks are kind of redundant, finalize_sink_fd may fail, but then you probably want the program to see them because they are probably stdout or stderr). - getdents returns the entries in numerical order, so all valgrind file descriptors come at the end. Turns out that last assumption is wrong :{ You can see with: $ valgrind -q /bin/ls /proc/self/fd 0 1 1024 1025 1026 1027 1028 1029 1030 2 3 So there really is a change getdents for a particular size would only return "skipped" entries. In which case we would return zero and the program would assume it saw end of directory. The changes of this seem small, glibc seems to allocate a buffer between 32Kb and 1Mb to do getdent calls. Likely containing all entries at once. But it might still happen when someone does getdents calls by hand. See the example at https://www.man7.org/linux/man-pages/man2/getdents.2.html So we have to figure out what to do when result_size != RES && result_size == 0. (Maybe we just have to do a full new getdents call ourselves?) O, and I just remembered one (actually two) directories to filter in the same way. /proc/self/fdinfo or /proc/<pid>/fdinfo -- You are receiving this mail because: You are watching all bug changes.
