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
Hi Sean, Is it possible that your compiled method has been corrupted? It's the compiler that chokes when Fuel tries to read #endPC, and the compiler should not choke on a well formed compiled method... (or ever for that matter?), Max On 20 Jun 2018, at 15:07, Sean P. DeNigris wrote:
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
Hi Sean, could you post some more information? What's the pc? What's the CompiledMethod's output for #symbolic? Where in interpretNextV3PlusClosureInstructionFor: is it stuck? What's the computed index? On Wed, Jun 20, 2018 at 6:07 AM, Sean P. DeNigris <sean@clipperadams.com> wrote:
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
-- _,,,^..^,,,_ best, Eliot
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
Good on you! I don't need the information for Fuel, but if you discovered a compiler bug it would help to post the information. Max On 21 Jun 2018, at 5:54, Sean P. DeNigris wrote:
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
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
Hi Sean,
On Jun 21, 2018, at 5:48 AM, Sean P. DeNigris <sean@clipperadams.com> 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
Looks like the bug is that Fuel is not adjusting the pcs in Contexts and BlockClosures when loading something saved in a different word size. CompiledCode (CompiledMethod & CompiledBlock) is a hybrid object, the first part being object references (the methodâs header followed by its literals), the second part being bytes (the bytecodes for the method and any additional info encoded in trailing bytes). So in 32 bits a pc is (4*numLiterals+1) less than it is in 64 bits, and Fuel and other code must adjust things accordingly. See CompiledCode>>#initialPC
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
Eliot Miranda-2 wrote
Looks like the bug is that Fuel isâ¦
Ah, glad we identified it! Where should this bug be reported? https://github.com/theseion/Fuel/issues ? ----- Cheers, Sean -- Sent from: http://forum.world.st/Pharo-Smalltalk-Developers-f1294837.html
On 21 Jun 2018, at 15:34, Sean P. DeNigris wrote:
Eliot Miranda-2 wrote
Looks like the bug is that Fuel isâ¦
Ah, glad we identified it!
Where should this bug be reported? https://github.com/theseion/Fuel/issues ?
Yes, please.
----- 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
Thanks Sean. On 21 Jun 2018, at 18:08, Sean P. DeNigris wrote:
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
participants (3)
-
Eliot Miranda -
Max Leske -
Sean P. DeNigris