OK folks, thanks for your suggestions, I will see how to be more  
careful with such threads. The instance browser seems a very  
interesting idea and I will try to use it (although not necessarily  
for such problems, but for bugs popping up during very long  
computations, it can be great). As well is the idea of drawing in a  
bitmap canvas before displaying: I would like to see some kind of  
better sandboxing for such problems...


Another cup of big bad error this morning. After seeing the image  
freezes once again on a long process, out of frustration I tried to  
interrupt it multiple times. I didn't get any debugger and the VM just  
quit after a while, but at least it seems like the stack dump still  
works in this case. So the last stack dump looks like this:

Bitmap class(Behavior)>>basicNew:
        Receiver: Bitmap
        Arguments and temporary variables:
                sizeRequested:  206074
        Receiver's instance variables:
                superclass:     ArrayedCollection
                methodDict:     a MethodDictionary(#asByteArray->a 
CompiledMethod(4056:  
Bitmap>>asB...etc...
                format:         33538
                instanceVariables:      nil
                organization:   ('accessing' atAllPut: bitPatternForDepth: 
byteAt:  
byteAt:put: by...etc...
                subclasses:     nil
                name:   #Bitmap
                classPool:      a Dictionary()
                sharedPools:    nil
                environment:    nil
                category:       #'Graphics-Primitives'
                traitComposition:       nil
                localSelectors:         nil

Bitmap class(Behavior)>>basicNew:
Bitmap class(Behavior)>>basicNew:
Bitmap class(Behavior)>>basicNew:
Bitmap class(Behavior)>>basicNew:
etc.

while it's trying to open the debugger.

Now I would like to get a better understanding. Why does this  
primitive keep failing and retry? My best guess is that the VM runs  
out of ressources (memory) but can not report it.




On 1 déc. 2009, at 03:01, Hernán Morales Durand wrote:

> Hi Simon,
>  Have you tried http://www.squeaksource.com/LightweightClasses.html ?
> It's in an experimental stage, but I've used it succesfully for the
> recursive debugger problem. You may load it in Pharo-Core this way  :
>
> Gofer new
>       squeaksource: 'LightweightClasses';
>       addPackage: 'ParametrizedCompiler';
>       addPackage: 'LightweightClasses';
>       addPackage: 'OBLightweightClass';               
>       load;
>       recompile.
>
> Cordialement,
>
> Hernán
>
> 2009/11/30 Simon Denier <[email protected]>:
>>
>> Unfortunately, this is an issue which I cant easily reproduce, at  
>> least not
>> without a third party tool (1525). Now I would like the general
>> opinion/experience of debugging Morphic code especially in threads.
>> Usually an exception raised from within Morphic code pops up a  
>> debugger as
>> usual. However, from time to time, or for more complicated stuff, the
>> situation runs out of hand and tons of debugger pop up everywhere  
>> because
>> the same faulty gets obviously executed again and again.
>> Now can somebody with some Morphic knowledge explain how this is  
>> supposed to
>> work and how to deal with such issues?
>> --
>>  Simon
>>
>>
>>
>> _______________________________________________
>> Pharo-project mailing list
>> [email protected]
>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
>>
>
> _______________________________________________
> Pharo-project mailing list
> [email protected]
> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

--
  Simon




_______________________________________________
Pharo-project mailing list
[email protected]
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

Reply via email to