5.2a (18179) Test Results on Windows - 32bit and 64bit

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

5.2a (18179) Test Results on Windows - 32bit and 64bit

cbc
Hi again.

After the discussion a while back about 64 bit being slower than 32, I ran the full test suite for the latst 5.2a release against both on Windows.

32bit - 22:52.193
64bit - 25:07.789

Yep, looks like the truth.

The results - same number of failures (21) and expected failures (29) on both.
32bit had 2 errors
  - WebClientServerTest>>#testGetFields (Test timed out)
  - AllocationTest>>#testOutOfMemorySignal

64bit has 2 errors:
  - WebClientServerTest>>#testServerDestroy (twice) (Test timed out)
No idea why it had it twice - weird.

Both also had 1 unexpected passes as well.  How do you find these in the TestRunner?

Hmm.  The timeouts - before writing this email, I tried it a few times and continued to get timeouts. Then, looked away, fiddled, and they ran.  After clicking on one of them about 30 times, I got the timeout error again, then once again they are clearly sub-second.  Very annoying heisen bugs.

The 32bit outOfMemorySignal is failing at allocationTest>>vmParameterAt:put:, where it is getting called to set parm 67 to 1712567184 (instead of 0, which it was previously).  I'm not sure how to debug this - anything else that would help?

Thanks,
cbc


Reply | Threaded
Open this post in threaded view
|

Re: 5.2a (18179) Test Results on Windows - 32bit and 64bit

Levente Uzonyi
On Sat, 25 Aug 2018, Chris Cunningham wrote:

> Hi again.
> After the discussion a while back about 64 bit being slower than 32, I ran the full test suite for the latst 5.2a release against both on Windows.
>
> 32bit - 22:52.193
> 64bit - 25:07.789
>
> Yep, looks like the truth.

I tried running the tests myself on windows 10 and they really take
extremely long to finish compared to linux. I suspect that I/O operations
(files and network) are responsible for this.

>
> The results - same number of failures (21) and expected failures (29) on both.
> 32bit had 2 errors
>   - WebClientServerTest>>#testGetFields (Test timed out)
>   - AllocationTest>>#testOutOfMemorySignal
>
> 64bit has 2 errors:
>   - WebClientServerTest>>#testServerDestroy (twice) (Test timed out)
> No idea why it had it twice - weird.
>
> Both also had 1 unexpected passes as well.  How do you find these in the TestRunner?
I think the passing test has been fixed. I don't remember which one it
was, but it was a fairly basic one.

Levente

>
> Hmm.  The timeouts - before writing this email, I tried it a few times and continued to get timeouts. Then, looked away, fiddled, and they ran.  After clicking on one of them about 30 times, I got the
> timeout error again, then once again they are clearly sub-second.  Very annoying heisen bugs.
>
> The 32bit outOfMemorySignal is failing at allocationTest>>vmParameterAt:put:, where it is getting called to set parm 67 to 1712567184 (instead of 0, which it was previously).  I'm not sure how to
> debug this - anything else that would help?
>
> Thanks,
> cbc
>
>