On 29 January 2015 at 09:06, Tobias Pape Das.Linux@gmx.de wrote:

Hi

On 29.01.2015, at 09:50, Marcel Taeumel marcel.taeumel@student.hpi.uni-potsdam.de wrote:

...

Hi!

There are process-specific variables. However, #doStep in Debugger does #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 that somehow?

The same problem exists for DynamicVariables that are not implemented with process-specific variables but with Notifications. Just want to throw that in :)

Yes: debugging with dynamic variables is Hard(tm), regardless of whether nice (delimited, through Notifications) or nasty (undelimited, through ProcessSpecificVariable), because you typically want the value of the variable in the context in which the code under debug is running, but asking it "what is your value?" returns the value of the variable in the context of the debugger.

Which I guess is the answer: the debugger needs to recognise you're working with a dynamic variable, and it must perform that current-value-lookup in the correct context (that of the process you're debugging).

frank

Best -Tobias

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

Levente

On Thu, 29 Jan 2015, Eliot Miranda wrote:

Hi Marcel,     can you give a specific example?  Andreas and I came up with a solution 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 Debugger does
  #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 that somehow?

  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

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 a

solution 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 Debugger

does #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 that

somehow?

  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