Bug 39060 - JIT asserts inside valgrind
: JIT asserts inside valgrind
: WebKit
: 528+ (Nightly build)
: PC Linux
: P2 Normal
Assigned To:
  Show dependency treegraph
Reported: 2010-05-13 06:42 PST by
Modified: 2011-01-01 22:55 PST (History)



You need to log in before you can comment on or make changes to this bug.

Description From 2010-05-13 06:42:14 PST
For a long time, with JIT enabled builds I am facing with asserts when running either jsc or QtLauncher inside valgrind.
Test cases are simple:
$ valgrind WebKitBuild/Debug/bin/QtLauncher #and browsing a little
$ valgrind WebkitBuild/Debug/JavaScriptCore/jsc SunSpider/tests/sunspider-0.9.1/3d-cube.js
Both of them asserts here:
ASSERTION FAILED: !callLinkInfo->isLinked()
(../../../JavaScriptCore/jit/JIT.cpp:610 static void JSC::JIT::linkCall(JSC::JSFunction*, JSC::CodeBlock*, JSC::CodeBlock*, JSC::JITCode&, JSC::CallLinkInfo*, int, JSC::JSGlobalData*))

As I remember, in the early days of the JIT there were no such problems.
Of course, we can not be sure that the bug is not in valgrind.
Personally I think that it would be useful to clarify the problem.
------- Comment #1 From 2010-06-23 07:51:57 PST -------
same here. I've created a very minimal test case: http://chani.ca/webkit/valgrind/

all I have to do is make two should* calls and I get the assert failure.
------- Comment #2 From 2010-06-23 18:16:27 PST -------
I have found a solution: use "--smc-check=all".
This is needed because the JIT::linkCall function (and some other JIT staff) modifying the jitted code, so valgrind must check self modification.
Alternatively we could use valgrind's client request mechanism. That would be cheaper, but I am dubious about how the apple folks would feel about to introduce valgrind into the codebase (we should have at least a build option, and a define for valgrind).
------- Comment #3 From 2010-06-23 18:19:34 PST -------
I think we can leave with the --smc-check=all option, so I set this as wontfix.
------- Comment #4 From 2011-01-01 22:55:10 PST -------
*** Bug 34484 has been marked as a duplicate of this bug. ***