Simulation guard <primitive: 19> crashes the image

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
5 messages Options
Reply | Threaded
Open this post in threaded view
|

Simulation guard <primitive: 19> crashes the image

Jaromir Matas
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

^[^ Jaromir
Reply | Threaded
Open this post in threaded view
|

Re: Simulation guard <primitive: 19> crashes the image

Christoph Thiede

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. :-)


2. Debugger chains crashing your image, which has already been discussed in great detail in http://forum.world.st/I-broke-the-debugger-td5110752.html#a5124736. I found the cause of the issue and have provided two possible solutions in this thread. Marcel and I are currently discussing the last details of the patch, but it should be complete soon and will arrive in the Trunk, probably together with the extended simulation guard as noted above!


If you find further interesting bugs, please let us know them all. :D


Best,

Christoph


Von: Squeak-dev <[hidden email]> im Auftrag von Jaromir Matas <[hidden email]>
Gesendet: Donnerstag, 4. März 2021 10:03:13
An: [hidden email]
Betreff: [squeak-dev] 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



Carpe Squeak!
Reply | Threaded
Open this post in threaded view
|

Re: Simulation guard <primitive: 19> crashes the image

Eliot Miranda-2
In reply to this post by Jaromir Matas
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
>

Reply | Threaded
Open this post in threaded view
|

Re: Simulation guard <primitive: 19> crashes the image

Eliot Miranda-2
In reply to this post by Christoph Thiede
Hi Christoph,


On Mar 4, 2021, at 3:08 AM, Thiede, Christoph <[hidden email]> wrote:



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:.

So I agree; we should nuke it, with one proviso.  We need to ensure that a newProcess gets Processor activePriority.  ie we need to ensure that Processor activeProcess is always correct.  Some more thought on this is needed.


2. Debugger chains crashing your image, which has already been discussed in great detail in http://forum.world.st/I-broke-the-debugger-td5110752.html#a5124736. I found the cause of the issue and have provided two possible solutions in this thread. Marcel and I are currently discussing the last details of the patch, but it should be complete soon and will arrive in the Trunk, probably together with the extended simulation guard as noted above!


If you find further interesting bugs, please let us know them all. :D


Best,

Christoph


Von: Squeak-dev <[hidden email]> im Auftrag von Jaromir Matas <[hidden email]>
Gesendet: Donnerstag, 4. März 2021 10:03:13
An: [hidden email]
Betreff: [squeak-dev] 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




Reply | Threaded
Open this post in threaded view
|

Re: Simulation guard <primitive: 19> crashes the image

Christoph Thiede
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

Carpe Squeak!