Re: Does HIGH_FD_MAX have to be so low?
On Thu, Oct 19, 2006 at 04:02:36PM -0400, Chet Ramey wrote: > Mike Stroyan wrote: > > > move_to_high_fd() only avoid open file descriptors if the > > check_new parameter is non-zero. open_shell_script() calls > > move_to_high_fd() with a check_new value of 0. The other two callers > > of the function do pass in a check_new value of 1. > > > > Aha! I missed the most relevant call. Now the question is whether or > not it's still a good idea to pass that 0 from open_shell_script. Forcing the reuse of an already open file descriptor does seem strange. I can't think of a situation when that is likely to be better than using a lower unopened file descriptor or just keeping the original file descriptor returned by open. If all callers will use a value of 1 you could just eliminate the "check_new" parameter. Looking at the other callers, I noticed that the call to move_to_high_fd() by process_substitute() is using a rather low value for maxfd. parent_pipe_fd = move_to_high_fd (parent_pipe_fd, 1, 64); It will search for an unopened file descriptor between 4 and 64 then take the highest one it can find. If no file descriptor is unopened in that range then it will keep using the original file descriptor returned by pipe(). It doesn't ask to look nearly as high as the other two callers of move_to_high_fd(). But it is not clear why it is different. -- Mike Stroyan, [EMAIL PROTECTED] ___ Bug-bash mailing list Bug-bash@gnu.org http://lists.gnu.org/mailman/listinfo/bug-bash
Re: Does HIGH_FD_MAX have to be so low?
Mike Stroyan wrote: > move_to_high_fd() only avoid open file descriptors if the > check_new parameter is non-zero. open_shell_script() calls > move_to_high_fd() with a check_new value of 0. The other two callers > of the function do pass in a check_new value of 1. > Aha! I missed the most relevant call. Now the question is whether or not it's still a good idea to pass that 0 from open_shell_script. Chet -- ``The lyf so short, the craft so long to lerne.'' - Chaucer Live Strong. No day but today. Chet Ramey, ITS, CWRU[EMAIL PROTECTED]http://cnswww.cns.cwru.edu/~chet/ ___ Bug-bash mailing list Bug-bash@gnu.org http://lists.gnu.org/mailman/listinfo/bug-bash
Re: Does HIGH_FD_MAX have to be so low?
On Thu, Oct 19, 2006 at 03:33:37PM -0400, Chet Ramey wrote: > Mike Stroyan wrote: > > > Looking at open_shell_script() in shell.c and move_to_high_fd() in > > general.c, I find that the code will force the use of fildes 255, > > (HIGH_FD_MAX), for reading the shell script when getdtablesize() reports > > that the maximum allowed file descriptor value is greater than 255. > > In this particular case the maximum file descriptor value was 1023, > > which would have stayed out of the way of the application's use. > > If you look closely at move_to_high_fd(), you see that it attempts to > avoid file descriptors already in use. Only if fcntl(fd, F_GETFD, ...) > returns -1 does it conclude that file descriptor fd is available. > > One can debate whether or not we should be checking explicitly for > EBADF, but that's the only value of errno that's valid for F_GETFD > anyway. > > I'd be interested in knowing why fcntl didn't return -1, if the parent > process really did leave the file descriptor open and didn't set the > close-on-exec flag. move_to_high_fd() only avoid open file descriptors if the check_new parameter is non-zero. open_shell_script() calls move_to_high_fd() with a check_new value of 0. The other two callers of the function do pass in a check_new value of 1. -- Mike Stroyan, [EMAIL PROTECTED] ___ Bug-bash mailing list Bug-bash@gnu.org http://lists.gnu.org/mailman/listinfo/bug-bash
Re: Does HIGH_FD_MAX have to be so low?
Mike Stroyan wrote: > Looking at open_shell_script() in shell.c and move_to_high_fd() in > general.c, I find that the code will force the use of fildes 255, > (HIGH_FD_MAX), for reading the shell script when getdtablesize() reports > that the maximum allowed file descriptor value is greater than 255. > In this particular case the maximum file descriptor value was 1023, > which would have stayed out of the way of the application's use. If you look closely at move_to_high_fd(), you see that it attempts to avoid file descriptors already in use. Only if fcntl(fd, F_GETFD, ...) returns -1 does it conclude that file descriptor fd is available. One can debate whether or not we should be checking explicitly for EBADF, but that's the only value of errno that's valid for F_GETFD anyway. I'd be interested in knowing why fcntl didn't return -1, if the parent process really did leave the file descriptor open and didn't set the close-on-exec flag. Chet -- ``The lyf so short, the craft so long to lerne.'' - Chaucer Live Strong. No day but today. Chet Ramey, ITS, CWRU[EMAIL PROTECTED]http://cnswww.cns.cwru.edu/~chet/ ___ Bug-bash mailing list Bug-bash@gnu.org http://lists.gnu.org/mailman/listinfo/bug-bash
Does HIGH_FD_MAX have to be so low?
I was recently helping to debug a problem with an application getting bad file descriptor errors when run from a shell wrapper script. The cause was that the parent process left fildes 255 open for the child process, but the bash wrapper script was causing fildes 255 to be closed. Looking at open_shell_script() in shell.c and move_to_high_fd() in general.c, I find that the code will force the use of fildes 255, (HIGH_FD_MAX), for reading the shell script when getdtablesize() reports that the maximum allowed file descriptor value is greater than 255. In this particular case the maximum file descriptor value was 1023, which would have stayed out of the way of the application's use. Does HIGH_FD_MAX need to be so low? (OK. 255 isn't _REALLY_ low.) Are there negative consequences for using a higher file descriptor when getdtablesize() reports that they are allowed? -- Mike Stroyan, [EMAIL PROTECTED] ___ Bug-bash mailing list Bug-bash@gnu.org http://lists.gnu.org/mailman/listinfo/bug-bash
