So this may be a rhinocommon bug, and it might be me doing something I’m not supposed to with geometry UserDictionaries. I’ve got a GH Definition + Rhino doc set up that grabs the contents of a block on a layer, embeds the layer name as a value in the geometry’s user data (for downstream retrieval). I make all that geometry a group, duplicate the group several times, ungroup it, and then use the layer info embedded in the object to retrieve the color, linetype, etc from the layer for display purposes.
This all works great, but if I rapidly change the “Count” slider - changing the number of copies - I will pretty consistently get a hard crash, killing GH and Rhino. The dot net crash dump report includes the following:
System::AppDomain::CurrentDomain->UnhandledException event occured
SENDER: Name:DefaultDomain
There are no context policies.
EXCEPTION: System.Runtime.InteropServices.SEHException
MESSAGE: External component has thrown an exception.
SOURCE: RhinoCommon
CALL STACK
at UnsafeNativeMethods.CRhCmnUserData_Delete(IntPtr pUserData, Boolean only_if_no_parent)
at Rhino.DocObjects.Custom.UserData.Dispose(Boolean disposing)
at Rhino.DocObjects.Custom.UserData.Finalize()
My guess is this has something to do with the “duplication” step - the Grasshopper move operation is creating a copy in some funny way that doesn’t play nice with the userdictionary - but that’s just speculation on my part. I can find ways to get around this by not relying on the user dictionary, but I’d love to get to the bottom of this, especially if it’s caused by me doing something I shouldn’t with the userdictionary.
The attached file contains the rhino, GH, and necessary plugins. You should be able to reproduce the issue by rapidly moving the “Count” slider up and down.
CrashExample.zip (244.8 KB)
Any thoughts?