Return to BSD News archive
Newsgroups: comp.os.386bsd.bugs
Path: sserve!newshost.anu.edu.au!munnari.oz.au!uunet!zaphod.mps.ohio-state.edu!magnus.acs.ohio-state.edu!csn!hellgate.utah.edu!fcom.cc.utah.edu!cs.weber.edu!terry
From: terry@cs.weber.edu (A Wizard of Earth C)
Subject: Re: VM problems w/unlimited memory?
Message-ID: <1993Mar20.235246.1980@fcom.cc.utah.edu>
Sender: news@fcom.cc.utah.edu
Organization: Weber State University (Ogden, UT)
References: <1o81joINNieh@usenet.INS.CWRU.Edu> <1993Mar18.183443.6397@fcom.cc.utah.edu> <1oaudnINNj1a@usenet.INS.CWRU.Edu>
Date: Sat, 20 Mar 93 23:52:46 GMT
Lines: 118
In article <1oaudnINNj1a@usenet.INS.CWRU.Edu> chet@odin.ins.cwru.edu (Chet Ramey) writes:
>In article <1993Mar18.183443.6397@fcom.cc.utah.edu> terry@cs.weber.edu (A Wizard of Earth C) writes:
>
>>Certainly this problem *must* have been solved in other environments in the
>>bash code, right? Allocation of all memory on an AIX 3.2 box will result
>>not in a crash, but in killing the process with the largest image size
>>(rather than the most recently run process or the one doing the excessive
>>allocation). This is arguably a *bad thing* for bash to do on AIX, right?
>
>It would be, I suppose, if it happened. The AIX 3.2 box I have access
>to doesn't allow you to raise the limit on open file descriptors past
>the default of 2000. I don't have any V.4 systems, but haven't yet heard
>of any problems.
Ok, maybe my life in the kernel has corrupted me; I haven't hit a limit at
all using fp_open() and family from within the kernel, and making hooks for
user space use of kernel code is relatively easy on AIX; this is probably
a per-process limit that is configurable, or at least soft-enforced, given
the way that AIX allocates it's process descriptor table. In any case, if
doing an "unlimit" on your AIX box causes it to still be limited, it won't
be a problem (but is probably a bug with "unlimit" there, as well as a
possible bug in the "getdtablesize" returning a range-restricted value).
I have to argue also that allocating ~64K of memory to get a high descriptor
is bad practice, even if allowed (2000*sizeof(struct file)).
>>>Bash uses the same technique in shell.c to protect the file descriptor
>>>it's using to read a script -- all shells do pretty much the same
>>>thing. (Well, at least it does now. The distributed version of 1.12
>>>does not do this.)
>>
>>There doesn't seem to be a good reason for this if the shell script is
>>in core in the shell; it should be closed after reading. Since reading
>>takes place entirely before execution, there is no conflict with the
>>shell script itself.
>
>This is not how things happen. A particular command is certainly read
>completely from the script by the time it is executed, but no shells
>of which I am aware read a whole script before executing any commands
>in it. (Bash does use a variant of this technique when reading the
>shell startup files: it reads the entire file into a string and
>executes the commands from there. This doesn't work very well for
>arbitrary scripts; I've tried it (think parent-child synchronization).
>It does get rid of the file descriptor problem, though.)
This is probably an acceptable design decision; what about generating an
interference table and yelling at the user when fd x is used (and then
picking 19 always?) You can still comply with POSIX while restricting the
user, can't you?
>>In any event, a shell script is run by a sub-shell,
>>not the active shell, unless one is playing games with a disk-based
>>interpreter and context frames within the shell. In this case, the
>>traditional recursion within a shell script played by many install
>>packages would fail anyway.
>
>Oh, think about what you're saying before you say it. The above
>paragraph is just gibberish. Look at, for instance, a typical
>Configure script. Say we run it as
>
> bash Configure
>
>and bash opens `Configure' to fd 3. Somewhere in the script we do
>
> exec 3>&1
> case "$silent" in
> true) exec 1>/dev/null;;
> esac
>
>to run silently unless we really have something to say (at which time,
>of course, we run a command with fd 3 duplicated to fd1). Bang, there
>goes the file descriptor open to the script. All of a sudden the
>shell hangs, apparently dead, in _filbuf or equivalent. Without doing
>*something* in the shell, this is unsolvable. We just picked a
>technique that you apparently have problems with.
This, admittedly, follows logically from bash not maintaining an interference
table and yelling at the user. If this were done, the action would result
in a message like:
"fd 3 in use: all future references assumed to be 19"
Or with bash just doing it without any messages at all. The fd's (other
than 0, 1, & 2) would be virtual, and the number simply used as a placeholder.
[ ... ]
>>There *is* a documented, *portable* way of replacing the fd associated
>
>This is documented? And guaranteed to work on things like QNX and
>OS/2, where bash already runs? It's an interesting idiom, if it
>works. I recall a discussion some time ago about ANSI or Posix.1
>making it not perfectly kosher to declare a FILE (as opposed to a
>FILE *), because a FILE * was the only thing that the stdio functions
>dealt with.
It's not; however, as long as the data is opaque, it's portable. I am
unsure of the memory protection of the fd tables on QNX or OS/2, so I
am skeptical of it's ability to work everywhere.
>>Traditionally, the soloution has been to use a "non-portable method" to
>>directly manipulate the fd in the fp; this is what most shells do;
>
>Most shells don't use stdio, period. Bash and maybe zsh are the only
>ones I know of.
Yep; zsh is what I had in mind.
Terry Lambert
terry@icarus.weber.edu
terry_lambert@novell.com
---
Any opinions in this posting are my own and not those of my present
or previous employers.
--
-------------------------------------------------------------------------------
"I have an 8 user poetic license" - me
Get the 386bsd FAQ from agate.berkeley.edu:/pub/386BSD/386bsd-0.1/unofficial
-------------------------------------------------------------------------------