|
From: Beorn J. <beo...@ya...> - 2006-08-13 19:53:52
|
I feel this idea (tracking the closing of un-opened fds) is very good. It should be extremely easy to implement. In fact, it would be a great starter/warm-up project for someone who wants to learn valgrind internals. Actually, I'm surprised I haven't seen a patch on the mailling list already; should be what, about five lines? I'm perhaps more surprised that it isn't in there already. It would also be extremely useful. Closing fds not known to be open may be fine in a single-threaded environment, but in a multi-threaded environment it is absolute disaster. I am not enough of an strace/gdb expert to be able to easily track this sort of thing down in under 1/2 a day in a complex multi-threaded program. It would be a matter of seconds with valgrind's help. (Oh, and throw in user-level threading to make things even more complex.) I do have some experience with multi-threaded servers, and in fact this very problem of closing previously closed file descriptors was one of those ghost bugs that haunted us for a while. Nigel Horne's idea is really very good (and so simple!), and should be encouraged. - Beorn Johnson __________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com |
|
From: John R.
|
Beorn Johnson wrote: > I feel this idea (tracking the closing of un-opened fds) is very good. > > It should be extremely easy to implement. ... > > It would also be extremely useful. ... > > I am not enough of an strace/gdb expert ... > > ... Nigel Horne's idea is really very > good (and so simple!), and should be encouraged. > > - Beorn Johnson You have already spent more time composing your polemic than would be necessary to learn "strace ... | grep EBADF" and conditional breakpoints in gdb. These are a far better solution than adding the proposed feature to memcheck. Let the developers/maintainers of memcheck work on better detection and reporting of memory access errors. Don't distract them with trivialities that are already solved elsewhere. -- |
|
From: Nigel H. <nj...@ba...> - 2006-08-14 10:33:15
Attachments:
njh.vcf
|
John Reiser wrote: > Beorn Johnson wrote: >> I feel this idea (tracking the closing of un-opened fds) is very good. >> >> It should be extremely easy to implement. ... >> >> It would also be extremely useful. ... >> >> I am not enough of an strace/gdb expert ... >> >> ... Nigel Horne's idea is really very >> good (and so simple!), and should be encouraged. >> >> - Beorn Johnson > > You have already spent more time composing your polemic > than would be necessary to learn "strace ... | grep EBADF" and > conditional breakpoints in gdb. These are a far better solution > than adding the proposed feature to memcheck. > > Let the developers/maintainers of memcheck work on better detection > and reporting of memory access errors. Don't distract them with > trivialities that are already solved elsewhere. Where are they already solved? I've had one strace suggestion that wasn't up to the job of valgrind. What solution can you suggest? > -- Nigel Horne. Arranger, Adjudicator, Band Trainer, Composer, Tutor, Typesetter. NJH Music, Barnsley, UK. ICQ#20252325 nj...@ba... http://www.bandsman.co.uk |
|
From: John R.
|
Nigel Horne wrote: > John Reiser wrote: >> Let the developers/maintainers of memcheck work on better detection >> and reporting of memory access errors. Don't distract them with >> trivialities that are already solved elsewhere. > > > Where are they already solved? I've had one strace suggestion that > wasn't up to the job of valgrind. What solution can you suggest? Paul Pluzhnikov's suggested strace [this list, 2006-08-13] reveals whether there are any close(not_open_fd) or not. If there are some, then rerun the application under gdb [and not strace] with a conditional breakpoint to detect calling close() with the particular not_open_fd; ask for a backtrace when it occurs. Even this two-pass process is faster and smaller than memcheck because strace is involved only at system calls, and not for every instruction. With a little more knowledge, you can use gdb directly in one pass. Examine the code for close(), and put a breakpoint in the errno return path, conditioned on EBADF. If you're truly having trouble with close(not_open_fd), then you also may be unaware of all the filenames the application uses. See the "-e trace=files" option to strace, and prepare to be astounded at the sheer number, as well as the "duplicated" work that many applications perform. -- |
|
From: Julian S. <js...@ac...> - 2006-08-15 11:29:51
|
> >> Let the developers/maintainers of memcheck work on better detection > >> and reporting of memory access errors. Don't distract them with > >> trivialities that are already solved elsewhere. > > > > Where are they already solved? I've had one strace suggestion that > > wasn't up to the job of valgrind. What solution can you suggest? I would have commented on all this earlier, but have been out of town. The original request (report closing of invalid fds) is not by itself unreasonable and I don't think Nigel should be criticised for making it. The real problem is that this kind of gradual accumulation of features makes the system ever more difficult to maintain. That is, there is a future cost associated with adding every such feature, and they add up quickly. In this case it's hard to justify considering that such bad closes can be found by strace (yes, I know not including the call stack). Also, surely checks of the return code of close() would find these problems? We have struggled with maintainability problems in the past. The valgrind developer/tester base is too small/underresourced to convincingly support anything much more than the current functionality and I don't really want to exacerbate that problem. J |