-
Notifications
You must be signed in to change notification settings - Fork 171
ThreadSanitizer support #557
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Comments
Observation: if I take and release the mutex inside diff --git a/quickjs.c b/quickjs.c
index 6467667..61eb29e 100644
--- a/quickjs.c
+++ b/quickjs.c
@@ -53574,7 +53574,7 @@ typedef struct JSAtomicsWaiter {
} JSAtomicsWaiter;
static js_once_t js_atomics_once = JS_ONCE_INIT;
-static js_mutex_t js_atomics_mutex;
+js_mutex_t js_atomics_mutex;
static struct list_head js_atomics_waiter_list =
LIST_HEAD_INIT(js_atomics_waiter_list);
diff --git a/run-test262.c b/run-test262.c
index b9928a9..5fd98fc 100644
--- a/run-test262.c
+++ b/run-test262.c
@@ -39,6 +39,8 @@
#include "list.h"
#include "quickjs-libc.h"
+extern js_mutex_t js_atomics_mutex;
+
/* enable test262 thread support to test SharedArrayBuffer and Atomics */
#define CONFIG_AGENT
@@ -651,6 +653,8 @@ static JSValue js_agent_sleep(JSContext *ctx, JSValue this_val,
uint32_t duration;
if (JS_ToUint32(ctx, &duration, argv[0]))
return JS_EXCEPTION;
+ js_mutex_lock(&js_atomics_mutex);
+ js_mutex_unlock(&js_atomics_mutex);
usleep(duration * 1000);
return JS_UNDEFINED;
} @saghul thoughts on whether that's a good idea or a bad idea? It doesn't materially affect run-test262 running time; it's around 20 seconds both ways for all of
And just Atomics.wait:
(pretty big wall-clock vs. CPU time difference) |
I'll take a look! Shouldn't the unlock happen after the sleep? |
I thought so too at first but I think it's really just acting as a fence / synchronization point and that's enough to make tsan happy. |
I see. A quick look at https://github.com/google/sanitizers/wiki/ThreadSanitizerReportFormat suggests it might indeed be a false positive triggered by the mix of atomics and mutexes. Suggestion: define CONFIG_AGENT (drop the define since it's now done always) in CMake when building the runner and only expose the mutex in quickjs.c in that case. An acompanying comment would also be nice. |
I don't think that works: run-tes262 links against qjs, the static library target, so either the symbol is always exposed or never (and I don't want to build qjs twice because life's too short) (Also, the no-CONFIG_AGENT build is broken. Might as well remove the define altogether.) I'll include the patch from a few comments up and if you really hate it, you can always nack it :-) |
Ah true that. Let's land the change then.
Yeah, axe that too please :-) |
Yes, I will in the "make run-test262 multi-threaded" PR. I'll be touching the agent code a great deal there anyway. |
Cool! |
I have TSan working after #564 but runs take so godawful long that it's not realistic to test on CI, ergo... closing. |
Out of curiosity, how long is that? Did you check with the -fast config? |
It's > 1 hr wall clock time on my MBP 2015 and 4-5 hrs cpu time. I didn't check |
This is the fast variant on an M1 Max (10 cores):
Sounds like something we could run no? |
Like we run valgrind, on push to master? |
Sounds like a plan! |
Uh oh!
There was an error while loading. Please reload this page.
Tracking issue because I'm trying to add TSan support but I'm hitting a snag - it doesn't like how we implement JS atomics and that may or may not be a legitimate complaint:
⬆️ excerpt from running
build/run-test262 -c test262.conf -d test262/test/built-ins/Atomics/wait
I'm undecided if the
as if synchronized via sleep
warning is a red herring or not but the observation that we mix atomic ops and mutexes is legit.CMakeLists.txt diff:
The text was updated successfully, but these errors were encountered: