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@gmail.com wrote:
I can now reprocuce corrupt sessions. The trick is to debug DFSession>>numberOfMethodCalls:
- start new session
- debug "DFSession uniqueInstance printString"
- step into #numberOfMehthodCalls
- proceed
- stop the session
- right click on the new session in the session browser and click "Export session"
- 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@usi.ch wrote:
Hi,
Thanks all of you for interest ;)
On May 24, 2013, at 7:15 AM, Max Leske maxleske@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@gmail.com wrote:
On 23.05.2013, at 22:58, Camille Teruel camille.teruel@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@gmail.com > Subject: Re: [Pharo-fuel] [Fuel] SubscriptOutOfBounds: 27 > Date: 23. Mai 2013 14:23:45 MESZ > To: The Fuel Project pharo-fuel@lists.gforge.inria.fr > Reply-To: The Fuel Project pharo-fuel@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@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@usi.ch" roberto.minelli@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@lists.gforge.inria.fr >> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-fuel > > _______________________________________________ > Pharo-fuel mailing list > Pharo-fuel@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@lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-fuel
Pharo-fuel mailing list Pharo-fuel@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-fuel
Pharo-fuel mailing list Pharo-fuel@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-fuel