Fuel Error in Latest Launcher

> While Fuel was trying to serialize a sort block ([ :a :b | a name < b
> name
> ]), I got CompiledMethod>>errorSubscriptBounds:. One strange thing
> about the
> block is that the outerContext is `SortedCollection>>DoIt`, meaning I
> probably had to initialize it by hand due to a previous Fuel problem.
>
> The odd thing about the error is that this object graph was
> serializing and
> materializing just fine before I upgraded Pharo Launcher.
>
> Call chain:
> CompiledMethod(Object)>>errorSubscriptBounds:
> CompiledMethod(Object)>>at:
> InstructionStream>>interpretNextV3PlusClosureInstructionFor:
> OpalEncoderForV3PlusClosures class>>interpretNextInstructionFor:in:
> InstructionStream>>interpretNextInstructionFor:
> [ (InstructionStream new method: self pc: pc)
> interpretNextInstructionFor: nil ] in
> CompiledMethod(CompiledCode)>>abstractBytecodeMessageAt: in Block: [
> (InstructionStream new method: self pc: pc)...
> BlockClosure>>on:do:
> CompiledMethod(CompiledCode)>>abstractBytecodeMessageAt:
> BlockClosure>>blockCreationBytecodeMessage
> BlockClosure>>endPC
> BlockClosure>>abstractBytecodeMessagesDo:
> BlockClosure>>isClean
> BlockClosure>>shouldBeSubstitutedByCleanCopy
> BlockClosure>>fuelAccept:
> FLLightGeneralMapper>>mapAndTrace:
>
>
>
> -----
> Cheers,
> Sean
> --
> Sent from:
> http://forum.world.st/Pharo-Smalltalk-Developers-f1294837.html

> Eliot Miranda-2 wrote
>>     could you post some more information?
>
> Hey guys, I solved my problem by recreating the blocks in question. I
> got
> lucky that they were all default values, so that was easy. However, if
> the
> problem is an interesting one, I can go back to the corrupt data and
> get the
> info you requested…
>
>
>
> -----
> Cheers,
> Sean
> --
> Sent from:
> http://forum.world.st/Pharo-Smalltalk-Developers-f1294837.html

> On Jun 21, 2018, at 5:48 AM, Sean P. DeNigris <[hidden email]> wrote:
>
> Max Leske wrote
>> if you discovered a compiler
>> bug it would help to post the information.
>
> I'm not sure if it's a bug, but here is the info I know:
> 1. Serialized a block in #60540 32-bit
> 2. Materialized it in same version 64-bit  and it was "broken", i.e.:
>    a. It can't be serialized again as indicated above
>    b. Strangely, its print string in the GT Inspector is the entire source
> code of #outerContext instead of the source code of just the block

>
> aBlock:
> - The following instVars are the same in both images: startup = 56, numArgs
> = 1
> - outerContext also seems the same, with the only obvious exception that the
> #method bytecodes are not all the same
>  - sender = nil
>  - pc = 45
>  - method = (SmallBaselineLoadScript>>#descriptionConflictBlock)
>  - closureOrNil = nil
>  - receiver = aSmallBaselineLoadScript
>
> Let me know if you would like any more info…
>
>
>
>
> -----
> Cheers,
> Sean
> --
> Sent from: http://forum.world.st/Pharo-Smalltalk-Developers-f1294837.html
>

> Max Leske wrote
>>> Where should this bug be reported?
>>> https://github.com/theseion/Fuel/issues ?
>>
>> Yes, please.
>
> https://github.com/theseion/Fuel/issues/234
>
>
>
> -----
> Cheers,
> Sean
> --
> Sent from: http://forum.world.st/Pharo-Smalltalk-Developers-f1294837.html