1250496 - Configuring with --enable-more-deterministic breaks many test cases

Status: RESOLVED INVALID

(Core :: JavaScript Engine, defect, P5)

Description

[Lars T Hansen [:lth]]

Ubuntu 15.10, GCC 5.2.1.  Of interest may be bug 1154185, bug 1248153.

Rev: 3a188fabb916 (m-c to m-i merge, Feb 22)
Configure flags: --enable-gczeal --disable-tests --enable-debug-symbols --without-intl-api --enable-more-deterministic

Run jit_test.py without flags.

Output:
FAILURES:
    .../js/src/jit-test/tests/baseline/bug848743-1.js
    .../js/src/jit-test/tests/basic/bug1100623.js
    .../js/src/jit-test/tests/basic/bug1219363.js
    .../js/src/jit-test/tests/basic/bug595963-2.js
    .../js/src/jit-test/tests/basic/bug703157.js
    .../js/src/jit-test/tests/basic/bug827104.js
    .../js/src/jit-test/tests/basic/bug839420.js
    .../js/src/jit-test/tests/basic/bug934997.js
    .../js/src/jit-test/tests/basic/exception-column-number.js
    .../js/src/jit-test/tests/basic/expression-autopsy.js
    .../js/src/jit-test/tests/basic/iterable-error-messages.js
    .../js/src/jit-test/tests/basic/property-enumeration-order.js
    .../js/src/jit-test/tests/basic/testBug474769.js
    .../js/src/jit-test/tests/basic/testBug604210.js
    .../js/src/jit-test/tests/basic/testCrossCompartmentTransparency2.js
    .../js/src/jit-test/tests/basic/testInitSingletons.js
    .../js/src/jit-test/tests/basic/testLet.js
    .../js/src/jit-test/tests/basic/unboxed-property-enumeration.js
    .../js/src/jit-test/tests/closures/bug496987.js
    .../js/src/jit-test/tests/closures/flat-closure-4.js
    .../js/src/jit-test/tests/closures/incr-exit-2.js
    .../js/src/jit-test/tests/debug/Memory-takeCensus-09.js
    .../js/src/jit-test/tests/debug/Memory-takeCensus-10.js
    .../js/src/jit-test/tests/gc/gcparam.js
    .../js/src/jit-test/tests/generators/bug931414.js
    .../js/src/jit-test/tests/ion/bug1060387.js
    .../js/src/jit-test/tests/ion/bug827659-2.js
    .../js/src/jit-test/tests/ion/bug913749.js
    .../js/src/jit-test/tests/latin1/decompiler.js
    .../js/src/jit-test/tests/parser/columnNumber.js
    .../js/src/jit-test/tests/proxy/testDirectProxyOnProtoWithForIn.js
    .../js/src/jit-test/tests/saved-stacks/caching-and-ccws.js
    .../js/src/jit-test/tests/saved-stacks/same-stack.js
    .../js/src/jit-test/tests/structured-clone/version3.js
    .../js/src/jit-test/tests/sunspider/check-regexp-dna.js
    .../js/src/jit-test/tests/sunspider/check-string-fasta.js
TIMEOUTS:
    .../js/src/jit-test/tests/gc/bug-1161303.js

I don't know if this warning is anything:

In file included from .../js/src/build-release-debug/mfbt/Unified_cpp_mfbt0.cpp:74:0:
.../mfbt/double-conversion/bignum.cc: In member function ‘void double_conversion::Bignum::AssignDecimalString(double_conversion::Vector<const char>)’:
.../mfbt/double-conversion/bignum.cc:101:6: warning: assuming signed overflow does not occur when assuming that (X + c) < X is always false [-Wstrict-overflow]
 void Bignum::AssignDecimalString(Vector<const char> value) {

Comment 1

[Lars T Hansen [:lth]]

A straw poll in the JIT team suggests people are still using GCC 4.8.

Comment 2

[Lars T Hansen [:lth]]

These failures can be provoked with gcc-4.8 as well, using (ironically) --enable-more-deterministic.  Deterministic it is -- fails every time.

Comment 3

[Lars T Hansen [:lth]]

Reopened to track the problem with --enable-more-deterministic.

Comment 4

[Gary Kwong [:gkw] [:nth10sd] (NOT official MoCo now)]

If we fix this, we should have these builds up on treeherder as well, to prevent them from turning builds orange due to future test failures.

See also bug 751700.

Comment 5

[u656541]

beware, I got bit by ac_add_options --enable-more-deterministic https://bugs.gentoo.org/717374

#ifdef JS_MORE_DETERMINISTIC
  
    /*
     * In some cases the enumeration order for an object depends on the
     * execution mode (interpreter vs. JIT), especially for native objects
     * with a class enumerate hook (where resolving a property changes the
     * resulting enumeration order). These aren't really bugs, but the
     * differences can change the generated output and confuse correctness
     * fuzzers, so we sort the ids if such a fuzzer is running.
     *
     * We don't do this in the general case because (a) doing so is slow,
     * and (b) it also breaks the web, which expects enumeration order to
     * follow the order in which properties are added, in certain cases.
     * Since ECMA does not specify an enumeration order for objects, both
     * behaviors are technically correct to do.
     */

but I guess it doesn't matter for this issue, because it's about uses within tests only, not for browsing the web.

Comment 6

[Matthew Gaudet (he/him) [:mgaudet]]

This option got moved to a runtime flag in Bug 1677045