Rhino 6 / Grasshopper - Crashing with Honeybee

Hi Wim,

No, this is not a new system, but we are trying to use honey bee for the first time on this laptop and my colleagues’ laptops as well.

Using just Rhino to make models and any analysis using Ladybug works great, I experience this crash only with Honeybee.

Rhino does not create a popup, it just crashes without any notification. I have updated the driver via Rhino->Notifications, but still, I have the same issue.

Any thoughts?

Regards,
Prethvi.

Thanks,
Wim

Hi Prethvi -

I’m afraid not, no. This sounds like something that @chris or @mostapha might have ideas about.
Can you perhaps narrow down which component leads to a crash?
Also, I take it that the Ladybug components that you are using successfully also are from the 1.4.0 release?
-wim

Hi Wim,
Thanks for your input. Placing any Honeybee component leads to a crash.

  • Prethvi

I think I might know what is going on. @piac pointed out that our use of subprocess.PIPE could be unstable on some Windows versions for some reason:

Does this LB Cumulative Sky Matrix component also crash Rhino for you, @Prethvi ?

If that’s the case, then we can be pretty confident that this is the problem.

Hi @chris ,

Yes, the Rhino crashes when I tried loading LB Cumulative Sky Matrix.

Hi @chris ,

Also on the other hand I read @piac 's post and tried enabling the (subprocess_test.gh). The grasshopper script works but unfortunately, both Honeybee components and Cumulative Sky Matrix crashes along with Rhino.

In this case, I’m 99% confident that you’re experiencing this issue because of our use of subprocess.PIPE, then.

Can you do another test for me to see if the following file crashes Rhino for you when you enable the component?
subprocess_test_2.gh (3.2 KB)

If everything runs successfully, this is what your canvas should look like.

And, if everything has run successfully, then I’ll be able to fix this problem for you.

It’s also possible that the UUID module might be to blame as described here. Let’s see if the Grasshopper definition above works and, if so, I’ll confirm that the problem isn’t with UUID before I try to fix things.

Hi @chris ,

Please find the following screenshot, after enabling the component.

1 Like

Woohoo! This is looking very promising, then. We just need one final test to rule out the use of UUID as the culprit. Can you try running the following Grasshopper file and send a screenshot of the output?

uuid_test.gh (2.7 KB)

If all is working well, it should look something like this:

Assuming that you’re able to test it and it all works well, I can start implementing a fix across the plugin this weekend.

Hi @chris,
I tried loading the “uuid_test.gh”. Unfortunately, the Rhino and Grasshopper crashes just like before when I tried loading Honey bee components.

I hope this is the result you are expecting.

Did you see the solution fort the other discussion?

What’s the antivirus that you’re using? Can you try the dance component after deactivating the antivirus on your machine?

1 Like

I just wanted to second what Mostapha said. It seems this issue is different than I originally thought and you should try deactivating your antivirus, @Prethvi .

Hi @mostapha ,
We are using SentinelOne and our IT team said it is not possible to turn off this software. However based on the link you shared above, the IT Team added the path to rhino and rhino.exe to the exclusion list. Despite the effort, the Honeybee component is crashing in my system.

Any further ideas or workaround?

Hi @Prethvi ,

There’s only so much that we can do if your IT insists on using settings for the antivirus software that cripple the usability of your computer. It looks like @Paul1 said that they also modified some settings for error suppression:

Has your IT also tried this?

Hi @chris @mostapha ,
Finally, the IT team turned off Sentinel One. The Honey bee components are working again.

1 Like

Just as a note for future users that encounter this… the problem is related to method 1 uuid1() in uuid.py as it accesses the mac address.

Honeybee doesn’t actually require uuid1() method of generating guids, and it uses uuid4.

If you modify the uuid.py in the Rhino/plugins/ironpython/lib folder … comment out or delete the code related to scanning and accessing the address and just leave random inside the uuid1() def instead. The script wouldn’t need to attempt to call this.

and placing components should now be possible again
image

NOTE reinstalling Rhino will reinstall the uuid.py so it would be good if Honey bee made an adjustment to avoid importing all of uuid.py

1 Like

so basically changing the def uuid1() to only use a random generation for the node component, and removing the defs above related to getnode will form a valid guid in accordance with RFC4122, but not affect Honey bee anyway since it calls uuid4()

To check the change to the uuid.py file works, just place a ghpython component on the canvas like this

Hey @JulesBuh ,

Thanks for the insight here. You are correct that we only ever use uuid4 in Ladybug Tools but I’m afraid that editing the IronPython UUID is probably not an ideal solution for all users if they have some other plugin that is actually using this function.

Can you do one more test for us to see if this gets around your issue? If it does, then I’ll implement it across Ladybug Tools so that no one has to deal with this antivirus issue. The test is to type the following into a GHPython component while having the original uuid1 function installed:

from uuid import uuid4
print(uuid4())

If I am right, this should only import the uuid4 function from the module and we might be able to avoid importing uuid1. If this is successful on your machine, then I’ll replace all of our uuid import statements across Ladybug Tools with this.