-
Notifications
You must be signed in to change notification settings - Fork 1.3k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Same plugin loaded twice #358
Comments
Filed as internal issue #155341. |
Just filed a PR which should fix this... |
This should be addressed by commit 9ad3c35. |
This fix is in release v0.8.3. Closing, thanks! |
AdamFelt
pushed a commit
to autodesk-forks/USD
that referenced
this issue
Apr 16, 2024
…nStudios#358) ### Description of Change(s) Merge adsk/feature/progressive rendering, which add cancel callback for frame interuption. ### Fixes Issue(s)
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Description of Issue
Hi - so we've had issues a few times where USD attempts to load the same plugin twice, leading to nasty error messages or straight-up-crashes.
This can happen if the same path ends up in the plugin search path twice... in our case, we got this because the at-build-time install location is baked into libplug.so, and added to the search path, and we had subsequently copied the install to a second location.
This happens because the PlugPlugin::_NewXXXPlugin() functions aren't properly locking on their plugin identifier, leading to the race conditions - ie, right now, the steps are:
So, if we have two threads, A and B, and they have an execution order like this:
A1-3, B1-3, A4, B4
...then you can see we get the same plugin loaded twice, and have problems.
This is easy to fix by adding a dummy entry to the plugin hashtables within the scope as the initial check, before the lock is released - ie, do:
This should solve any race conditions - the only downside is that we have no guarantee of "fallback" behavior - ie, if the same plugin is on the path twice, but one copy is "bad", and will fail to register somehow, and the second is "good", then, depending on order of operations, we may sometimes fail, sometimes succeed, etc.
Assuming you don't care about that - it's not unreasonable to require all plugins on the path to be functional - then I'll make a PR for my simple fix.
The text was updated successfully, but these errors were encountered: