BlockClosure asContext losing bound variable?

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

BlockClosure asContext losing bound variable?

Rob Withers
I am getting a walkback on this code, with a valid vat:

EventualProcess class>>#newOnVat: vat
        ^ super new
                suspendedContext: [
                        vat processSends.
                        Processor terminateActive] asContext;
                 priority: Processor userSchedulingPriority;
                 eventualName: 'vat thread';
                 vat: vat;
                 yourself

once it has been resumed.  The exception is
UndefinedObject(Object)>>doesNotUnderstand: #processSends.  Somehow the vat
variable inside the Closure/MethodContext has become nil.    Anyone know
about this stuff?

Many thanks,
Rob


Reply | Threaded
Open this post in threaded view
|

Re: BlockClosure asContext losing bound variable?

Eliot Miranda-2
Hi Rob, Hi All,

On Sun, Jun 27, 2010 at 3:34 PM, Rob Withers <[hidden email]> wrote:
I am getting a walkback on this code, with a valid vat:

EventualProcess class>>#newOnVat: vat
       ^ super new
               suspendedContext: [
                       vat processSends.
                       Processor terminateActive] asContext;
                priority: Processor userSchedulingPriority;
                eventualName: 'vat thread';
                vat: vat;
                yourself

once it has been resumed.  The exception is UndefinedObject(Object)>>doesNotUnderstand: #processSends.  Somehow the vat variable inside the Closure/MethodContext has become nil.    Anyone know about this stuff?


This is due to a bad bug i the closure support for BlockClosure>>asContext, which was forgetting to push any copied values (in the above case the argument vat) onto the stack of the new context so that when the process resumed the initial pushTemp0 that should push the copied value of vat in fact pushed (at least in the Cog VM) 4 bytes from the middle of the method, and hence bang!

The fixes are in Kernel-eem.468 and Kernel-eem.469.  Its probably best to load Kernel-eem.468 and then Kernel-eem.469 rather than just Kernel-eem.469 because the system will crash if the fixes come i in the wrong order.  Kernel-eem.468 also fixes restart in blocks in the debugger (its the same issue; forgetting to initialize the context with any arguments and copied values; local temps get initialized by explicit pushNil bytecodes).

thanks for the test case Rob!

best
Eliot

P.S. Here are the methods:


Many thanks,
Rob





MethodContext-privRefresh.st (902 bytes) Download Attachment
BlockClosure-asContextWithSender.st (644 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: BlockClosure asContext losing bound variable?

Levente Uzonyi-2
On Thu, 1 Jul 2010, Eliot Miranda wrote:

> Hi Rob, Hi All,
>
> On Sun, Jun 27, 2010 at 3:34 PM, Rob Withers <[hidden email]> wrote:
>
>> I am getting a walkback on this code, with a valid vat:
>>
>> EventualProcess class>>#newOnVat: vat
>>        ^ super new
>>                suspendedContext: [
>>                        vat processSends.
>>                        Processor terminateActive] asContext;
>>                 priority: Processor userSchedulingPriority;
>>                 eventualName: 'vat thread';
>>                 vat: vat;
>>                 yourself
>>
>> once it has been resumed.  The exception is
>> UndefinedObject(Object)>>doesNotUnderstand: #processSends.  Somehow the vat
>> variable inside the Closure/MethodContext has become nil.    Anyone know
>> about this stuff?
>>
>
>
> This is due to a bad bug i the closure support for BlockClosure>>asContext,
> which was forgetting to push any copied values (in the above case the
> argument vat) onto the stack of the new context so that when the process
> resumed the initial pushTemp0 that should push the copied value of vat in
> fact pushed (at least in the Cog VM) 4 bytes from the middle of the method,
> and hence bang!
>
> The fixes are in Kernel-eem.468 and Kernel-eem.469.  Its probably best to
> load Kernel-eem.468 and then Kernel-eem.469 rather than just Kernel-eem.469
> because the system will crash if the fixes come i in the wrong order.
> Kernel-eem.468

Thanks for the fix. I added a new update map to the trunk which makes sure
that Kernel-eem.468 is loaded before Kernel-eem.469.


Levente

> also fixes restart in blocks in the debugger (its the same issue; forgetting
> to initialize the context with any arguments and copied values; local temps
> get initialized by explicit pushNil bytecodes).
>
> thanks for the test case Rob!
>
> best
> Eliot
>
> P.S. Here are the methods:
>
>
>> Many thanks,
>> Rob
>>
>>
>