[Vm-dev] Re: [Pharo-dev] On things we do when our stack overflows

[Eliot Miranda]

On Tue, Feb 18, 2014 at 7:30 AM, Stefan Marr <smalltalk at stefan-marr.de>wrote:

>
> Hi:
>
> On 18 Feb 2014, at 15:58, Sven Van Caekenberghe <sven at 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 at 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-the-foot-with-stack-overflow/
> >>
> >> 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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.squeakfoundation.org/pipermail/vm-dev/attachments/20140218/591c5ec4/attachment-0001.htm