[Vm-dev] Re: [Pharo-fuel] [Pharo-dev] Corrupt BlockClosure

[Max Leske]

Thanks for your reply Eliot.

Maybe you're right and serializing blocks in the way we do is not the best. In my opinion however, that's not the issue here. I don't have any deep knowledge about bytecodes and closures but as I described, the block is corrupt without *any* interaction from Fuel (at least as far as I can tell from debugging the issue). Fuel can not finish the serialization, hence there's no materialization (or reconstruction as you call it) later either. The block is simply corrupt and even changing the method so that the startpc of the block changes, does not fix the block (the value of the startpc doesn't change and is still that of the first version of the method).

So what I'm worried about has nothing to do with Fuel but with the fact that it's possible to (somehow) create corrupt closures.


>>> Bump.
>>> 
>>> Doesn't anybody feel that corrupt blocks are a problem? IMHO that's
>>> something that should *never* happen.
>>> 
>> 
>> But what's happening here is that the Fuel serializer is allowing the
>> serialization of blocks without serializing their outer context and method,
>> and later the reconstruction of blocks against the *wrong* version of a
>> method.  This is a Fuel bug.  IMO the right solution is for Fuel to
>> serialize the method of the block, and on reconstruction replace the
>> reconstructed method with the method in the system iff the reconstructed
>> method is the same as that in the system, but substitute the recinstructed
>> method if it differs from the system's version (or of course if the
>> system;s version is missing).  this mimics the system's behaviour with
>> unbound methods, where e.g. a block holds onto a method and the code of a
>> class is recompiled, resulting iun that block holding onto an unbound
>> method.
>> 
> 
> Sorry, "without serializing their outer context and method" is wrong;
> "without serializing their method"