Crash if you invoke GetOutputList via WebSocket under some conditions

[BarryCarlyon]

Operating System Info

Windows 10

Other OS

No response

OBS Studio Version

31.0.0

OBS Studio Version (Other)

No response

OBS Studio Log URL

N/A

OBS Studio Crash Log URL

https://obsproject.com/logs/qMKTuld3G592YOZO

Expected Behavior

Not to crash

Current Behavior

Crashes

Steps to Reproduce

1. Invoke GetOutputList when a profile change is occuring (I think)
2. Crash

I've had this occur twice, the first time I wasn't sure when it was doing it
The second time it occur when I was making OBS change profiles.
I'm invoking GetOutputList every second, so theres a possible edge case where There are NO outputs (as it's rebuilding them) or things are occuring inside OBS meaning the outputs don't exist

Anything else we should know?

older log file:

Crash 2024-12-18 17-48-01.txt

[alinsavix]

I think https://github.com/obsproject/obs-websocket might be the better repository for this issue?

[BarryCarlyon]

I'm not sure if the fault is in OBS core or the Websocket plugin since WebSocket plugin just invokes the core functions, so the fault might be that obs_enum_outputs is returning null instead of an empty array

Or the websocket plugin needs to check if null before trying to enumerate it

Or it's something else

I can cross raise an issue in obs-websocket but this feels more like a core fault, since there an inconsitent return from the core function

since the core function of getting a width on a output that doesn't exist shouldn't crash obs?

[alinsavix]

I also ran into this crash, back in 30.0.2. I just disabled the stats gathering module that was enumerating the outputs to stop it in the short term, and then never got around to going back and looking closer.

I'll go ahead and include crash log, just in case it's useful, though I'm not sure it adds anything new.

crash 2024-08-12 (1).txt

[alinsavix]

@BarryCarlyon Could you post the matching regular OBS log that matches your crash log?

[BarryCarlyon]

Theres absolutely nothing (relavant) in the log other than

• websocket connected
• webscoket disconnected
• log ends

So I didn't include it, end snippet around where the crash happened

You can see I connected at 17:47:59.212 to the socket then OBS crashed and disconnected the socket 5 seconds later

This one doesn't have a profile change associated but there might have been a profile change that was attempted dispite being live/streaming. The UI locks out profile changes when streaming, but that doesn't stop websockets doing the profile change. (need to retest and file that one)

17:40:51.414: caption settings changed, starting captioning
17:40:51.414: caption_output_writer_loop streaming starting
17:40:51.414: captioning start ok
17:40:51.417: ==== Streaming Start ===============================================
17:40:59.879: User switched to scene 'Intro'
17:41:51.453: [obs-websocket] [WebSocketServer::onClose] WebSocket client `[::ffff:127.0.0.1]:64518` has disconnected with code `1006` and reason: End of File
17:41:51.588: [obs-websocket] [WebSocketServer::onOpen] New WebSocket client has connected from [::ffff:127.0.0.1]:50508
17:43:41.276: User switched to scene 'NiceIntro'
17:45:40.706: User switched to scene 'Player'
17:45:46.589: QObject::connect: Cannot connect (nullptr)::focusObjectChanged(QObject*) to OBSApp::_q_updateFocusObject(QObject*)
17:47:59.212: [obs-websocket] [WebSocketServer::onOpen] New WebSocket client has connected from [::ffff:127.0.0.1]:51168
17:48:04.929: [obs-websocket] [WebSocketServer::onClose] WebSocket client `[::ffff:127.0.0.1]:51168` has disconnected with code `1006` and reason: End of File
17:48:32.837: last caption line was sent 23.040206 secs ago, > 15.000000, clearing

Full log: https://obsproject.com/logs/TiUS6BXlYWOVTvbN

[alinsavix]

Not everything relevant is going to be clearly labelled as being a websocket thing -- there's a lot of other useful information in a log. For example, I can see from the one you posted (thanks!) that you have multiple potential outputs that could be getting iterated -- ndi, multi-rtmp, and aitum-multistream are all present, which seems like it could be relevant. And it also looks like you're not using decklink hardware, which is also useful information (with the crash I saw, we were using decklink hardware and just added a second card the day before it crashed, so knowing that the decklink card probably wasn't (directly) the trigger in both our cases is useful knowledge.

So more useful than you might think, at first glance.

[BarryCarlyon]

interestingly with aitum only shows in the output list when a given aitum output is active which is odd in itself

I should probably remove multi RTMP as I had that for testing with.
NDI always shows whether it's active or not

So it can't iterate aitum outputs if no aitum outputs are active, which was the case in my crashes, I only had the main output or no outputs active at all