Nveglglessink MESA: error: Failed to attach to x11 shm with Docker and Ubuntu 24

• Hardware Platform: RTX 4070
• DeepStream Version: 8.0
• NVIDIA GPU Driver Version: 580.126.09
• Issue Type: bug
• Requirements: Ubuntu 24 host OS, docker, nvidia-container-toolkit

I want to start a deepstream 8.0 pipeline from my host (Ubuntu 24), displaying stream with nveglglessink, but it fails with MESA: error: Failed to attach to x11 shm.

To reproduce the issue, from the terminal, just run:

xhost +
docker container run \
    -it \
    --rm \
    --runtime nvidia \
    -e DISPLAY=$DISPLAY \
    -v /tmp/.X11-unix:/tmp/.X11-unix \
    -v /etc/X11:/etc/X11 \
    nvcr.io/nvidia/deepstream:8.0-triton-multiarch \
    gst-launch-1.0 -e nvvideotestsrc ! nvvideoconvert ! nveglglessink

With 7.1 image it works fine:

docker container run \
    -it \
    --rm \
    --runtime nvidia \
    -e DISPLAY=$DISPLAY \
    -v /tmp/.X11-unix:/tmp/.X11-unix \
    -v /etc/X11:/etc/X11 \
    nvcr.io/nvidia/deepstream:7.1-triton-multiarch \
    gst-launch-1.0 -e nvvideotestsrc ! nvvideoconvert ! nveglglessink

I know the link FAQ for Deepstream On WSL — DeepStream documentation but I’m using a bare Ubuntu 24 installation, not WSL2.

I really need this to work, because I get the same problem in my devcontainer environment where I develop an application using deepstream pipeline. I think I will stick to 7.1 until there is a working solution, I need to display the output in a window, at least for debugging purpose.

The DeepStream platform compatibility should be followed exactly. Installation — DeepStream documentation. Your driver version should be R570.133.20

You mean each version of DeepStream MUST run with a unique version of the driver??

I will try the driver R570.133.20, but it sounds to me a regression that it works (580.126.09) with 7.1, and not with 8.0…

Yes. The compatibility limitation should be followed.

And you need to make sure the nvidia-container-toolkit has been installed correctly. https://docs.nvidia.com/datacenter/cloud-native/container-toolkit/install-guide.html

OK then I’ll try the driver 570.133.20.

Thanks

And you need to make sure the nvidia-container-toolkit has been installed correctly. https://docs.nvidia.com/datacenter/cloud-native/container-toolkit/install-guide.html

Your command works well with DeepStream 8.0 docker container

OK good news then, thanks for testing it.

I’ll try the driver 570, and if needed I’ll reinstall nvidia-container-toolkit.
What surprises me is that I work without any problem with DS7.1, and wanted to test DS8 on the same machine and got the error.

I cleaned up everything about the container toolkit and the driver, and did a clean install of the 570 driver and the nvidia-container-toolkit.

I still get the same error with DS8 (DS7.1 works fine), I also notices some error about amd (I do have a AMD ryzen CPU):

Setting pipeline to PAUSED ...
_amdgpu_device_initialize: amdgpu_get_auth (1) failed (-1)
amdgpu: amdgpu_device_initialize failed.
libEGL warning: egl: failed to create dri2 screen
libEGL warning: egl: failed to create dri2 screen
Pipeline is PREROLLING ...
Got context from element 'eglglessink0': gst.egl.EGLDisplay=context, display=(GstEGLDisplay)NULL;
MESA: error: Failed to attach to x11 shm
Pipeline is PREROLLED ...
Setting pipeline to PLAYING ...
Redistribute latency...
New clock: GstSystemClock
MESA: error: Failed to attach to x11 shm
MESA: error: Failed to attach to x11 shm
MESA: error: Failed to attach to x11 shm
MESA: error: Failed to attach to x11 shm
MESA: error: Failed to attach to x11 shm
MESA: error: Failed to attach to x11 shm
MESA: error: Failed to attach to x11 shm
MESA: error: Failed to attach to x11 shm

With DS7.1 docker image, I get the following output (nothing about AMD here):

Setting pipeline to PAUSED ...
libEGL warning: DRI2: could not open /dev/dri/card2 (No such file or directory)
Pipeline is PREROLLING ...
Got context from element 'eglglessink0': gst.egl.EGLDisplay=context, display=(GstEGLDisplay)NULL;
Pipeline is PREROLLED ...
Setting pipeline to PLAYING ...
Redistribute latency...
New clock: GstSystemClock
^Chandling interrupt.
Interrupt: Stopping pipeline ...
EOS on shutdown enabled -- Forcing EOS on the pipeline
Waiting for EOS...
Got EOS from element "pipeline0".
EOS received - stopping pipeline...
Execution ended after 0:00:01.100215702
Setting pipeline to NULL ...
Freeing pipeline ...

OK I found the problem, I don’t know why in DS8 it happens, maybe because the base image is ubuntu 24 instead of 22.

It seems it detects AMD GPU (integrated with the Ryzen CPU).

If I add --device /dev/dri or --privileged to the docker command, the pipeline works fine.

I guess GStreamer 1.24 works differently compared to 1.20, and that generates this problem.

I found some info at Running ROCm Docker containers — ROCm installation (Linux) .

It has maybe to see with nveglglessink plugin, here is the GST_DEBUG=7 output just before the amd stuff error:

0:00:00.168738517   388 0x5d50abf1c560 DEBUG                GST_BUS gstbus.c:339:gst_bus_post:<bus1> [msg 0x5d50ac37f610] posting on bus have-context message: 0x5d50ac37f610, time 99:99:99.999999999, seq-num 9, element 'eglglessink0', GstMessageHaveContext, context=(GstContext)NULL;
0:00:00.168747825   388 0x5d50abf1c560 DEBUG                GST_BUS gstbus.c:392:gst_bus_post:<bus1> [msg 0x5d50ac37f610] pushing on async queue
0:00:00.168751812   388 0x5d50abf1c560 DEBUG                GST_BUS gstbus.c:395:gst_bus_post:<bus1> [msg 0x5d50ac37f610] pushed on async queue
0:00:00.168755459   388 0x5d50abf1c560 TRACE        GST_REFCOUNTING gstobject.c:266:gst_object_unref:<bus1> 0x5d50ac272e90 unref 3->2
0:00:00.168761551   388 0x5d50abf1c560 TRACE        GST_REFCOUNTING gstminiobject.c:660:gst_mini_object_unref: 0x5d50ac37f610 unref 2->1
0:00:00.168768384   388 0x5d50abf1c560 DEBUG                GST_BUS gstbus.c:381:gst_bus_post:<bus0> [msg 0x5d50ac37f610] dropped
0:00:00.168772010   388 0x5d50abf1c560 TRACE        GST_REFCOUNTING gstobject.c:266:gst_object_unref:<bus0> 0x5d50ac270ff0 unref 5->4
_amdgpu_device_initialize: amdgpu_get_auth (1) failed (-1)
amdgpu: amdgpu_device_initialize failed.
libEGL warning: egl: failed to create dri2 screen
libEGL warning: egl: failed to create dri2 screen
0:00:00.188931073   388 0x5d50abf1c560 INFO             egladaption ext/eglgles/gstegladaptation_egl.c:174:gst_egl_adaptation_init_display:<eglglessink0> System reports supported EGL version v1.5
0:00:00.188950189   388 0x5d50abf1c560 DEBUG            egladaption ext/eglgles/gstegladaptation.c:207:gst_egl_adaptation_fill_supported_fbuffer_configs:<eglglessink0> Building initial list of wanted eglattribs per format
0:00:00.188971449   388 0x5d50abf1c560 TRACE               GST_CAPS gstcaps.c:263:gst_caps_new_empty: created caps 0x5d50ac37b390
0:00:00.188983612   388 0x5d50abf1c560 TRACE               GST_CAPS gstcaps.c:263:gst_caps_new_empty: created caps 0x5d50ac37b310
0:00:00.188994713   388 0x5d50abf1c560 TRACE              structure gststructure.c:292:gst_structure_new_id_empty_with_size: created structure 0x5d50ac39af10

No. It has nothing to do with GStreamer.

It is necessary to share all devices between host and the container with --privileged option.

it’s fine, I’ll do this, but for sure something changed between the 2 images, maybe libdrm or MESA stuff. Anyway it’s working fine now.

This topic was automatically closed 14 days after the last reply. New replies are no longer allowed.