Smalltalk › Squeak › Squeak - Dev

Failed Tests for 5.3-19647

_‹ Previous Topic Next Topic _›

Classic

List

Threaded

8 messages Options

timrowledge

Failed Tests for 5.3-19647

After managing to do that update I returned to what I had been thinking about in order to suggest some fixes for the failing tests.

In this update image I get 5031 tests run, 16 failures and 48 errors. Note again that this is a 32bit image on a Pi.

The testrunner stopped with a notifier complaIning about a failed socket prim in SqueakSSLTest>>#testSSLSockets and I suppose it may well be due to the previously mentioned very out of date certificate. Is anyone seeing this test pass? And shouldn't the testrunner be trapping the errors and not showing notitifers?

I'm going to attach screenshots of the lists of failures since we don't have a way to save a list.

You can ignore the mouse buttons preference since I swap mouse buttons to be the PROPER way.

The second failure is the #testBecomeForwardIdentityHash where the has is not transferred correctly. This was a recent topic of list discussions and IIRC a vm fix. Perhaps it didn't make it into the 5.0-202004292351 vm?

The next problem, CaseErrorTest>testCaseErrorInPrintOn simply locked up the system completely as soon as I tried to run it to examine the code; evidently one of those cases where it went wild in a way that screwed over any attempt to cmd-. We really need to find ways to stop this sort of nastiness. I left it running for about 5 minutes before getting too bored to leave it any more. In another attempted run that test did actually terminate when run via the 'Run Failures' button.

The undeclared test fails because there are two Undelcreds - MirrorPrimitives and WindowColorSpec.

#testFindSelector is an interesting case since it looks like it might relate to the problem I had updating - a symbol and string finding a selector etc.

So, not a very good result and I haven't got to the errors list yet.

tim
--
tim Rowledge; [hidden email]; http://www.rowledge.org/tim
Cashew: nut that makes you sneeze

timrowledge

Re: Failed Tests for 5.3-19647

> On 2020-05-09, at 7:49 PM, tim Rowledge <[hidden email]> wrote:
>
> The next problem, CaseErrorTest>testCaseErrorInPrintOn simply locked up the system completely as soon as I tried to run it to examine the code; evidently one of those cases where it went wild in a way that screwed over any attempt to cmd-. We really need to find ways to stop this sort of nastiness. I left it running for about 5 minutes before getting too bored to leave it any more. In another attempted run that test did actually terminate when run via the 'Run Failures' button.

Sigh, well of course it is in infinite recursion. #printOn: is re-implemented in CaseErrorTestObject in order to cause the caseError.
What is the original intention of this test case? So far as I can see the #aseError method can never get as far as actually raising the error that the test hopes to catch.

tim
--
tim Rowledge; [hidden email]; http://www.rowledge.org/tim
"!sgub evah t'nseod CP sihT ?sgub naem ayaddahW"

timrowledge

Re: Failed Tests for 5.3-19647

More results in digging into this list of failures -

A partial explanation for the failed socket (not just the SSL) tests - I remembered that we recently decided to turn on the IPv6 switch to see what happens. Well, on a Pi all the socket tests fail. Turn off IPv6 and they all pass. Sigh. Is there some magic I would need to do to turn on IPv6 on Raspbian? Is it a compile flag issue in the VM build?

Though not of course the SSL ones; that seems to need a new certificate, however one handles that. Can we make a new certificate?

A partial explanation of what is happening in the BecomeTest>>#testBecomeForwardIdentityHash code - instead of both objects getting the original identity hash of 'a', they get the hash of 'b'.

BitmapStreamTests>>#testOtherClasses fails because PointArray new:3 makes an array with 6 slots (because x & y values) and so reports a #basicSize -> 6, but still uses 4 bytes per slot and thus fails the test since 6 * 4 is not 12. I suggest we might want to over-ride #byteSize in PointArray to solve this.

SpectrumAnalyzerMorph>>#showSonogram needs fixing to remove the underscore assign.

Eight pacakge dependency tests need some attention -
PackageDependencyTest>>#testCollections
PackageDependencyTest>>#testMorphic
PackageDependencyTest>>#testMultilingual
PackageDependencyTest>>#testNetwork
PackageDependencyTest>>#testPreferenceBrowser
PackageDependencyTest>>#testProtocols
PackageDependencyTest>>#testShoutCore
ST80PackageDependencyTest>>#testST80

WriteBarrierTest refers to Undeclared 'MirrorPrimitives'
The deprecated Object class>>#windowColorSpecification referes to Undeclared 'WindowColorSpec'.

tim
--
tim Rowledge; [hidden email]; http://www.rowledge.org/tim
A bug in the hand is better than one as yet undetected.

David T. Lewis

Re: Failed Tests for 5.3-19647

On Sun, May 10, 2020 at 11:50:35AM -0700, tim Rowledge wrote:
> More results in digging into this list of failures -
>
> A partial explanation for the failed socket (not just the SSL) tests - I remembered that we recently decided to turn on the IPv6 switch to see what happens. Well, on a Pi all the socket tests fail. Turn off IPv6 and they all pass. Sigh. Is there some magic I would need to do to turn on IPv6 on Raspbian? Is it a compile flag issue in the VM build?
>

The IPv6 primitives are all in SocketPlugin. I would not expect the actual primitives
to work any differently, but as Windows users have noticed there are definitely
differences in the resolvers on different platforms, and you may be hitting issues
related to that. Also, I think that some of our network code assumes that there
is such a thing as "the IP address of my computer", which is generally wrong and
probably causes mischief in some of the tests. My best suggestion would be just
to step slowly though any of the failing tests and see if you can spot where
it's getting confused.

Also, try turning off the "EnableIPv6" preference and see if the tests start passing.

Dave

> Though not of course the SSL ones; that seems to need a new certificate, however one handles that. Can we make a new certificate?
>
> A partial explanation of what is happening in the BecomeTest>>#testBecomeForwardIdentityHash code - instead of both objects getting the original identity hash of 'a', they get the hash of 'b'.
>
> BitmapStreamTests>>#testOtherClasses fails because PointArray new:3 makes an array with 6 slots (because x & y values) and so reports a #basicSize -> 6, but still uses 4 bytes per slot and thus fails the test since 6 * 4 is not 12. I suggest we might want to over-ride #byteSize in PointArray to solve this.
>
> SpectrumAnalyzerMorph>>#showSonogram needs fixing to remove the underscore assign.
>
> Eight pacakge dependency tests need some attention -
> PackageDependencyTest>>#testCollections
> PackageDependencyTest>>#testMorphic
> PackageDependencyTest>>#testMultilingual
> PackageDependencyTest>>#testNetwork
> PackageDependencyTest>>#testPreferenceBrowser
> PackageDependencyTest>>#testProtocols
> PackageDependencyTest>>#testShoutCore
> ST80PackageDependencyTest>>#testST80
>
> WriteBarrierTest refers to Undeclared 'MirrorPrimitives'
> The deprecated Object class>>#windowColorSpecification referes to Undeclared 'WindowColorSpec'.
>
> tim
> --
> tim Rowledge; [hidden email]; http://www.rowledge.org/tim
> A bug in the hand is better than one as yet undetected.
>
>
>

timrowledge

Re: Failed Tests for 5.3-19647

> On 2020-05-10, at 1:58 PM, David T. Lewis <[hidden email]> wrote:
>
> On Sun, May 10, 2020 at 11:50:35AM -0700, tim Rowledge wrote:
>> More results in digging into this list of failures -
>>
>> A partial explanation for the failed socket (not just the SSL) tests - I remembered that we recently decided to turn on the IPv6 switch to see what happens. Well, on a Pi all the socket tests fail. Turn off IPv6 and they all pass. Sigh. Is there some magic I would need to do to turn on IPv6 on Raspbian? Is it a compile flag issue in the VM build?
>>
>
> The IPv6 primitives are all in SocketPlugin. I would not expect the actual primitives
> to work any differently, but as Windows users have noticed there are definitely
> differences in the resolvers on different platforms, and you may be hitting issues
> related to that. Also, I think that some of our network code assumes that there
> is such a thing as "the IP address of my computer", which is generally wrong and
> probably causes mischief in some of the tests. My best suggestion would be just
> to step slowly though any of the failing tests and see if you can spot where
> it's getting confused.
>
> Also, try turning off the "EnableIPv6" preference and see if the tests start passing.

Yup, done that - " Turn off IPv6 and they all pass."

I've also now tried the test on a Mac 64bit system and the socket (and SSL of course) tests fail there too.

I had to exclude the AllocationTest stuff since that just tried to eat the Mac when I attempted it.

For extra fun, on the Mac FloatTest>>#testTimesTwoPowerGradualUnderflow failed where it did not on Pi. As did the PolygonMorphTest>testContainsPoint. Quite what would make them different I can't see right now.

tim
--
tim Rowledge; [hidden email]; http://www.rowledge.org/tim
Strange OpCodes: BYEBYE: Store in Write-Only Storage

marcel.taeumel

Re: Failed Tests for 5.3-19647

Hi all!

Build version 19647 is not Squeak 5.3. It is Trunk, 6.0alpha. The Squeak release version 5.3 is at build 19438.

If you start updating an older 5.3alpha image, you end up with 6.0alpha, not the 5.3 release version.

@Tim: If you want to run all the tests after such an update, make sure to run "ReleaseBuilder prepareSourceCode; prepareEnvironment" first. Maybe take a look at ReleaseBuilder class >> #saveAsNewClean.

Best,

Marcel

Am 11.05.2020 02:07:19 schrieb tim Rowledge <[hidden email]>:

> On 2020-05-10, at 1:58 PM, David T. Lewis wrote:
>
> On Sun, May 10, 2020 at 11:50:35AM -0700, tim Rowledge wrote:
>> More results in digging into this list of failures -
>>
>> A partial explanation for the failed socket (not just the SSL) tests - I remembered that we recently decided to turn on the IPv6 switch to see what happens. Well, on a Pi all the socket tests fail. Turn off IPv6 and they all pass. Sigh. Is there some magic I would need to do to turn on IPv6 on Raspbian? Is it a compile flag issue in the VM build?
>>
>
> The IPv6 primitives are all in SocketPlugin. I would not expect the actual primitives
> to work any differently, but as Windows users have noticed there are definitely
> differences in the resolvers on different platforms, and you may be hitting issues
> related to that. Also, I think that some of our network code assumes that there
> is such a thing as "the IP address of my computer", which is generally wrong and
> probably causes mischief in some of the tests. My best suggestion would be just
> to step slowly though any of the failing tests and see if you can spot where
> it's getting confused.
>
> Also, try turning off the "EnableIPv6" preference and see if the tests start passing.

Yup, done that - " Turn off IPv6 and they all pass."

I've also now tried the test on a Mac 64bit system and the socket (and SSL of course) tests fail there too.

I had to exclude the AllocationTest stuff since that just tried to eat the Mac when I attempted it.

For extra fun, on the Mac FloatTest>>#testTimesTwoPowerGradualUnderflow failed where it did not on Pi. As did the PolygonMorphTest>testContainsPoint. Quite what would make them different I can't see right now.

tim
--
tim Rowledge; [hidden email]; http://www.rowledge.org/tim
Strange OpCodes: BYEBYE: Store in Write-Only Storage

Nicolas Cellier

Re: Failed Tests for 5.3-19647

In reply to this post by timrowledge

Le lun. 11 mai 2020 à 02:07, tim Rowledge <[hidden email]> a écrit :

> On 2020-05-10, at 1:58 PM, David T. Lewis <[hidden email]> wrote:
>
> On Sun, May 10, 2020 at 11:50:35AM -0700, tim Rowledge wrote:
>> More results in digging into this list of failures -
>>
>> A partial explanation for the failed socket (not just the SSL) tests - I remembered that we recently decided to turn on the IPv6 switch to see what happens. Well, on a Pi all the socket tests fail. Turn off IPv6 and they all pass. Sigh. Is there some magic I would need to do to turn on IPv6 on Raspbian? Is it a compile flag issue in the VM build?
>>
>
> The IPv6 primitives are all in SocketPlugin. I would not expect the actual primitives
> to work any differently, but as Windows users have noticed there are definitely
> differences in the resolvers on different platforms, and you may be hitting issues
> related to that. Also, I think that some of our network code assumes that there
> is such a thing as "the IP address of my computer", which is generally wrong and
> probably causes mischief in some of the tests. My best suggestion would be just
> to step slowly though any of the failing tests and see if you can spot where
> it's getting confused.
>
> Also, try turning off the "EnableIPv6" preference and see if the tests start passing.

Yup, done that - " Turn off IPv6 and they all pass."

I've also now tried the test on a Mac 64bit system and the socket (and SSL of course) tests fail there too.

I had to exclude the AllocationTest stuff since that just tried to eat the Mac when I attempted it.

For extra fun, on the Mac FloatTest>>#testTimesTwoPowerGradualUnderflow failed where it did not on Pi. As did the PolygonMorphTest>testContainsPoint. Quite what would make them different I can't see right now.

If you know how to increase pressure on apple developpers, I opened a bug report already.

Find it thru https://github.com/OpenSmalltalk/opensmalltalk-vm/issues/383

But are maths really important on a computer? No, no one cares ;)

tim
--
tim Rowledge; [hidden email]; http://www.rowledge.org/tim
Strange OpCodes: BYEBYE: Store in Write-Only Storage

timrowledge

Re: Failed Tests for 5.3-19647

In reply to this post by marcel.taeumel

> On 2020-05-10, at 10:58 PM, Marcel Taeumel <[hidden email]> wrote:
>
> Hi all!
>
> Build version 19647 is not Squeak 5.3. It is Trunk, 6.0alpha. The Squeak release version 5.3 is at build 19438.

Ah - good point. My preferences file includes setting the update stream to trunk; I'd completely forgotten that.

A freshly downloaded 5.3-19435 zip runs all the tests and fails only the allocate test and the SSL tests. I think this means we can tolerably sensibly package the 20200429xxx VM with this image version for a replacement ARM package.

tim
--
tim Rowledge; [hidden email]; http://www.rowledge.org/tim
Useful random insult:- Not all his dogs are barking.