CRASH w/ user dictionaries

crash
bug

(Andrew Heumann) #1

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?


(Menno Deij - van Rijswijk) #2

It seems related to this
http://discourse.mcneel.com/t/std---non-rtti-object-unhandled-exception-followed-by-crash/10797

I suspected, and still do, a timing/threading issue during .NET garbage collection.


#3

Hi Andrew,
i’m happy you started using the userdictionary also. I’m having this problem for years with some of my Plugins, due to extensive use of the UD. I’ve reported this problem several times to McNeel. They either constantly ignored the case, or didn’t get any solution to this yet.
It is still not working and i just run into this problem again on some project at the office. In your case i think you didn’t do anything wrong. It happens also in the very simple example attached (move the slider for some time). I can recommend using the UserStrings, which do not cause the crashes. I had to recode parts of my plugins as well. UserDictionary would be still nice to get to work without crashes, because it allows to store Geometry.

Cheers,
FF

UserDictionary_CrashTest.gh (5.1 KB)


(Menno Deij - van Rijswijk) #4

Just for completeness in this topic, update to SR13 and your problem will most likely be solved.

https://discourse.mcneel.com/t/userdictionary-crashes-in-gh-solved-in-sr13/44228/6?source_topic_id=25731