On Thu, Jan 29, 2015 at 12:29 PM, Eliot Miranda eliot.miranda@gmail.com wrote:
Hi Levente,
On Thu, Jan 29, 2015 at 10:29 AM, Levente Uzonyi leves@elte.hu wrote:
That would help, but it seems like the effectiveProcess variable is not set correctly. At least I don't see it being set while debugging the following:
| ep | ep := Processor activeProcess instVarNamed: #effectiveProcess. self haltIf: ep isNil
That is correct behavior. effectiveProcess is only ever non-nil in the process the debugger is using to run code on behalf of another. In a normal process effectiveProcess is always nil, and therefore the effectiveProcess is the process itself. Try this instead, stepping over the second environment access. If you look at the stack top you'll see it is #present.
Processor activeProcess environmentAt: #foo put: #present. self halt. Processor activeProcess environmentAt: #foo
Try it without the System-eem.699 changes and you'll get the environment key not found error.
Hmmm. Perhaps a better fix would be to install the debugged process's env in the debugger's process during evaluate:onBehalfOf:
Levente
On Thu, 29 Jan 2015, Eliot Miranda wrote:
Hi Marcel,
can you give a specific example? Andreas and I came up with asolution for accessing Processor activeProcess correctly in the debugger. It works like this:
ProcessorScheduler>>activeProcess ^activeProcess effectiveProcess
Process>>effectiveProcess "effectiveProcess is a mechanism to allow process-faithful debugging. The debugger executes code on behalf of processes, so unless some effort is made the identity of Processor activeProcess is not correctly maintained when debugging code. The debugger uses evaluate:onBehalfOf: to assign the debugged process as the effectiveProcess of the process executing the code, preserving process identity." ^effectiveProcess ifNil: [self]
Process>>evaluate: aBlock onBehalfOf: aProcess "Evaluate aBlock setting effectiveProcess to aProcess. Used in the execution simulation machinery to ensure that Processor activeProcess evaluates correctly when debugging." | oldEffectiveProcess | oldEffectiveProcess := effectiveProcess. effectiveProcess := aProcess. ^aBlock ensure: [effectiveProcess := oldEffectiveProcess]
and then in activateReturn:value: complete: popTo: popTo:value: return:value: step step: stepToCallee stepToSendOrReturn it is used as in
Process>>step
^Processor activeProcess evaluate: [suspendedContext := suspendedContext step] onBehalfOf: self
Perhaps all that is needed is the access of process-specific variables to use effectiveProcess?
On Thu, Jan 29, 2015 at 12:50 AM, Marcel Taeumel < marcel.taeumel@student.hpi.uni-potsdam.de> wrote: Hi!
There are process-specific variables. However, #doStep in Debuggerdoes #completeStep: on the process object and Processor >> #activeProcess will be wrong during that execution.
Is this a general problem of global state or could we fix thatsomehow?
Best, Marcel -- View this message in context: http://forum.world.st/Process-specific-state-difficult-to-debug-tp4802422.html Sent from the Squeak - Dev mailing list archive at Nabble.com.
-- best,Eliot
-- best, Eliot