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

[Eliot Miranda]

On Tue, Jun 4, 2013 at 11:08 AM, Max Leske <maxleske at gmail.com> wrote:

>
> 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.
>

How does that happen?  It doesn't happen in normal use.  I can see how Fuel
does it.  I can't see how non-Fuel use would do it (other than deliberate
construction).  A closure is created by evaluating the push-closure
bytecode in a specific method, and when this closure is created, it refers,
through its outer context to the method object containing the evaluated
push-closure bytecode.  Since the closure's startpc is derived from the pc
of the push-closure bytecode, there is always a match.

However, when Fuel serializes (IIRC) it serializes a *reference* to a
method in the form of a class-name,selector pair, and this approach can
obviously yield an invalid method.

therefore I think it much more likely that what you;re seeing is a result
of a bug in Fuel than some systemic problem with 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"
>



-- 
best,
Eliot
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.squeakfoundation.org/pipermail/vm-dev/attachments/20130604/69f3e29d/attachment.htm