[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: login shell crash on Mac OS X while closing file descriptors

From: Chet Ramey
Subject: Re: login shell crash on Mac OS X while closing file descriptors
Date: Tue, 24 Aug 2010 09:59:50 -0400
User-agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv: Gecko/20100802 Thunderbird/3.1.2

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


``The lyf so short, the craft so long to lerne.'' - Chaucer
                 ``Ars longa, vita brevis'' - Hippocrates
Chet Ramey, ITS, CWRU    address@hidden    http://cnswww.cns.cwru.edu/~chet/

reply via email to

[Prev in Thread] Current Thread [Next in Thread]