Control: retitle -1 mozjs52: test failure on alpha|sparc64: Expected value 'InternalError: allocation size overflow', Actual value 'out of memory' Control: user debian-sp...@lists.debian.org 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: "") > > and > > ## 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 > debian/patches/tests-For-tests-that-are-skipped-on-64-bit-mips64-is-also.patch > (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. smcv