AccessViolationException CRhinoUnroll_CreateFlatBreps (BUG?)

Rhino Developer compute.rhino3d
,
1

hello hello back with a problem.

Problem:
I’m encountering a System.AccessViolationException when running my custom plugin via Rhino.Compute. The same plugin runs without any issues inside Rhino Desktop (Rhino 8).

Error Output:

G  [15:33:45 DBG] Setting input values  
CG  [15:33:45 DBG] Solving definition...  
Fatal error. System.AccessViolationException: Attempted to read or write protected memory. This is often an indication that other memory is corrupt.  
Repeat 2 times:  
--------------------------------  
   at UnsafeNativeMethods.CRhinoUnroll_CreateFlatBreps(IntPtr, Double, Int32 ByRef, Int32 ByRef, Int32 ByRef, Int32 ByRef)  
--------------------------------  
   at Rhino.Geometry.Unroller.PerformUnroll(Rhino.Geometry.Curve[] ByRef, Rhino.Geometry.Point3d[] ByRef, Rhino.Geometry.TextDot[] ByRef)  
   at Parapet.Lib.Crown.Crown.UnrollBrepAndProcess(...)  
   at Parapet.Components.CrownGenerators.GH_CrownBase.SolveInstance(...)

Context:

  • Compute version: 8.0.0.0
  • Rhino version: 8.20.25157.13001
  • Plugin targets: .NET Framework 4.8 and .NET 7.0
  • Observed behavior:
    • Runs fine within Rhino 8 (desktop).
    • Crashes with AccessViolationException in Compute when calling Unroller.PerformUnroll(...).

What I’ve Tried:

  • Upgraded all RhinoCommon/NuGet packages to latest versions.
  • Tried forcing Rhino to use .NET 7.0 instead of 8.0.
  • Verified the input Breps and Curves are valid before passing them to Unroller.

Has anyone an idea why? Or is it a bug?

Thanks already in advance

2

I uninstalled Rhino 8.20xx and downgraded to 8.16xx and it works again. I didn’t change anything related to Rhino.Compute, so my suspicion is that the issue is caused by Rhino 8.20xx using .NET 8.0 as the default?

6

Have you tried telling Rhino.Compute to create a new headless document whenever it receives a new request. To use this feature, create a local environment variable called RHINO_COMPUTE_CREATE_HEADLESS_DOC. The value of this variable can be set to either true or false but you would want it to be set to True in this case. Then, each time a new request is received, a brand new headless document is instantiated with tolerances and units determined by the input object. I’m not 100% sure if this would fix this issue, but I think it might be worth a try.

7

Hi Andy

Yes thats what i did in the end and it all works.

Is there actually any downside setting this to true?

8

No. There isn’t really a downside to setting this value to true. Historically, Rhino.Compute started without any document and then we were able to add this feature at a later date, so I think it was left off by default since that was the original pattern.