Re: [Pharo-dev] MNU: receiver of "stepToCallee:" is nil
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 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 >
Re: [Pharo-dev] MNU: receiver of "stepToCallee:" is nil
40233 (September 18.) So that probably solves it :) On 23.09.2014, at 16:30, Clara Allende wrote: > pharo 4, but not the latest image > > 2014-09-23 16:27 GMT+02:00 Clément Bera : > 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 : > 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? > >
Re: [Pharo-dev] MNU: receiver of "stepToCallee:" is nil
On 23.09.2014, at 15:59, Clara Allende 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
Re: [Pharo-dev] MNU: receiver of "stepToCallee:" is nil
On 23.09.2014, at 16:45, Clara Allende 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 : > pharo 4, but not the latest image > > 2014-09-23 16:27 GMT+02:00 Clément Bera : > 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 : > 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? > > >
Re: [Pharo-dev] MNU: receiver of "stepToCallee:" is nil
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
Re: [Pharo-dev] MNU: receiver of "stepToCallee:" is nil
https://pharo.fogbugz.com/f/cases/14060/MNU-receiver-of-stepToCallee-is-nil 2014-09-23 17:48 GMT+02:00 Clément Bera : > 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 : > >> 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 : >> >>> pharo 4, but not the latest image >>> >>> 2014-09-23 16:27 GMT+02:00 Clément Bera : >>> 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 : > 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? > >>> >> >
Re: [Pharo-dev] MNU: receiver of "stepToCallee:" is nil
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 : > 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 : > >> pharo 4, but not the latest image >> >> 2014-09-23 16:27 GMT+02:00 Clément Bera : >> >>> 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 : >>> 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? >>> >>> >> >
Re: [Pharo-dev] MNU: receiver of "stepToCallee:" is nil
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 : > pharo 4, but not the latest image > > 2014-09-23 16:27 GMT+02:00 Clément Bera : > >> 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 : >> >>> 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? >>> >> >> >
Re: [Pharo-dev] MNU: receiver of "stepToCallee:" is nil
pharo 4, but not the latest image 2014-09-23 16:27 GMT+02:00 Clément Bera : > 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 : > >> 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? >> > >
Re: [Pharo-dev] MNU: receiver of "stepToCallee:" is nil
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 : > 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-dev] 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?
