I am getting an error when trying to run a husk procedural.
The procedural works locally in MPlay test and also resolves correctly in Solaris with the preview node.
When I send this to the farm using husk, some of our machines seem to render it just fine and some complain with this error message
Invalid checksum for procedural invoking script: {OUR_PIPE_PATH}/houdini/python3.9libs/husd/runprocedurals.py
the error is consistent , so any machine that can render it always renders fine and the ones that don't consistently do not. Any ideas what could cause this? I can see that this check in in the husk executable but obviously it's binary so I can't debug
A successful machine logs this:
{OUR_PIPE_PATH}/houdini/python3.9libs/husd/runprocedurals.py --mode prerender --validategeo
We are on Houdini_19.5.569 on windows,
Thank you,
Roy Malhi
Husk procedural error
1396 7 2- roymalhi
- Member
- 4 posts
- Joined: July 2014
- Offline
- goldleaf
- Staff
- 4168 posts
- Joined: Sept. 2007
- Offline
- robp_sidefx
- Staff
- 451 posts
- Joined: June 2020
- Offline
Hi Roy, further to Chris' request for logging a bug, there's something you can investigate on your side: we made a small change to
But yes, let's carry the discussion on further via our bug tracker.
runprocedurals.py
in 19.5.557 which would have resulted in new checksums. I wonder whether it's possible that husk.exe
and runprocedurals.py
on your problematic machines are actually coming from different Houdini versions (one from 19.5.569 as you mentioned, and one from a version pre-19.5.557).But yes, let's carry the discussion on further via our bug tracker.
Edited by robp_sidefx - May 19, 2023 05:22:55
- roymalhi
- Member
- 4 posts
- Joined: July 2014
- Offline
Thank you, I did log a bug report, but I'm also trying to understand if something is going on with our system. we've never used 19.5.557. As I understand it husk sees runprocedurals.py for some reason as different to what husk expects and the hash verification fails?
- roymalhi
- Member
- 4 posts
- Joined: July 2014
- Offline
- robp_sidefx
- Staff
- 451 posts
- Joined: June 2020
- Offline
roymalhi
We discovered that is was the line endings on windows crlf vs lf that husk is expecting when testing the hash
Sorry, the bug report hasn't quite reached me yet, so I'll continue on the forum for the time being.
Can you elaborate on this? Was the installed
runprocedurals.py
modified (including resaving the file in a way that changed line-endings) after installation? I've been unable to reproduce the issue myself, using various combinations of Windows & Linux boxes, so I'm very curious if you think there's an issue here that could affect others, or if it was something specific to your studio.
- roymalhi
- Member
- 4 posts
- Joined: July 2014
- Offline
The issue was caused by the default behavior of git on windows , it has autocrlf on by default for text files. We package our dcc apps in tagged repos and whilst the runprocedurals.py was correct in the repository, upon localization of the package, on checkout , git converted the line endings form lf to crlf and the checksum thus failed because the hash returned would have been different with crlf line endings.
This is an edge case , but if you want to make sure it doesn’t happen again or at lease be more specific about the error message when the checksum fails, you already check if it’s windows I believe as part of the hash test , so check for unexpected line endings and print it as part of the error , or better yet, allow crlf resolved hash on windows as well as lf . But it’s no longer an issue for us, once I realized what it was , I just changed the git config and problem solved . Thank you for your attention to this issue
This is an edge case , but if you want to make sure it doesn’t happen again or at lease be more specific about the error message when the checksum fails, you already check if it’s windows I believe as part of the hash test , so check for unexpected line endings and print it as part of the error , or better yet, allow crlf resolved hash on windows as well as lf . But it’s no longer an issue for us, once I realized what it was , I just changed the git config and problem solved . Thank you for your attention to this issue
- robp_sidefx
- Staff
- 451 posts
- Joined: June 2020
- Offline
-
- Quick Links