Control: retitle -1 mozjs52: test failure on alpha|sparc64: Expected value
'InternalError: allocation size overflow', Actual value 'out of memory'
Control: user email@example.com
Control: usertags -1 + sparc64
On Fri, 10 Aug 2018 at 11:05:33 +0100, Simon McVittie wrote:
> Two mozjs52 tests fail on alpha:
> ## js1_5/Array/regress-157652.js: rc = 0, run time = 0.418948
> BUGNUMBER: 157652
> STATUS: Testing that Array.sort() doesn't crash on very large arrays
> --- NOTE: IN THIS TESTCASE, WE EXPECT EXIT CODE 0 ---
> --- NOTE: IN THIS TESTCASE, WE EXPECT EXIT CODE 5 ---
> FAILED! [reported from top level script] Testing that Array.sort() doesn't
> crash on very large arrays : Expected value 'InternalError: allocation size
> overflow', Actual value 'out of memory'
> TEST-UNEXPECTED-FAIL | js1_5/Array/regress-157652.js | (args: "")
> ## js1_5/Regress/regress-422348.js: rc = 0, run time = 0.458987
> BUGNUMBER: 422348
> STATUS: Proper overflow error reporting
> FAILED! [reported from test()] Proper overflow error reporting : Expected
> value 'InternalError: allocation size overflow', Actual value 'out of memory'
> TEST-UNEXPECTED-FAIL | js1_5/Regress/regress-422348.js | (args: "")
> I suspect that alpha just needs to be added to the list of 64-bit
> architectures where tests like these are skipped, similar to how mips64
> was added in
> (generalizing that patch to be more like "add more 64-bit architectures"
> would probably be the best solution).
sparc64 also has a similar failure mode and should probably also be
added to that list of 64-bit architectures, although on sparc64 this
is swamped by a different failure mode where tests expect NaN and get
undefined instead (I've opened a separate sparc64-specific bug for that).
riscv64 and other new 64-bit architectures would probably have the same
bug if mozjs supported them.
If someone who likes portability and understands the Mozilla build/test
system better than I do could upstream a patch that replaces
skip-if(xulRuntime.XPCOMABI.match(...)) with some sort of
skip-if(xulRuntime.WORDSIZE == 64) or similar, that would be an even better
solution; the build system already has a concept of matching architectures
to word sizes.