I am hunting down what is causing the display of this error message, but there really is no clue as to what causes this, except that, unless I check “Do not show this message again”, it keeps popping up.
Also, after discarding the message, the definition essentially freezes.
This could be related to the “fix” for the recent crashes, because that definition didn’t freeze like that ; it just worked until it crashed Rhino.
If this is caused by something bad in my definition, my only investigation method is to :
-Lock the canvas
-Open the definition
-Disable a part of my definition
-Unlock
-See if the error message pops up
-If it does, start again and disable more components until the origin of the problem can be singled out
This method has worked for me in the past, but I really wish the “Breakpoint call stack” (whatever that is) gave me simple information about what causes the issue.
My post is not about solving a particular issue, but rather to point out a weakness in the way errors are reported by GH.
The definition in question is a behemoth, and certainly not something I can share.
If the error message is to be believed (An object expired during a solution) then something is triggering updates inside updates. There’s two ways in which this typically happens:
A component is listening to events or callbacks from processes other than Rhino or perhaps a web-based data exchange and triggering updates in Grasshopper without going through the proper channels, i.e. it doesn’t wait for any current solution to complete, it just waltzes in and starts making coffee while someone else is busy cooking a meal in the same kitchen. This is a threading issue.
A component is updating itself or other components from within a solution. This is a recursion issue.
You shouldn’t be able to do anything that would cause this, it requires code. So either a script component or a GHA component.
I agree the message is pretty summary and could do with some beefing up, but on the other hand the component which is expiring is not necessarily the one at fault. Still, more information is always better than less information.
The fact that the process gets stuck after you dismiss the message tells me that something is stuck in a loop causing one update after another. Again that requires custom code.
I’ve logged an issue under RH-46662 to display more data in the error, maybe that will help us figure out what’s going on.
Hi David, I suspect this is linked to an issue I have with a Human UI button which should only output “True” when pressed, but in fact remains “stuck” .
Visually, it looks like it is in the “not pressed” state though.
Here’s my post on this issue.
Actually the fact that there isn’t any information inside the stacktrace seems to be a clue in and of itself. The way I designed this error dialog is that it post-pones gathering information about what went wrong until after it’s definitely running on the UI thread. Which is probably too late and in the wrong context.
If I replicate the problem using the recursive approach, I get the following (with already improved messaging):
Illegal activity originating in threads is now handled better, although it is in the nature of threads that it can be really hard to figure out who set the ball rolling…
I am beyond flabbergastedness…
How can you do stuff so fast ?
I’m not sure if it will help ME find the exact origin of the problem, but maybe a smart individual…
I’m encountering case 1 (using web to trigger updates). I’m new to writing GH components, can you point me to a resource that explains how to trigger that update in the proper way? Thanks for all your work.
I got rid of the Fabtool bakes because I thought they were causing the problem, but now that I have done all these tests, I have the feeling that Baking in general has become a great source of headaches.
I think the possibility of this error message originating from either of these components is highly unlikely. Are you using any unusual scripts or metahopper components - specifically any related to listening to changes in the rhino model?
the most obvious component listening to changes in Rhino is the “Dynamic Geometry Pipeline” which is at the heart of this definition, but it used to work fine.
Other than that, I don’t think I have Metahopper components, apart maybe for a “Wrap” and “Unwrap”.
Notice that I filter the pipeline for blocks, and none of the objects generated by the Bakes are blocks, so I can’t see why this would pose a problem.
I also noticed the “Listen to object attributes” option, so I set out to un-check it, and it hard-crashed Rhino.
OK, I just sent it in my message about the sticky buttons.
The two problems can be replicated with the file combo I sent you.
Thanks for looking into this.
I opened your definition once without elefront installed, and got no error messages, no stuck button, and no slow text component. With elefront installed, the error messages popped up and the button remained stuck. I went through the definition and disabled all elefront components, and the errors went away. This doesn’t rule out the issue being something else, but your definition is far too complex for me to sort it out beyond that.
I’ll try the same.
I guess that this is the right time to ask if you could add the ability to bake Text dots.
For the extraction of attributes from blocks, I’m sure I can find a more Humane way of doing it
Here’s a def w/ a script for baking dots w/ attributes, and a means of getting attributes from block instances by name w/ human (I think this is what you were doing with elefront but not 100% clear.)
