Smalltalk › Squeak › Squeak - Dev

Updating a 5.3-19335 image fails on Pi

_‹ Previous Topic Next Topic _›

Classic

List

Threaded

8 messages Options

timrowledge

Updating a 5.3-19335 image fails on Pi

I just asked my 5.3 alpha 19335 image to update. It has failed in a really interesting way whilst doing the #recompileAll triggered by the update-eem.463.mcm - the swap to Sista bytecodes.

When recompiling MVCUIManager class>dialogStringFromQuery:withTitle: method the argument selector is not identical to the methodNode selector! The two have identical characters (easily shown by
`selector asString = methodNode selector asString` -> true) but somehow the symbol handling has not dealt with ensuring uniqueness.

I have made an attempt at debugging this but somehow ended up with a broken debugger, which is always such fun.

The problem does NOT arise when doing the same update on a 64bit image on my Mac, leading me to suspect some corner of 32/64 differences.

However - to make life even more puzzling this morning... I tried restarting the same image and re-doing the update. And it did not fail. So I dunno; something very strange but not reproducible immediately. Worth recording I suppose just in case it triggers a wise thought from somebody some day.

tim
--
tim Rowledge; [hidden email]; http://www.rowledge.org/tim
Useful random insult:- Thinks E=MC^2 is a rap star.

Eliot Miranda-2

Re: Updating a 5.3-19335 image fails on Pi

Hi Tim,

please, if you have it, take a pristine copy of the image and changes prior to the update and eg upload them to ftp.mirandabanda.org

_,,,^..^,,,_ (phone)

> On May 9, 2020, at 11:15 AM, tim Rowledge <[hidden email]> wrote:
>
> I just asked my 5.3 alpha 19335 image to update. It has failed in a really interesting way whilst doing the #recompileAll triggered by the update-eem.463.mcm - the swap to Sista bytecodes.
>
> When recompiling MVCUIManager class>dialogStringFromQuery:withTitle: method the argument selector is not identical to the methodNode selector! The two have identical characters (easily shown by
> `selector asString = methodNode selector asString` -> true) but somehow the symbol handling has not dealt with ensuring uniqueness.
>
> I have made an attempt at debugging this but somehow ended up with a broken debugger, which is always such fun.
>
> The problem does NOT arise when doing the same update on a 64bit image on my Mac, leading me to suspect some corner of 32/64 differences.
>
> However - to make life even more puzzling this morning... I tried restarting the same image and re-doing the update. And it did not fail. So I dunno; something very strange but not reproducible immediately. Worth recording I suppose just in case it triggers a wise thought from somebody some day.
>
> tim
> --
> tim Rowledge; [hidden email]; http://www.rowledge.org/tim
> Useful random insult:- Thinks E=MC^2 is a rap star.
>
>
>

timrowledge

Re: Updating a 5.3-19335 image fails on Pi

> On 2020-05-09, at 11:31 AM, Eliot Miranda <[hidden email]> wrote:
>
> Hi Tim,
>
> please, if you have it, take a pristine copy of the image and changes prior to the update and eg upload them to ftp.mirandabanda.org

I would happily do so if that ftp site appeared to exist in the same universe as my web browser :-)

Side notes - long ago I remember #recompileAll being a go-to-lunvh operation. Now on a Pi 4 it took all of a couple of minutes even with interruptions for some syntax errors where we *still* have a few methods using _ as assign. Oh and an assign-to-block-arg.

tim
--
tim Rowledge; [hidden email]; http://www.rowledge.org/tim
The world will end in 5 minutes. Please log out.

Nicolas Cellier

Re: Updating a 5.3-19335 image fails on Pi

In reply to this post by Eliot Miranda-2

Hi Tim,

From time to time I experience this exact same problem. It's not new, just rare. There are two different instances of the same Symbol... i have patched with a workaround, but I'd be curious to learn how this happens...

Le sam. 9 mai 2020 à 20:31, Eliot Miranda <[hidden email]> a écrit :

Hi Tim,

please, if you have it, take a pristine copy of the image and changes prior to the update and eg upload them to ftp.mirandabanda.org

_,,,^..^,,,_ (phone)

> On May 9, 2020, at 11:15 AM, tim Rowledge <[hidden email]> wrote:
>
> I just asked my 5.3 alpha 19335 image to update. It has failed in a really interesting way whilst doing the #recompileAll triggered by the update-eem.463.mcm - the swap to Sista bytecodes.
>
> When recompiling MVCUIManager class>dialogStringFromQuery:withTitle: method the argument selector is not identical to the methodNode selector! The two have identical characters (easily shown by
> `selector asString = methodNode selector asString` -> true) but somehow the symbol handling has not dealt with ensuring uniqueness.
>
> I have made an attempt at debugging this but somehow ended up with a broken debugger, which is always such fun.
>
> The problem does NOT arise when doing the same update on a 64bit image on my Mac, leading me to suspect some corner of 32/64 differences.
>
> However - to make life even more puzzling this morning... I tried restarting the same image and re-doing the update. And it did not fail. So I dunno; something very strange but not reproducible immediately. Worth recording I suppose just in case it triggers a wise thought from somebody some day.
>
> tim
> --
> tim Rowledge; [hidden email]; http://www.rowledge.org/tim
> Useful random insult:- Thinks E=MC^2 is a rap star.
>
>
>

Behavior-recompilefrom.st (1K) Download Attachment

timrowledge

Re: Updating a 5.3-19335 image fails on Pi

> On 2020-05-09, at 12:11 PM, Nicolas Cellier <[hidden email]> wrote:
>
> Hi Tim,
> From time to time I experience this exact same problem. It's not new, just rare. There are two different instances of the same Symbol... i have patched with a workaround, but I'd be curious to learn how this happens...
>

Well, that *is* interesting. Obviously shouldn't happen, so what is behind it?

In the depths of the compile stuff I saw that the selector is derived from the source input in Parser>>#method:context:right at the beginning
` sap := self pattern: doit inContext: ctxt.
self properties selector: (sap at: 1).
encoder selector: (sap at: 1).`
The Parser>>#pattern:inContext: code clearly sends asSymbol to the string it extracts, which in turn leads us to #like: in WeakSet, which of course relies on hash values and we have had a little fun with those and 32/64 bit stuff.

tim
--
tim Rowledge; [hidden email]; http://www.rowledge.org/tim
Strange OpCodes: RC: Rewind Core

timrowledge

Re: Updating a 5.3-19335 image fails on Pi

> On 2020-05-09, at 12:31 PM, tim Rowledge <[hidden email]> wrote:
>
> The Parser>>#pattern:inContext: code clearly sends asSymbol to the string it extracts, which in turn leads us to #like: in WeakSet, which of course relies on hash values and we have had a little fun with those and 32/64 bit stuff.

Hmm, the hashing of the string is done in the MiscPrimitivePlugin; didn't we have some fun with that too, recently? Similarly the string collation to match the string with the content of the symbol. How any of that can be non-deterministic I just don't know.

tim
--
tim Rowledge; [hidden email]; http://www.rowledge.org/tim
Make it right before you make it faster.

Nicolas Cellier

Re: Updating a 5.3-19335 image fails on Pi

Le sam. 9 mai 2020 à 21:57, tim Rowledge <[hidden email]> a écrit :

> On 2020-05-09, at 12:31 PM, tim Rowledge <[hidden email]> wrote:
>
> The Parser>>#pattern:inContext: code clearly sends asSymbol to the string it extracts, which in turn leads us to #like: in WeakSet, which of course relies on hash values and we have had a little fun with those and 32/64 bit stuff.

Hmm, the hashing of the string is done in the MiscPrimitivePlugin; didn't we have some fun with that too, recently? Similarly the string collation to match the string with the content of the symbol. How any of that can be non-deterministic I just don't know.

String/Symbol hash is pretty deterministic I hope...

#like: hash hex -> '16r7FA4E7F' both on 32 and 64 bits image/VM.

As a reformulation of the problem, #like: looks maybe like a Symbol, but not the one we like.

tim
--
tim Rowledge; [hidden email]; http://www.rowledge.org/tim
Make it right before you make it faster.

K K Subbu

Re: Updating a 5.3-19335 image fails on Pi

In reply to this post by Nicolas Cellier

On 10/05/20 12:41 am, Nicolas Cellier wrote:
> Hi Tim,
> From time to time I experience this exact same problem. It's not new,
> just rare. There are two different instances of the same Symbol... i
> have patched with a workaround, but I'd be curious to learn how this
> happens...

Is there a integrity test that can be run on all the objects in memory
to catch this type of error? perhaps during full GC?

Will it require a build.assert?

Regards .. Subbu