Crash during Scene Item Collection change (with partial analysis); Web Sockets also involved

[Notinasnaid]

I'm not quite sure of the best way to report this crash. I have done a certain amount of source code analysis, and it seems to lie in a grey area between OBS itself and the OBS web sockets plug-in, but I'm leaning more towards it being a core OBS issue. The crash has shown itself in the final OBS 26.x and in 27.0 on Mac (M1, Big Sur). It happens during change of Scene Collection. This is what seems to be happening in one particular crash.

- Nothing is written to the OBS log from this point
- The Scene Collection change starts
- All current sources are destroyed. Notifications are sent (from OBS events to OBS web sockets events) showing this has happened.
- About 0.2 seconds pass. The scene collection has not yet loaded and the UI is locked.
- An external app sends a request via OBS web sockets "GetSceneList". It does this every second, so it's likely to hit a lot of scene item collection changes.
- This results in a call to obs_frontend_get_scenes, and this function crashes. Details SYSSEGV, offset + 120 (version 27.0).

I speculate that the data structures in the UI are not in a good state at this point in the scene collection change. It would be better to lock out requests if they are going to cause crashes. Perhaps an event OBS_FRONTEND_EVENT_SCENE_COLLECTION_CHANGING could also be sent; this could also clue in monitor processes to just not bother themselves until OBS_FRONTEND_EVENT_SCENE_COLLECTION_CHANGED is sent, because even if all the requests are ok, there is likely to be a lot of redundant work.

I am working with a customised OBS websockets plug-in and would happily add tests to avoid this problem, but I can't really see what to look for. (The only other plug-in loaded is OBS Audio Monitor).

 

[Notinasnaid]

I will share a work around for this problem. It isn't pretty, but it seems to keep from getting OBS crashes on scene collection changes when a plug-in tries to call obs_frontend_get_scenes.
1. In a plug-in, register for a preloadcallback with obs_frontend_add_preload_callback
2. Also add code to handle OBS_FRONTEND_SCENE_COLLECTION_CHANGED.
3. Between these two calls, lock out normal processing (since there is not much point trying to track what is happening until the scene collection change completes).
There is no API for "start scene collection change", so we see a succession of "source destroyed" messages, however everything remains stable. The preload callback indicates we are entering the load process.
I believe a full solution lies in OBS: if the front end data is potentially unreliable or might cause a crash, then the front end API should not continue into a crash. There is already an interlock against saving during this period, but that is not accessible to an API, and probably doesn't cover quite the same ground.
NB I don't know if a preloadcallback is called during OBS initialisation; the plug-in client is not yet connected so it would not see the event.