-
Notifications
You must be signed in to change notification settings - Fork 284
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
napi_threadsafe_function -- Segmentation fault: 11 #1387
Comments
@gabrielschulhof can you take a look at this? |
@jazz-soft the thread-safe function is meant to be used with an existing threads implementation. Creating a thread-safe function will not cause N-API to spawn new threads. The semantics of It is very important that Since Overall, from the usage pattern in the code sample you provide, it looks to me like you might be better served by |
@gabrielschulhof thank you for explanation. napi_value stop(napi_env env, napi_callback_info args)
{
std::cout << "stop...\n";
napi_release_threadsafe_function(TSF, napi_tsfn_release); // also tried with napi_tsfn_abort
napi_value value;
napi_get_undefined(env, &value);
return value;
} As for documentation, it would be great to have a complete copy-pasteable threadsafe_function lifecycle example similar to the one in my original post.
|
@jazz-soft it turns out that there were no tests for the case where queue size is zero, meaning unlimited. In those conditions, Good catch! |
I'm glad my complain was helpful :) |
A condition variable is only created by the thread-safe function if the queue size is set to something larger than zero. This adds null-checks around the condition variable and tests for the case where the queue size is zero. Fixes: nodejs/help#1387
A condition variable is only created by the thread-safe function if the queue size is set to something larger than zero. This adds null-checks around the condition variable and tests for the case where the queue size is zero. Fixes: nodejs/help#1387 PR-URL: #21871 Reviewed-By: Benjamin Gruenbaum <benjamingr@gmail.com> Reviewed-By: Colin Ihrig <cjihrig@gmail.com> Reviewed-By: Michael Dawson <michael_dawson@ca.ibm.com>
I've also noticed this. Was browsing through the napi code and noticed that if you set the queue size to something, then it didn't crash. Happy someone else found it and that it got fixed. I'm guessing for now, a workaround is to actually set queue size to something > 0. |
A condition variable is only created by the thread-safe function if the queue size is set to something larger than zero. This adds null-checks around the condition variable and tests for the case where the queue size is zero. Fixes: nodejs/help#1387 PR-URL: nodejs#21871 Reviewed-By: Benjamin Gruenbaum <benjamingr@gmail.com> Reviewed-By: Colin Ihrig <cjihrig@gmail.com> Reviewed-By: Michael Dawson <michael_dawson@ca.ibm.com>
A condition variable is only created by the thread-safe function if the queue size is set to something larger than zero. This adds null-checks around the condition variable and tests for the case where the queue size is zero. Fixes: nodejs/help#1387 PR-URL: #21871 Backport-PR-URL: #25002 Reviewed-By: Benjamin Gruenbaum <benjamingr@gmail.com> Reviewed-By: Colin Ihrig <cjihrig@gmail.com> Reviewed-By: Michael Dawson <michael_dawson@ca.ibm.com>
A condition variable is only created by the thread-safe function if the queue size is set to something larger than zero. This adds null-checks around the condition variable and tests for the case where the queue size is zero. Fixes: nodejs/help#1387 PR-URL: #21871 Backport-PR-URL: #25002 Reviewed-By: Benjamin Gruenbaum <benjamingr@gmail.com> Reviewed-By: Colin Ihrig <cjihrig@gmail.com> Reviewed-By: Michael Dawson <michael_dawson@ca.ibm.com>
Getting segmentation fault on exit in MacOS and Linux, no error output in Windows.
Have I missed something in the c++ code?
Sorry, the documentation at https://nodejs.org/api/n-api.html#n_api_asynchronous_thread_safe_function_calls was a bit unclear...
Thank you!
The text was updated successfully, but these errors were encountered: