We started testing the beta release of Houdini 20.0.485
I almost accidentally found a way to make the tk-houdini engine work in Houdini 20. If anyone else is looking to test this :
With tk-houdini v1.8.6, look into the folder structure of the engine. You’ll find two directories called “python3.9libs” in two separate locations. Duplicate each of those with their content, and rename them “python3.10libs”
In our pipe, with these changes, the SG menu comes up in Houdini. Without these changes, there’s no SG menu at all. I didn’t test this thoroughly but I hope it helps someone.
To the SG team : can you look into this when Houdini 20 is officially released ? Thanks in advance
Could you please add support for Houdini 20.5 to the tk-houdini engine ?
I did the similar fix as previously (see above) and it seems to work. Albeit for some reason Houdini 20.5.278 crashes when launching it with a compatible HtoA 6.3.3.0 on Windows. But before investigating that bug I’d like to request an official tk-houdini engine
Regards
BTW : I filed a support case requesting this update to tk-houdini
+1 for 20.5
We copied over the python3.11 directory, but it crashes on most machines (with traceback pointing to python execution). So far it seems to work on only one machine on Windows.
@mmoshev do you use HtoA ? In my case I only have crashes when trying to start Houdini 20.5 with HtoA. Starting from SG without HtoA is working (only tested on Windows)
My traceback also points to some python dlls
Regards
BTW After contacting the Autodesk support, they gave me this internal ticket reference for the update of the houdini engine to support 20.5: SG-35936 (notice the SG in there… )
We do not. Actually we have not installed any plugins for 20.5 yet (and lots of them are not compatible anyway).
I suspect you stack trace might be similar to ours.
Hey. I had the same issue as above with the same crash log. I tracked the issue down to tank.platform.engine line 1563: if not QtGui.QApplication.instance():. It seems to be getting an instance of the QApplication that causes the crash.
After a bunch of messing around it seems that if you’ve accessed the QApplication before the engine starts, it doesn’t crash.
This is horrendous hack but I’ve added the following to plugin_bootstrap.py at line 85 just before the engine starts:
from PySide2 import QtWidgets
QtWidgets.QApplication.instance()
I don’t know exactly what is going on but, for me, this no longer crashes. It’ll do until ShotGrid release official support.
ETA: This is even weirder. To make things a little neater I tried moving the above code to the start of plugin_bootstrap.py. That crashes instantly. Something is going on around there that makes Houdini particularly fragile when accessing the QApplication.
[DEBUG tk-houdini] Engine init: Instantiating <Sgtk Engine 0x11d98d7d0: tk-houdini, env: project>
[DEBUG tk-houdini] Engine init: Current Context: Project 24-XXX-LUCIDLINK
[DEBUG tk-houdini] <Sgtk Engine 0x11d98d7d0: tk-houdini, env: project>: Initializing...
[DEBUG qt_importer] Requesting Qt4-like interface
[DEBUG qt_importer] Unable to import module 'QtWebKit': No module named 'PySide2.QtWebKitWidgets'
[DEBUG qt_importer] Unable to import module 'QtWebEngineWidgets': module 'PySide2.QtWebEngineWidgets' has no attribute 'QtWebEngineWidgets'
[DEBUG qt_importer] Imported PySide2 as PySide.
[DEBUG qt_importer] Requesting Qt5-like interface
[DEBUG qt_importer] Imported PySide2.
[DEBUG qt_importer] Requesting Qt6-like interface
[DEBUG qt_importer] Qt6 interface not implemented for Qt5
[DEBUG qt_importer] No Qt matching that interface was found.
18304: Fatal error: Segmentation fault
In this debugging message it appears that their bootstrapping code fails to import the QtWeb* modules while attempting to load and rename the PySide2 modules. I don’t have a fix for this at the moment either, just wanted to add the debugging info to this thread for visibility. I think initially the way they built their Qt compatibility up over time made sense. But after years of patching for new releases of Python and Qt / PySide / PySide2 and now PySide6, this entire process is a whirlwind of pain. The best solution would be to use qt.py which is a well supported and more complete compatibility module. It would be painful, but it would probably bring a semblance of sanity to their bootstrapping process and allow them to spend less time focusing on patches for Qt each year.
Here is what ended up working for me. This probably only works with Python 3.7+ but, we are well beyond Python2 at this point aren’t we?!?! I couldn’t tell you why the old __import__ function fails to work in H20.5.
Thanks donat, I just tried the branch, but still crashes
This time on Windows, I get the console briefly, it says something about “can’t open resource” or similar (too fast to read it), and closes.
So far the QApplication instantiation sounds most plausible.
Just chiming in here. I have the same problem as @mmoshev.
For Linux I tried the production build (278) and the latest daily build of Houdini 20.5 (Python 3.11). Other plugins like HtoA seemed to load fine but when I launched through the toolkit environment then it would crash.
I can confirm the Houdini 20.5 Python 3.10 version doesn’t crash with the toolkit environment and that’s the same code, so it’s something to do with Python 3.11.
Seems to be crashing for me on a simple os.path.join call. Pretty weird. When I remove the code where it crashes, it just fails later on a different os.path.join call.
@mmoshev Can you set this environment variable export PYTHONFAULTHANDLER=1 and see where it crashes for you?
Fatal Python error: Segmentation fault
Current thread 0x00007f599efa7380 (most recent call first):
File "", line 83 in join
File ".../shotgun/install/core/python/tank/platform/engine.py", line 2936 in __get_platform_resource_path
File ".../shotgun/install/core/python/tank/platform/engine.py", line 1578 in _ensure_core_fonts_loaded
File ".../shotgun/install/core/python/tank/platform/engine.py", line 199 in __init__
File ".../shotgun/install/core/python/tank/platform/engine.py", line 3202 in _start_engine
File ".../shotgun/install/core/python/tank/platform/engine.py", line 3042 in start_engine
File ".../shotgun/install/app_store/tk-houdini/v1.8.8/python/tk_houdini/bootstrap.py", line 97 in bootstrap_classic
File ".../shotgun/install/app_store/tk-houdini/v1.8.8/classic_startup/python3.11libs/pythonrc.py", line 47 in classic_startup
File ".../shotgun/install/app_store/tk-houdini/v1.8.8/classic_startup/python3.11libs/pythonrc.py", line 65 in
The error doesn’t look quite the same here.
Seemingly it happens on loading shelf files (or rather destroy_tools, which calls hou.shelves.shelves().get(self._name, None)). pythonfailure.log (6.9 KB)
Hello @donat ,
I was testing in a Linux machine and found the same crash issue, most of the time crashes exist in version 20.5.278 but crashes don’t exist in version 20.5.332. I also tested on Windows getting the same result.
So I recommend using the version 20.5.332 with this new PR support for 20.5.