Re: [Pharo-dev] On things we do when our stack overflows
Locked
Re: [Pharo-dev] On things we do when our stack overflows
 
|
Hi: On 18 Feb 2014, at 15:58, Sven Van Caekenberghe <[hidden email]> 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 <[hidden email]> 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/ |
Re: [Pharo-dev] On things we do when our stack overflows
|
|
On Tue, Feb 18, 2014 at 7:30 AM, Stefan Marr <[hidden email]> wrote:
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?
best, Eliot
|
«
Return to Squeak VM
|
1 view|%1 views
| Free forum by Nabble | Edit this page |