Simulation guard <primitive: 19> crashes the image

Hi, why the simulation guard <primitive: 19> in BlockClosure >> newProcess?

It crashes the image when debugging e.g. [] fork. You hit Into -> Into ->
the the error window pops up, you cancel it (or Abandon...) and hit Into
again and the image is done :|

In case there's no reason to keep the simulation guard why not just remove
it?
Thanks,

Squeak6.0alpha-20243-64bit-202003021730-Windows



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

Hi, why the simulation guard <primitive: 19> in BlockClosure >> newProcess?

It crashes the image when debugging e.g. [] fork. You hit Into -> Into ->
the the error window pops up, you cancel it (or Abandon...) and hit Into
again and the image is done :|

In case there's no reason to keep the simulation guard why not just remove
it?
Thanks,

Squeak6.0alpha-20243-64bit-202003021730-Windows



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

Hi Jaromir,


> On Mar 4, 2021, at 1:03 AM, Jaromir Matas <[hidden email]> wrote:
>
> Hi, why the simulation guard <primitive: 19> in BlockClosure >> newProcess?
>
> It crashes the image when debugging e.g. [] fork. You hit Into -> Into ->
> the the error window pops up, you cancel it (or Abandon...) and hit Into
> again and the image is done :|

I wish it was adequately documented.  I can see some justification, that one doesn’t want simulation to “run away@.  But I can also see the counter argument; one wants the debugger to simply be a way of inspecting any computation.  If always struck me as odd but I’ve not had the courage to nuke it.

>
> In case there's no reason to keep the simulation guard why not just remove
> it?

Well, we have some choices:

a) present the user with a notifier and offer that they proceed of not
b) have a preference
c) spawn a new debugger with the new process (so one now has two debuggers).
d) nuke it
e) leave it unchanged
f...) ?...

I like a. b is too hidden. d has the risk in rare circumstances of surprising behavior; after all someone must have been bitten at one point to want to put the simulation guard in.


> Thanks,
>
> Squeak6.0alpha-20243-64bit-202003021730-Windows
>

Eliot
_,,,^..^,,,_ (phone)


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

Hi Christoph,



Hi Jaromir,

thanks for your report. There are two problems here:

1. The usage of primitive 19 in #newProcess, which I'm glad not to be the only person to find it questionary. I already mentioned this here: http://forum.world.st/Just-another-debugger-bug-primitive-19-td5109411.html IMO the primitive does not make sense in this place, rather we should raise the simulation guard when primitiveSuspend or primitiveResume is invoked via simulation. Still, it is not necessarily a bad thing to let these things happen during simulation - that's why I would prefer to show some confirmation dialog instead of a warning. This is already on my to-do list and a solution for the second aspect should arrive in the Trunk during the next weeks. :-)

Good to hear.  And your point about it not making sense makes me think.  Given fast step, whether one hits the simulation guard or not doesn’t depend on whether one is debugging, but depends on whether one is at just the right point to enter doPrimitive:... rather than just perform:.

Hi Eliot,

I have just uploaded Kernel-ct.1381 to the inbox. Please let me know how you
think about it. :-)

IMHO, the priority of the instantiated process should not be a problem
because #newProcess and variants always use Processor activeProcess for
reference. Rather, we might have a problem when a direct send to Process
class >> #forContext:priority: is simulated where we do not have any
simulation guard installed. But I think by simply showing a warning every
time an attempt is made to resume/suspend a process (as done in
Kernel-ct.1381), we should have fixed this problem, too.

Have a nice weekend!

Best,
Christoph



-----
Carpe Squeak!
--
Sent from: http://forum.world.st/Squeak-Dev-f45488.html