OBS/CEF segfaults consistently on application exit

[mihawk90]

edit:
Offending commit and workaround found, see comment 7.

---

Operating System Info

Other

Other OS

Fedora 42

OBS Studio Version

Other

OBS Studio Version (Other)

32.0.0-beta1

OBS Studio Log URL

https://github.com/user-attachments/files/22277058/2025-09-11.16-08-07.txt

OBS Studio Crash Log URL

https://github.com/user-attachments/files/22277059/gdb.txt

Expected Behavior

OBS should be closing the browserdocks and exiting cleanly.

Current Behavior

OBS segfaults on exit, resulting in the "unclean shutdown" dialogue showing each launch.

Steps to Reproduce

Unfortunately reproduction is a bit murky since last time during testing I wasn't able to get it consistently either (which is why I didn't open an issue then), so I can only infer from my main profile where it happens consistently.

1. Login to Twitch to get the Twitch docks
2. Add a couple more custom browser docks (I have 5 additional)
   • https://dashboard.twitch.tv/popout/u/<user>/stream-manager/stream-health
   • https://dashboard.twitch.tv/popout/u/<user>/stream-manager/quick-actions
   • https://dashboard.twitch.tv/popout/u/<user>/stream-manager/activity-feed?uuid=<uuid> (not sure why I still have this TBH)
   • https://dashboard.twitch.tv/popout/u/<user>/stream-manager/reward-queue?uuid=<uuid>
   • https://play.pretzel.rocks/my-music/playlists
   • I also have various browser sources, but from what I understand they should not be relevant here
3. Close OBS
4. Get lucky(?)
5. ...
6. Profit(?)/segfault

Anything else we should know?

This used to be a widespread issue (happening with just the Twitch docks even), but was fixed in (IIRC) OBS 30. It started happening again with the OBS 31.1 beta cycle.

On Discord I was troubleshooting with Matt and we ended up increasing the timeout here:

obs-browser/panel/browser-panel.cpp

Lines 169 to 176 in 910617b

	#if !defined(_WIN32) && !defined(__APPLE__) && CHROME_VERSION_BUILD >= 6533
	QEventLoop loop;
	connect(this, &QCefWidgetInternal::readyToClose, &loop, &QEventLoop::quit);
	QTimer::singleShot(1000, &loop, &QEventLoop::quit);
	loop.exec();

... to 5000, which fixed it for the most part. However it seems to me that increasing the timeout is really only a bandaid and not fixing the actual problem?

Regardless, during testing with a new profile I was unable to reproduce this consistently, which is likely due to not adding all the docks I have in my main profile, where I do get this consistently.

To my knowledge the exact cause of this crash is still unknown, but it was "fixed" with OBS 30 introducing the timeout loop. I have yet to figure out what happened between 31 and 31.1 beta1 to have this reappear, since I didn't get to bisect considering I couldn't reproduce it reliably in testing.

I don't remember if the backtrace from back then was the same/similar, you'd have to check the old beta discord channels for it, pretty sure I posted it.

This crash is likely tangentially related to #353

[mihawk90]

tytan suggested testing with 6533v6 as well (the previous log was with v5), so here we are:

https://github.com/user-attachments/files/22282679/gdb.txt

To me these GDB backtraces are all hieroglyphs but at first glance it looks to be the same(-ish), except for

#0  0x0000000000000000 in ??? ()

Which I don't know what that is because I have all the debug symbols I could get...

[RytoEX]

tytan suggested testing with 6533v6 as well (the previous log was with v5), so here we are:

https://github.com/user-attachments/files/22282679/gdb.txt

To me these GDB backtraces are all hieroglyphs but at first glance it looks to be the same(-ish), except for

#0  0x0000000000000000 in ??? ()

Which I don't know what that is because I have all the debug symbols I could get...

Due to the presence of QMainWindowTabBar in the stack, this almost sounds like QTBUG-137755:

• qt/qtbase@cc1ddeb

The stack in that QTBUG is the same as yours. Fixed in Qt 6.9.2 and 6.10+.

[mihawk90]

This is with Qt 6.9.2 (runtime, I didn't rebuild):

https://github.com/user-attachments/files/22283813/gdb.txt

[RytoEX]

This is with Qt 6.9.2 (runtime, I didn't rebuild):

https://github.com/user-attachments/files/22283813/gdb.txt

# 0 0x0000555558004000 in ??? ()
# 1 0x00007fff2a89625c in QCefWidgetInternal::unsetToplevelXdndProxy (this=0x555559b8e400) at /usr/src/debug/obs-studio-32.0.0~beta1-11.fc42.x86_64/plugins/obs-browser/panel/browser-panel.cpp:249
[...]
# 13 0x00007fff2a88e712 in BrowserManagerThread () at /usr/src/debug/obs-studio-32.0.0~beta1-11.fc42.x86_64/plugins/obs-browser/obs-browser-plugin.cpp:415

The only context I can provide is here:

obs-browser/panel/browser-panel.cpp

Lines 237 to 253 in c3b1e81

	/* On Linux / X11, CEF sets the XdndProxy of the toplevel window
	* it's attached to, so that it can read drag events. When this
	* toplevel happens to be OBS Studio's main window (e.g. when a
	* browser panel is docked into to the main window), setting the
	* XdndProxy atom ends up breaking DnD of sources and scenes. Thus,
	* we have to manually unset this atom.
	*/
	void QCefWidgetInternal::unsetToplevelXdndProxy()
	{
	if (!cefBrowser)
	return;
	CefWindowHandle browserHandle = cefBrowser->GetHost()->GetWindowHandle();
	Display *xDisplay = cef_get_xdisplay();
	Window toplevel, root, parent, *children;
	unsigned int nChildren;
	bool found = false;

Line 249 is the offending line in the stack here. Perhaps somehow cefBrowser still exists here, but something else is wrong here.

[RytoEX]

Some further pondering:
What's puzzling to me is that unsetToplevelXdndProxy() seems like it should only be called on initialization. Or at least, it's added to the CEF task queue on initialization. Not sure why it's being called on application exit, unless it's flushing the task queue and it's still stuck in there.

obs-browser/panel/browser-panel.cpp

Lines 276 to 281 in c3b1e81

	// Check if the XdndProxy property is set
	Atom xDndProxyAtom = XInternAtom(xDisplay, "XdndProxy", False);
	if (needsDeleteXdndProxy && !XWindowHasAtom(xDisplay, toplevel, xDndProxyAtom)) {
	QueueCEFTask([this]() { unsetToplevelXdndProxy(); });
	return;
	}

obs-browser/panel/browser-panel.cpp

Lines 326 to 328 in c3b1e81

	#ifdef __linux__
	QueueCEFTask([this]() { unsetToplevelXdndProxy(); });
	#endif

[mihawk90]

OK so I've been trying to bisect and started with bisecting obs-browser first because it is the smaller commit count compared to OBS proper.

The relevant history is this:
b56fd78...5ee8056

And here's how it went:

All testing with CEF 6533v6

31.0.3^0
5ee8056
build failure :<

31.0.3^1
a54e7c4
good

31.0.3^2
0fb70b6
good

31.0.3^3
f617868
build failure :<

The build failures are this:

/builddir/build/BUILD/obs-studio-31.0.3_3-build/obs-studio/plugins/obs-browser/obs-browser-plugin.cpp:719:21: error: ‘gs_get_driver_version’ was not declared in this scope
  719 |         glVersion = gs_get_driver_version();
      |                     ^~~~~~~~~~~~~~~~~~~~~

And this is beyond me to fix because I have no idea about the codebase.

However, f617868 is windows-specific so should be irrelevant. The commit after that (5ee8056) only increases the version, and the commit before (0b13eb9) introduces the build failure.
So unless the problem is the glVersion change I think it's safe to say obs-browser is not the issue.

[mihawk90]

Finally done with bisecting OBS commits.

TLDR:

obsproject/obs-studio@bdebea3

bdebea3d858deeccf1900fe8272d1f40bb9501e3 is the first bad commit
commit bdebea3d858deeccf1900fe8272d1f40bb9501e3
Author: tytan652
Date:   Wed Sep 11 14:01:36 2024 +0200

    frontend: Enable browser hw accel toggle under Linux

 frontend/OBSApp.cpp                    |  6 ++++--
 frontend/settings/OBSBasicSettings.cpp | 10 +++++-----
 2 files changed, 9 insertions(+), 7 deletions(-)

---

edit:
It's late so I didn't think of the next logical step which Matt pointed out...
Disabling Hardware Acceleration (in the settings, not by reverting the commit) does indeed fix the crash. Across 8 restarts there was no crash, turned it back on and I immediately got one again.

---

git bisect good 31.0.3

git bisect bad 31.1.0-beta1

git bisect good/bad && git submodule update --init --recursive after each

Test builds

All testing with CEF 6533v6

31.0.3^4
obsproject/obs-studio@f03280c
good

31.0.3^5
obsproject/obs-studio@8f1bcc1
good

31.0.3^6
obsproject/obs-studio@a19945b
good

31.0.3^7
obsproject/obs-studio@6204c22
good

31.0.3^8
obsproject/obs-studio@b46e5bb
good

31.0.3^9
obsproject/obs-studio@b9cd9f3
good

31.0.3^10
obsproject/obs-studio@f6c6b3f
good

31.0.3^11
obsproject/obs-studio@bdebea3
bad (3/10 good)

31.0.3^12
obsproject/obs-studio@e8d1834
good

[RytoEX]

Acknowledging that the above conclusion seems to be that the browser source hardware acceleration setting seems to be somehow causing this. Unfortunately, debugging that is beyond me, as I primarily work on Windows.

[RytoEX]

The build failures are this:

/builddir/build/BUILD/obs-studio-31.0.3_3-build/obs-studio/plugins/obs-browser/obs-browser-plugin.cpp:719:21: error: ‘gs_get_driver_version’ was not declared in this scope
  719 |         glVersion = gs_get_driver_version();
      |                     ^~~~~~~~~~~~~~~~~~~~~

And this is beyond me to fix because I have no idea about the codebase.

For completeness, this should be because gs_get_driver_version() was only added in OBS Studio 31.1, so obviously the function is not available when building against 31.0.x (before obsproject/obs-studio@abb8cdf).