regression: TestObjectsAsMethods crash in 4.19.5 (not in 4.16.7)

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
21 messages Options
12
Reply | Threaded
Open this post in threaded view
|

regression: TestObjectsAsMethods crash in 4.19.5 (not in 4.16.7)

stes
 
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256


As can be seen in the screenshot at:

http://docs.openindiana.org/handbook/community/squeak/index.html

I'm deselecting the Tests-ObjectsAsMethods test (1 test),
because it causes (reproducible) SIGSEGV on Solaris cc/OpenIndiana gcc.

I think the segmentation fault is new in recent 4.19, I think it didn't happen
a while ago in 4.16.

I can test this as follows: when I install an older version

squeak -version
4.16.7-3775

then I go into test runner: Tests-ObjectsAsMethods and select
TestObjectsAsMethods that works in 4.16.7

Test Runner

...
TestObjectsAsMethods

3 run, 3 passes, 0 expected failures, 0 failures, 0 errors, 0 unexpected passes

But it stopped working in 4.19.x which is from I believe from:

ContextInterpreter VMMaker-dtl.422 uuid: e72b95a0-204e-45a1-a4e4-3ac3c9e7a51a

the interp.c file is automatically generated from VMMaker-dtl.422.

It's reproducible in the sense that if I deselect all tests, and just select
that one single test, I can repeatedly and reproducible SIGSEGV the VM.

When I run the VM under a debugger:

dbx: warning: Bad transition in runtime linker interface. CONSISTENT->CONSISTENT
t@1 (l@1) signal SEGV (no mapping at the fault address) in interpret at line 9120 in file "interp.c"
 9120   foo->freeContexts = longAt((newContext + (BASE_HEADER_SIZE)) + (0 << (SHIFT_FOR_WORD)));

(dbx) where
current thread: t@1
=>[1] interpret(), line 9120 in "interp.c"
  [2] main(argc = 1, argv = 0xfeffe250, envp = 0xfeffe258), line 1484 in "sqUnixMain.c"

The above is from Solaris with cc/dbx but the same thing appears to happen
for me on OpenIndiana with gcc/gdb.

Unfortunately because the code of interp.c is automatically generated,
it looks complicated to me and I don't see what's wrong with those "
freeContext" code.

The crash appears to be in:

                                /* begin internalActivateNewMethod */
                                methodHeader = longAt((foo->newMethod + (BASE_HEADER_SIZE)) + (HeaderIndex << (SHIFT_FOR_WORD)));
                                needsLarge = methodHeader & LargeContextBit;
                                if ((needsLarge == 0) && (foo->freeContexts != NilContext)) {
                                        newContext = foo->freeContexts;
                                        /* begin setFreeContextsAfter: */
                                        foo->freeContexts = longAt((newContext + (BASE_HEADER_SIZE)) + (0 << (SHIFT_FOR_WORD)));
                                } else {
                                        /* begin externalizeIPandSP */

Has anyone seen this ?

Also what is the test
TestObjectsAsMethods
actually doing please ? what is it testing ?


Regards,
David Stes



-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2

iQEcBAEBCAAGBQJgMnV5AAoJEAwpOKXMq1MafEgH/3EWQxaSaVm2g4r/2p99Wc21
P+U+ijqKpVTDfJ1smwV/GsgF0V8ZrZky0k7BzRDAyq3Gi/HGVm0e2bqOAKa1fo2Y
MUS9JHOW4Lys+9qWgT0aLiWypjYlzThtYS0/Lfh013tsF1bBv2eppTceUyq/Zitv
6J0IFvDOspMN/zHwBw/ux3H6uR049boZ3mvk23sp3KIHDc2Yw2kF4TAXBwjZXmVO
UFlIAC4EAahrtNZyLZSIBDbsXOl+wJGmQTsOIBG81pfSFpP6RBrIARcu6enZC3Wc
bwsvWYADs49SKgVq3NBovfyzkZBIW30V82xlVKpOnp6A4FnOYXxQiVm9sNaOVXc=
=34TJ
-----END PGP SIGNATURE-----
Reply | Threaded
Open this post in threaded view
|

Re: regression: TestObjectsAsMethods crash in 4.19.5 (not in 4.16.7)

David T. Lewis
 
Thanks.

Confirmed on Linux amd64, so it is not Solaris/OpenIndiana issue.

Dave

On Sun, Feb 21, 2021 at 04:02:38PM +0100, [hidden email] wrote:

>  
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA256
>
>
> As can be seen in the screenshot at:
>
> http://docs.openindiana.org/handbook/community/squeak/index.html
>
> I'm deselecting the Tests-ObjectsAsMethods test (1 test),
> because it causes (reproducible) SIGSEGV on Solaris cc/OpenIndiana gcc.
>
> I think the segmentation fault is new in recent 4.19, I think it didn't happen
> a while ago in 4.16.
>
> I can test this as follows: when I install an older version
>
> squeak -version
> 4.16.7-3775
>
> then I go into test runner: Tests-ObjectsAsMethods and select
> TestObjectsAsMethods that works in 4.16.7
>
> Test Runner
>
> ...
> TestObjectsAsMethods
>
> 3 run, 3 passes, 0 expected failures, 0 failures, 0 errors, 0 unexpected passes
>
> But it stopped working in 4.19.x which is from I believe from:
>
> ContextInterpreter VMMaker-dtl.422 uuid: e72b95a0-204e-45a1-a4e4-3ac3c9e7a51a
>
> the interp.c file is automatically generated from VMMaker-dtl.422.
>
> It's reproducible in the sense that if I deselect all tests, and just select
> that one single test, I can repeatedly and reproducible SIGSEGV the VM.
>
> When I run the VM under a debugger:
>
> dbx: warning: Bad transition in runtime linker interface. CONSISTENT->CONSISTENT
> t@1 (l@1) signal SEGV (no mapping at the fault address) in interpret at line 9120 in file "interp.c"
>  9120   foo->freeContexts = longAt((newContext + (BASE_HEADER_SIZE)) + (0 << (SHIFT_FOR_WORD)));
>
> (dbx) where
> current thread: t@1
> =>[1] interpret(), line 9120 in "interp.c"
>   [2] main(argc = 1, argv = 0xfeffe250, envp = 0xfeffe258), line 1484 in "sqUnixMain.c"
>
> The above is from Solaris with cc/dbx but the same thing appears to happen
> for me on OpenIndiana with gcc/gdb.
>
> Unfortunately because the code of interp.c is automatically generated,
> it looks complicated to me and I don't see what's wrong with those "
> freeContext" code.
>
> The crash appears to be in:
>
>                                 /* begin internalActivateNewMethod */
>                                 methodHeader = longAt((foo->newMethod + (BASE_HEADER_SIZE)) + (HeaderIndex << (SHIFT_FOR_WORD)));
>                                 needsLarge = methodHeader & LargeContextBit;
>                                 if ((needsLarge == 0) && (foo->freeContexts != NilContext)) {
>                                         newContext = foo->freeContexts;
>                                         /* begin setFreeContextsAfter: */
>                                         foo->freeContexts = longAt((newContext + (BASE_HEADER_SIZE)) + (0 << (SHIFT_FOR_WORD)));
>                                 } else {
>                                         /* begin externalizeIPandSP */
>
> Has anyone seen this ?
>
> Also what is the test
> TestObjectsAsMethods
> actually doing please ? what is it testing ?
>
>
> Regards,
> David Stes
>
>
>
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v2
>
> iQEcBAEBCAAGBQJgMnV5AAoJEAwpOKXMq1MafEgH/3EWQxaSaVm2g4r/2p99Wc21
> P+U+ijqKpVTDfJ1smwV/GsgF0V8ZrZky0k7BzRDAyq3Gi/HGVm0e2bqOAKa1fo2Y
> MUS9JHOW4Lys+9qWgT0aLiWypjYlzThtYS0/Lfh013tsF1bBv2eppTceUyq/Zitv
> 6J0IFvDOspMN/zHwBw/ux3H6uR049boZ3mvk23sp3KIHDc2Yw2kF4TAXBwjZXmVO
> UFlIAC4EAahrtNZyLZSIBDbsXOl+wJGmQTsOIBG81pfSFpP6RBrIARcu6enZC3Wc
> bwsvWYADs49SKgVq3NBovfyzkZBIW30V82xlVKpOnp6A4FnOYXxQiVm9sNaOVXc=
> =34TJ
> -----END PGP SIGNATURE-----
Reply | Threaded
Open this post in threaded view
|

Re: regression: TestObjectsAsMethods crash in 4.19.5 (not in 4.16.7)

David T. Lewis
 
I'm not yet sure what to do about it, but the problem was introduced last
April in VMMaker-dtl.415. Apparently the obsolete primitiveInvokeObjectAsMethod
was not quite as obsolete as I thought it was.

Dave


Name: VMMaker-dtl.415
Author: dtl
Time: 19 April 2020, 5:30:30.208 pm
UUID: 747f8591-57e6-4950-858a-c7fbc22ad1c2
Ancestors: VMMaker-dtl.414

VMMaker 4.19.1
Required for Squeak trunk Collections-eem.885 and above.

Install primitiveArrayBecomeOneWayNoCopyHash as primitive 248, replacing obsolete primitiveInvokeObjectAsMethod.

Fix 128 primitiveArrayBecome to match oscog logic. This a fix from VMMaker.oscog-eem.647 which Eliot explained as follows:
Fix primitiveArrayBecome (the two-way become); it should /not/
specify copyHash.  ObjectMemory ignores the copyHash flag when doing a two-way become, hence the wrong sense of the flag had
no effect.  Hence correctly evaluate testBecomeIdentityHash.

The primitives now do this:
  primitive 72: twoWay: false copyHash: true
  primitive 128: twoWay: true copyHash: false
  primitive 248: twoWay: false copyHash: false
  primitive 249: twoWay: false copyHash: <arg 3 value>



On Sun, Feb 21, 2021 at 11:29:13AM -0500, David T. Lewis wrote:

>  
> Thanks.
>
> Confirmed on Linux amd64, so it is not Solaris/OpenIndiana issue.
>
> Dave
>
> On Sun, Feb 21, 2021 at 04:02:38PM +0100, [hidden email] wrote:
> >  
> > -----BEGIN PGP SIGNED MESSAGE-----
> > Hash: SHA256
> >
> >
> > As can be seen in the screenshot at:
> >
> > http://docs.openindiana.org/handbook/community/squeak/index.html
> >
> > I'm deselecting the Tests-ObjectsAsMethods test (1 test),
> > because it causes (reproducible) SIGSEGV on Solaris cc/OpenIndiana gcc.
> >
> > I think the segmentation fault is new in recent 4.19, I think it didn't happen
> > a while ago in 4.16.
> >
> > I can test this as follows: when I install an older version
> >
> > squeak -version
> > 4.16.7-3775
> >
> > then I go into test runner: Tests-ObjectsAsMethods and select
> > TestObjectsAsMethods that works in 4.16.7
> >
> > Test Runner
> >
> > ...
> > TestObjectsAsMethods
> >
> > 3 run, 3 passes, 0 expected failures, 0 failures, 0 errors, 0 unexpected passes
> >
> > But it stopped working in 4.19.x which is from I believe from:
> >
> > ContextInterpreter VMMaker-dtl.422 uuid: e72b95a0-204e-45a1-a4e4-3ac3c9e7a51a
> >
> > the interp.c file is automatically generated from VMMaker-dtl.422.
> >
> > It's reproducible in the sense that if I deselect all tests, and just select
> > that one single test, I can repeatedly and reproducible SIGSEGV the VM.
> >
> > When I run the VM under a debugger:
> >
> > dbx: warning: Bad transition in runtime linker interface. CONSISTENT->CONSISTENT
> > t@1 (l@1) signal SEGV (no mapping at the fault address) in interpret at line 9120 in file "interp.c"
> >  9120   foo->freeContexts = longAt((newContext + (BASE_HEADER_SIZE)) + (0 << (SHIFT_FOR_WORD)));
> >
> > (dbx) where
> > current thread: t@1
> > =>[1] interpret(), line 9120 in "interp.c"
> >   [2] main(argc = 1, argv = 0xfeffe250, envp = 0xfeffe258), line 1484 in "sqUnixMain.c"
> >
> > The above is from Solaris with cc/dbx but the same thing appears to happen
> > for me on OpenIndiana with gcc/gdb.
> >
> > Unfortunately because the code of interp.c is automatically generated,
> > it looks complicated to me and I don't see what's wrong with those "
> > freeContext" code.
> >
> > The crash appears to be in:
> >
> >                                 /* begin internalActivateNewMethod */
> >                                 methodHeader = longAt((foo->newMethod + (BASE_HEADER_SIZE)) + (HeaderIndex << (SHIFT_FOR_WORD)));
> >                                 needsLarge = methodHeader & LargeContextBit;
> >                                 if ((needsLarge == 0) && (foo->freeContexts != NilContext)) {
> >                                         newContext = foo->freeContexts;
> >                                         /* begin setFreeContextsAfter: */
> >                                         foo->freeContexts = longAt((newContext + (BASE_HEADER_SIZE)) + (0 << (SHIFT_FOR_WORD)));
> >                                 } else {
> >                                         /* begin externalizeIPandSP */
> >
> > Has anyone seen this ?
> >
> > Also what is the test
> > TestObjectsAsMethods
> > actually doing please ? what is it testing ?
> >
> >
> > Regards,
> > David Stes
> >
> >
> >
> > -----BEGIN PGP SIGNATURE-----
> > Version: GnuPG v2
> >
> > iQEcBAEBCAAGBQJgMnV5AAoJEAwpOKXMq1MafEgH/3EWQxaSaVm2g4r/2p99Wc21
> > P+U+ijqKpVTDfJ1smwV/GsgF0V8ZrZky0k7BzRDAyq3Gi/HGVm0e2bqOAKa1fo2Y
> > MUS9JHOW4Lys+9qWgT0aLiWypjYlzThtYS0/Lfh013tsF1bBv2eppTceUyq/Zitv
> > 6J0IFvDOspMN/zHwBw/ux3H6uR049boZ3mvk23sp3KIHDc2Yw2kF4TAXBwjZXmVO
> > UFlIAC4EAahrtNZyLZSIBDbsXOl+wJGmQTsOIBG81pfSFpP6RBrIARcu6enZC3Wc
> > bwsvWYADs49SKgVq3NBovfyzkZBIW30V82xlVKpOnp6A4FnOYXxQiVm9sNaOVXc=
> > =34TJ
> > -----END PGP SIGNATURE-----
Reply | Threaded
Open this post in threaded view
|

Re: regression: TestObjectsAsMethods crash in 4.19.5 (not in 4.16.7)

stes
In reply to this post by stes
 
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256


> Install primitiveArrayBecomeOneWayNoCopyHash as primitive 248
> replacing obsolete primitiveInvokeObjectAsMethod.

That must be it, I guess.

TestObjectsAsMethods used to work for me with the VM 4.16.7

Test Runner

...
TestObjectsAsMethods

3 run, 3 passes, 0 expected failures, 0 failures, 0 errors, 0 unexpected passes

I have no idea whether the test can be simply removed,
maybe if the test is obsoleted, the problem is solved!

But that still leaves the issue of how to use the new VM with an *OLD* image!

I must add that I'm not sure what TestObjectsAsMethods is doing,
and whether there is any code out there that uses this functionality.

Regards,
David Stes

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2

iQEcBAEBCAAGBQJgNMTZAAoJEAwpOKXMq1Ma33QH/joLL1fRFiOiOWVowpB6ESX0
qeVlQvRm02HFk9+che3d3eirqqpp73Vucj4TQabgXsAfJ4GwYKWugNgReyMTJVeK
M62Ue5+UkuiRBQUTxlw5wR3FPsI8OxDP0XBIiad0Qqk8uPjLWcx6uBGXR4NCNE0r
D4Jy94o7L9g+b0zuGhJ711zfLCoicAIkipifCqCjneHzbZK8VXcY7kgdg62PaXcw
JH7DN/glh8gkOyt8qWY+mt13BchEswIh/8m0LdIruviMJtQYUy27/zqadbcf3BFL
2bnkRlVQj+bDLfxhVhr4GAsZHYSrF1zFdNqrO9Xb1fTSj8IAMcDi2exISNsceCs=
=Gqk7
-----END PGP SIGNATURE-----
Reply | Threaded
Open this post in threaded view
|

Re: regression: TestObjectsAsMethods crash in 4.19.5 (not in 4.16.7)

stes
 
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256


> Install primitiveArrayBecomeOneWayNoCopyHash as primitive 248
> replacing obsolete primitiveInvokeObjectAsMethod.

Any news on this Tests-ObjectsAsMethods issue ?

The purpose of those tests are not clear to me;

Perhaps the change for the "primitives" which was made, can be reverted ?

Possibly that creates a new problem for primitiveArrayBecomeOneWayNoCopyHash.

David Stes

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2

iQEcBAEBCAAGBQJgPSIjAAoJEAwpOKXMq1MaKBoIALZFV2hJydzkLUcLB1YDIS5D
7M3E/ucLxvfWoCBygz0/r/TLou2Sk57x9WpGTWpBkMwOlQiPfL5q10Zq5iOZ+qDA
Zbdz3iUHEV8FlVTGoOD4HR+eoblfnNhE6KhhkKb5YqmIVkpXr1UNY5ao/MPOFYV0
s12lTGqznhoh5ZI+i2U+sTDJljNiJojxzvWdq5rJ658PISWFPuqw/YJamQZvKiWx
/HFQf+om5MKPt/jtzfpCxskuJ5evU2XBcTb6dFXzNgeaoqJEsLnnUj08vubHMA34
mRYHk+Pp4SxMYV/0CJ3dWOgOirMN7yVi7tTdKAdJeEmoPqP4cMUMbb8C+xOA5Uc=
=5Ffs
-----END PGP SIGNATURE-----
Reply | Threaded
Open this post in threaded view
|

Re: regression: TestObjectsAsMethods crash in 4.19.5 (not in 4.16.7)

David T. Lewis
 
On Mon, Mar 01, 2021 at 06:20:58PM +0100, [hidden email] wrote:

>  
> > Install primitiveArrayBecomeOneWayNoCopyHash as primitive 248
> > replacing obsolete primitiveInvokeObjectAsMethod.
>
> Any news on this Tests-ObjectsAsMethods issue ?
>
> The purpose of those tests are not clear to me;
>
> Perhaps the change for the "primitives" which was made, can be reverted ?
>
> Possibly that creates a new problem for primitiveArrayBecomeOneWayNoCopyHash.
>
> David Stes
>

You can consider this a bug in the most recent interpreter VMs. I had
failed to notice that there is a hard coded reference to that primitive
number within the VM itself, and this reference is now resulting in
invocation of the wrong function.

A trivial fix is to rearrange some primtive number assignments, but the
correct thing to do is adopt the logic that Eliot uses in oscog so that
the function is not invoked as a "primitive" at all.

I'll try to follow up on this next week.

Dave
Reply | Threaded
Open this post in threaded view
|

Re: regression: TestObjectsAsMethods crash in 4.19.5 (not in 4.16.7)

stes
In reply to this post by stes
 
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256


> A trivial fix is to rearrange some primtive number assignments, but the
> correct thing to do is adopt the logic that Eliot uses in oscog so that
> the function is not invoked as a "primitive" at all.
>
> I'll try to follow up on this next week.

Would it please be possible to commit to subversion the trivial fix,
while waiting for the correct fix.

As I understand it, this means to undo the "primitives" change.

David Stes

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2

iQEcBAEBCAAGBQJgTlXxAAoJEAwpOKXMq1MaG0kH/1aQ1MNWaMkbErs/ce3VcFhN
a/97ONAJ4uMkXT6xHQbt1Pkapx7hpXd7dvLXjFoWQ+lv7dPv7y2ac5mQyjUJs0nY
HrnTh12C8VqP2zwAX1q8AYog7ZSLGqyo8SIRcoM8Lzqbw01SPkN2FuXGz9dqKCwe
+6/D4m+HnfwdeqtazYYNr4dGiJWrkXf/uGiCMWogbJAphxKzokeiKpUD21lBFzyG
2NGzkWncn51z1lZPfLoRfqO/vNQ1jv3q5mOJ8iFJCwsq84k6h300+ZSfO4BvRDFh
zRkoDrNotuNn5VzWpiwNjNrkth2XzLM/MU+m5SKoTKBwQUaNkTa97NVT4U6hzkc=
=EGUN
-----END PGP SIGNATURE-----
Reply | Threaded
Open this post in threaded view
|

Re: regression: TestObjectsAsMethods crash in 4.19.5 (not in 4.16.7)

stes
 
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256


If there exists a solution that simply makes the ObjectsAsMethodsExample
fail (instead of crash) that would also be OK.

For example, I suppose it could be a choice to "abandon"
primitiveInvokeObjectAsMethod() and run:with:in
and to declare it as "obsolete".

It can be a deliberate choice to make the TestObjectsAsMethods *fail*
in the future ... but preferably not crash.

By fail I mean that when running the TestRunner it marks the test as failed,
and continues to run the other tests.  The current situation is that the VM
crashes and all tests are aborted.

TestObjectsAsMethods can be made some sort of an expected failure, I suppose.

Such a solution would be fine for the moment, while waiting for the
definitive fix.

David Stes

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2

iQEcBAEBCAAGBQJgTm59AAoJEAwpOKXMq1MajcUH/1hxKnoJf+rbp/86+yASjxdq
fOlkl48X3iVFK+lqUcMGclpmqjqzShGUryTq9d9S1/8hnVZAesOeB9Y2DCNZcGVS
vO8A33sw1w1cptggb9mvQ1Bg6bZ4kcEMj7znfpnLSDRd7h1NUZluzsBpWG4YEDI9
McBUXTFlHtZ2jjZ4DFLm7B/DkENje9uT696GgFdyR1YChBVclWBJ+x7nYsW98467
NQ7OtMDBjxhSAwiZIzpeuelOST2akXAzPZImg7MU4UTCXpAk7Fst+Ua74Z+lZb6L
JvnjdnSPibpShwcTYo4Woc5LwrFmvwefCdUt5Mh2l9SpZSjE2NQCr7Fo/tdcG3Y=
=VeC2
-----END PGP SIGNATURE-----
Reply | Threaded
Open this post in threaded view
|

Re: regression: TestObjectsAsMethods crash in 4.19.5 (not in 4.16.7)

David T. Lewis
In reply to this post by stes
 
Hi David,

Sorry I did not reply earlier,

On Sun, Mar 14, 2021 at 07:30:25PM +0100, [hidden email] wrote:
>  
> > A trivial fix is to rearrange some primtive number assignments, but the
> > correct thing to do is adopt the logic that Eliot uses in oscog so that
> > the function is not invoked as a "primitive" at all.
> >
> > I'll try to follow up on this next week.
>
> Would it please be possible to commit to subversion the trivial fix,
> while waiting for the correct fix.

Unfortunately no. I tried reassigning primitiveInvokeObjectAsMethod to
an unused primitive number. That worked fine, but I quickly found that
more recent versions of Squeak trunk were using that "unused" primitive
number for some other purpose, so this is a no-go.

A quick and dirty fix is not feasible, it needs to be done right. That
means adapting or adopting Eliot's implementation.


<OT>
  <RANT>
      Numbered primitives are a plague and a pestilence. Please just stop doing that.
  </RANT>
</OT>

Dave

Reply | Threaded
Open this post in threaded view
|

Re: regression: TestObjectsAsMethods crash in 4.19.5 (not in 4.16.7)

stes
In reply to this post by stes
 
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256


If a good solution exists, it's better of course than a quick
(and possibly) wrong short term solution ...

Thanks for having looked into this.

David Stes

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2

iQEcBAEBCAAGBQJgU14JAAoJEAwpOKXMq1MaexAH/2Yrs3XcC5oqvVXtt1e3n1HI
xHn9As+/BO6d2yq7M8Xd86ZP3JuSo/MtvvCAqLX7GlhQDeCG567MBBdX+7g1Cgqt
0U+OTTaaVrzH1YOEeKEXINLyOKhtzgv7mSMzNhvh56Mbo96ww24288P7srG0ozv5
HB+jvLuxiCHPIdQaZcnw4GGI3jQXgZDqADAQ/AYOfX5AvSTda++N+DMxd0o9q5O/
EwbdyOWMMOVNX85q+sQ1VISnm8nzafSmxr6IPW8TuH0c70wRIDOcdpfRHR0Sz1CH
GKE5JJIneIiSsVGL74BU7qVu8fmUviuvw9sX/t94Op0abh/xV0i7RE4nlvVapgk=
=W5VI
-----END PGP SIGNATURE-----
Reply | Threaded
Open this post in threaded view
|

Re: regression: TestObjectsAsMethods crash in 4.19.5 (not in 4.16.7)

codefrau
In reply to this post by David T. Lewis
 
On Mon, Mar 1, 2021 at 16:05 David T. Lewis <[hidden email]> wrote:
 
On Mon, Mar 01, 2021 at 06:20:58PM +0100, [hidden email] wrote:

> > Install primitiveArrayBecomeOneWayNoCopyHash as primitive 248
> > replacing obsolete primitiveInvokeObjectAsMethod.
>
> Any news on this Tests-ObjectsAsMethods issue ?
>
> The purpose of those tests are not clear to me;
>
> Perhaps the change for the "primitives" which was made, can be reverted ?
>
> Possibly that creates a new problem for primitiveArrayBecomeOneWayNoCopyHash.
>
> David Stes
>

You can consider this a bug in the most recent interpreter VMs. I had
failed to notice that there is a hard coded reference to that primitive
number within the VM itself, and this reference is now resulting in
invocation of the wrong function.

A trivial fix is to rearrange some primtive number assignments, but the
correct thing to do is adopt the logic that Eliot uses in oscog so that
the function is not invoked as a "primitive" at all.

I'll try to follow up on this next week.

Dave


This test crashes SqueakJS, too. Could be the same primitive reassignment confusion. 

Can you describe this “hard coded reference”? Under what circumstances is a primitive being called without being an actual primitive?

Vanessa
Reply | Threaded
Open this post in threaded view
|

Re: regression: TestObjectsAsMethods crash in 4.19.5 (not in 4.16.7)

David T. Lewis
 
On Fri, Mar 19, 2021 at 09:11:52AM -0700, Vanessa Freudenberg wrote:

>  
> On Mon, Mar 1, 2021 at 16:05 David T. Lewis <[hidden email]> wrote:
>
> >
> > On Mon, Mar 01, 2021 at 06:20:58PM +0100, [hidden email] wrote:
> > >
> > > > Install primitiveArrayBecomeOneWayNoCopyHash as primitive 248
> > > > replacing obsolete primitiveInvokeObjectAsMethod.
> > >
> > > Any news on this Tests-ObjectsAsMethods issue ?
> > >
> > > The purpose of those tests are not clear to me;
> > >
> > > Perhaps the change for the "primitives" which was made, can be reverted ?
> > >
> > > Possibly that creates a new problem for
> > primitiveArrayBecomeOneWayNoCopyHash.
> > >
> > > David Stes
> > >
> >
> > You can consider this a bug in the most recent interpreter VMs. I had
> > failed to notice that there is a hard coded reference to that primitive
> > number within the VM itself, and this reference is now resulting in
> > invocation of the wrong function.
> >
> > A trivial fix is to rearrange some primtive number assignments, but the
> > correct thing to do is adopt the logic that Eliot uses in oscog so that
> > the function is not invoked as a "primitive" at all.
> >
> > I'll try to follow up on this next week.
> >
> > Dave
>
>
>
> This test crashes SqueakJS, too. Could be the same primitive reassignment
> confusion.
>
> Can you describe this ???hard coded reference???? Under what circumstances is a
> primitive being called without being an actual primitive?
>

Hi Vanessa,

Sorry I did not think about SqueakJS and yes I am sure it is the same issue.

The hard coded reference to primitive 248 is in ContextInterpreter>>lookupMethodInDictionary:
which assumes that primitiveInvokeObjectAsMethod is installed as primitive 248.

I tried assigning primitiveInvokeObjectAsMethod to primitive number 575 in
initializePrimitiveTable (last available entry in the current table, which
appeared to be unused), and changed lookupMethodInDictionary: to call 575
rather than 248.

That worked fine until I tried running a trunk-level V3 image, which failed
because we are now calling primitive 575 for primitiveHighBit.

I'm sure there's some other primitive number we could use to hide
primitiveInvokeObjectAsMethod elsewhere in the primitive table, but this
approach seems obviously wrong to me, and the right thing would be to do
whatever Eliot did in oscog to avoid trying to pretend that this method
is a primitive (which it is not despite its name).

At that point I had no more time to follow up on this, sorry. But that's
where the problem lies, and I'm sure there is a way to do this correctly
based on Eliot's implementation.

Dave

Reply | Threaded
Open this post in threaded view
|

Re: regression: TestObjectsAsMethods crash in 4.19.5 (not in 4.16.7)

codefrau
 


On Fri, Mar 19, 2021 at 11:47 AM David T. Lewis <[hidden email]> wrote:
 
On Fri, Mar 19, 2021 at 09:11:52AM -0700, Vanessa Freudenberg wrote:

> On Mon, Mar 1, 2021 at 16:05 David T. Lewis <[hidden email]> wrote:
>
> >
> > On Mon, Mar 01, 2021 at 06:20:58PM +0100, [hidden email] wrote:
> > >
> > > > Install primitiveArrayBecomeOneWayNoCopyHash as primitive 248
> > > > replacing obsolete primitiveInvokeObjectAsMethod.
> > >
> > > Any news on this Tests-ObjectsAsMethods issue ?
> > >
> > > The purpose of those tests are not clear to me;
> > >
> > > Perhaps the change for the "primitives" which was made, can be reverted ?
> > >
> > > Possibly that creates a new problem for
> > primitiveArrayBecomeOneWayNoCopyHash.
> > >
> > > David Stes
> > >
> >
> > You can consider this a bug in the most recent interpreter VMs. I had
> > failed to notice that there is a hard coded reference to that primitive
> > number within the VM itself, and this reference is now resulting in
> > invocation of the wrong function.
> >
> > A trivial fix is to rearrange some primtive number assignments, but the
> > correct thing to do is adopt the logic that Eliot uses in oscog so that
> > the function is not invoked as a "primitive" at all.
> >
> > I'll try to follow up on this next week.
> >
> > Dave
>
>
>
> This test crashes SqueakJS, too. Could be the same primitive reassignment
> confusion.
>
> Can you describe this ???hard coded reference???? Under what circumstances is a
> primitive being called without being an actual primitive?
>

Hi Vanessa,

Sorry I did not think about SqueakJS and yes I am sure it is the same issue.

The hard coded reference to primitive 248 is in ContextInterpreter>>lookupMethodInDictionary:
which assumes that primitiveInvokeObjectAsMethod is installed as primitive 248.

I tried assigning primitiveInvokeObjectAsMethod to primitive number 575 in
initializePrimitiveTable (last available entry in the current table, which
appeared to be unused), and changed lookupMethodInDictionary: to call 575
rather than 248.

That worked fine until I tried running a trunk-level V3 image, which failed
because we are now calling primitive 575 for primitiveHighBit.

I'm sure there's some other primitive number we could use to hide
primitiveInvokeObjectAsMethod elsewhere in the primitive table, but this
approach seems obviously wrong to me, and the right thing would be to do
whatever Eliot did in oscog to avoid trying to pretend that this method
is a primitive (which it is not despite its name).

At that point I had no more time to follow up on this, sorry. But that's
where the problem lies, and I'm sure there is a way to do this correctly
based on Eliot's implementation.

Dave

Ah that makes sense. Yes, in SqueakJS it is used directly too:


... and the easiest fix would indeed be to assign an unused primitive number, because that would require no changes to the rest of the execution mechanism. Putting it in the lookup phase, and caching it, seems quite elegant. Otherwise we would have to find another place to check that the method dict entry is actually a method, and invoke the run:with:in: mechanism if not.

Vanessa
Reply | Threaded
Open this post in threaded view
|

Re: regression: TestObjectsAsMethods crash in 4.19.5 (not in 4.16.7)

David T. Lewis
 
On Fri, Mar 19, 2021 at 01:14:32PM -0700, Vanessa Freudenberg wrote:

>  
>
> Ah that makes sense. Yes, in SqueakJS it is used directly too:
>
> https://github.com/codefrau/SqueakJS/blob/02d88e6cd5592029071c1939d85181b79a8f0d7a/vm.interpreter.js#L934
>
>
> ... and the easiest fix would indeed be to assign an unused primitive
> number, because that would require no changes to the rest of the
> execution mechanism. Putting it in the lookup phase, and caching it, seems
> quite elegant. Otherwise we would have to find another place to check that
> the method dict entry is actually a method, and invoke the run:with:in:
> mechanism if not.
>

Hmmm that gives me an idea. We can extend the actual size of the primitive
table beyond MaxPrimitiveIndex and hide primitiveInvokeObjectAsMethod there.
That protects it against accidental invocation from the image as more numbered
primitives get added (yuk). I'll give that a try and see how it looks.

Dave

Reply | Threaded
Open this post in threaded view
|

Re: regression: TestObjectsAsMethods crash in 4.19.5 (not in 4.16.7)

David T. Lewis
In reply to this post by stes
 
On Thu, Mar 18, 2021 at 03:05:29PM +0100, [hidden email] wrote:
>
>
> If a good solution exists, it's better of course than a quick
> (and possibly) wrong short term solution ...
>
> Thanks for having looked into this.
>
> David Stes
>

Hi David,

I found a "good enough" solution. Sources are updated in SVN r3799.

Dave
 
Reply | Threaded
Open this post in threaded view
|

Re: regression: TestObjectsAsMethods crash in 4.19.5 (not in 4.16.7)

timrowledge
In reply to this post by David T. Lewis
 


> On 2021-03-20, at 9:01 AM, David T. Lewis <[hidden email]> wrote:
>
> That protects it against accidental invocation from the image as more numbered
> primitives get added (yuk). I'll give that a try and see how it looks.

I really wish for no numbered primitives at all. I thought I had worked out how once upon a time but not quite.

tim
--
tim Rowledge; [hidden email]; http://www.rowledge.org/tim
Diagnostics are the programs that run when nothing else will.


Reply | Threaded
Open this post in threaded view
|

Re: regression: TestObjectsAsMethods crash in 4.19.5 (not in 4.16.7)

stes
In reply to this post by stes
 
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256


Thanks, I've tested the 4.19.6 version and it works.

By it works, I mean that the Tests-ObjectsAsMethods is no longer crashing,
tested on OpenIndiana.

Also I have ran all 3763 tests again (takes a while) to see if the
rest works or continues to work.

I'm having a few failures on Solaris and OpenIndiana in test-suite,
but I'm not worrying too much about them;  a failure is not as bad as a crash.

With 4.19.6 I have the following results on OpenIndiana:

3763 run, 3724 passes, 24 expected failures, 15 failures, 0 errors, 0 unexpected passes

The run:with:in: crash was worse but a crash aborted the entire test-suite.

However that is fixed now - so the abort/crash is no longer happening.

Perhaps run:with:in: is a little bit of an obscure feature of Squeak,
but it looked bad that it was crashing (SIGSEGV) which for a new user,
may be confusing and giving a bad impression (worse than it really is).

Also I'll try to test SqueakJS which is something I have no experience with,
at all (JS = Javascript).

As far as I understand, SqueakJS is a Javascript runtime for Squeak.

I'll try to test that as well ...

I'm learning about all the different runtimes ...

  - squeak-5 (OpenSmalltalk) and squeak-5 Cog Spur (COG VM)
  - squeak-4 classical VM
  - squeakJS javascript

The best results related to run:with:in were with OpenSmalltalk squeak-5 (COG),
but I think the various runtimes have their own strenghts and weaknesses.

Regards,
David Stes

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2

iQEcBAEBCAAGBQJgVkkRAAoJEAwpOKXMq1MaQbcH/ix2VkUQ2mln6TaayK9AV+ME
ocFg6s6Q1eWJx9Y7fkCoKSilYqOEJAadvmzI9a+2cuMFWPI3lzwAj2UCf0zSikkt
9b2hsXYmqDZv2sAGWqSOsokbul00JNHszJP01dVNMBGkw3KgEZ6FPFo3OvMGUyik
ObY/KQs+ltqBXC6WBrBB8n2MWPcsOVdSjpTZ+wwNYfa5QjE3h5LBtObiSOSO0V1n
q2vGNbQ2N6FdPEzDUjG3XQs53YqSrTKxidHFTvjrBmzfOJxCu/KLqZxSnS9OWQ2i
uHbMbbGZLAcL+hWz4RsLjJn/6VGtPDt/ScW5TAgbDDLcTBnQQK9xtQ5VmV/Yt2w=
=qtca
-----END PGP SIGNATURE-----
Reply | Threaded
Open this post in threaded view
|

Re: regression: TestObjectsAsMethods crash in 4.19.5 (not in 4.16.7)

David T. Lewis
 
On Sat, Mar 20, 2021 at 08:14:30PM +0100, [hidden email] wrote:

>
> Also I'll try to test SqueakJS which is something I have no experience with,
> at all (JS = Javascript).
>
> As far as I understand, SqueakJS is a Javascript runtime for Squeak.
>
> I'll try to test that as well ...
>
> I'm learning about all the different runtimes ...
>
>   - squeak-5 (OpenSmalltalk) and squeak-5 Cog Spur (COG VM)
>   - squeak-4 classical VM
>   - squeakJS javascript
>

I certainly encourage you to get acquainted with SqueakJS. It is not the
fastest VM for Squeak, but is it certainly the most portable with respect
to supporting various Squeak images, and it demonstrates that the virtual
machine that runs the Squeak image does not necessarily need to be tied
to any specific operating system or implementation language.

Dave
 
Reply | Threaded
Open this post in threaded view
|

Re: regression: TestObjectsAsMethods crash in 4.19.5 (not in 4.16.7)

Nicolas Cellier
 
Hi all,
just FYI, I had to use a numbered primitive for highBit because to my
knowledge, named primitives cannot be jitted yet...
And the main interest for this primitive is to be jitted.
https://github.com/OpenSmalltalk/opensmalltalk-vm/issues/418

Le sam. 20 mars 2021 à 23:14, David T. Lewis <[hidden email]> a écrit :

>
>
> On Sat, Mar 20, 2021 at 08:14:30PM +0100, [hidden email] wrote:
> >
> > Also I'll try to test SqueakJS which is something I have no experience with,
> > at all (JS = Javascript).
> >
> > As far as I understand, SqueakJS is a Javascript runtime for Squeak.
> >
> > I'll try to test that as well ...
> >
> > I'm learning about all the different runtimes ...
> >
> >   - squeak-5 (OpenSmalltalk) and squeak-5 Cog Spur (COG VM)
> >   - squeak-4 classical VM
> >   - squeakJS javascript
> >
>
> I certainly encourage you to get acquainted with SqueakJS. It is not the
> fastest VM for Squeak, but is it certainly the most portable with respect
> to supporting various Squeak images, and it demonstrates that the virtual
> machine that runs the Squeak image does not necessarily need to be tied
> to any specific operating system or implementation language.
>
> Dave
>
Reply | Threaded
Open this post in threaded view
|

Fast named primitives (was: regression: TestObjectsAsMethods crash in 4.19.5 (not in 4.16.7))

David T. Lewis
In reply to this post by timrowledge
 
On Sun, Mar 21, 2021 at 12:00:04AM +0100, Nicolas Cellier wrote:

>
> On Sat, Mar 20, 2021 at 11:17:23AM -0700, tim Rowledge wrote:
> >
> > > On 2021-03-20, at 9:01 AM, David T. Lewis <[hidden email]> wrote:
> > >
> > > That protects it against accidental invocation from the image as more numbered
> > > primitives get added (yuk). I'll give that a try and see how it looks.
> >
> > I really wish for no numbered primitives at all. I thought I had worked out how once upon a time but not quite.
> >
>
> just FYI, I had to use a numbered primitive for highBit because to my
> knowledge, named primitives cannot be jitted yet...
> And the main interest for this primitive is to be jitted.
> https://github.com/OpenSmalltalk/opensmalltalk-vm/issues/418
>

I wonder if there might be a solution that meets both goals:

  1) From the image, I want to call named primitives

  2) In the VM, I need the primitives to be numbered for fast JIT

Is there some way that a table of primitive numbers could be created
at runtime to support the JIT without requiring a declarative table
of primitive numbers at VM compile time?

Dave
 
12