Segmentation fault (core dumped) on Realsense-Viewer in Ubuntu 18 and Ubuntu 20

[KevinKenntec]

Required Info
Camera Model	D415
Firmware Version	5.12.10.00
Operating System & Version	Ubuntu 18 & Ubuntu 20
Kernel Version (Linux Only)	18.04.5 & 20.04.1
Platform	PC
SDK Version	2
Language	C++
Segment	Robot

Issue Description

I am getting a segmentation fault whenever I use the realsense-viewer (absolutely no code whatsoever is being run) on multiple versions of Ubuntu (18 and 20). They are preceded by a large amount of warning errors.
I run with 2 D415 cameras on Ubuntu 18 and 1 on Ubuntu 20

After experimenting, I get these segmentation faults in the following scenarios:

1. If I just turn the depth stream on and then off fairly quickly (a few seconds between turning it on and off)
2. If I leave the depth stream on 1 camera on and (on the Ubuntu 18 system), try to select the 2nd camera

I have attached screenshots from both OSes errors.

[KevinKenntec]

The most reliable way I can trigger this is by doing the following:
Get 2 D415 cameras on the realsense-viewer turn on all streams and then turn any stream off once all the streams are on. This will cause the system to freeze and then segmentation fault.

[MartyG-RealSense]

Hi @KevinKenntec We discussed this case recently at the Intel RealSense Help Center website. I will continue the case here on the GitHub so that the conversation is not occurring in two places at the same time.

There was a similar case recently in which a RealSense user was experiencing a segmentation error with the RealSense Viewer. They also had the error message WARNING [139918474991360] (backend-v4l2.cpp:1775) Invalid md size: bytes used = 0 ,start offset=10

As a first step in investigating the issue, I suggested building librealsense with the RSUSB backend method in order to eliminate whether the problem is being caused by a conflict with the Linux kernel.

https://support.intelrealsense.com/hc/en-us/community/posts/360051658134/comments/360013903134

[KevinKenntec]

This issue does not seem to exist on an older computer that I have that I have not updated for a long time and it is still on SDK version 2.40.0, which I found very strange, has something change fundamentally between 2.40.0 and 2.41.0?

[MartyG-RealSense]

A small number of cases involving segmentation errors with the Viewer have been reported as far back as 2019, so it may not related to the newness of the SDK version.

Differences between the USB ports or USB controllers on particular machines may mean that a camera works fine on one machine and has problems on another. Plugging the camera into a USB hub instead of attaching the camera directly to the computer's USB ports may make a difference. If a mains electricity powered hub is used then it can provide additional stability, as the power supplied to the ports from the mains is independent from the computer's power supply (which supplies built-in ports and non-marine "passive" hubs).

If the same cameras work fine on the older computer then the problem is likely unrelated to the camera firmware driver, as the firmware is stored inside the camera hardware and so firmware-related problems should be carried along with the camera to whatever computer the camera is plugged into.

[KevinKenntec]

I first purged all the realsense libraries from my Ubuntu 18.04 install then I downloaded the librealsense-2.41.0.tar.gz folder from online and inside the librealsense root directory, I did following:

mkdir build && cd build
cmake ../ -DFORCE_RUSB_BACKEND=ON
sudo make uninstall && make clean && make && sudo make install

And now I can't even access realsense-viewer. It just says:
bash: /usr/bin/realsense-viewer: No such file or directory

[MartyG-RealSense]

It looks as though you have not included the CMake flags to build the examples and tools. The CMake build command below should build librealsense from source code with the examples and tools (including the Viewer) and build the SDK in the non-debug 'Release' mode for optimised operation.

cmake ../ -DFORCE_RSUSB_BACKEND=ON -DCMAKE_BUILD_TYPE=release -DBUILD_EXAMPLES=true -DBUILD_GRAPHICAL_EXAMPLES=true

[KevinKenntec]

If I have built from source, how do I access the realsense-viewer?

[MartyG-RealSense]

Are you able to launch the Viewer if you input the command realsense-viewer into the Ubuntu terminal?

[pumpkin-ws]

I installed from source on 20.04. Did "sudo make install" after "make". Restart the terminal and type realsense-viewer works for me.

[MartyG-RealSense]

Great to hear that the Viewer works for you @pumpkin-ws - thanks for the update!

[KevinKenntec]

I did "sudo make install" and the realsense-viewer did indeed start up. But I get the exact same problem again. Not to mention, I needed to install the udev rules in.

[MartyG-RealSense]

Hi @KevinKenntec The fourcc code RW16! error suggests to me that there is a conflict with the Ubuntu kernel.

Earlier in this case I mentioned how I had suggested to another person with the invalid md size problem that they try building librealsense using the RSUSB method. This method is not dependent on Linux versions or kernel versions and does not need patching. Have you attempted an RSUSB build of librealsense please?

[luisrayas3]

We have also had a segfault after upgrading to 2.41, seems likely to be the same issue as this ticket. In our case we are using Ubuntu 18.04 and this is going through the pyrealsense2 wrappers. This happens with 100% consistently with 2.41 whereas it never happens since downgrading to 2.40, and note that we are using the exact same machine and exact same USB layout in both cases. This also happens in our case when using both a D415 and a D435, but not when using a single camera. The segfault comes with the call to wait_for_frames by the way.

Unfortunately I don't have the time to recreate the problem with a minimal example at this time and downgrading to 2.40 is a suitable workaround for us but if it would be helpful to do so I'd be happy to re-upgrade and provide the details of our failure when I get the chance.

[MartyG-RealSense]

Hi @luisrayas3 Given that it has been nearly a month at the time of writing this since 2.41.0 has been released, it may be worth waiting for the next SDK version and see whether the segfault issue is still present for you in it, and using 2.40.0 in the meantime.

[ev-mp]

@KevinKenntec hello, thank you for the report.
We reviewed the changes and isolated a potential configuration change in v4l buffers exchange that would cause the core dump on stream stop
The fix is scheduled for the next release, but in the meanwhile you can try/cherry-pick the pending PR (above)

[MartyG-RealSense]

Hi @KevinKenntec Do you require further assistance with this case, please? Thanks!

[MartyG-RealSense]

Case closed due to no further comments received.