simon smith

I just ran into a problem with with cmake hanging when trying to create my Visual Studio solution files for Houdini 20.5.332. It turns out that if you happen to have a DSO compiled somewhere in your Houdini search paths that is incompatible binary-wise with the houdini that you are running cmake for, it will hang with no error or seeming reason. (In my case I had accidently compiled one using the v143 toolset rather than v142 and it was sat in my Documents\houdini20.5\dso folder).

It gets triggered from the houdini_get_default_install_dir function in the cmake process which executes hython.exe. If you go to the houdini command prompt (hcmd.exe) and run hython.exe, you will get a nice popup saying "couldn't load xxx incompatible compiler versions" (equally if you have run Houdini itself you will get the same error message) but if you run cmake directly without realising, it hangs - I assume the popup is somehow hidden but execution stalled waiting on it to be dismissed.

The solution is to delete/move the DSO dll's that are incompatible and then running cmake again, but it would be very, very useful to have houdini/hython handle this gracefully and not hang. Must have lost a couple of days on this as I thought it was due to a Visual Studio update, but it wasn't! Just wanted to post these here in case anyone else comes across it.

- Simon.

That's the one - rather than using a UT_Lock to manage access to the LOP of my operations, it instead needed the HOM_AutoLock so that
nobody else went near it whilst it was changed/cooked. It does make we worry that it must be quite an "expensive" lock to be taking mind!

Hi,

I have a thread that I wish to change some data that my custom LOP will then use to generate its USD content from, and I wanted to check if i'm doing this right as I can get exceptions thrown as well as a crash - so something is not right!

My LOP has some data structures (straight struct's basically) that I change on another thread.
1) I cache the "working lop" path via the main thread and the pNode->getFullPath() call
2) On the worker thread I use this path via OPgetDirector()->findNode(pathLop) to get the LOP instance
3) On this worker thread I then set the struct data for the LOP ready for its next cook.
4) Once set, I call forceRecook() on the LOP pointer in the thread to indicate it needs recooking.

From the bottom up, is the forceRecook() call the one to make to flag that the LOP needs recooking? I can get exceptions thrown of they the type "std::out_of_range at memory location" in the python calls that occur from within this call. These do not cause a crash, but it makes me suspicious that this might not the call to make from another thread. In case this is important, the forceRecook can be called more than once on the worker thread before the main thread picks up the change and calls cookMyLop at a later date.

Occasionally I get a null pointer crash on the main thread in libUI.dll!UI_Queue::processNextEvent() Line 2025 whereby UI_Queue::UI_ActualQueue::remove() returns a nullptr. This is terminal so i'm certainly breaking this one.


I tried adding UT_Lock's in both threads around changing the data (in case that was causing issues) but it made no difference to the crashes and exceptions occuring.

My code is based on the sample sphere lop in terms of how I generates the USD and i'm working under Windows (compiled with the v143 toolset) and H20.0.625.

If anyone can help/point me in the right direction for this it would be greatly appreciated!

- Simon