Husk procedural error

   1396   7   2
User Avatar
Member
4 posts
Joined: July 2014
Offline
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
User Avatar
Staff
4168 posts
Joined: Sept. 2007
Offline
Hi Roy. This sounds gnarly; I wonder if it's a network situation. Can you please log a bug so we can track this issue? It'd also make it easier to share sensitive information back and forth (as opposed to the public forum)

Thanks!
I'm o.d.d.
User Avatar
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 runprocedurals.pyin 19.5.557 which would have resulted in new checksums. I wonder whether it's possible that husk.exeand runprocedurals.pyon 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
User Avatar
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?
User Avatar
Member
4 posts
Joined: July 2014
Offline
We discovered that is was the line endings on windows crlf vs lf that husk is expecting when testing the hash
User Avatar
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.pymodified (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.
User Avatar
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
User Avatar
Staff
451 posts
Joined: June 2020
Offline
Thanks Roy, I really appreciate the detailed explanation. As you say, it's an edge case, but it's good for us to have it on the radar in case it affects other customers in future.
  • Quick Links