Lyon_ Rosenblatt

lyon001

About Me

Connect

LOCATION
Not Specified
ウェブサイト

Houdini Engine

Availability

Not Specified

Recent Forum Posts

Reloading USD Stages Causes UseAfterFree Error 2024年11月21日9:38

## Hello USD Users,

I'm currently working on an open-source USD Resolver and need some help refreshing a LOPs node stage. My primary goal is to reload all assets, which would be useful for clearing the resolver. In the future, I aim to implement functionality to reload specific assets selectively.

### The Problem

I assumed that running `.Reload()` on the stage provided by a node would cause the resolver to trigger `__RefreshContext()`, thereby refreshing the context and informing the stage that all resolves done with a given resolver are invalid. However, to my surprise, I encountered a *UseAfterFree* error.

I wasn’t able to dig too deeply into this with GDB, but I found that a series of locks were accessed by Houdini and one PXR lock (`pxrInternal_v0_24__pxrReserved__::XUSD_Data::afterLock`). This all occurred in a single thread within a combination of `libHoudiniUSD` and `libHoudiniAPPS3`. My assumption is that Houdini keeps the stage or layer pointer cached for later use, and when the resolver gets destructed, this leaves behind a dangling pointer.

### Issues Encountered
1. **Reloading USD Stage from Python LOP**: Attempting `.Reload()` on the stage not only fails but also causes a *use-after-free* error, resulting in segmentation faults.
2. **Resolver Context Notifications**:
- When I notify the stage that a resolver context has changed, all matching contexts are deleted. However, I don’t observe new resolutions.
- Based on the documentation, I assumed Houdini would reload everything since the notification invalidates the current resolver context, ensuring the user is shown up-to-date information.
3. **Re-resolution on Node Connection**:
- When connecting a new node, the entire stage is re-resolved, but this only occurs if something new is resolved.
- Is this behavior expected? I assumed the re-resolution would happen immediately after the stage is invalidated.

### Example Script
Here's a minimal script to reproduce the issue:

1. Go to LOPs.
2. Load something.
3. Run this in a Python LOP:
```python
node = hou.pwd()
stage = node.editableStage()
stage.Reload()
```

### Questions
1. Why does `.Reload()` fail and cause a segfault? Is it related to the stage being backed by an anonymous `SdfLayer`?
2. What is the expected behavior of the resolver context notification? Shouldn’t it trigger a reload automatically?
3. Is it normal for the stage to be re-resolved only when a new asset is resolved, rather than immediately after invalidation?

Any insights or suggestions to address these issues would be greatly appreciated!

Thanks in advance for your help!

Accessing Upstream Node Data in Custom ROP Node 2024年10月10日9:07

Hi everyone,

I'm currently developing a custom ROP node within the /out context, and my goal is to retrieve data from upstream nodes in the graph. The purpose is to "split up" the output process and publish individual portions to a database. For this, I need access to the upstream nodes in the node graph.

Initially, I considered using the SOHO system, but it seems SOHO is more oriented towards rendering workflows. From my understanding, it provides access to the render scene and the node that triggers the SOHO script, but not the broader Houdini Scene Graph, which makes sense given its rendering focus.

I also noticed that the Deadline node leverages a callback script, but this method didn’t work as expected when I tried to integrate it into a chain of nodes. For instance, when I added a null node at the end of the chain, the callback didn’t behave as I anticipated.

Here are my main questions:

- Is there a way to execute a callback script upon issuing a Render command in Houdini, with access to upstream node information?
- Alternatively, would it be feasible to adapt SOHO for this type of operation, even though I’m not dealing with a rendering context?

Since I don’t plan on generating any output, it seems like a pre-render script wouldn’t be the ideal solution. Any advice, suggestions, or insights on how to approach this would be greatly appreciated!

Thanks in advance for your time and assistance!

Usd Asset Resolver using boost and usd instead of hboost 2024年2月22日9:10

Im opening this topic because i would like to learn more about the inner workings off usd and hboost from inside houini.

some context what im doing and why im asking:
hi my name is Lyon im a developer for Ynput and im currently working on a Usd resolver that is gonna ship with AYON in the future.

im currently in the progress off improving the build process off the resolver, hou20 with gcc11 is working very well on both win and Linux.

but i would like to get the build system to a point that allows building the resolver for many many more software packages
(i know that this forum is Houdini only im just mentioning it in order to give the correct context)



and with that said here is what i have in mind and where i could use some sweet sweet info's or even documentation:

so in the end off the day my perfect little world would allow me to build one resolver against every usd library version that has important / breaking changes and then ship just those build files. plus the source code for people that are interested.

im am aware that this will probably not happen as version off library's external to usd might need to be on the same version as the one in a software package.

with that said i saw that there was a notion on i believe a houdini20 version that building against boost instead off hboost would be possible again.

but at the same time there are 2 things that make be question how possible it might be in the end.
1. first there is the hdk documentation that says that building usd plugins must be done against Houdini internal usd
(link2*)

2. second there is a mention in luca sellers CMakeLists file that Houdini on Linux switched from not using GLIBCXX_USE_CXX11_ABI
to doing so. (link1*)
and i would be very interested in understanding how this influences the build processes off a usd resolver.


so and now with all off this out off the way the end result for me is that building against hou20 works very well but hou19 is giving me some problems right now and building against non Houdini usd library is something i would like to get working.

so if some one has some info's about that stuff, or some places where i could look that would be great.
and now there is only one thing left for me; thanks for reading.


link1
https://github.com/LucaScheller/VFX-UsdAssetResolver/blob/36a6926ef73e399a36c279eca01d387eb0ec5d5b/CMakeLists.txt#L136 [github.com]

link2
https://www.sidefx.com/docs/hdk/_h_d_k__u_s_d.html#HDK_USD_Plugins [www.sidefx.com]