Branch: refs/heads/main Home: https://github.com/WebKit/WebKit Commit: 41d744be940c32814bcfc1740dcca8dfd3c38837 https://github.com/WebKit/WebKit/commit/41d744be940c32814bcfc1740dcca8dfd3c38837 Author: Vitaly Dyachkov <vit...@igalia.com> Date: 2023-07-13 (Thu, 13 Jul 2023)
Changed paths: M Tools/TestWebKitAPI/Tests/JavaScriptCore/glib/TestJSC.cpp Log Message: ----------- [GTK][WPE] `TestJSC` `/jsc/basic` API test is flaky https://bugs.webkit.org/show_bug.cgi?id=259178 Reviewed by Michael Catanzaro. On WPE and GTK, when we evaluate a JS expression, we wrap the resulting `JSValueRef` in `JSCValue`. Internally, we cache and reuse a `JSValue` for expressions that evaluate to the same `JSValueRef` result. When `JSCValue` object is destroyed it is also removed from the cache. There is a test in `testJSCBasic()` which checks that after we destroy a `JSCValue` and then evaluate the same JS expression, a new `JSCValue` wrapper is created: ``` GRefPtr<JSCValue> result = adoptGRef(jsc_context_evaluate(context.get(), "2 + 2", -1)); auto* resultPtr = result.get(); result = nullptr; GRefPtr<JSCValue> result4 = adoptGRef(jsc_context_evaluate(context.get(), "2 + 2", -1)); g_assert_false(result4.get() == resultPtr); ``` To verify that we got a new object we simply compare memory addresses. But it might happen (and actually happens on bots) that the new wrapper is allocated at the same address as the original one, making this test fail. What we can do instead, is to tag the original `JSCValue` and then ensure that the new `JSCValue` is not tagged. * Tools/TestWebKitAPI/Tests/JavaScriptCore/glib/TestJSC.cpp: (testJSCBasic): Canonical link: https://commits.webkit.org/266035@main _______________________________________________ webkit-changes mailing list webkit-changes@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-changes