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

Eliot Miranda eliot.miranda at gmail.com
Fri May 31 20:11:11 UTC 2013


On Fri, May 31, 2013 at 12:54 AM, Max Leske <maxleske at gmail.com> wrote:

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

Max
>
> On 25.05.2013, at 17:56, Max Leske <maxleske at gmail.com> wrote:
>
> > I can now reprocuce corrupt sessions. The trick is to debug
> DFSession>>numberOfMethodCalls:
> > 1. start new session
> > 2. debug "DFSession uniqueInstance printString"
> > 3. step into #numberOfMehthodCalls
> > 4. proceed
> > 5. stop the session
> > 5. right click on the new session in the session browser and click
> "Export session"
> > 6. boom!
> >
> > The reason is of course, that now the compiled method of
> #numberOfMethodCalls is referenced by the session and will be serialized by
> Fuel and when Fuel gets to the corrupt BlockClosure, serialization fails.
> >
> > So the real question still is: how did that BlockClosure obtain a wrong
> start PC? What I find particularly interesting, is that even changing the
> method does not fix the BlockClosure. I added the line "Transcript show:
> 'foo'." before the block (so the block should get a new start PC). Then
> running the procedure detailed above still produced an open debugger.
> > To illustrate that the block did indeed not get fixed I ran
> "BlockClosure allInstances select: [ :e | e startpc = 59 ]", with 59 being
> the new startPC ("55 <8F 01 00 03> closureNumCopied: 0 numArgs: 1 bytes 59
> to 61"). The result does not include the block.
> >
> >
> > Any ideas?
> >
> > Max
> >
> > On 24.05.2013, at 08:10, roberto.minelli at usi.ch wrote:
> >
> >> Hi,
> >>
> >> Thanks all of you for interest ;)
> >>
> >> On May 24, 2013, at 7:15 AM, Max Leske <maxleske at gmail.com>
> >> wrote:
> >>
> >>> I played around with reverting the method and serializing but that
> doesn't change anything (the existing BlockClosure is obviously not
> modified).
> >>> Then I thought that maybe the method was changed during a running
> DFSession but still couldn't reproduce.
> >>
> >> Me neither!!
> >>
> >>>
> >>> @Roberto
> >>> Can you tell us anything about what you did befor / during / after
> running your session?
> >>
> >> Nope. Unfortunately I've a couple of "broken sessions" I cannot
> serialize because of that bug.. But all of them refers sooner or later to
> the DFSession>>#numberOfMethodCalls method. Dunno why.
> >>
> >>> @Roberto
> >>> Is it possible to reproduce the stack with a new session? Or did this
> only happen once?
> >>
> >> I have no clue how to reproduce, but it did not happen only once. As I
> said, there are 3/4 sessions I couldn't export due to this
> SubscriptOutOfBounds.
> >>
> >> Cheers,
> >> Roby
> >>
> >>
> >>>
> >>>
> >>> On 24.05.2013, at 06:44, Max Leske <maxleske at gmail.com> wrote:
> >>>
> >>>>
> >>>> On 23.05.2013, at 22:58, Camille Teruel <camille.teruel at gmail.com>
> wrote:
> >>>>
> >>>>> Hi,
> >>>>>
> >>>>> This is indeed strange, the BlockClosure has an incorrect startpc
> (31 instead of 43). You can fix it with:
> >>>>> theBlock instVar: 2 put: 43.
> >>>>> The wrong startpc corresponds to the beginning of the block in the
> previous version of the method (DFSession>>#numberOfMethodCalls), but I
> don't know why.
> >>>>
> >>>> Would it help to recompile the method?
> >>>>
> >>>>> I don't know fuel enough but could it be because the method of the
> block changed between serialization and materialization?
> >>>>
> >>>> No, there was never a materialization of that session.
> >>>>
> >>>>>
> >>>>> Camille
> >>>>>
> >>>>> On 23 mai 2013, at 21:02, Max Leske wrote:
> >>>>>
> >>>>>> Hi Marcus
> >>>>>>
> >>>>>> Roberto sent this mail to the Fuel-dev list. When we looked at the
> problem we noticed that serialization fails because of a corrupt
> BlockClosure. Since that's not really our territorry Mariano suggested to
> forward this to you.
> >>>>>>
> >>>>>> The image with the corrupt BlockClosure is available here:
> https://dl.dropboxusercontent.com/u/6281855/DFlow-SubscriptOutOfBounds.zip
> .
> >>>>>> To see the stack, right click on the only entry in the right window
> and click "export session". You'll find the corrupt BlockClosure at
> BlockClosure>>fuelAccept:
> >>>>>>
> >>>>>> @Roberto
> >>>>>> Is it possible to reproduce the stack with a new session? Or did
> this only happen once?
> >>>>>>
> >>>>>>
> >>>>>> Cheers,
> >>>>>> Max
> >>>>>>
> >>>>>>
> >>>>>> Begin forwarded message:
> >>>>>>
> >>>>>>> From: Mariano Martinez Peck <marianopeck at gmail.com>
> >>>>>>> Subject: Re: [Pharo-fuel] [Fuel] SubscriptOutOfBounds: 27
> >>>>>>> Date: 23. Mai 2013 14:23:45 MESZ
> >>>>>>> To: The Fuel Project <pharo-fuel at lists.gforge.inria.fr>
> >>>>>>> Reply-To: The Fuel Project <pharo-fuel at lists.gforge.inria.fr>
> >>>>>>>
> >>>>>>> Indeed, it would be nice if you can known which CompiledMethod and
> blockclosure are having the problem. Not only the source code but the real
> bytecodes.
> >>>>>>> Also, can you isolate and just try to serialize them alone and
> reproduce the problem? In other words, a reproducible test case? :)
> >>>>>>> Thanks!
> >>>>>>>
> >>>>>>>
> >>>>>>> On Thu, May 23, 2013 at 8:41 AM, Max Leske <maxleske at gmail.com>
> wrote:
> >>>>>>> What's the compiled method? Is it a special one? Which selector in
> which class?
> >>>>>>>
> >>>>>>> Max
> >>>>>>>
> >>>>>>> On 23.05.2013, at 12:45, "roberto.minelli at usi.ch" <
> roberto.minelli at usi.ch> wrote:
> >>>>>>>
> >>>>>>>> Hi,
> >>>>>>>>
> >>>>>>>> While using Fuel in a 2.0 image to serialize some objects
> (including CompiledMethods) I'm getting this error: SubscriptOutOfBounds:
> 27.
> >>>>>>>>
> >>>>>>>> I spent hours in the debugger before writing this email, but I'm
> not able to figure out why this is happening. I attach the full stack of
> the error (STACK#1).
> >>>>>>>>
> >>>>>>>> I understood that it has something to do with a particular
> CompiledMethod in my image and/or a BlockClosure which for some reason
> cannot be printed (i.e., the printString returns <error in printString:
> evaluate "self printString" to debug>) and when I try to printString to
> debug I got the STACK#2 which in turn does not bring me to any possible
> solution.
> >>>>>>>>
> >>>>>>>> Hope some of you will have an intuition on that or at least tell
> me where to look or how to script a possible workaround.
> >>>>>>>>
> >>>>>>>> Thanks in advance,
> >>>>>>>> Roby
> >>>>>>>>
> >>>>>>>>
> ############################################################################################
> >>>>>>>> ######################################### STACK#1
> ###########################################
> >>>>>>>>
> ###########################################################################################
> >>>>>>>> CompiledMethod(Object)>>errorSubscriptBounds:
> >>>>>>>> CompiledMethod(Object)>>at:
> >>>>>>>> InstructionStream>>interpretNextInstructionFor:
> >>>>>>>> CompiledMethod>>abstractBytecodeMessageAt: in Block:
> [(InstructionStream new method: self pc: pc)...
> >>>>>>>> BlockClosure>>on:do:
> >>>>>>>> CompiledMethod>>abstractBytecodeMessageAt:
> >>>>>>>> BlockClosure>>blockCreationBytecodeMessage
> >>>>>>>> BlockClosure>>endPC
> >>>>>>>> BlockClosure>>abstractBytecodeMessagesDo:
> >>>>>>>> BlockClosure>>isClean
> >>>>>>>> BlockClosure>>shouldBeSubstitutedByCleanCopy
> >>>>>>>> BlockClosure>>fuelAccept:
> >>>>>>>> FLFullGeneralMapper(FLLightGeneralMapper)>>mapAndTrace:
> >>>>>>>> FLFullGlobalMapper>>mapAndTrace: in Block: [(anObject class ==
> CompiledMethod...
> >>>>>>>> FLLargeIdentityDictionary>>at:ifAbsent:
> >>>>>>>> FLFullGlobalMapper>>mapAndTrace:
> >>>>>>>> FLPluggableSubstitutionMapper>>mapAndTrace:
> >>>>>>>> FLPluggableSubstitutionMapper>>mapAndTrace:
> >>>>>>>> FLAnalysis>>mapAndTrace:
> >>>>>>>> FLAnalysis>>run
> >>>>>>>> FLAnalyzer>>setDefaultAnalysis in Block: [:anObject |
> (FLAnalysis...
> >>>>>>>> FLAnalyzer>>analysisFor:
> >>>>>>>> FLSerialization>>analysisStep
> >>>>>>>> FLSerialization>>run
> >>>>>>>> DFSerializer(FLSerializer)>>setDefaultSerialization in Block:
> [:anObject :anEncoder | (FLSerialization...
> >>>>>>>> DFSerializer(FLSerializer)>>serialize:on: in Block: [:anEncoder |
> ...
> >>>>>>>> FLEncoder class>>on:globalEnvironment:do: in Block: [aBlock
> value: anEncoder]
> >>>>>>>> BlockClosure>>ensure:
> >>>>>>>> FLEncoder class>>on:globalEnvironment:do:
> >>>>>>>> DFSerializer(FLSerializer)>>serialize:on:
> >>>>>>>>
> >>>>>>>>
> >>>>>>>>
> ############################################################################################
> >>>>>>>> ######################################### STACK#2
> ###########################################
> >>>>>>>>
> ############################################################################################
> >>>>>>>> Decompiler(Object)>>error:
> >>>>>>>> Decompiler>>decompileBlock:
> >>>>>>>> BlockClosure>>decompile
> >>>>>>>> BlockClosure>>printOn:
> >>>>>>>> BlockClosure(Object)>>printStringLimitedTo: in Block: [:s | self
> printOn: s]
> >>>>>>>> String class(SequenceableCollection
> class)>>streamContents:limitedTo:
> >>>>>>>> BlockClosure(Object)>>printStringLimitedTo:
> >>>>>>>> BlockClosure(Object)>>printString
> >>>>>>>> BlockClosure>>DoIt
> >>>>>>>> Compiler>>evaluate:in:to:notifying:ifFail:logged:
> >>>>>>>> SmalltalkEditor>>evaluateSelectionAndDo: in Block: [rcvr class
> evaluatorClass new...
> >>>>>>>> BlockClosure>>on:do:
> >>>>>>>> SmalltalkEditor>>evaluateSelectionAndDo:
> >>>>>>>> SmalltalkEditor>>evaluateSelection
> >>>>>>>> PluggableTextMorph>>doIt in Block: [textMorph editor
> evaluateSelection]
> >>>>>>>> PluggableTextMorph>>handleEdit: in Block: [result := editBlock
> value]
> >>>>>>>> TextMorphForEditView(TextMorph)>>handleEdit:
> >>>>>>>> PluggableTextMorph>>handleEdit:
> >>>>>>>> PluggableTextMorph>>doIt
> >>>>>>>> SmalltalkEditor class>>buildSmalltalkEditorKeymappingsOn: in
> Block: [:morph | morph doIt]
> >>>>>>>> BlockClosure>>cull:
> >>>>>>>> BlockClosure>>cull:cull:
> >>>>>>>> BlockClosure>>cull:cull:cull:
> >>>>>>>> KMCategoryTarget>>completeMatch:buffer:
> >>>>>>>> KMKeymap>>notifyCompleteMatchTo:buffer: in Block: [:l | l
> completeMatch: self buffer: aBuffer]
> >>>>>>>> Array(SequenceableCollection)>>do:
> >>>>>>>> KMKeymap>>notifyCompleteMatchTo:buffer:
> >>>>>>>> KMKeymap>>onMatchWith:notify:andDo:
> >>>>>>>> KMCategory>>onMatchWith:notify:andDo: in Block: [:entry | entry...
> >>>>>>>> Set>>do:
> >>>>>>>>
> >>>>>>>>
> >>>>>>>>
> >>>>>>>> _______________________________________________
> >>>>>>>> Pharo-fuel mailing list
> >>>>>>>> Pharo-fuel at lists.gforge.inria.fr
> >>>>>>>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-fuel
> >>>>>>>
> >>>>>>> _______________________________________________
> >>>>>>> Pharo-fuel mailing list
> >>>>>>> Pharo-fuel at lists.gforge.inria.fr
> >>>>>>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-fuel
> >>>>>>>
> >>>>>>>
> >>>>>>>
> >>>>>>> --
> >>>>>>> Mariano
> >>>>>>> http://marianopeck.wordpress.com
> >>>>>>> _______________________________________________
> >>>>>>> Pharo-fuel mailing list
> >>>>>>> Pharo-fuel at lists.gforge.inria.fr
> >>>>>>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-fuel
> >>>>>>
> >>>>>
> >>>>
> >>>
> >>> _______________________________________________
> >>> Pharo-fuel mailing list
> >>> Pharo-fuel at lists.gforge.inria.fr
> >>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-fuel
> >>
> >>
> >> _______________________________________________
> >> Pharo-fuel mailing list
> >> Pharo-fuel at lists.gforge.inria.fr
> >> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-fuel
> >
>
>


-- 
best,
Eliot
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.squeakfoundation.org/pipermail/vm-dev/attachments/20130531/97fd3635/attachment-0001.htm


More information about the Vm-dev mailing list