Hi Marcel,

>> In this discussion, you should always specify whether "responds to"
>> involves a sender within a simulated or genuine "context". ;-) I am still
>> not convinced that this is an actual problem.

Sorry for confusing you, this all new to me :)

How can I convince you? I debug quite naively, no fancy stuff. I'll try
again to show the exact steps replicating the issue using Christoph's
example:

0. downloaded the latest trunk image
Squeak6.0alpha-20304-64bit-202003021730-Windows with Kernel-mt.1381
1. open Process Browser with auto-update on
2. open an explorer window on the current UI process to watch it
3. do-it `[self error: 'e1'] ensure: [^2]` in a Workspace

Now three things happened, as expected (screenshot 1):
a) an Error debugger window popped up
a) the UI process has become suspended
b) a new UI has been created

4. open an explorer window on the new UI process to watch it
5. Abandon the Error window 

And now a couple of highly surprising things happened (screenshot 2):
d) Error window disapeared - that's still expected but
e) the new UI process (88230) disappeared from the Process Browser - NOT
expected
    AND became the genuineProcess - expected
    AND it responds true to isTerminated sent to self in its Explorer window
- NOT expected
f) the old UI process (48259) became the current UI process - NOT expected
     AND became the effectiveProcess - NOT expected
     AND responds true to isActiveProcess sent to self in its Explorer
window - confusing

At this point however the genuine process is indeed not terminated but
executing. It is not shown on the Process Browser however because it filters
out terminated processes. You can verify this by changing first line in
isTerminated, for a moment, to:

    (self isActiveProcess or: [self effectiveProcess == Processor
activeProcess]) ifTrue: [^ false].

And now everything runs as usual as if nothing happened except the really
executing process is hidden from your view and the formerly debugged process
acts as the active process but is not really executing (see screenshot 3
with the invisible process 88230 shown).

6. now I reverted isTerminated back to original and did Christoph's do-it
`self error`

And the rest went as Christoph described; I'd just like to point out the
hidden process 88230 now reappears as the current UI process and correctly
responds true to isActiveProcess e.g. in the Explorer window. In case you
hit Proceed on the Unwind error window the two UI processes above will start
alternating because they are now both runnable in the priority 40 queue.

I find this course of events very unexpected; trying to follow using the
standard tools is very confusing - namely the disappearing genuine process.
I know it's due to the bug Christoph discovered and described but the tools
should rather reveal, not hide information vital for understanding what's
happening :)

I apologize for such a long description and sincerely hope I haven't made
any error here to waste your time.

Thanks,

Screenshot1.png <http://forum.world.st/file/t372955/Screenshot1.png>  
Screenshot2.png <http://forum.world.st/file/t372955/Screenshot2.png>  
Screenshot3.png <http://forum.world.st/file/t372955/Screenshot3.png>  



-----
^[^ Jaromir
--
Sent from: http://forum.world.st/Squeak-Dev-f45488.html