I have an average scale script that populates things based on referenced geometry.
Now in some cases when I move the referenced geometry the Grasshopper crashes, but the issue is I do not know which component caused the crash. I waited quite long in an attempt to see if it finishes computing so I can track the faulty node with Metahopper.
So, the question is, can I somehow see which node was taking so long to compute after Grasshopper crashes? Or I should go through tedious forensics?
Yeah, it would be great if there was some low level log for Grasshopper, at least to enable optionally so we have a chance of seeing what causes a repeatable crash.
@DavidRutten Does something like that exist and if not is it even feasible?
Logging was removed from Grasshopper 1.0 once the logs stopped giving me useful information for fixing bugs. It takes resources to log things, especially if the recorded data is dense.
Now, if a crash happens and you see a crash reporting window, please send it in. If it crashes without a reporting window, then weâd love to know how to reproduce that.
It doesnât crash per se. It just freezes whereas in theory it shouldnât. I am running a low amount of computation on a strong machine. And most of the time the whole script runs in a second. I assume if I push all possible autosave options in both Rhino and GH when it crashes it should be possible to recover the faulty state of things. Any better way youâd suggest?
Open GH without any file, right-click to âLock Solverâ, then open your file. Disable key components to prevent the crash, unlock solver and methodically enable components until it crashes.
âCrashâ typically means the program stops running because it tried to do something like execute an invalid instruction or reference a non-existent memory location. My experience with GH is that it (it = either GH and/or Rhino) doesnât stop running, but instead goes into some sort of âinfinite loopâ such as calculating a distance that is half as long as the previous calculation.
The way to tell whatâs happening is to open Task Manager and look at the CPU usage for Rhino. The CPU usage will be 0 if it (GH and/or Rhino) has crashed, but I have never seen this. For me it has always been some fairly low, continuous (around 10%) usage - a CPU loop.
The fairly low number results from most of the functional things that happen in GH/Rhino being single threaded, meaning they are computed by using only one of the CPU cores in PCâs main processor. For example, a PC with a 10-core processor would show at most 10% CU usage if a single-threaded operation was in an instruction loop.
Sometimes a looping program will end up crashing because it sucks up all available RAM. Iâve seen this happen by watching Task Managerâs Memory Usage for Rhino slowly reach 100%. When this happens Rhino (and GH) crash and Rhino creates and memory dump which is intended to be sent to McNeel. In this situation the whole computer crashes and has to be rebooted.
In the case of a CPU loop the only way I know of to determine what is looping is to use the Process Monitor utility, but this is hard to do because the utility produces voluminous data in real time and it takes a large amount of screen area. Iâve never actually tried to use it in the event of a CPU loop.
Josephâs method of slowly enabling GH components 1 by 1 is probably he best way to identify a looping function. My GH scripts are fairly simple so my approach is to disable GH components and then enable them one at a time until the loop happens. Then I use Task Manager to abort Rhino, restart it, and the top file in the GH Autosave list gets me back to the point just before the loop started.