Debugging my plugin's crash while thread is in Rhino

Rhino Developer
, , ,
1

Hi all,
I’ve looked around for this in the forum, but haven’t found anything sufficiently current, so apologies if this has been answered before.

I am having a crash issue with my plugin, but it is happening after the thread has left my code, but before control has been given back to the user, and while the thread is in Rhino (I think… it could also be ETO). I’m sure it is something I did… but I can’t tell what I did wrong with the crash happening at a point where Visual Studio’s debugger won’t stop on exception for me.

Rhino used to drop a .dmp file on the desktop, but it doesn’t seem to be doing that anymore. (I haven’t watched for such a thing in a long time, because I haven’t had many issues like this in a very long time). Is there still a dmp file I can find? If not, is there something you can suggest for me to figure out what I’m doing that is torturing Rhino?

Arthur

2

Perhaps you can share your plug-in RHP and PDB file with us so we can have a quick look. If you don’t want to share it here publicly you can either send me a direct message, or use Rhino - Upload to Support to upload a zip file with all necessary files. Please add some instructions how to replicate the crash so we can reproduce and see about the crash and then help you get past it or give pointers on how to go on about debugging this type of situation.

3

Ok. Noted…
This time, I guessed at the problem a few times, and one of those guesses turned out to be correct. It was (I think) something to do with the wrong thread trying to update the UI. Re-writing some of the methods to operate as async awaitable methods and then using them as such seems to have fixed not only issues with the crash, but also some difficulties with progress feedback to the UI.

Thanks for the reply, though. I’ll remember that this is an option if I still can’t find the dmp file, and I’m running into something similar in the future…

Arthur

4

Remember that when you want to update GUI elements from a thread you’ll have to invoke the updates on the UI thread. You can do that by using Rhino.RhinoApp.InvokeOnUiThread

5

Thanks. I was looking for that… Does that work with ETO also?

6

Yes, that should work with Eto as well. I use it in a few places in RhinoCycles as well ( Code search results · GitHub )

7

Thanks. I also discovered ‘Just my code.’, which in VS2022, disabling it gives me all the exceptions thrown in Rhino.

Oh my goodness… going to avoid doing that when I can…

8

I don‘t know if it helps, but I tend to create lots of sanity checks and I spoil my system with tons of log messages. In comparison to guards, sanity checks assert that you (the developer) have made correct assumptions. Its not so much about validating input. See Trace.Assert or Debug.Assert.

Proper logging has the advantage that users can give you log files. You decorate those to yield the current thread and component, if you expect a thread related issue.

Other than that, the VS Profiler offers some amazing ways in investigating issues with concurrency, although its quite unintuitive.

9

Thanks. That sounds like it might have been helpful before, when I did use a straightforward multi threaded system. I just rewrote it for valuetask parallelism, which, to my surprise, gives me much faster results with better cpu utilization. However, tasks are executed in the thread pool, and so are thread agnostic… And I guess much harder to debug. So it seems like I may need to continue developing those deductive skills instead.

So far I’ve managed, but sometimes tracking the issue down requires a few good nights sleep, and abstaining from coffee.

I would love to understand the profiler better, but it’s mostly greek to me.

Arthur