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. 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. Any comment/idea/advice is welcome I can submit the workaround specific to SharedQueue in the meantime. TIA -- Regards, Alain