Hi there!
Was wondering if anyone is having a similar issue. Im using Nuke 12.1v2 and when launching nuke from both the desktop and web browser Nuke locks up when trying to use the Shotgun File open window. This is on a windows 10 system. The only work around that has worked for me so far is by launching nuke directly from the shotgun repository in command prompt.
-Nick
Try disabling debug logging (right-click menu in sg-desktop) before launching nuke. That usually gets things stable for me.
Hey Patrick. Thanks for the response. Sadly that has not worked. One thing worth noting as well is that this issue only persists with Nuke 12. Launching Nuke 11 projects is no issue
This is happening to me as well on Linux Centos 7.
The first time I open the shotgun open window works fine, but the second time I open it, it just freezes with no error, and I need to force quit nuke.
Any suggestions are appreciated!
Just a sanity check, did you guys update to teh latest core and tk-nuke engine and apps?
Yes ! : )
Latest of everything.
One more thing to check - I had noticed earlier that with the Error console and/or the Script editor windows open, it crashes. Probably some problem with thread safety.
Try closing these windows and starting Nuke again, if you had them open.
Hi all –
We’ve seen what seems to be the same crash in one other client, and we have a hunch based on their logs that it might be related to user sandboxing.
@Nrickolai, would you be able to test it on a stock tk-config-default2, which doesn’t support sandboxing, and see if you still get the crash? This would help us narrow down what’s causing it.
thanks!
Hey Tannaz,
Can you describe your hunch in more detail? How is stock tk-config-default2 not supporting user sandboxing? Is it only if you use user sandboxed folders in your schema that you think is a problem? or by sandboxing are you referring to pipeline config sandboxing?
Cheers
p.
Hello all!
As the TD that dove in and finally fixed this, I want to reply with what we found. Patrick, you saved my life! You were absolutely right - disabling debug logging was the issue (previously, the client had simply disabled it in the SG Desktop app, however in a few of our env configs the flag was forcibly set to True). Without your suggestion, I can’t tell you at what step my debugging process would’ve been to disable debugging!
Is it simply the case that, since Nuke 11/12, printing into the script editor is no longer safe? That seems to be the lesson I’m taking.
Hi all –
Thanks for your patience on this one.
First off, @Patrick, that hunch was unfounded. Nothing to see here. 
Secondly, as I’ve mentioned, we’ve seen this in a few cases now, and at first we thought it was limited to the Breakdown app, but as @tk421storm suggests, it does seem to crop up whenever there’s printing to the Python console going on.
I brought this in front of an engineer this morning, and he has a good hunch: we are using Python’s print function to display any logging output in the Python console. In 3ds Max, we had an issue where we had to forward print calls to the main thread, because the Python interpreter would blow up when we used a background thread. So, the suspicion is that there is a regression in Nuke 12 (and maybe 11?) that behaves the same way?
We had an internal ticket for this bug, but we’ve bumped up its priority substantially. I’ve linked this post to the internal ticket, so we’ll be notified when it’s resolved, and will notify you all in turn.
It’s indeed a challenge when the tools you use to debug the crash are what’s causing the crash in the first place. Thanks to everyone who chimed in with ideas of how to get around it! We’ll keep you posted.
That’s fantastic to hear Tannaz! Thanks so much.
I bet that’s true, printing is no longer safe from other threads starting in 11. I did notice that the same apps with similar configs (multi-publish2, workfiles2) would run flawlessly in 3dsmax but hang up in Nuke, so I bet something similiar might have to happen here.
Great to hear!
I’m pretty sure it goes back way before Nuke 11, but I could be mistaken.
We have actually just done some tests and while I’m not completely sure yet it seems that performance in Nuke 11.3 (and Nuke 12) is different when playing back frames with tk-nuke and apps loaded and without.
Also I notice the tk-nuke-writenode prints out a lot of knobchanged callbacks to the script editor.
This may have to do with this issue.
Hi All!
We just released out a v0.12.8 version of tk-nuke that we hope will fix the locking up of Nuke when debug is enabled. You’ll need to update your config to use the newer version.
Let us know how you get on!
Cheers
Thanks Phil! Looks like a good solution to the debug issue. I’m excited to see if that fixes it.