[Vm-dev] Re: [Pharo-project] Collection new

Eliot Miranda eliot.miranda at gmail.com
Tue Jan 31 23:40:03 UTC 2012


On Mon, Jan 30, 2012 at 9:18 PM, S Krish
<krishnamachari.sudhakar at gmail.com>wrote:

> In general why is there not a catch all for Stack Overflow and infinite
> loops.


There is, low space (and user interrupt for flat infinite loops).  But the
low space interrupt machinery is easily broken.  It is difficult to test,
and an increasingly silly approach on modern machines with huge amounts of
memory.  We need to think again.


>
> Thats very annoying for newbie.. and infact gives a bad feel to using
> Pharo. The image they are working for say 3-4 hours and the crash just
> pushes them out of all the code they are working on with.. small as it
> maybe..
>
> Recover / and other options are fallbacks but invariably newbies have it
> messed up and are not very clear on how to recover either .. thats a job
> for the experienced user actually...
>
> This occurs so often from all of the polling code.. and if anyone
> unknowingly puts in a debug point in the methods that loop infinitely.. and
> so many of them lurk all around the image..
>
> Just stop the loop and throw up a debugger if say 100 calls have gone to
> very same method..? or detect a clear loopback to the same method..
>
> On Tue, Jan 31, 2012 at 12:01 AM, Andrew P. Black <black at cs.pdx.edu>wrote:
>
>> Teaching a class of novices, it's not surprising that someone tried
>> "Collection new".  What was surprising is that this got the VM is a loop of
>> some kind, with emergency stack dumps and so on.
>>
>> Here is my reply:
>>
>>
>> > On 30 Jan 2012, at 01:18 , Xingzhi Harry Pan wrote:
>> >
>> >> ...it's pretty innocent:
>> >> Collection new
>> >
>> >
>> > OK. I looked at this.  The problem comes when trying to print the
>> collection.  Somehow the VM gets confused when trying to do do: ... I'm not
>> quite clear why.
>> >
>> > The quick fix is to change the Collection>>new method to
>> >
>> >       self error: 'Collection is an abstract class, and cannot be
>> instantiated'
>> >
>> > However this will break Heap>>new: , which sends super new.  It ought
>> to send self basicNew instead.
>> >
>> > These two changes seem to avoid the problem, but I'm waiting to see ...
>> >
>> >       Andrew
>>
>> But I don't understand the root cause.  Printing eventually sends do:,
>> which is self subclassResponsibility.  Why don't we get a clean failure?
>>
>>        Andrew
>>
>>
>>
>


-- 
best,
Eliot
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.squeakfoundation.org/pipermail/vm-dev/attachments/20120131/4e592d5c/attachment-0001.htm


More information about the Vm-dev mailing list