[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:1.9.2.8) 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
that.
Chet
--
``The lyf so short, the craft so long to lerne.'' - Chaucer
``Ars longa, vita brevis'' - Hippocrates
Chet Ramey, ITS, CWRU chet@case.edu http://cnswww.cns.cwru.edu/~chet/