(Duplicate of post at
https://obsproject.com/forum/thread...al-analysis-web-sockets-also-involved.145612/)
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).