You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
C++ (VS2017, MSVC toolset vs141, Windows SDK 10.0.17763)
Segment
VR
Issue Description
I have built a minimal project consisting of a main program file and two classes. It simply streams gyroscope data and
can detect if the device is disconnected and reconnected and can restart streaming. See attached text files for the program:
SDK warnings and errors are enabled and print to output.
The program stops if you type 'c' and press enter. It happens quite often (typically at least once in 20 trials) that the program hangs during destruction in the mp_sensorManager.reset() step of the IntelRealSenseControl::controlLoop().
The pointer mp_sensorManager holds a class with a context and a sensor member.
Thus, the reset destroys these SDK objects. First sensor, then context.
Further Details
It seems to happen in the destruction of the rs2_delete_sensor of rs.cpp.
There, VALIDATE_NOT_NULL(device) evaluates sometimes to false and a throw is issued
which leads to skipping the call of the context destructor.
However, the context destructor would stop the thread, where the device watcher is running (_device_watcher->stop()). This thread was started when the program was handed over a callback function to the API member function of context: set_devices_changed_callback.
Thus, this thread is never stopped and the controlLoop thread cannot be joined back and the program hangs.
Does this program use the API in a wrong way or is it indeed an API bug?
Thanks for help.
Asbjoern
The text was updated successfully, but these errors were encountered:
This PR is effectively the suggested fix in the GH issue below. Thank you @ankyur.
IntelRealSense#7276
I've validated the fix works using the following code:
// Reproduces T265 Hand on Exit.
int main(int, char**)
{
constexpr std::chrono::seconds timeout{ 1 };
while (true)
{
// Start
rs2::config config;
rs2::pipeline pipeline;
std::cout << "Entering pipeline.start()" << std::endl;
pipeline.start();
std::cout << "Exiting pipeline.start()" << std::endl;
std::cout << "Sleeping for 1 second..." << std::endl;
std::this_thread::sleep_for(timeout);
std::cout << "Entering pipeline.stop()" << std::endl;
pipeline.stop();
std::cout << "Exiting pipeline.stop()" << std::endl;
}
return 0;
}
Suspect this fix potentially addresses the following open T265 issues as well:
IntelRealSense#7553IntelRealSense#5807IntelRealSense#6272IntelRealSense#7555IntelRealSense#7750
Issue Description
I have built a minimal project consisting of a main program file and two classes. It simply streams gyroscope data and
can detect if the device is disconnected and reconnected and can restart streaming. See attached text files for the program:
IntelRealSenseControl_cpp.txt
IntelRealSenseControl_h.txt
IntelRealSenseSensor_cpp.txt
IntelRealSenseSensor_h.txt
main_cpp.txt
SDK warnings and errors are enabled and print to output.
The program stops if you type 'c' and press enter. It happens quite often (typically at least once in 20 trials) that the program hangs during destruction in the mp_sensorManager.reset() step of the IntelRealSenseControl::controlLoop().
The pointer mp_sensorManager holds a class with a context and a sensor member.
Thus, the reset destroys these SDK objects. First sensor, then context.
Further Details
It seems to happen in the destruction of the rs2_delete_sensor of rs.cpp.
There, VALIDATE_NOT_NULL(device) evaluates sometimes to false and a throw is issued
which leads to skipping the call of the context destructor.
However, the context destructor would stop the thread, where the device watcher is running (_device_watcher->stop()). This thread was started when the program was handed over a callback function to the API member function of context: set_devices_changed_callback.
Thus, this thread is never stopped and the controlLoop thread cannot be joined back and the program hangs.
Does this program use the API in a wrong way or is it indeed an API bug?
Thanks for help.
Asbjoern
The text was updated successfully, but these errors were encountered: