While investigating a segmentation fault in one of our applications, and while working on #2377 yesterday, I found another small possible bug in the implementation of ros::CallbackQueue::callAvailable() in the way it keeps track of how many callbacks are currently being executed in any spinner thread, namely the calling_ variable.
When copying over pending calls to the thread-local callback queue held in tls->callbacks, the calling_ member was not updated correctly with the number of added callbacks if tls->callbacks was not empty before. This may be the case if callAvailable() is called recursively, e.g. from within another callback.
The issue should only affect the calling_ member and empty() and isEmpty() member functions, which apparently are unused within roscpp itself, but may be used by external code.
While investigating a segmentation fault in one of our applications, and while working on #2377 yesterday, I found another small possible bug in the implementation of
ros::CallbackQueue::callAvailable()in the way it keeps track of how many callbacks are currently being executed in any spinner thread, namely thecalling_variable.When copying over pending calls to the thread-local callback queue held in
tls->callbacks, thecalling_member was not updated correctly with the number of added callbacks iftls->callbackswas not empty before. This may be the case ifcallAvailable()is called recursively, e.g. from within another callback.The issue should only affect the
calling_member andempty()andisEmpty()member functions, which apparently are unused within roscpp itself, but may be used by external code.