-
Notifications
You must be signed in to change notification settings - Fork 165
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
Realm access from incorrect thread error during CI for flx sync test #6919
Comments
From the same pr #6918 thread sanitizer issue on different build run: Details
[2023/08/24 07:54:48.418] 1: Thread[03]: ../test/test_util_future.cpp:227: Begin Future_Fail_getConstLvalue |
So as per @ironage comment about the tsan issue (which is definitely unrelated): "Those reports are about a race on global state having to do with the use of system time libraries from the test Json_Timestamp and Parser_basic_serialisation (and others). This is most likely due to using timegm The issue in test itself is weird. How could that be for this line in code "flx_sync.cpp:1296: FAILED"? Btw, it seems that the usage of catch2 in this test is incorrect one. Callback on async_open_realm will be executed on different thread, leading to data races for sure. |
Ok, the fix for mentioned tsan issue was added to #6911. Let track this issue for realm access from incorrect test. I've seen this locally also on tsan build on linux with gcc during object store tests Details
|
@nicola-cab @kiburtse what is the status on this? |
I was under the impression that this is still relevant, but I am not sure, since @kiburtse is really bisecting and chasing these issues down. |
yeah, right... sorry, i've totally forgotten about this particular issue. We are not going to see these failures anymore. Code was changed in relevant tests as a part of #6911. The issues were reproducible quite easily. @jedelbo You may check all relevant fixes for uv scheduler and shared_realm instantiation. Essentially, the exception was triggered because the scheduler in realm thinks it's on the wrong thread, the problem is that every instance on UV based scheduler works only on main thread, but our tests didn't account for that. I've described the real cause and what we should fix in core here #7083. |
The text was updated successfully, but these errors were encountered: