Skip to content
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

Using context and sensor in user class hangs on destruction #7553

Closed
ghost opened this issue Oct 13, 2020 · 2 comments
Closed

Using context and sensor in user class hangs on destruction #7553

ghost opened this issue Oct 13, 2020 · 2 comments
Labels
T260 series Intel® T265 library

Comments

@ghost
Copy link

ghost commented Oct 13, 2020


Required Info
Camera Model T265
Firmware Version 0.2.0.951
Operating System & Version Win 10
Kernel Version (Linux Only) --
Platform PC
SDK Version 2.38.1 }
Language 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:

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

@ghost
Copy link
Author

ghost commented Oct 13, 2020

Just as an update: there is a potential bug in my IntelRealSenseControl.cpp source, thus I update it here:

IntelRealSenseControl_cpp.txt

In createCallBack(), gyro_data is now defined within the functor.

This DOES NOT change the issue described above.

@RealSenseSupport RealSenseSupport added the T260 series Intel® T265 library label Oct 27, 2020
krazycoder2k added a commit to krazycoder2k/librealsense that referenced this issue Mar 12, 2021
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#7553
IntelRealSense#5807
IntelRealSense#6272
IntelRealSense#7555
IntelRealSense#7750
@RealSenseSupport
Copy link
Collaborator

Fixed in latest via PR #8561

Thanks

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
T260 series Intel® T265 library
Projects
None yet
Development

No branches or pull requests

1 participant