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

Max Leske maxleske at gmail.com
Fri May 31 07:54:59 UTC 2013 

Bump.

Doesn't anybody feel that corrupt blocks are a problem? IMHO that's something that should *never* happen.

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
>

More information about the Vm-dev mailing list