2009/6/25 Andreas Raab andreas.raab@gmx.de:
Igor Stasenko wrote:
I prefer a more shorter way to get puzzled:
type: 0
and then use 'debug it' from menu
:)
There is an easy fix for it, just change one expression in
ParagraphEditor>>debug:receiver:in:
from this
[debugger interruptedContext method == aCompiledMethod] whileFalse: [debugger send].
to instead
[debugger interruptedContext method == aCompiledMethod or:[guineaPig isTerminated]] whileFalse: [debugger send].
The issue is that because the expression has no send the simulation runs away and causes a bunch of problems.
BTW, since this thread is about mastering Squeak, if you can explain why the runaway simulation suspends the simulator process I will personally acknowledge your mastery of Squeak. I couldn't figure out why that happens :-)
1. The compiled method '0' looks like following: all bytecodes: Quick return 0 header: 261 "primitive: 261 numArgs: 0 numTemps: 0 numLiterals: 0 frameSize: 16 isClosureCompiled: false"
2. stepToSendOrReturn doesn't treat this as return:
stepToSendOrReturn "Simulate the execution of bytecodes until either sending a message or returning a value to the receiver (that is, until switching contexts)."
| ctxt | [self willReallySend | self willReturn | self willStore] whileFalse: [ ctxt _ self step. ctxt == self ifFalse: [self halt. "Caused by mustBeBoolean handling" ^ctxt]] neither 'willStore' nor 'willReallySend' nor 'willReturn' checks that method contains no bytecode, but an primitive which does quick return of literal value. I think a #willReturn need to be modified to check against this primitive number. Another way - is to force compiler to not optimize the 'doit' method. Unfortunately squeak's compiler having no option to turn off all optimizations.
3. because of 2. the process continue simulation and returns to a #newProcess: method newProcess "Answer a Process running the code in the receiver. The process is not scheduled." <primitive: 19> "Simulation guard" ^Process forContext: [self value. Processor terminateActive] priority: Processor activePriority
where "Processor terminateActive" effectively kills/suspends the debugger process, because active process is not the simulated process, as this method thinking :)
This could be fixed like following:
newProcess "Answer a Process running the code in the receiver. The process is not scheduled." <primitive: 19> "Simulation guard" | process | ^process := Process forContext: [self value. process terminate] priority: Processor activePriority
--- It seems works at first try, not sure about side effects. I'm letting you to explore :) On debug '0' its now spawns another error: subscript out of bounds. But its not hangs anymore.
Cheers, - Andreas