Smalltalk › Squeak › Squeak - Dev

Unable to finish running tests on current trunk

_‹ Previous Topic Next Topic _›

Classic

List

Threaded

5 messages Options

cbc

Unable to finish running tests on current trunk

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

Eliot Miranda-2

Re: Unable to finish running tests on current trunk

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

Eliot Miranda-2

Re: Unable to finish running tests on current trunk

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

Re: Unable to finish running tests on current trunk

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

Levente Uzonyi

Re: Unable to finish running tests on current trunk

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
>
>
>
>
>
>