Custom Component Freezes at End of SolveInstance( )

[David_Saylor]

When debugging my custom component in VS 2019, Grasshopper and Rhino freeze at the end of the SolveInstance method. DA.SetData have output data correctly. The C# code compiles, but the component processing freezes as well as both Grasshopper and Rhino windows.

Once all tasks are detached in the debugger, after a few seconds the debugger offers the following exception.

When running the custom component independent of the debugger, the Grasshopper windows is slightly different.

The output ports display reasonable data, but there is an error flag displayed on the component. When clicking anywhere in the Grasshopper window, the spinning blue circle appears, and Grasshopper is unresponsive. Clicking in the Rhino window freezes it. My only recourse is to close Rhino from the Task Manager.

Thanks much for your reply.
Dave

[rawitscher-torres (Nicholas Rawitscher)]

Hi @David_Saylor

It seems like another thread is taking to long to execute another process. Can you post the part of the code where the issue is happening? I.e where you have the tasks?

[David_Saylor]

Hi, Nicholas:
Thank you for responding to my inquiry. I will again use pictures and explanations.
A bit of changes are noted from my last post. I set a second breakpoint at the very end of the SolveInstance(…) method.

Then I stepped ahead to the next statement with this result.

In the Grasshopper window, the output ports emit data as expected, but both the Grasshopper and Rhino windows freeze.

Last night, I only once got this Grasshopper breakpoint dialog.

As I haven’t the expertise, there is no threading or tasking in my code.

If this is not enough information to suggest a solution, I have attached the component.gha and source files.

VesselCam_Project _ Zip.zip (61.4 KB)

Thanks much for your reply.
Dave

[David_Saylor]

Hi, Nicholas:
I woke up this morning thinking about how to offer as much information as possible to you,
or anyone else that is kind enough to help. Therefore, I am sending along the Grasshopper file that I use to attempt VS debugging.

test VesselCAM2020_12.0.gh (184.5 KB)

In the file is the custom component as well as necessary input parameters with data internalized. The custom component is not enabled to allow for setting up VS debugger breakpoints before the component freezes both Rhino and Grasshopper. When using the debugger with single line code stepping, as shown yesterday, the component outputs data, and then freezes. Without the debugger, Grasshopper freezes before any data is emitted.
For context, the original code was developed in a Grasshopper C# Script component. One feature is a large datatree for visualizing the reasonableness of the code by previewing individual branches of the tree in Rhino. While using the C# Script component, by change input parameters, the code had generated in excess of 120,000 gcode blocks, written to a text panel in less than 2 minutes. Much faster than CAM software I used 20 years ago.

Yesterday, I tested if incremental saving to DropBox was the cause of the freeze, but after having removed DropBox’s file synchronization, and stopping incremental saving in Grasshopper, the component still freezes the application.

There is also another anomaly. When debugging yesterday, when starting debugging, I got an error message asking for the IronPython .pdb file. My workaround was to not load IronPython when Rhino boots up. I get an error dialog, that I acknowledge. I will attempt today to adjust settings in Visual Studio to remove this error.

Lacking a solution for the problem, I intend to rebuild the component code gradually, debugging along the way. This is allow moving the code to OOP style, versus, its current procedural coding. I don’t think this is the source of the problem, but I want to improve my meager coding skills in any case.

Thanks much for your reply,
Dave

[David_Saylor]

Hi, Nicholas and anyone else:
With a slight set of adjustments I am able to capture a bit more information about my freeze problem. First the adjustments:

1. Checked JIT Compiling , managed
2. Checked to Enable Just My Code
3. Checked to Enable source server support
4. Removed the ScriptParasite PlugIn. I could see it was attached to the debugger and is not relevant.

With these modifications, I no longer have the IronPython error.

So at the end of the SolveInstance (…) method, I am able to see the tasks running. When I get to the second breakpoint, the debugger stops, and both Grasshopper and Rhino freeze.

I hope this helps and saves diagnosis time
.
Thanks for your reply.
Dave

[David_Saylor]

Hi, Nicholas and all others following this post:

I think I found the problem. For context, I started development of my custom component in the C# script component, it compiled and worked fine. I was able to review large lists of points using preview from specific branches in a DataTree. When I moved the code from the C# script component IDE to Visual Studio 2019, the DataTree BranchCount was 2617, and the DataCount was 46,285. This morning, on a whim, while in VS, I gradually reduced the BranchCount which also reduced the DataCount. At a BranchCount of 1209 the component behaves fine, at a BranchCount of 1410, things get flaky, and Grasshopper freezes. The flaky symptoms are that I get an exception when loading Rhino, and after the debugger finishes the SolveInstance, moving the component is jerky.

For another test, I wanted to determine if the DataTree BranchCount was the lone culprit or did the DataCount add to instability. (My adjustment to the DataCount was to increase the ptOnCurve parameter affecting the hits the surface of a Brep.) At BranchCount of 1209, I was able to push the DataCount to > 940,000 without freezing. Furthermore, the text panel receiving the GCode blocks behaved as normal.

So a few days lost, but a lesson learned → Don’t overload a DataTree when working in VS Studio.

I am interested in your comments.

Thanks Much,
Dave