[Vm-dev] Cog: Infinite recursion leads to crash

[John M McIntosh]

Tim Rowledge and I spent a week about 6 years back exploring this issue. 

It's a fascinating problem to fix, good luck. 

The problem is that you are allocating a method context , I can't speak to what COG is doing, but obviously memory has to come from somewhere, memory is finite... 

So allocate a memory context, a few 100 bytes (more or less) frantically...  The "flawed" low memory logic wakes up and decides there is a problem. What's the threshold for that? A few 100K? Allocating 100K a second, what maybe 100MB a second via this recursion?  Well you get the idea. You've seconds or less to determine what to do. 

The default is to throw an exception which triggers a dialog, but too late...  By the time the dialog gets working the recursive loop has burn thru the final bits of free memory. 

Also if this task a back ground thread it would still be running. 

Now a possible fix. 

(a) You suspend all processes except the one(s) needed to show the emergency memory dialog. This actually isn't hard it just requires a good knownledge of what can or cannot be suspended. 

I do note in this case you might be able to say. Oh look if that process has a context depth of 10,000 that could be the villain, and or see (a)

On 2010-10-20, at 12:15 PM, Igor Stasenko wrote:

> Hello, Eliot.
> 
> By running some experimental stuff under Cog, Chris get into an
> infinite resursion,
> which, instead of showing 'low space' warning leads to VM crash.
> 
> I am not sure what exactly caused recursion in his code (i hope this
> just a simple bug, not related to VM).
> What i found disturbing, that i was able to reproduce crash with
> simple code (see attachment).
> 
> The only difference between crash report of mine:
> 
> Smalltalk stack dump:
>  0x924088 M InfiniteRecursion>deeeep: 292975484: a(n) InfiniteRecursion
>  0x9240ac M InfiniteRecursion>deeeep: 292975484: a(n) InfiniteRecursion
>  0x91e6f8 M InfiniteRecursion>deeeep: 292975484: a(n) InfiniteRecursion
>  0x91e71c M InfiniteRecursion>deeeep: 292975484: a(n) InfiniteRecursion
>  0x91e740 M InfiniteRecursion>deeeep: 292975484: a(n) InfiniteRecursion
>  0x91e764 M InfiniteRecursion>deeeep: 292975484: a(n) InfiniteRecursion
>  0x91e788 M InfiniteRecursion>deeeep: 292975484: a(n) InfiniteRecursion
>  ....
> 
> and Chris, that in his case an objects, somehow went outside of a heap:
> 
> 
> Smalltalk stack dump:
> 0xbfa31668 M  class()> 20181257720x784a27cc is not on the heap
> 0xbfa31690 M  class( class)> 20268642800x78cf7e98 is not on the heap
> 0xbfa316a8 M  class( class)> 20268642800x78cf7e98 is not on the heap
> 0xbfa316c8 M ()> 20366153080x7964488c is not on the heap
> 0xbfa316e0 M  class> 20129812280x77fba7ec is not on the heap
> 0xbfa316f8 M > 20135071280x7803ae38 is not on the heap
> 0xbfa31720 M  class( class)> 20268642800x78cf7e98 is not on the heap
> 0xbfa31738 M  class( class)> 20268642800x78cf7e98 is not on the heap
> 0xbfa31758 M ()> 20366153080x7964488c is not on the heap
> 0xbfa31770 M  class> 20129812280x77fba7ec is not on the heap
> 0xbfa31788 M > 20135071280x7803ae38 is not on the heap
> ...
> 
> 
> I was running under windoze, and were able to watch how vm consuming
> memory, and somewhere little above 512Mb, it crashing.
> 
> It is bad, of course, when your own code going mad, but it should not
> be the reason for VM to go mad as well :)
> 
> 
> 
> -- 
> Best regards,
> Igor Stasenko AKA sig.
> <InfiniteRecursion.st>

--
===========================================================================
John M. McIntosh <johnmci at smalltalkconsulting.com>   Twitter:  squeaker68882
Corporate Smalltalk Consulting Ltd.  http://www.smalltalkconsulting.com
===========================================================================




-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 3829 bytes
Desc: not available
Url : http://lists.squeakfoundation.org/pipermail/vm-dev/attachments/20101020/544baeab/smime.bin