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

pxr.UsdGeom.Xformable.ClearXformOpOrder on an invalid prim crashes #872

Closed
marktucker opened this issue Jun 10, 2019 · 6 comments
Closed

Comments

@marktucker
Copy link
Contributor

Description of Issue

Invoking ClearXformOpOrder on an invalid UsdGeom.Xformable object in python will cause a crash.

Steps to Reproduce

  1. start python
  2. run:
    from pxr import UsdGeom
    p = UsdGeom.Xformable()
    p.ClearXformOpOrder()
    The process will crash.

There are about a dozen levels in the call stack where the proverbial null pointer check could be added, but I'm not sure which of those is the right level, in line with existing protections for python functions on invalid Usd objects (trading off between the number of functions to which a null pointer check must be added vs the additional runtime of performing redundant null pointer checks).

Package Versions

19.05

@spiffmon
Copy link
Member

Thanks for reporting, @marktucker ! I think the desired fix here is to add similar getattribute treatment as is given in usd/wrapObject.cpp to wrapSchemaBase.cpp ... and also the one or two "property schemas" we have, like UsdGeomPrimvar.

@marktucker
Copy link
Contributor Author

I just did a quick test, and was able to implement this for UsdGeomXformable and UsdGeomPrimvar pretty easily... If you want to tell me which other classes fall into this category I can wrap them all into one PR? I also didn't whitelist any particular functions since I didn't see any of them making sense to call on "null" prims. Let me know if you think there are functions that should pass through the getattribute filter.

@spiffmon
Copy link
Member

Hi @marktucker ! If you hit wrapSchemaBase.cpp in core usd, that should handle all derived generated schema classes. UsdGeomPrimvar is the only "USD Object wrapper" schema I can recall that needs special treatment of its own.

I do think we want to pass at least GetPrim(), GetPath(), and the operator bool (though I'm not sure how to indicated that in this context.. my python-wrapping fu is not great). @gitamohr might have suggestions of other methods it would be good to pass.

marktucker added a commit to sideeffects/USD that referenced this issue Jun 13, 2019
… being

done in wrapObject. This overloaded __getattribute__ actually allows any of
the UsdSchemaBase APIs to be called (as all of the methods at this level can
still return useful information). But its purpose is to block calls to APIs
defined on subclasses.

Provided similar protection for UsdGeomPrimvar, which is an odd case that is
like a schema class, but operates on a single attribute and so is not derived
from SchemaBase.

Added some test cases, including an explicit test of issue PixarAnimationStudios#872, a crash when
calling UsdGeom.Xformable().ClearXformOpOrder(). TestUsdRiSplineAPI had to be
updated because a test in there was not expecting the RuntimeException from
an invalid object.
@marktucker
Copy link
Contributor Author

Not claiming the above pull request is complete, but I think it's easier to have something concrete to look at when discussing possible refinements. I ended up allowing all SchemaBase methods to be called on invalid SchemaBase objects, because they are safe, and make sense even if the underlying prim is null. But this change blocks all methods of all subclasses.

@jilliene
Copy link

Filed as internal issue #USD-5373

@sunyab
Copy link
Contributor

sunyab commented May 30, 2020

Closing this issue out as it was addressed by #876. I also wanted to note we recently added similar protection to UsdGeom.XformOp in commit 91f37aa. Thanks1

@sunyab sunyab closed this as completed May 30, 2020
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

4 participants