From: "Bart Schaefer" <schaefer@candle.brasslantern.com>
To: "C. v. Stuckrad" <stucki@math.fu-berlin.de>,
Zsh workers list <zsh-workers@math.gatech.edu>
Subject: Re: Strange coredump in new zsh-3.0.1 on Sunos4.1.3 (2)
Date: Sat, 2 Nov 1996 10:21:58 -0800 [thread overview]
Message-ID: <961102102158.ZM23264@candle.brasslantern.com> (raw)
In-Reply-To: "C. v. Stuckrad" <stucki@math.fu-berlin.de> "Strange coredump in new zsh-3.0.1 on Sunos4.1.3 (2)" (Nov 2, 4:30pm)
On Nov 2, 4:30pm, C. v. Stuckrad wrote:
} Subject: Strange coredump in new zsh-3.0.1 on Sunos4.1.3 (2)
}
} On Sat, 2 Nov 1996, C. v. Stuckrad wrote:
}
} > Program terminated with signal 11, Segmentation fault.
} > #0 0x6fe4c in zclose (fd=19) at utils.c:921
} > 921 while (!fdtable[max_zsh_fd])
} (gdb) p max_zsh_fd
} $1 = 16777234
} ^ ^ ^ ^ OUTCH !?!?!?!?
} (gdb) p fdtable
} $2 = '\000' <repeats 17 times>, "\001\001"
}
} Well, this explains the coredump, but WHY ?
zsh is picking an arbitrary value of 20 for the OPEN_MAX constant. If
zclose() is being called on fd=19, chances are that at some previous
time the fdtable[] array was overflowed and trampled on max_zsh_fd.
Chances are further that the reason for this is that `screen' is leaving
way too many file descriptors open when it forks off children. This is
actually a potential security problem, because a program written to expect
this behavior might obtain access to a pseudo-tty that it was not supposed
to be able to access.
I seem to recall patching at least one version of `screen' to close down
file descriptors when forking children, but that was years ago; I very
seldom use `screen' any more since it became gnuware (no, not *because*
it did), and I quit hacking on it even before that.
As the comment in system.h says, OPEN_MAX should be getting set by doing
a query of the OS at run time. You should try to get a fixed screen, but
you should also try compiling with a larger OPEN_MAX (around 64 for SunOS,
I think) and see if that solves the problem.
--
Bart Schaefer Brass Lantern Enterprises
http://www.well.com/user/barts http://www.nbn.com/people/lantern
next prev parent reply other threads:[~1996-11-02 18:35 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
1996-11-02 15:25 Strange coredump in new zsh-3.0.1 on Sunos4.1.3 C. v. Stuckrad
1996-11-02 15:30 ` Strange coredump in new zsh-3.0.1 on Sunos4.1.3 (2) C. v. Stuckrad
1996-11-02 18:21 ` Bart Schaefer [this message]
1996-11-03 15:37 ` Strange coredump in new zsh-3.0.1 on Sunos4.1.3 (FIXED) C. v. Stuckrad
1996-11-03 18:44 ` Bart Schaefer
1996-11-03 21:25 ` Zoltan Hidvegi
1996-11-02 22:18 ` Strange coredump in new zsh-3.0.1 on Sunos4.1.3 Zoltan Hidvegi
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=961102102158.ZM23264@candle.brasslantern.com \
--to=schaefer@candle.brasslantern.com \
--cc=schaefer@nbn.com \
--cc=stucki@math.fu-berlin.de \
--cc=zsh-workers@math.gatech.edu \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
Code repositories for project(s) associated with this public inbox
https://git.vuxu.org/mirror/zsh/
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).