On 8/22/10 10:13 PM, Rainer Müller wrote: > Bash Version: 4.1 > Patch Level: 7 > Release Status: release > > > > I cannot reproduce this very good, but it happens for me now with > iTerm.app and '/opt/local/bin/bash -l' as command. A crash report is > attached to this message. > > The important part of this report is: > "BUG IN CLIENT OF LIBDISPATCH: Do not close random Unix descriptors" > > I tracked this down to the shell initialization in the main function, > where bash closes any open file descriptors in the range from 3 to 19. > Apparently this causes problems with libdispatch, Apple's threading > library, as it works fine if I comment this section out. > > This is the code in question: > > | #define CLOSE_FDS_AT_LOGIN > | #if defined (CLOSE_FDS_AT_LOGIN) > | /* > | * Some systems have the bad habit of starting login shells with > lots of open > | * file descriptors. For instance, most systems that have picked up the > | * pre-4.0 Sun YP code leave a file descriptor open each time you > call one > | * of the getpw* functions, and it's set to be open across execs. That > | * means one for login, one for xterm, one for shelltool, etc. > | */ > | if (login_shell && interactive_shell) > | { > | for (i = 3; i < 20; i++) > | close (i); > | } > | #endif /* CLOSE_FDS_AT_LOGIN */ > > I am not sure how to proceed so I am asking for advice. Should I just > remove this code with a patch and let bash ignore any open file > descriptors? Would that be bad? Any other ideas?
Well, if they cause bash to crash, I suppose removing that code (or removing the #define) is a good place to start. That code has been there for a very long time. Maybe if you changed it to turn on the FD_CLOEXEC bit instead of closing the fd we could solve the problem. There is a SET_CLOSE_ON_EXEC(fd) macro you can use to do that. Chet -- ``The lyf so short, the craft so long to lerne.'' - Chaucer ``Ars longa, vita brevis'' - Hippocrates Chet Ramey, ITS, CWRU c...@case.edu http://cnswww.cns.cwru.edu/~chet/