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