MNU: receiver of "stepToCallee:" is nil
Hi! When debugging tests, if I just close the debugger without finishing the test run, I get this weird message. Has anybody had this problem before?
On 23.09.2014, at 15:59, Clara Allende <clari.allende@gmail.com> wrote:
Hi! When debugging tests, if I just close the debugger without finishing the test run, I get this weird message. Has anybody had this problem before?
Yes, just five minutes ago, but I was doing weird stuff with processes, so I thought it was my fault. The error happens #runUntilErrorOrReturnFrom:. The error is weird, since âtopContextâ should be set to âthisContextâ. Maybe a compiler problem? Cheers, Max
In the latest Pharo 4, #stepToCallee: is not implemented nor sent. Which version of Pharo are you using ? 2014-09-23 15:59 GMT+02:00 Clara Allende <clari.allende@gmail.com>:
Hi! When debugging tests, if I just close the debugger without finishing the test run, I get this weird message. Has anybody had this problem before?
pharo 4, but not the latest image 2014-09-23 16:27 GMT+02:00 Clément Bera <bera.clement@gmail.com>:
In the latest Pharo 4, #stepToCallee: is not implemented nor sent.
Which version of Pharo are you using ?
2014-09-23 15:59 GMT+02:00 Clara Allende <clari.allende@gmail.com>:
Hi! When debugging tests, if I just close the debugger without finishing the test run, I get this weird message. Has anybody had this problem before?
40233 (September 18.) So that probably solves it :) On 23.09.2014, at 16:30, Clara Allende <clari.allende@gmail.com> wrote:
pharo 4, but not the latest image
2014-09-23 16:27 GMT+02:00 Clément Bera <bera.clement@gmail.com>: In the latest Pharo 4, #stepToCallee: is not implemented nor sent.
Which version of Pharo are you using ?
2014-09-23 15:59 GMT+02:00 Clara Allende <clari.allende@gmail.com>: Hi! When debugging tests, if I just close the debugger without finishing the test run, I get this weird message. Has anybody had this problem before?
Sorry, the message is #stepToCallee (without the colon, my bad). in 40243 I still get it. 2014-09-23 16:30 GMT+02:00 Clara Allende <clari.allende@gmail.com>:
pharo 4, but not the latest image
2014-09-23 16:27 GMT+02:00 Clément Bera <bera.clement@gmail.com>:
In the latest Pharo 4, #stepToCallee: is not implemented nor sent.
Which version of Pharo are you using ?
2014-09-23 15:59 GMT+02:00 Clara Allende <clari.allende@gmail.com>:
Hi! When debugging tests, if I just close the debugger without finishing the test run, I get this weird message. Has anybody had this problem before?
On 23.09.2014, at 16:45, Clara Allende <clari.allende@gmail.com> wrote:
Sorry, the message is #stepToCallee (without the colon, my bad). in 40243 I still get it.
Youâre right. I just checked the latest image and #stepToCallee is implemented in Context and send in #runUntilErrorOrReturnFrom:
2014-09-23 16:30 GMT+02:00 Clara Allende <clari.allende@gmail.com>: pharo 4, but not the latest image
2014-09-23 16:27 GMT+02:00 Clément Bera <bera.clement@gmail.com>: In the latest Pharo 4, #stepToCallee: is not implemented nor sent.
Which version of Pharo are you using ?
2014-09-23 15:59 GMT+02:00 Clara Allende <clari.allende@gmail.com>: Hi! When debugging tests, if I just close the debugger without finishing the test run, I get this weird message. Has anybody had this problem before?
The theory I've had for a while for this issue is that ensure blocks are sometimes not executed when the process is manipulated / terminated from another process (so topContext was not assigned even if in an ensure block). I've tried to fix it but I failed. Can you give a reproduceable case ? And open a bug tracker issue with it ? Thanks. 2014-09-23 16:45 GMT+02:00 Clara Allende <clari.allende@gmail.com>:
Sorry, the message is #stepToCallee (without the colon, my bad). in 40243 I still get it.
2014-09-23 16:30 GMT+02:00 Clara Allende <clari.allende@gmail.com>:
pharo 4, but not the latest image
2014-09-23 16:27 GMT+02:00 Clément Bera <bera.clement@gmail.com>:
In the latest Pharo 4, #stepToCallee: is not implemented nor sent.
Which version of Pharo are you using ?
2014-09-23 15:59 GMT+02:00 Clara Allende <clari.allende@gmail.com>:
Hi! When debugging tests, if I just close the debugger without finishing the test run, I get this weird message. Has anybody had this problem before?
https://pharo.fogbugz.com/f/cases/14060/MNU-receiver-of-stepToCallee-is-nil 2014-09-23 17:48 GMT+02:00 Clément Bera <bera.clement@gmail.com>:
The theory I've had for a while for this issue is that ensure blocks are sometimes not executed when the process is manipulated / terminated from another process (so topContext was not assigned even if in an ensure block). I've tried to fix it but I failed.
Can you give a reproduceable case ? And open a bug tracker issue with it ?
Thanks.
2014-09-23 16:45 GMT+02:00 Clara Allende <clari.allende@gmail.com>:
Sorry, the message is #stepToCallee (without the colon, my bad). in 40243 I still get it.
2014-09-23 16:30 GMT+02:00 Clara Allende <clari.allende@gmail.com>:
pharo 4, but not the latest image
2014-09-23 16:27 GMT+02:00 Clément Bera <bera.clement@gmail.com>:
In the latest Pharo 4, #stepToCallee: is not implemented nor sent.
Which version of Pharo are you using ?
2014-09-23 15:59 GMT+02:00 Clara Allende <clari.allende@gmail.com>:
Hi! When debugging tests, if I just close the debugger without finishing the test run, I get this weird message. Has anybody had this problem before?
On 09/23/2014 08:48 AM, Clément Bera wrote:
The theory I've had for a while for this issue is that ensure blocks are sometimes not executed when the process is manipulated / terminated from another process (so topContext was not assigned even if in an ensure block). I've tried to fix it but I failed.
VW had a long-standing bug (finally fixed some time ago) that when a process was terminated, any unwind blocks that had already started would not finish. This caused us all kinds of grief -- most commonly stuck semaphores due to #critical: blocks not signaling the semaphore. I haven't had time to look into whether Pharo has the same problem, but in my reading through the Exceptions chapter of "Deep into Pharo" it looked like that problem was probably in Pharo, too. I believe that the "correct" (most desirable) behavior for unwind blocks when the process is terminated is that 1) Any unwind blocks that are on the stack but have not yet started evaluation should be run, in order, before the process finally terminates. 2) Any unwind blocks that are in the process of being evaluated should be allowed to finish before proceeding with step 1. 3) Any unwind block that, at any point in its evaluation, signals an exception, should have a handler for that exception in some context within its own evaluation. Any unwind block that signals an exception which it does not handle has given up the right to its own normal completion, and process termination is free to skip the rest of that unwind block. Behavior 1) I believe we already do. We probably also do 3), more or less. I have my doubts about 2). Regards, -Martin
Just for reference, in my case I can reproduce it only because I trick the simulation into thinking that the process Iâm working with is not the active process. Hereâs a test case that reproduces the problem (the process context will be in the handler at the end): testIsTerminatingForcedTermination | process started unwound terminator | process := [ started := true. [ process terminate ] ensure: [ terminator := Processor activeProcess. unwound := true ] ] newProcess. "Because we're simulating, we need to trick the simulation to get into the code for not running processes." [ process suspendedContext selector = #isActiveProcess ] whileFalse: [ process step ]. process popTo: process suspendedContext sender value: false. "Again, trick the simulation into thinking the process is suspended." [ process suspendedContext selector = #popTo: ] whileFalse: [ process step ]. [ process suspendedContext selector = #activeProcess ] whileFalse: [ process step ]. process popTo: process suspendedContext sender value: false. process completeTo: process suspendedContext bottomContext On 23.09.2014, at 19:53, Martin McClure <martin@hand2mouse.com> wrote:
On 09/23/2014 08:48 AM, Clément Bera wrote:
The theory I've had for a while for this issue is that ensure blocks are sometimes not executed when the process is manipulated / terminated from another process (so topContext was not assigned even if in an ensure block). I've tried to fix it but I failed.
VW had a long-standing bug (finally fixed some time ago) that when a process was terminated, any unwind blocks that had already started would not finish. This caused us all kinds of grief -- most commonly stuck semaphores due to #critical: blocks not signaling the semaphore.
I haven't had time to look into whether Pharo has the same problem, but in my reading through the Exceptions chapter of "Deep into Pharo" it looked like that problem was probably in Pharo, too.
I believe that the "correct" (most desirable) behavior for unwind blocks when the process is terminated is that
1) Any unwind blocks that are on the stack but have not yet started evaluation should be run, in order, before the process finally terminates.
2) Any unwind blocks that are in the process of being evaluated should be allowed to finish before proceeding with step 1.
3) Any unwind block that, at any point in its evaluation, signals an exception, should have a handler for that exception in some context within its own evaluation. Any unwind block that signals an exception which it does not handle has given up the right to its own normal completion, and process termination is free to skip the rest of that unwind block.
Behavior 1) I believe we already do. We probably also do 3), more or less. I have my doubts about 2).
Regards,
-Martin
participants (4)
-
Clara Allende -
Clément Bera -
Martin McClure -
Max Leske