Frequent Rhino 6 Crashes using Grasshopper

Thank you for your help!

Hi, we are also experiencing frequent crashes in V6 with definitions that used to run smooth.
We do not have Vray on our machines.
The only plugins used by these definitions are Human, Human UI and Metahopper, but I suspect the problem is elsewhere because these plugins are in other GH definitions which are not prone to crashing.

1 Like

@osuire do you have some parallel components running in the definition?

Please run the _GetIssueState command with the RH-46468 issue identifier. If the command line tells you that “git commit in this build = True”, then please test whether the crash frequency is down.

@osuire do you have some parallel components 3 running in the definition?

Yes, lots of them.
They are one of the GH improvements that make the update to V6 worthwhile.

Is there a reason behind the question? I don’t know of any parallel components that are crashing.

Yes. I’ve seen a few components crash in early releases of V6. Multi-threading is also one of the major changes in V6 Grasshopper.

Hi @osuire,

do you think you could you try disabling “Multi-threaded GH components” for a test? It would help ruling out this one as a possible source of problems.

But Giulio, things have been working fine since the last release (6.6.18156.11421, 06/05/2018).
How could I tell if disabling “Multi-threaded GH components” had any effect ?

If things are working fine since the last release, I doubt the multithreading had anything to do with this. The more likely cause would have been components that create Text3d instances. We just fixed a major bug in the latest release that could have manifested itself when Text3d instances were being used.

I’m still crashing, crashing, crashing,…

Hello I have gotten 1 or 2 reports of grasshopper crashing in my office with Rhino 6. I was able to replicate a crash on my end. Windows Event Viewer shows this message:

Application: Rhino.exe Framework Version: v4.0.30319 Description: The process was terminated due to an unhandled exception. Exception Info: System.AccessViolationException at UnsafeNativeMethods.ON_Intersect_CurveBrep(IntPtr, IntPtr, Double, IntPtr, IntPtr) at Rhino.Geometry.Intersect.Intersection.CurveBrep(Rhino.Geometry.Curve, Rhino.Geometry.Brep, Double, Rhino.Geometry.Curve[] ByRef, Rhino.Geometry.Point3d[] ByRef) at SurfaceComponents.SolidComponents.Component_BRepLineIntersect.Compute(Rhino.Geometry.Brep, Rhino.Geometry.Line) at SurfaceComponents.SolidComponents.Component_BRepLineIntersect+_Closure$__11-0._Lambda$__0() at System.Threading.Tasks.Task`1[[System.__Canon, mscorlib, Version=, Culture=neutral, PublicKeyToken=b77a5c561934e089]].InnerInvoke() at System.Threading.Tasks.Task.Execute() at System.Threading.ExecutionContext.RunInternal(System.Threading.ExecutionContext, System.Threading.ContextCallback, System.Object, Boolean) at System.Threading.ExecutionContext.Run(System.Threading.ExecutionContext, System.Threading.ContextCallback, System.Object, Boolean) at System.Threading.Tasks.Task.ExecuteWithThreadLocal(System.Threading.Tasks.Task ByRef) at System.Threading.Tasks.Task.ExecuteEntry(Boolean) at System.Threading.ThreadPoolWorkQueue.Dispatch()

I would love to see this definition if at all possible. Crashes like this are something we would like to fix as soon as possible,

I was able to get a crash by selecting multiple breps and single brep in the brep node in the lower left. It will either crash immediately or after a few attempts.

perspective (16 KB)
perspective drawing sample_V2_crash.3dm (189.4 KB)[quote=“stevebaer, post:35, topic:57162, full:true”]

I would love to see this definition if at all possible. Crashes like this are something we would like to fix as soon as possible,

1 Like

Thank you so much! We were able to reproduce this crash and are looking into it right now to try and fix the issue.

RH-46966 is fixed in the latest Service Release.

looks like this error is resolved. thank you.

I’ve had more than 5 crashes in the last hour. Rhino does create a Crash Dump, but it’s empty. Grasshopper creates a Crash Dump and asks me to reload once I open Grasshopper again. It seems as if Rhino crashes after manipulating sliders. It’s super annoying having to save my file manually before doing something in GH all the time. The definition has worked well in Rhino 5. I had to replace a few old components. As you can see in the screenshot, I’m baking objects to layers with Elefront.

What do you mean by an empty crashdump? The dump is a copy of part of the memory used by Rhino during the crash, which may help us figure out where the crash was triggered from. It is this memory extract that is uploaded to our servers when you send in the error report:

You can choose whether or not to include the 3dm file, but there’s currently no way for users to include the gh file. This is why it’s a good idea to include your contact details, so we can ask you for any additional files if we’ve determined the crash happens in Grasshopper.

My PC is not connected to the internet all the time hence this is usually an additional effort for me to send the report.

Empty crash dump: Rhino created this file called RhinoCrashDump on my desktop. There is nothing in it. I’ve had other situations that led to crashes and the file contained what was in the document I was working on but this time nothing in it…

Not 100% sure but I think I didn’t even have the option to send the report on these crashes today. Anyway, next time it happens I’ll send the report.