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: 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:
_______________________________________________ Pharo-project mailing list [hidden email] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project MethodContext-privRefresh.st (902 bytes) Download Attachment BlockClosure-asContextWithSender.st (644 bytes) Download Attachment |
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 >> >> > _______________________________________________ Pharo-project mailing list [hidden email] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project |
Free forum by Nabble | Edit this page |