add strong ref to resolve race condition#1707
Conversation
* there was a narrow window between calling find() and OBSSource where a race condition could still happen triggering a use-and-free situation. * add findAndRef to resolve this crash dump. * remove the js test it does not trigger the issue. In another PR, it properly spins up parallel threads to validate the fix.
There was a problem hiding this comment.
Pull request overview
This PR addresses a reported use-after-free crash by ensuring a strong OBS source reference is acquired under the manager lock, closing a race window between lookup and ref acquisition. It also removes a JS concurrency test that was not reliably reproducing the issue.
Changes:
- Added
Source::Manager::findAndRef()to atomically look up a source and acquire a strong reference under the manager mutex. - Updated
Source::GetProperties()to usefindAndRef()and hold the returned strong reference viaOBSSourceAutoRelease. - Removed the JS test that attempted to reproduce the concurrency crash but did not reliably trigger it.
Reviewed changes
Copilot reviewed 3 out of 3 changed files in this pull request and generated 1 comment.
| File | Description |
|---|---|
| tests/osn-tests/src/test_osn_source.ts | Removes the nondeterministic concurrent getProperties/release test case. |
| obs-studio-server/source/osn-source.hpp | Adds findAndRef() helper and includes <obs.hpp> for OBSSourceAutoRelease. |
| obs-studio-server/source/osn-source.cpp | Uses findAndRef() in GetProperties() to avoid the race window. |
💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.
There was a problem hiding this comment.
A note for future improvements.
A smaller scope caveat: this only fixes Source::GetProperties. Other Source RPCs still use raw Manager::find() and dereference after the lock is released. That's fine for now, but it does not eliminate the whole class of release-vs-source-use races.
Description
void osn::Source::GetProperties) where a race condition could still happen triggering a use-and-free situation.Motivation and Context
This is a follow up to my previous pull request. Copilot alledged there was still a small window where the race condition could still occur.
Hoping to fix this sentry call stack:
How Has This Been Tested?
I have a WIP branch that adds a C++ test that properly reproduces this issue and verifies it is fixed.
Types of changes
Checklist: