GNU bug report logs - #16999
calc crashes when computation limit is increased

Previous Next

Full log

View this message in rfc822 format

From: Eli Zaretskii <eliz <at> gnu.org>
To: Dmitry Antipov <dmantipov <at> yandex.ru>
Cc: eggert <at> cs.ucla.edu, 16999 <at> debbugs.gnu.org
Subject: bug#16999: calc crashes when computation limit is increased
Date: Thu, 13 Mar 2014 18:56:53 +0200

> Date: Thu, 13 Mar 2014 13:11:50 +0400
> From: Dmitry Antipov <dmantipov <at> yandex.ru>
> CC: Paul Eggert <eggert <at> cs.ucla.edu>, Eli Zaretskii <eliz <at> gnu.org>
> 
> On 03/13/2014 09:13 AM, Dmitry Antipov wrote:
> 
> > Perhaps there should be a kind of protection against this. For example,
> > eval_sub can check current stack depth against getrlimit (RLIMIT_STACK,...).
> 
> This is rather simple on general *NIX. But:
> 
> 1) it should be implemented for MS-Windows and OSX too if we really need this;

It should be easy enough to emulate on MS-Windows getrlimit that
supports RLIMIT_STACK.  Let me know if you want me to do that (should
ideally be ready before it is used, to avoid breaking the build).

> 2) Linux has prlimit to tweak limits of another process at run time,
>     so actual limit should be checked each time eval_sub is called, thus
>     introducing a (minor?) slowdown.

I'm not sure we should bother.  We already use getrlimit/setrlimit for
making sure the stack is large enough to accommodate re_max_failures.
We do that only once, at startup, and never look back.  And yet I
don't think we've seen regexp related crashes that would point to
stack overflow.

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.