Unable to finish running tests on current trunk

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

Unable to finish running tests on current trunk

cbc
Hi.

I was running the full test suite (which takes a LONG time), and it encountered a #halt in Decompiler>>pushTemporaryVariable:

When trying to figure out where this was, it appears to be in DecompilerTests>>testDecompilerInClassesCNtoCZ.

Appears to be because the image is now borked - unusuable.  Any attempt to browse one of those classes or methods throws an error about the change file failing (primGetPosition: failed).

Is this related to the "don't log changes while tests are running"?  Or something else.

Also, based on that test name, is it really and truely going through every class in the image an decompiling them?

Thanks,
cbc


Reply | Threaded
Open this post in threaded view
|

Re: Unable to finish running tests on current trunk

Eliot Miranda-2
Hi Chris,

On Wed, Jun 13, 2018 at 8:34 PM, Chris Cunningham <[hidden email]> wrote:
Hi.

I was running the full test suite (which takes a LONG time), and it encountered a #halt in Decompiler>>pushTemporaryVariable:

When trying to figure out where this was, it appears to be in DecompilerTests>>testDecompilerInClassesCNtoCZ.

Appears to be because the image is now borked - unusuable.  Any attempt to browse one of those classes or methods throws an error about the change file failing (primGetPosition: failed).

Is this related to the "don't log changes while tests are running"?  Or something else.

Something else.  It is due to some serious bugs with the full block support that we get with the SistaV1 bytecode set. Full block support implies that blocks are now their own methods, rather than sequences of byte codes and literals embedded in the enclosing compiled method.  I can see a problem in the Decompiler (the halt in Decompiler>>pushTemporaryVariable:) but also a possibly related issue in the debugger where stepping within a full block doesn't highlight the pc correctly.  I'll be looking at these over the next few days (I have a priority that I'll have to squeeze this along side).


Also, based on that test name, is it really and truely going through every class in the image an decompiling them?

Damn right ;-)

Thanks,
cbc

_,,,^..^,,,_
best, Eliot


Reply | Threaded
Open this post in threaded view
|

Re: Unable to finish running tests on current trunk

Eliot Miranda-2
In reply to this post by cbc
Hi Chris,

On Wed, Jun 13, 2018 at 8:34 PM, Chris Cunningham <[hidden email]> wrote:
Hi.

I was running the full test suite (which takes a LONG time), and it encountered a #halt in Decompiler>>pushTemporaryVariable:

When trying to figure out where this was, it appears to be in DecompilerTests>>testDecompilerInClassesCNtoCZ.

Appears to be because the image is now borked - unusuable.  Any attempt to browse one of those classes or methods throws an error about the change file failing (primGetPosition: failed).

Is this related to the "don't log changes while tests are running"?  Or something else.

As stated earlier it is due to bugs in the decompiler/debugger (specifically block start to temp name mapping) in the full block regime.  You should find this fixed in  Compiler-eem.383/Compiler-eem.384.  Thank you _very much_ for spotting this.  It would have been an awful black mark on the new release.

[snip]

_,,,^..^,,,_
best, Eliot


cbc
Reply | Threaded
Open this post in threaded view
|

Re: Unable to finish running tests on current trunk

cbc


On Sat, Jun 16, 2018 at 3:26 PM, Eliot Miranda <[hidden email]> wrote:
Hi Chris,

On Wed, Jun 13, 2018 at 8:34 PM, Chris Cunningham <[hidden email]> wrote:
Hi.

I was running the full test suite (which takes a LONG time), and it encountered a #halt in Decompiler>>pushTemporaryVariable:

When trying to figure out where this was, it appears to be in DecompilerTests>>testDecompilerInClassesCNtoCZ.

Appears to be because the image is now borked - unusuable.  Any attempt to browse one of those classes or methods throws an error about the change file failing (primGetPosition: failed).

Is this related to the "don't log changes while tests are running"?  Or something else.

As stated earlier it is due to bugs in the decompiler/debugger (specifically block start to temp name mapping) in the full block regime.  You should find this fixed in  Compiler-eem.383/Compiler-eem.384.  Thank you _very much_ for spotting this.  It would have been an awful black mark on the new release.
Thank you for fixing it.  Just verifying that it truly does work.
And with a recent/decent cog/spur VM, the full decompiler test of all methods in the image really isn't that slow, either (fast, even - 45 seconds on my machine).
Thanks,
Chris 
[snip]
_,,,^..^,,,_
best, Eliot






Reply | Threaded
Open this post in threaded view
|

Re: Unable to finish running tests on current trunk

Levente Uzonyi
On Sat, 14 Jul 2018, Chris Cunningham wrote:

>
>
> On Sat, Jun 16, 2018 at 3:26 PM, Eliot Miranda <[hidden email]> wrote:
>       Hi Chris,
>       On Wed, Jun 13, 2018 at 8:34 PM, Chris Cunningham <[hidden email]> wrote:
>             Hi.
> I was running the full test suite (which takes a LONG time), and it encountered a #halt in Decompiler>>pushTemporaryVariable:
>
> When trying to figure out where this was, it appears to be in DecompilerTests>>testDecompilerInClassesCNtoCZ.
>
> Appears to be because the image is now borked - unusuable.  Any attempt to browse one of those classes or methods throws an error about the change file failing (primGetPosition: failed).
I've never seen this error before, but I know for sure that if you run
ImageSegmentTest, it will break your image[1].

Levente

[1] http://lists.squeakfoundation.org/pipermail/squeak-dev/2018-June/199208.html

>
> Is this related to the "don't log changes while tests are running"?  Or something else.
>
>
> As stated earlier it is due to bugs in the decompiler/debugger (specifically block start to temp name mapping) in the full block regime.  You should find this fixed
> in  Compiler-eem.383/Compiler-eem.384.  Thank you _very much_ for spotting this.  It would have been an awful black mark on the new release.
>
> Thank you for fixing it.  Just verifying that it truly does work.
> And with a recent/decent cog/spur VM, the full decompiler test of all methods in the image really isn't that slow, either (fast, even - 45 seconds on my machine).
> Thanks,
> Chris 
>       [snip]
>       _,,,^..^,,,_
> best, Eliot
>
>
>
>
>
>