Skip to content

Conversation

@dirkfeytons
Copy link

This tries to fix the issue outlined in the commit message.

Note that I only changed the epoll-based backend of uloop. I'm not familiar with kqueue, and I'm not even sure the issue is even possible there...

cc: @nbd168 and @jow- since you guys seem to have been involved with the interval timer code

Previously the following scenario was possible:
1. event loop returns with some events
2. one event triggers a callback invocation that removes a timer,
   possibly as part of a bigger cleanup
3. another event is that same timer firing, which invokes the timer's
   callback, which in turn potentially accesses data that no longer
   exists due to the earlier cleanup
Fix this by using uloop_fd_delete() instead of __uloop_fd_delete()
when removing the interval timer so a possible pending event is
cleared.

The above fix breaks the feature that uloop_interval_cancel() can be
called again on an already cancelled interval timer:
1. The first cancel closes the timerfd and memsets the whole uloop_fd
   struct to 0.
2. In every subsequent cancel the uloop_fd_delete() call will return 0
   which results in the following code closing fd 0 due to the memset.
Avoid this by checking the struct uloop_fd registered flag as first
thing in the timer_remove() function.

Signed-off-by: Dirk Feytons <[email protected]>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant