Since updating to Rhino 7 SR8, I get systematic Rhino crashes (no warning, no message, no log) when opening a GH definition that uses Human UI heavily.
I disabled the solver, disabled the Human UI components and re-enabled the solver : no crashing.
I can’t be sure, but it “seems” like it’s related to Human UI.
Maybe some more ETO library incompatibility ?
EDIT : it is possible that this was due to a UI element that had two listners…
Hello there Osuire –
We are investigating a series of new crashes related to having complex HumanUI (our custom build) definitions and the latest few versions of Rhino 7. This is the first I’ve heard confirmation that this is happening in the Off-the-shelf version as well, so thank you for bringing this up.
This appears to happen when Rhino is attempting to open dialog windows and there is a shared memory access violation (that does not occur when HumanUI is not active). Here is an example of the debug info I can get during the crash, which is very limited:
And another:
These are repeatable and consistent, but thus far it has been very hard to debug. Some level of comment from the folks at McNeel (@stevebaer, @scottd) would be great. I am happy to get on a call to help diagnose further as necessary, as this is a significant setback for the HumanUI ecosystem at the moment and we are happy to work on finding a solution and sharing it with the community.
@osuire, can you provide any more details on what you are doing when the crash occurs?
Thanks,
Marc
Do you know if this just started in SR8? If you can get me a repeatable crash, I can run a search through our internal builds to find the code change that caused this.
Yes, great question – I actually ignored the SR8 part of this thread because we had problems surfacing in earlier versions. Because we are in a corporate application deployment, we have a slightly older version that just went into deployment (7.6). The problem appeared in 7.4 and I just recently installed 7.6 and so far the results have been promising. The color crash and the namedView crash appear to be better now.
I haven’t done extensive testing but this looks promising and I will advise our users to update and follow up as things develop. I have not tested in 7.7 or 7.8, so osuire’s issues may be something entirely new, and we will look out for that as well.
Thanks,
Marc
Ok; we have an internal tool that helps us perform a binary search of all of our internal builds to track down a known regression. If we have a problem that we can repeat and know that it worked in Rhino 7.0, then we typically can narrow in on a set of code changes that caused the problem with about a 3 hour window of development.
If you find a regression that we can repeat, let us know.
@osuire do you have a definition that exhibits this regression?
Hi folks,
I had been pestering for 2 years about blank dialogs, and finaly, Curtis Wensley found out that it was due to an incompatibility between the Xceed.Wpf.Toolkit.dll file provided with Human UI and the one used by Rhino.
This has been solved, but maybe the problem is coming back with a vengeance.
I could PM you my GH definition, but it uses a bunch of other plug-ins and I can hear you complaining already about that as Giulio did…
If you have something that can easily reproduce the crash, I’ll give it a try
I just updated to the latest version of the Human UI plugin (8.8), and the crash still occurs : no warning, no log.
