524364 - TM: Assertion failure: exit not in unstable exit list with valgrind

Status: RESOLVED WONTFIX

(Core :: JavaScript Engine, defect)

Description

[Bob Clary [:bc] (inactive)]

When running the jsreftests on mozilla-central under valgrind 3.5.0 on Cento5 64 bit, I get the following assertion on several tests. I don't get this without valgrind and don't see it on 32bit Linux.

ecma/Array/15.4.4.4-1.js
ecma_2/Exceptions/date-001.js
ecma_3/RegExp/regress-289669.js
js1_2/String/slice.js
js1_5/Array/regress-99120-01.js
js1_8/regress/regress-463783.js
js1_8_1/trace/regress-451673.js

Assertion failure: exit not in unstable exit list, at /work/mozilla/builds/1.9.3/mozilla/js/src/jstracer.cpp:5700

Program /work/mozilla/builds/1.9.3/mozilla/firefox-debug/dist/bin/firefox-bin (pid = 27312) received signal 6.
Stack:
UNKNOWN  (/lib64/libpthread.so.0)
gsignal+0x00000035  (/lib64/libc.so.6)
abort+0x00000110  (/lib64/libc.so.6)
JS_Assert (/work/mozilla/builds/1.9.3/mozilla/js/src/jsutil.cpp:69)
TreeInfo::removeUnstableExit(VMSideExit*) (/work/mozilla/builds/1.9.3/mozilla/js/src/jstracer.cpp:5701)
AttemptToStabilizeTree (/work/mozilla/builds/1.9.3/mozilla/js/src/jstracer.cpp:5737)
js_MonitorLoopEdge(JSContext*, unsigned int&, MonitorReason) (/work/mozilla/builds/1.9.3/mozilla/js/src/jstracer.cpp:6936)
js_Interpret (/work/mozilla/builds/1.9.3/mozilla/js/src/jsops.cpp:923)
js_Execute (/work/mozilla/builds/1.9.3/mozilla/js/src/jsinterp.cpp:1598)
JS_EvaluateUCScriptForPrincipals (/work/mozilla/builds/1.9.3/mozilla/js/src/jsapi.cpp:5054)
nsJSContext::EvaluateString(nsAString_internal const&, void*, nsIPrincipal*, char const*, unsigned int, unsigned int, nsAString_internal*, int*) (/work/mozilla/builds/1.9.3/mozilla/dom/base/nsJSEnvironment.cpp:1682)
nsScriptLoader::EvaluateScript(nsScriptLoadRequest*, nsString const&) (/work/mozilla/builds/1.9.3/mozilla/content/base/src/nsScriptLoader.cpp:690)
nsScriptLoader::ProcessRequest(nsScriptLoadRequest*) (/work/mozilla/builds/1.9.3/mozilla/content/base/src/nsScriptLoader.cpp:604)
nsScriptLoader::ProcessScriptElement(nsIScriptElement*) (/work/mozilla/builds/1.9.3/mozilla/content/base/src/nsScriptLoader.cpp:515)
nsScriptElement::MaybeProcessScript() (/work/mozilla/builds/1.9.3/mozilla/content/base/src/nsScriptElement.cpp:193)


(for s in js/src/tests/{e4x,ecma*,js1*}; do python firefox-debug/_tests/reftest/runreftest.py --timeout=3600 --extra-profile-file=js/src/tests/user.js --debugger=valgrind --debugger-args="--leak-check=full --trace-children=yes --tool=memcheck" $s/jstests.list; done) > firefox-debug/jstestbrowser.log 

You can limit the test run to the appropriate directories by restricting the directories being tested to one of:

ecma, ecma_2, ecma_3, js1_2, js1_5, js1_8, js1_8_1

or to make it faster one of: (I've tested ecma/Array)

ecma/Array/, ecma_2/Exceptions/, ecma_3/RegExp/, js1_2/String/, js1_5/Array/, js1_8/regress/, js1_8_1/trace/

Comment 1

[David Anderson [:dvander] - inactive, e-mail if emergency]

Use --smc-check=all. What's happening is that Valgrind isn't seeing some code get patched, so a branch is being taken after we remove it from a list of known unpatched branches.

Comment 2

[Bob Clary [:bc] (inactive)]

dvander: So, does this mean that even with --enable-valgrind we will have to run with --smc-check=all? That kind of negates the usefulness of --enable-valgrind.

Comment 3

[David Anderson [:dvander] - inactive, e-mail if emergency]

I'm not sure what that config option really does :) CC'ing valgrind folks.

Comment 4

[Bob Clary [:bc] (inactive)]

From what I understand it is supposed to allow us to valgrind jitted code without using --smc-check=all.

Comment 5

[Julian Seward [:jseward]]

(In reply to comment #4)
That's my understanding too.

--enable-valgrind is supposed to enable macros which tell Valgrind
when NJ is overwriting existing code, so V can throw away
translations.

--smc-check=all forces V to check each time a translation is run, that
the code it was translated from has not changed.  Hence it allows V to
handle code overwriting without external assistance, but at the cost
of a severe performance overhead.

First question is: does said assertion failure still happen with
--smc-check=all ?

Comment 6

[Bob Clary [:bc] (inactive)]

(In reply to comment #5)

> First question is: does said assertion failure still happen with
> --smc-check=all ?

no. (testing ecma/Array only)

Comment 7

[Nicholas Nethercote [inactive]]

In which case the Valgrind macros must have got out of date.  There must be a newly added place where code is generated but no VALGRIND_DISCARD_TRANSLATIONS macro is present.

Comment 8

[Ryan VanderMeulen [:RyanVM]]

Obsolete with the removal of tracejit.