D455 Segfault toggling advanced mode: set_power_state

[fk-bbraun]

---

Required Info
Camera Model	D455
Firmware Version	5.15.1.0
Operating System & Version	Debian
Kernel Version (Linux Only)	5.10.155
Platform	PC
SDK Version	2.54.2
Language	C++

Edit: By now, we found out the root cause was to call toggle_advanced_mode(). It resets the camera and consecutive calls will run into an undefined hardware state.

Issue Description

When calling pipe.start(config) the application crashes every 2nd or 3rd time, but never consecutively.

Stack Trace:

[Current thread is 1 (Thread 0x7f9cf0ff9700 (LWP 1675))]
(gdb) bt
#0 0x00007f9e944b1371 in librealsense::platform::multi_pins_uvc_device::set_power_state(librealsense::platform::power_state) () from /opt/work/lib/librealsense2.so.2.54
#1 0x00007f9e9484606c in librealsense::uvc_sensor::acquire_power() () from /opt/work/lib/librealsense2.so.2.54
#2 0x00007f9e944ba78c in librealsense::uvc_sensor::power::power(std::weak_ptrlibrealsense::uvc_sensor) () from /opt/work/lib/librealsense2.so.2.54
#3 0x00007f9e944c5e1e in librealsense::d400_device::init(std::shared_ptrlibrealsense::context,librealsense::platform::backend_device_
#4 0x00007f9e944cb8d6 in librealsense::d400_device::d400_device(std::shared_ptrlibrealsense::context,librealsense::platform::backend_
#5 0x00007f9e9451dcee in librealsense::rs455_device::rs455_device(std::shared_ptrlibrealsense::context,librealsense::platform::backen
#6 0x00007f9e94506fbc in librealsense::d400_info::create(std::shared_ptrlibrealsense::context, bool) const () from /opt/work/lib/librealsense2.so.2.54
#7 0x00007f9e9450c77e in librealsense::device_info::create_device() const () from /opt/work/lib/librealsense2.so.2.54
#8 0x00007f9e947eefa1 in librealsense::device_hub::create_device(std::__cxx11::basic_string<char, std::char_traits,std::allocator
#9 0x00007f9e947f0441 in librealsense::device_hub::wait_for_device(std::chrono::duration<long, std::ratio<1l, 1000l> > const&, bool,
#10 0x00007f9e94753893 in librealsense::pipeline::pipeline::wait_for_device(std::chrono::duration<long, std::ratio<1l, 1000l> > const&,
#11 0x00007f9e94758c56 in librealsense::pipeline::config::resolve_device_requests(std::shared_ptrlibrealsense::pipeline::pipeline,<long, std::ratio<1l, 1000l> > const&) () from /opt/work/lib/librealsense2.so.2.54
#13 0x00007f9e94756439 in librealsense::pipeline::pipeline::unsafe_start(std::shared_ptrlibrealsense::pipeline::config) () from /opt/work/lib/librealsense2.so.2.54
#14 0x00007f9e94756609 in librealsense::pipeline::pipeline::start(std::shared_ptrlibrealsense::pipeline::config, std::shared_ptr<rs2_frame_callback>) () from /opt/work/lib/librealsense2.so.2.54
#15 0x00007f9e9481e7e1 in rs2_pipeline_start_with_config () from /opt/work/lib/librealsense2.so.2.54
#16 0x00007f9e9c293038 in rs2::pipeline::start (this=this@entry=0x55aa7a17dee8, config=...) at /opt/work/include/librealsense2/hpp/rs_pipeline.hpp:426

We run the same code with a D405 which runs just fine.

[MartyG-RealSense]

Hi @fk-bbraun Please first try setting the Laser Power value to 0 using the C++ code under the librealsense2 heading at the link below. This will temporarily disable the D455 camera's projector.

https://dev.intelrealsense.com/docs/api-how-to#controlling-the-laser

The D405 is not equipped with a projector, so if the program stops failing after disabling the D455 projector then it could suggest that the laser is drawing more power than the computer can provide to the camera to meet its power requirements.

[fk-bbraun]

Thanks for the reply, setting the laser power to 0 did not improve things.

The same hardware setup ran quite stable before. But we rewrote our driver, actually simplifying things, and updated the SDK and firmware to latest. So I cant trace it back to a single change.

[MartyG-RealSense]

If you swap the USB cables of the D405 and D455, does the D455 then work but the D405 doesn't. If this happens then it would indicate a possible problem with the D455's USB cable.

[fk-bbraun]

I tried different cameras as well as different cables, no difference. When compared to debian, in ubuntu it sometimes gives an exception (also pointing to set_power_state) instead of a segfault.

[fk-bbraun]

Trying and altering a minimal example, I found a possible root cause.

// set depth resolution
rs400::advanced_mode adv_mode(m_device);
STDepthTableControl depth_ctrl = adv_mode.get_depth_table();
depth_ctrl.depthUnits = 100;
adv_mode.set_depth_table(depth_ctrl);
adv_mode.toggle_advanced_mode(true);

//start streaming
auto selection = pipe.start(config);

provokes the set_power_state fails.

When instead setting the depth resolution directly, the startup is fine:

sensor.set_option(rs2_option::RS2_OPTION_DEPTH_UNITS, 0.001);
auto selection = pipe.start(config);

This works for now. But in a more complex scenario, e.g. needing the advanced mode to set depth clamping, it will not.

[MartyG-RealSense]

Instead of using Advanced Mode's depth clamping, I would recommend defining a minimum and maximum depth clamp with the Threshold Filter post-processing filter, like the example C++ code at #7771

I also confirm that setting the depth units with RS2_OPTION_DEPTH_UNITS is preferable to doing so via the depth table.

I note that you are setting the depth units to 0.001. This is unnecessary as the camera already uses the 0.001 depth unit value by default.

[fk-bbraun]

Thanks to your comments @MartyG-RealSense , we probably dont even need advanced mode then.

To your comment about setting depth units to the default value: We just make sure the parameters are right at every startup.

[MartyG-RealSense]

Some RealSense users do prefer to set the default parameter values even though they are applied automatically anyway in order to provide reassurance of correct settings, so it's totally fine to do so.

[fk-bbraun]

As for the original problem, I updated the title, so that this might help future bug hunters.

The problem was to call toggle_advanced_mode(true) which provokes something like a hardware reset. So whatever you do right after this, relying on the device still being connected has pretty much undefined behavior.

So, while in our case, not using advanced mode was the solution. A better patch here is to set up the context.set_devices_changed_callback() very early, which at least tells you about the device not being available. (We did this only after configuring the settings, so this didnt catch the problem and then proceeding gave us the troubles above)

So, if anybody needs to use advanced mode: First, check if enabled already as its persistent once activated. If not, toggle to true. Take your time and reconnect to the device, once its back up. (Timings: After 1.5s we get notified about the device disconnect, after another 2s it comes back up)

Maybe as last remarks:

1. Unfortunately the advanced mode behavior is not documented well ( @MartyG-RealSense ;) ), just mentioned briefly in this python example. and in a somewhat outdated issue here.
2. Also, its quite unfortunate that subsequent calls have a chance to segfault instead of throwing.

Thanks for caring and no more assistance needed with this.

[MartyG-RealSense]

You are very welcome. Thanks so much for the detailed feedback for the benefit of other RealSense users. As you do not require further assistance, I will close this case. Thanks again!