osx,fsevent: fix race during uv_loop_close#2626
Conversation
| state->signal_source, | ||
| *pkCFRunLoopDefaultMode); | ||
|
|
||
| state->loop = NULL; |
There was a problem hiding this comment.
we were not resetting this before?
There was a problem hiding this comment.
It also looks like a race condition to me since it's modified without holding the mutex. uv__cf_loop_signal() reads it and runs on the other thread.
There was a problem hiding this comment.
We weren't—in fact, we should never use or read this field again after this point in the code (we also never branch on it being NULL). The mistake was that we sometimes would (because we didn't hold the necessary mutex). Clearing it here just helps to makes any bad concurrent usage more obvious.
bnoordhuis
left a comment
There was a problem hiding this comment.
LGTM but can I suggest splitting this into two commits so it's clear from history that state->loop = NULL is not part of the bug fix?
The mutex also needs to protect the access to the state->loop variable, since that's owned by the child thread and will be destroyed as soon as it processes our message. Fixes: libuv#2625 PR-URL: libuv#2626 Reviewed-By: Ben Noordhuis <info@bnoordhuis.nl> Reviewed-By: Saúl Ibarra Corretgé <saghul@gmail.com>
Set this to NULL just before disposing it to make mistakes more painfully obvious, hopefully. PR-URL: libuv#2626 Reviewed-By: Ben Noordhuis <info@bnoordhuis.nl> Reviewed-By: Saúl Ibarra Corretgé <saghul@gmail.com>
The mutex also needs to protect the access to the state->loop variable, since that's owned by the child thread and will be destroyed as soon as it processes our message. Fixes: libuv#2625 PR-URL: libuv#2626 Reviewed-By: Ben Noordhuis <info@bnoordhuis.nl> Reviewed-By: Saúl Ibarra Corretgé <saghul@gmail.com>
Set this to NULL just before disposing it to make mistakes more painfully obvious, hopefully. PR-URL: libuv#2626 Reviewed-By: Ben Noordhuis <info@bnoordhuis.nl> Reviewed-By: Saúl Ibarra Corretgé <saghul@gmail.com>
The mutex also needs to protect the access to the state->loop variable, since that's owned by the child thread and will be destroyed as soon as it processes our message. Fixes: libuv/libuv#2625 PR-URL: libuv/libuv#2626 Reviewed-By: Ben Noordhuis <info@bnoordhuis.nl> Reviewed-By: Saúl Ibarra Corretgé <saghul@gmail.com>
Set this to NULL just before disposing it to make mistakes more painfully obvious, hopefully. PR-URL: libuv/libuv#2626 Reviewed-By: Ben Noordhuis <info@bnoordhuis.nl> Reviewed-By: Saúl Ibarra Corretgé <saghul@gmail.com>
The mutex also needs to protect the access to the state->loop variable, since that's owned by the child thread and will be destroyed as soon as it processes our message. Fixes: libuv/libuv#2625 PR-URL: libuv/libuv#2626 Reviewed-By: Ben Noordhuis <info@bnoordhuis.nl> Reviewed-By: Saúl Ibarra Corretgé <saghul@gmail.com>
Set this to NULL just before disposing it to make mistakes more painfully obvious, hopefully. PR-URL: libuv/libuv#2626 Reviewed-By: Ben Noordhuis <info@bnoordhuis.nl> Reviewed-By: Saúl Ibarra Corretgé <saghul@gmail.com>
The mutex also needs to protect the access to the state->loop variable,
since that's owned by the child thread and will be destroyed as soon as
it processes our message.
This previously caused shutdown of libuv loops (especially the stress test fs_event_error_reporting) to segfault occasionally.
Fixes: #2625