Martin Dorey wrote:
However, your point about programs invoked by make inheriting the
setrlimit() is definitely something that seems problematic. Perhaps
GNU
make could change the stack limit back to what it was after it forks
but
before it execs its child. I wonder what happens if you change a
limit to
something too small for the current processes resources?
It doesn't look specified by
http://www.opengroup.org/onlinepubs/009695399/functions/getrlimit.html.
This test suggests that it works fine on my Linux box. I presume the
limit check is normally done on a faulting access off the end of the
stack, so setrlimit would need some to have some different and special
code to check the current stack usage if it wanted to apply the check
immediately. It seems a bit unlikely that anyone would have gone to
that effort, thus stopping you from doing something useful in this sort
of situation.
In Linux (and most other Unix systems) the stack is allocated in
page-sized chunks, and an extra page with no access permissions is
mapped at the end of it. Accessing that page is what generates the SEGV
that occurs when you overrun the stack. The mappings are only
established when the stack is grown, and generally the stack never
shrinks. So if you already have X pages of stack legitimately in use,
lowering the rlimit isn't going to have an immediate effect. I.e., the
stack growth occurred before the limit decreased. In general, Unix
doesn't impose restrictions retroactively. (E.g., if you open a file and
have a valid descriptor on it, and someone else chmods the file,
removing your access permissions, you still have your original
privileges through the open descriptor.)
--
-- Howard Chu
Chief Architect, Symas Corp. http://www.symas.com
Director, Highland Sun http://highlandsun.com/hyc
OpenLDAP Core Team http://www.openldap.org/project/
_______________________________________________
Bug-make mailing list
Bug-make@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-make