Open Bug 1250496 Opened 9 years ago Updated 2 years ago

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

Categories

(Core :: JavaScript Engine, defect, P5)

x86_64
Linux
defect

Tracking

()

REOPENED

People

(Reporter: lth, Unassigned)

Details

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) {
A straw poll in the JIT team suggests people are still using GCC 4.8.
These failures can be provoked with gcc-4.8 as well, using (ironically) --enable-more-deterministic. Deterministic it is -- fails every time.
Status: NEW → RESOLVED
Closed: 9 years ago
Resolution: --- → WONTFIX
Reopened to track the problem with --enable-more-deterministic.
No longer blocks: 1248153
Status: RESOLVED → REOPENED
Resolution: WONTFIX → ---
Summary: Many jit-test failures in GCC 5 release builds → COnfiguring with --enable-more-deterministic breaks many test cases
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.
Summary: COnfiguring with --enable-more-deterministic breaks many test cases → Configuring with --enable-more-deterministic breaks many test cases
Priority: -- → P5

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.

Severity: normal → S3
You need to log in before you can comment on or make changes to this bug.