Invalid MIT-MAGIC-COOKIE-1 key[1] 8313 segmentation fault (core dumped)

Hi - I’m trying to run ffplay /dev/video0 and I’m getting this message:

Invalid MIT-MAGIC-COOKIE-1 key[1]   8313 segmentation fault (core dumped)   ffplay /dev/video0

Any help on what might be happening or where I can start debugging?


I fixed part of the message it looks like:


export DISPLAY=desktop:0

This removed the MIT-MAGIC-COOKIE-1 key

Now the message says

[1]  10980 segmentation fault (core dumped). ffplay /dev/video0

I couldn’t say for sure, but have you tried instead “DISPLAY=:0”? Is the same user launching ffplay also the user which is logged in to the GUI? Do you see your user listed in:
grep 'video' /etc/group

Thanks @linuxdev

I reflashed my sd card with the latest Image blob JP4.5.1 to my jetson nano 4gb B01 board and ran ffplay /dev/video0 and got a new message that says:

dbus[7838]: arguments to dbus_message_new_method_call() were incorrect, assertion "path != NULL" failed in file ../../../dbus/dbus-message.c line 1362.
This is normally a bug in some application using the D-Bus library.

  D-Bus not built with -rdynamic so unable to print a backtrace
Aborted (core dumped)

I tried DISPLAY=:0 and now the message Invalid MIT-MAGIC-COOKIE-1 has returned.

Running the command:
grep 'video' /etc/group


“bg-user” is my user name so yes it is listed in the group.

Anything else that it might be?

Really appreciate your help!

I don’t develop for ffplay, so I can’t answer the questions specific to that. However, if your user is “bg-user”, and you run ffplay as that user, then your software has full access to GPU hardware (if things are set up correctly, then there is no reason that user would not succeed). The content of “/etc/group” verifies this is set up correctly.

If you start ffplay from the GUI itself, and are running ffplay as the user logged in to that GUI, then there would be no need to “export DISPLAY=....something...”. If you were to log in to your user in a non-GUI console, then you would need to export the correct DISPLAY to associate to the available GUI. If you are in your GUI and run command “echo $DISPLAY”, then this would guarantee the correct DISPLAY to export when not running from that GUI while trying to associate the ffplay with that GUI. Usually it is this:
export DISPLAY=":0"
…what do you see from your GUI with “echo $DISPLAY”?

In most cases DISPLAY is “:0”, but in other cases, DISPLAY is “:1”; you would use the correct DISPLAY from the non-GUI console (if running ffplay from outside of the X GUI) prior to running ffplay:

export DISPLAY=":1"
...some ffplay command...

(but keep in mind I don’t have to run from a text-based non-GUI console…you can ignore all of that export and DISPLAY information when launched in a GUI your user already owns…launching from inside the GUI automates setting this up)

Note that all of the MIT-MAGIC-COOKIE errors are part of the X GUI security setup. This is a big reason why I mention the “export” and “DISPLAY” information. You should never see an error related to that when a user logged in to a GUI launches software from that GUI…at least it wouldn’t be a security issue. Can you launch the ffplay without error from the GUI your user is already logged in to? If you can, then your ffplay command should be valid; if not, then regardless of running from a non-GUI terminal or from the GUI I would expect failure. If you can run ffplay directly on the GUI, expect a similar error by specifying the wrongDISPLAY”, e.g., if you are really on “:0” and specify “:1” (or vice versa), then you would get such an error. Also, if using a non-GUI and specifying DISPLAY such that it is lost prior to running ffplay (e.g., not using export from that console prior to running ffplay), then I would also expect such an error.

Thanks again @linuxdev

This makes sense. I’ve been ssh-ing in to the nano from my macbook and that could’ve been part of the problem.

When I run echo $DISPLAY from a nano terminal I get :1. When DISPLAY is set to :0 I get the MIT-MAGIC-COOKIE error but when set it to :1 there is NO error.

So I seemed to get ffplay to run after I searched for dbus errors and found a workaround here.

Running the command export DBUS_FATAL_WARNINGS=0 allowed video to be displayed from my camera running ffplay but it still says the warning:

dbus[8099]:  arguments to dbus_message_new_method_call() were incorrect, assertion "path != NULL" failed in file ../../../dbus/dbus-message.c line 1362.
This is normally a bug in some application using the D-Bus library.

Apparently DBUS is related to the emulator. As another piece of information regarding my setup, I have both the nano 2GB running jp441 and the nano 4GB B01 running jp441 as well and I only see this error on the 4GB B01 machine.
maybe this is useful information?

Any suggestions on if or how I should investigate this dbus issue?

Thanks so much,

Yes, if you ssh in from a Mac it won’t know which “$DISPLAY” the command is intended to display to. I will assume you don’t want it to remote display to the Mac itself, which would be its own topic on forwarding (and pointless if the Mac doesn’t have an X server, and I don’t have a Mac…while Macs have a lot in common with Linux I have no idea if they use X or not…though probably not).

The best thing to do, at least while testing and setting up, is to actually go to a terminal in the video output GUI of the Jetson, and see what occurs from “echo $DISPLAY”. This would be the DISPLAY to export prior to the command from the ssh terminal. E.g., if it is “:0”, then from the ssh terminal:
export DISPLAY=":0"
…followed by running your “ffplay” command.

Also be certain that the user which has the Jetson GUI open is also the user the ssh session is logged in as.

Note that dbus is a secure mechanism for certain communications between applications in the X environment. MIT-MAGIC-COOKIE can be related to this, and so can “$DISPLAY” and the user name you are logged in as. Basically it is either an issue of security, or an issue of being able to find and associate the correct GUI to display to.

Also, note that if you are trying to display to the Mac what you are running on the Jetson, that this will fail unless the Mac is running X and security has allowed the forwarding. I don’t know Mac setup, so I couldn’t tell you what is needed to remote display to a Mac without a virtual desktop.

1 Like

Thanks @linuxdev

I will do some research on dbus and the X environment.