_glf.pyd import freezes Python process
krzykli opened this issue · comments
First of all thanks a lot for setting up this repo! It's great!
I've managed to successfully build USD without a single error, but when I try to run usdview the Python process freezes.
I've tracked the issue down to an import of Glf module, after that Python becomes unresponsive.
Do you have any ideas what might be the cause of this?
Thanks!
What platform are you running on? I am seeing something similar on macOS 10.12.1. Both usdcat and usdview used to work but now after doing a new compiled build both processes freeze up after running them on the command line. Note, I compiled the prerequisites and did not use brew for this build.
Hi I've just confirmed that the deadlock occurs on Windows 10 as well.
Cool, when was the last time you have successfully ran usdview on Win/MacOs @vfxpro99 ? Was it before or after Bringing dev_win_ip up to date with dev ?
I haven't tried syncing before that yet. The general consensus at the moment seems to be that one of the dependencies might be causing the issue, as others who build the prerequisites several weeks ago, but are at the head revision of USD are functional at the moment.
Ok, the latest merge commit in the dev_win_ip branch is massive, so it looked a bit scary to me, but if you're saying other people got it working with the head revision then indeed it seems like a third party issue.
I reported this over in the USD issues: It's OpenImageIO deadlocking.
[External Code]
OpenImageIO.dll!00007ffbfee33660() Unknown
OpenImageIO.dll!00007ffbfee34e99() Unknown
OpenImageIO.dll!00007ffbfee34c88() Unknown
OpenImageIO.dll!00007ffbfee33e57() Unknown
OpenImageIO.dll!00007ffbfee33eb6() Unknown
OpenImageIO.dll!00007ffbfee34869() Unknown
OpenImageIO.dll!00007ffbfe7c2339() Unknown
[External Code]
OpenImageIO.dll!00007ffbfee74ba7() Unknown
OpenImageIO.dll!00007ffbfee74cf9() Unknown
[External Code]
python27.dll!000000001e125268() Unknown
Regressed and found a commit prior to the deadlock issue. Please pull and build OIIO again.
Can anybody (on either platform) catch this with a debug build of OpenImageIO and send me the stack traces that reveal exactly where in OIIO the threads are stuck?