Skip to content
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

Closed
pmolodo opened this issue Dec 21, 2017 · 4 comments
Closed

Same plugin loaded twice #358

pmolodo opened this issue Dec 21, 2017 · 4 comments

Comments

@pmolodo
Copy link
Contributor

pmolodo commented Dec 21, 2017

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:

  1. Get Lock
  2. Check if another plugin with same name is registered
  3. Release Lock
  4. Make plugin
  5. Get Lock
  6. Add plugin to registry
  7. Release lock

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:

  1. Get Lock
  2. Check if another plugin with same name is registered
  3. Add null-ptr plugin entry to registry
  4. Release Lock
  5. Make plugin
  6. Get Lock
  7. Add real plugin to registry (overwriting our null entry)
  8. Release lock

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.

@jtran56
Copy link

jtran56 commented Dec 21, 2017

Filed as internal issue #155341.

@pmolodo
Copy link
Contributor Author

pmolodo commented Dec 21, 2017

Just filed a PR which should fix this...

@sunyab
Copy link
Contributor

sunyab commented Feb 1, 2018

This should be addressed by commit 9ad3c35.

@sunyab
Copy link
Contributor

sunyab commented Feb 7, 2018

This fix is in release v0.8.3. Closing, thanks!

@sunyab sunyab closed this as completed Feb 7, 2018
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
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants