zsh-workers
 help / color / mirror / code / Atom feed
From: Bart Schaefer <schaefer@brasslantern.com>
To: zsh-workers@zsh.org
Subject: Re: unbounded recursive call in a shell script crashes zsh
Date: Sun, 16 Apr 2017 17:17:33 -0700	[thread overview]
Message-ID: <170416171733.ZM21913@torch.brasslantern.com> (raw)
In-Reply-To: <20170416231218.GA28022@fujitsu.shahaf.local2>

On Apr 16, 11:12pm, Daniel Shahaf wrote:
}
} I realized that the code could compare how far it is from main() to
} RLIMIT_STACK and bail out gracefully if it has, say, less than X KB or
} Y% of stack remaining.

Well ...

Another approach would be to add a C function that does nothing more
than declare a large array to force a stack allocation, and assign
something to the last byte; then in doshfunc(), trap the appropriate
signals (SIGSEGV and SIGSTKFLT ?) while calling that function.  If a
signal is raised, bail out as if MAX_FUNCTION_DEPTH has been reached.

I suspect this would destroy some efficiency gains Sebastian has been
so diligently wringing out of the code the last few months, but it'd
probably be fairly bulletpoof.  doshfunc() could remember the depth it
last safely reached and skip calling the stack-probe until that was
next exceeded, so you'd only pay the penalty once.

But is all this really worth it?

I note in passing that MAX_FUNCTION_DEPTH can be switched off at compile
time, leaving the shell entirely at the mercy of ths script writer in
this regard.


  reply	other threads:[~2017-04-17  0:17 UTC|newest]

Thread overview: 17+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-04-11 13:00 Kamil Dudka
2017-04-11 13:29 ` Jérémie Roquet
2017-04-11 14:01   ` Jérémie Roquet
2017-04-11 14:38     ` Kamil Dudka
2017-04-12  2:12       ` Bart Schaefer
2017-04-12  7:30         ` Kamil Dudka
2017-04-12 22:11           ` Bart Schaefer
2017-04-13 14:30             ` Kamil Dudka
2017-04-13 15:21               ` Jérémie Roquet
2017-04-13 16:01                 ` Jérémie Roquet
2017-04-15 16:14                   ` Bart Schaefer
2017-04-16 18:56                     ` Daniel Shahaf
2017-04-16 21:00                       ` Bart Schaefer
2017-04-16 23:12                         ` Daniel Shahaf
2017-04-17  0:17                           ` Bart Schaefer [this message]
2017-04-18 13:54                   ` Kamil Dudka
2017-04-19 21:01                     ` Bart Schaefer

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=170416171733.ZM21913@torch.brasslantern.com \
    --to=schaefer@brasslantern.com \
    --cc=zsh-workers@zsh.org \
    /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).