31.0.0 freezes when exiting on macOS

[izwb003]

Operating System Info

macOS 15

Other OS

No response

OBS Studio Version

31.0.0

OBS Studio Version (Other)

No response

OBS Studio Log URL

https://obsproject.com/logs/BQZ9q616XlYA2vgE

OBS Studio Crash Log URL

No response

Expected Behavior

OBS can quit normally every time and will not display the safe mode dialog on next startup.

Current Behavior

Sometimes (frequently) OBS will freeze on quit.

Steps to Reproduce

1. Launch OBS 31.0.0 (both tried in normal mode and safe mode);
2. Do something or not;
3. Quit OBS, then it freezes, macOS beachball appears;
4. Force to quit and launch again, OBS will ask me to choose running in safe mode or normal mode;

Anything else we should know?

Other users have also reported this issue, see the forum, which seems to only occur in OBS 31.0.0 version. This issue will occur regardless of whether the program is started in safe mode or not. The above log was recorded in safe mode, and it seems that it did not record any issues.

I also discovered that if this issue occurs, OBS will not be able to show any window and will not display any pop-up menus except the settings window. But when I open the settings or click the OBS icon on the dock, these windows will appear again. OBS will also freeze if I try to switch between Profiles or Scene Collections.

[morningwind128]

me too!

[jcm93]

Could you please collect a Spindump while OBS is in the unresponsive state?

Specifically, you'll want to select OBS in the list of applications in Activity Monitor (it should say "Not Responding"), then hit the ellipsis and Spindump. Then when the file pops up in Finder, attach it here.

[izwb003]

Could you please collect a Spindump while OBS is in the unresponsive state?

Sure. Here is it:
OBS_issue_11650_spindump.txt
And here is how it is symbolized with dSYMs, if no mistake:
OBS_issue_11650_spindump_symbolized.txt

[jcm93]

Thanks; it looks like a deadlock between the destruction task queue and the main thread. I can't tell exactly why it's happening though at the moment and am not able to reproduce. If other users have a Spindump (accompanied by an OBS log) that would still be useful to perhaps identify a common factor.

[izwb003]

Thanks; it looks like a deadlock between the destruction task queue and the main thread. I can't tell exactly why it's happening though at the moment and am not able to reproduce. If other users have a Spindump (accompanied by an OBS log) that would still be useful to perhaps identify a common factor.

It sounds like a problem that can only be replicated on some devices. Perhaps we need to wait for more reports from users.

Since my device can reproduce the issue, will it help identifying the cause if I try to build from the source for debugging?

[Kinfxhk]

me2 , using mac mini

[jcm93]

@Kinfxhk
@ForsakenDelusion

Please refrain from commenting "me too" on issues by itself; it makes it harder to track the important information in the thread. Per #11650 (comment), I could use spindumps and OBS logs from other users to help find common factors or eliminate variables connected to this issue. If you are having this issue, kindly collect a Spindump and attach it; do not just add "me too". Thanks.

[Lastorder-DC]

Spindump.txt
2024-12-23 15-18-03.txt

collected from macOS 14.6.1 / OBS 31.0.0 / MacBook Pro (13-inch, M1, 2020)

==========

p.s.) I know of other streamer who are experiencing the same issue. However, I don't have a spindump file for it. In this case, the symptoms of this issue occur on shutdown if you've been broadcasting on OBS for more than 10 minutes, and restarting in safe mode and then normal mode temporarily fixes it.

Downgrading to 30.2.3 fixes all problem(without disabling or changing any plugin version)

I can contact the streamer and get the spindump file if needed, the streamer uses an Intel Macbook.

[izwb003]

I guess I found out why... See commit 4dac849, InputMethodChangedProc():

...
pthread_mutex_lock(&hotkeys->mutex);
...
if (!platform->layout_data) {
    blog(LOG_ERROR, "hotkeys-cocoa: Failed to retrieve keyboard layout data");
    hotkeys->platform_context = NULL;
    pthread_mutex_unlock(&hotkeys->mutex);
    hotkeys_release(platform);
    return;
}
...

Then if platform->layout_data exists, the mutex on hotkeys will never be released. So if the input method changed, when exiting the destruction task queue will never get the lock on hotkeys, so freezes the whole OBS.

@Kinfxhk @ForsakenDelusion @Lastorder-DC Are you a multilingual user and have input methods installed in the system? If so, this may explain why it can only be reproduced on some devices.

If it can be confirmed that this is the reason, I will try to submit a PR.

[jcm93]

Nice catch; it looks like you are correct; failing to unlock that mutex would definitely result in this behavior. I can indeed reproduce it by changing my keyboard layout while OBS is open.

[izwb003]

Nice catch; it looks like you are correct; failing to unlock that mutex would definitely result in this behavior. I can indeed reproduce it by changing my keyboard layout while OBS is open.

I have #11663 for this and hope it works.

[Samo-DSF]

OBS Studio 30.1.2 KLAS