On things we do when our stack overflows
Hi there, Toyota shoot its foot and learnt how not to anymore. This is a nice read on the things our software do when the stack overflows. Are We Shooting Ourselves in the Foot with Stack Overflow? http://embeddedgurus.com/state-space/2014/02/are-we-shooting-ourselves-in-th... The question on the table is are we following time proven safety rules when the same thing happen to our VM? Nice reading sebastian o/
Is anyone porting the CogVM on a bare Cortex-M without OS :P ? Thierry Le 18/02/2014 13:08, Sebastian Sastre a écrit :
Hi there,
Toyota shoot its foot <http://www.eetimes.com/author.asp?section_id=36&doc_id=1319910> and learnt how not to anymore.
This is a nice read on the things our software do when the stack overflows.
Are We Shooting Ourselves in the Foot with Stack Overflow?
http://embeddedgurus.com/state-space/2014/02/are-we-shooting-ourselves-in-th...
The question on the table is
/are we following time proven safety rules <http://training.nra.org/nra-gun-safety-rules.aspx> when the same thing happen to our VM?/
Nice reading
sebastian <https://about.me/sebastianconcept>
o/
-- Thierry Goubier CEA list Laboratoire des Fondations des Systèmes Temps Réel Embarqués 91191 Gif sur Yvette Cedex France Phone/Fax: +33 (0) 1 69 08 32 92 / 83 95
The VM could sure use stack overflow protection, it would/could help catch numerous 'hangs' due to infinite loops. On 18 Feb 2014, at 13:08, Sebastian Sastre <sebastian@flowingconcept.com> wrote:
Hi there,
Toyota shoot its foot and learnt how not to anymore.
This is a nice read on the things our software do when the stack overflows. Are We Shooting Ourselves in the Foot with Stack Overflow? http://embeddedgurus.com/state-space/2014/02/are-we-shooting-ourselves-in-th...
The question on the table is
are we following time proven safety rules when the same thing happen to our VM?
Nice reading
sebastian
o/
Hi: On 18 Feb 2014, at 15:58, Sven Van Caekenberghe <sven@stfx.eu> wrote:
The VM could sure use stack overflow protection, it would/could help catch numerous 'hangs' due to infinite loops.
On 18 Feb 2014, at 13:08, Sebastian Sastre <sebastian@flowingconcept.com> wrote:
Hi there,
Toyota shoot its foot and learnt how not to anymore.
This is a nice read on the things our software do when the stack overflows. Are We Shooting Ourselves in the Foot with Stack Overflow? http://embeddedgurus.com/state-space/2014/02/are-we-shooting-ourselves-in-th...
The question on the table is
are we following time proven safety rules when the same thing happen to our VM?
From the top of my head, I would expect operating systems for non-embedded devises to allocate a protected page at the end of the stack to detect stack overflows. And, most of the standard OSes should use Address Space Layout Randomization, which you need to turn off explicitly if you actually want to make sure that your stack is at a predefined position.
I think, this article is really targeted towards embedded systems, where you might not even got a MMU. And, if you are interested in those things, it might be best to follow Eliotâs suggestion and discuss it on the VM list. Best regards Stefan -- Stefan Marr INRIA Lille - Nord Europe http://stefan-marr.de/research/
On Tue, Feb 18, 2014 at 7:30 AM, Stefan Marr <smalltalk@stefan-marr.de>wrote:
Hi:
On 18 Feb 2014, at 15:58, Sven Van Caekenberghe <sven@stfx.eu> wrote:
The VM could sure use stack overflow protection, it would/could help catch numerous 'hangs' due to infinite loops.
But Smalltalk, having a spaghetti stack composed of contexts needs a different approach. The stack guard page won't work. The original approach of waiting for space to run out and signalling the low space semaphore doesn't scale, and hasn't been well-maintained, often resulting in systems that lock-up before they open a debugger on an offending process when space is low (it can be difficult to pick the right process also). Counting the stack depth periodically is sloooow, but something the VM can optimize unsafely (e.g. imagine an inst var in Process that records a per-process stack depth, and imagine that is updated by the VM on process switch and that the VM can efficiently compute the stack depth of the part of the process's context chain that is mapped to stack pages in the stack zone; this is fine provided nothing edits the process's stack chain explicitly, as does e.g. Seaside). So this is not a trivial problem to solve satisfactorily. To understand how we should implement this one really should understand the architecture of context-to-stack mapping in the Cog and Stack VMs. You can read my blog for that. Here's a hack off the top of my head: Process contains an inst var which records the number of contexts it creates. This count is not accurate. In Cog and the Stack VM it records only contexts created when the VM evacuates a page of contexts. In the classic Interpreter VM we count context allocations). Whenever a process's context count exceeds a given threshold, its actual depth is counted (accurately) and if this exceeds a second threshold, the process is interrupted. These thresholds need to be known to the VM and hence be vm parameters. Thoughts? Other ideas?
On 18 Feb 2014, at 13:08, Sebastian Sastre <sebastian@flowingconcept.com> wrote:
Hi there,
Toyota shoot its foot and learnt how not to anymore.
This is a nice read on the things our software do when the stack overflows. Are We Shooting Ourselves in the Foot with Stack Overflow?
http://embeddedgurus.com/state-space/2014/02/are-we-shooting-ourselves-in-th...
The question on the table is
are we following time proven safety rules when the same thing happen to
our VM?
From the top of my head, I would expect operating systems for non-embedded devises to allocate a protected page at the end of the stack to detect stack overflows. And, most of the standard OSes should use Address Space Layout Randomization, which you need to turn off explicitly if you actually want to make sure that your stack is at a predefined position.
I think, this article is really targeted towards embedded systems, where you might not even got a MMU.
And, if you are interested in those things, it might be best to follow Eliot's suggestion and discuss it on the VM list.
Best regards Stefan
-- Stefan Marr INRIA Lille - Nord Europe http://stefan-marr.de/research/
-- best, Eliot
On 19 Feb 2014, at 02:53, Eliot Miranda <eliot.miranda@gmail.com> wrote:
On Tue, Feb 18, 2014 at 7:30 AM, Stefan Marr <smalltalk@stefan-marr.de> wrote:
Hi:
On 18 Feb 2014, at 15:58, Sven Van Caekenberghe <sven@stfx.eu> wrote:
The VM could sure use stack overflow protection, it would/could help catch numerous 'hangs' due to infinite loops.
But Smalltalk, having a spaghetti stack composed of contexts needs a different approach. The stack guard page won't work. The original approach of waiting for space to run out and signalling the low space semaphore doesn't scale, and hasn't been well-maintained, often resulting in systems that lock-up before they open a debugger on an offending process when space is low (it can be difficult to pick the right process also). Counting the stack depth periodically is sloooow, but something the VM can optimize unsafely (e.g. imagine an inst var in Process that records a per-process stack depth, and imagine that is updated by the VM on process switch and that the VM can efficiently compute the stack depth of the part of the process's context chain that is mapped to stack pages in the stack zone; this is fine provided nothing edits the process's stack chain explicitly, as does e.g. Seaside). So this is not a trivial problem to solve satisfactorily.
To understand how we should implement this one really should understand the architecture of context-to-stack mapping in the Cog and Stack VMs. You can read my blog for that.
Here's a hack off the top of my head: Process contains an inst var which records the number of contexts it creates. This count is not accurate. In Cog and the Stack VM it records only contexts created when the VM evacuates a page of contexts. In the classic Interpreter VM we count context allocations). Whenever a process's context count exceeds a given threshold, its actual depth is counted (accurately) and if this exceeds a second threshold, the process is interrupted. These thresholds need to be known to the VM and hence be vm parameters.
Thoughts? Other ideas?
Sounds right (not knowing the details underneath): the performance hit of the protection should indeed be as low as possible. It does not have to be super accurate. The UX should be something like this (www.lispworks.com) CL-USER 1 > (defun deep-recursion (n) (if (< n 1000) (deep-recursion (1+ n)) 'done)) DEEP-RECURSION CL-USER 2 > (deep-recursion 1) Stack overflow (stack size 31744). 1 (continue) Extend stack by 50%. 2 (abort) Return to level 0. 3 Return to top loop level 0. Type :b for backtrace or :c <option number> to proceed. Type :bug-form "<subject>" for a bug report template or :? for other options. CL-USER 3 : 1 > :c Stack overflow (stack size 48128). 1 (continue) Extend stack by 50%. 2 (abort) Return to level 0. 3 Return to top loop level 0. Type :b for backtrace or :c <option number> to proceed. Type :bug-form "<subject>" for a bug report template or :? for other options. CL-USER 4 : 1 > :c Stack overflow (stack size 80896). 1 (continue) Extend stack by 50%. 2 (abort) Return to level 0. 3 Return to top loop level 0. Type :b for backtrace or :c <option number> to proceed. Type :bug-form "<subject>" for a bug report template or :? for other options. CL-USER 5 : 1 > :c DONE
On 18 Feb 2014, at 13:08, Sebastian Sastre <sebastian@flowingconcept.com> wrote:
Hi there,
Toyota shoot its foot and learnt how not to anymore.
This is a nice read on the things our software do when the stack overflows. Are We Shooting Ourselves in the Foot with Stack Overflow? http://embeddedgurus.com/state-space/2014/02/are-we-shooting-ourselves-in-th...
The question on the table is
are we following time proven safety rules when the same thing happen to our VM?
From the top of my head, I would expect operating systems for non-embedded devises to allocate a protected page at the end of the stack to detect stack overflows. And, most of the standard OSes should use Address Space Layout Randomization, which you need to turn off explicitly if you actually want to make sure that your stack is at a predefined position.
I think, this article is really targeted towards embedded systems, where you might not even got a MMU.
And, if you are interested in those things, it might be best to follow Eliotâs suggestion and discuss it on the VM list.
Best regards Stefan
-- Stefan Marr INRIA Lille - Nord Europe http://stefan-marr.de/research/
-- best, Eliot
participants (5)
-
Eliot Miranda -
Goubier Thierry -
Sebastian Sastre -
Stefan Marr -
Sven Van Caekenberghe