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

Fri May 24 06:33:38 UTC 2013

Begin forwarded message:

> From: "roberto.minelli at usi.ch" <roberto.minelli at usi.ch>
> Subject: Re: [Pharo-fuel] [Pharo-dev] Corrupt BlockClosure
> Date: 24. Mai 2013 08:10:19 MESZ
> To: The Fuel Project <pharo-fuel at lists.gforge.inria.fr>
> Reply-To: The Fuel Project <pharo-fuel at lists.gforge.inria.fr>
> 
> 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

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.squeakfoundation.org/pipermail/vm-dev/attachments/20130524/b5bd8cd2/attachment.htm