On Thu, May 7, 2015 at 9:09 PM, Alain Rastoul <alf.mmm.cat@gmail.com> wrote:

Le 05/05/2015 14:35, Ben Coman a ��crit :

Not sure if this is related, but if you put a haltOnce at the top of
SpecDebugger>>updateReceiverInspectorFromContext:
then step down until the 'receiver' temporary variable is set,
then inspect 'receiver', the system hangs.
cheers -ben

After digging into it, the cause of the hang is now obvious, but the simplest solution makes me perplex
and does not cover other cases (ProcessLocalVariables, see below).

The problem comes from the display of the object in the lower pane of the debugger
that locks itself because the monitor is owned by the debugged process.
(the inspector ends up in a call to�� xxx>>printOn: aStream to display the object
and SharedQueue>>printOn: aStream starts with a critical block on the monitor).
So we could be hanged in various ways : clicking on the debugger stack on the Sharedqueue context,
opening an inspector on the Sharedqueue etc).
A simple solution is to evaluate the printOn: in the context of the owner process
in SharedQueue (tested and works), but it is specific to SharedQueue.

Does the #printOn: really need a monitor?�� What is it protecting?

* not the stream, ��that is passed in as a parameter from a single thread

* not the class name, that is handled normally

* items size does ��"^ lastIndex - firstIndex + 1" ��in OrderedCollection, which presumably will be inlined and not interruptible, and even if it could be interrupted part way through the calculation to become inconsistent, the value is only printed, so do we really care?

For reference...

�� SharedQueue>>printOn: aStream

�� monitor critical: [

�� aStream��

�� nextPutAll: self class name;

�� nextPutAll: ' with ';

�� print: items size;

�� nextPutAll: ' items' ].

��

When an inspector ask an object to print itself, it does not take into account��the "effective/owner process " part of the object.

For example for�� ProcessLocalVariable (and descendants) it does not work:
�� |�� process variable |
�� process := [ variable := ProcessLocalVariable value: 'hello world' ]
�� forkAt: Processor userInterruptPriority .

�� variable�� value => evaluates to nil

��

this makes it difficult (impossible ?) to inspect/debug - a workaround would be to track��the effective process near the host in the inspector (in AbstractEyeElement?) but��it could be tricky and I do not know implications here.

I am not clear on the semantics we want debugging ProcessLocalVariable, however if without forking I do...

�� variable := ProcessLocalVariable value: 'hello world'

then inspecting /variable/ shows me only...

�� self: a ProcessLocalVariable

�� index: 6

And there is no change when forking...

�� process := [��

variable := ProcessLocalVariable value: 'hello world'.

variable inspect.

] fork.

Also, the following works as expected with respect to the /result/ variable.

�� | ��process variable result |

�� process := [��

�� variable := ProcessLocalVariable value: 'hello world'.

�� self halt.

�� result := variable value.

�� ] fork.

So as ProcessLocalVariable is currently displayed in the debugger there seems no problem (?) for what the debugger displays. ��

cheers -ben

��

| ��process variable result |

process := [��

variable := ProcessLocalVariable value: 'hello world'.

self halt.

result := variable value.

] fork.