[Linux] Browser plugin keeps OBS 29.x from closing

[cybik]

Operating System Info

Ubuntu 22.10

Other OS

Technically, using Pop!_OS

OBS Studio Version

29.0.2

OBS Studio Log URL

https://obsproject.com/logs/9tLgxfOM7GVdLTmC

OBS Studio Crash Log URL

No response

Expected Behavior

OBS closes fine.

Current Behavior

Main OBS app closes okay, but ps faux | grep obs shows about five obs-browser-page processes (or more) hanging around after using File > Quit (not minimizing to system tray here)

Steps to Reproduce

1. Install OBS
2. Open OBS
3. Setup at least 6 different scenes with different pages
4. Close
5. ps aux | grep -v grep | grep obs

Anything else we should know?

My theory is that any browser plugin "instance" except the current scene, might not get the signal to clear out, and the main OBS object [instance / global / whatever] might be waiting on the plugin.

Not sure if this is a plugin issue, or a main app issue.

[Fenrirthviti]

Please test again without third-party plugins installed. Browser subprocesses are normal if something is blocking exit of the program.

[cybik]

@Fenrirthviti will do. I'll just note here that I know browser subprocesses are normal by themselves - I code in C++ on occasion, I'm acquainted with threading, processes and the such. Them surviving an app close is what I'm reporting on.

(I might just dive into the code myself if I'm bored enough :P)

[tt2468]

I can replicate this as a fault of StreamFX blocking shutdown. The subprocesses you see running are just standard CEF stuff and will exit along with OBS at final shutdown.

EDIT: Here's a gdb backtrace of the deadlock:

#1  __pthread_cond_wait_common (abstime=0x0, clockid=0, mutex=0x5634ffc5ab90, cond=0x5634ffc5abb8) at pthread_cond_wait.c:508
#2  __pthread_cond_wait (cond=0x5634ffc5abb8, mutex=0x5634ffc5ab90) at pthread_cond_wait.c:647
#3  0x00007f5dca9ade30 in std::condition_variable::wait(std::unique_lock<std::mutex>&) () at /usr/lib/x86_64-linux-gnu/libstdc++.so.6
#4  0x00007f5d72d3c7e3 in streamfx::util::threadpool::task::wait() () at /usr//lib/x86_64-linux-gnu/obs-plugins/StreamFX.so
#5  0x00007f5d72d3da99 in streamfx::configuration::~configuration() () at /usr//lib/x86_64-linux-gnu/obs-plugins/StreamFX.so
#6  0x00007f5d72d3a58a in streamfx::configuration::finalize() () at /usr//lib/x86_64-linux-gnu/obs-plugins/StreamFX.so
#7  0x00007f5d72d41317 in obs_module_unload () at /usr//lib/x86_64-linux-gnu/obs-plugins/StreamFX.so
#8  0x00007f5dcb672ecb in free_module () at /usr/lib/x86_64-linux-gnu/libobs.so.0
#9  0x00007f5dcb6525e7 in obs_shutdown () at /usr/lib/x86_64-linux-gnu/libobs.so.0
#10 0x00005634fef14ad5 in  ()
#11 0x00005634feeefed1 in main ()

[cybik]

Oh my.

Validated. Closing this one.

[cybik]

Linking bug report in that plugin, for the record

https://github.com/Xaymar/obs-StreamFX/issues/1017

[cybik]

@Xaymar you wanted a backtrace/stacktrace, I believe?

[tt2468]

I found the issue and have relayed the fix to Xaymar, so I think we're all good.