UI: Fix crash on *nix caused by OBSQTDisplay destruction after draw surface invalidation

[tt2468]

Description

Deletes the underlying obs_display_t object when the window draw surface is destroyed (X11 and Wayland), preventing OBS from attempting to switch to invalid GLX context on draw.

Closes #4185

Motivation and Context

Currently: This issue is mainly caused by the behavior of Qt's DeleteLater. When a window using OBSQTDisplay is closed, there is an indeterminate delay until the Qt object for it is deleted, allowing for a race.

With this: The OBSQTDisplay object is deleted before the draw surface is, preventing the race condition. No longer reports any X errors, let alone crashes.

How Has This Been Tested?

This issue can be most easily reproduced by doing:

• Open OBS
• Open the filters dialog of a playing source
• Close the dialog via the x in the top right corner (Not the Close button)
  Expect X errors to be logged, and if lucky enough, a crash. It varies system to system, but if you have the bug (like me), it's usually very easy to reproduce.

Types of changes

• Bug fix (non-breaking change which fixes an issue)

Checklist:

• My code has been run through clang-format.
• I have read the contributing document.
• My code is not on the master branch.
• The code has been tested.
• All commit messages are properly formatted and commits squashed where appropriate.
• I have included updates to all appropriate documentation.

[kkartaltepe]

Very cool find! I dont think this is the fix but it seems there is some issue with our sync between the UI and the libobs.

[tt2468]

I've updated the PR with a more updated and direct patch to the issue. Testing on both of my PCs, I could not get any GLXBadDrawable errors or crashes. One PC is running nvidia-440 drivers and a tesla t4, one is running nvidia-450 and an rtx 4000.

On 440.100, the problem usually manifests itself as:

#0  __memmove_avx_unaligned_erms () at ../sysdeps/x86_64/multiarch/memmove-vec-unaligned-erms.S:262
#1  0x00007ffff5dd10f1 in memcpy (__len=<optimized out>, __src=0x7fff29c8bb60, __dest=<optimized out>) at /usr/include/x86_64-linux-gnu/bits/string_fortified.h:34
#2  gs_texture_set_image (tex=0x7fffd01297c0, data=0x7fff29c8bb60 "X", linesize=<optimized out>, flip=flip@entry=false) at /home/tt2468/irltk/obs-studio/libobs/graphics/graphics.c:1173

[ekordas]

On my System it used to crash every time after closing the v4l2 video properties Dialog.
Tested your pull and it fixes the Crash of the v4l2 video properties Dialog.

[jp9000]

Just wanted to make sure you didn't forget about this PR. Seems some people have been testing it.

[tt2468]

Just wanted to make sure you didn't forget about this PR. Seems some people have been testing it.

I haven't forgotten about it, but I'm unsure what direction to proceed in. This seems to fix the issue, but it feels more like a patch. The graphics thread is still susceptible to failed context switches. I don't remember which particular call was the problem, but my idea was to turn it into a boolean return, to be able to know if the GLX context is valid. Implementing my PR in its current form does not guard against this same issue cropping up in future features using OBSQTDisplay.

[leohoe]

Just making sure, is this still in the works? The problem is ongoing, and if this fixes it, it would be great to have available for production use.

[tt2468]

@leohoe Last time I brought it up to OBS project devs, I was told to wait to ask questions about the direction I should take until 27.1 is out, so that's the current status of this PR.

[leohoe]

Since we're on 27.1.3 now, how are things looking for this PR?

[tt2468]

Update for those subscribed: This is slated to be released with 27.2. Thank you for your patience!