RhinoWIP instantly crashes

Hi,

I’m trying to open the latest (14th Jan 2020) WIP, but I cannot: either creating a new file from a template or clicking open and selecting an existing file results in a crash instantly.

I’m on 10.13.6 with this machine, RhinoWIP: Version 7 WIP (7.0.20014.12056, 2020-01-14)

Thanks!

I suspect there is a bug in macOS that will require you update to Mojave 10.14.6 to fix.
Is there some reason you haven’t updated?
We are seeing this same symptom on 10.14.2 and 10.14.3
!0.14.6 and 10.15.2 seem to be okay.

Hi John,

Thanks for the reply.

My reason:
Apple Intel 64-bit macOS Version 10.13.6 (Build 17G65) (Physical RAM: 64Gb)
Mac Model Identifier: MacPro5,1
NVIDIA GeForce GTX TITAN X OpenGL Engine (OpenGL ver:4.1 NVIDIA-10.33.0 387.10.10.10.40.105)

I use this machine for rendering and heavier tasks, everything works smoothly right now, I don’t want to mess this up with a new video card and OS. I guess I need to boot into Windows then…

Hello…
Reading this because having instant crashes…since last update
For my company, updates OS need some other softwares updates… which means cost…
So stuck with OSX 10.13.6 as you @furtonb
@John_Brock…so no expectation that next updates will reoffer compatibility to last OS?
Thank you

1 Like

I @furtonb. I doubt we’ll be able to support that MacPro5,1 in Rhino 7 for Mac. That said…

Do you get a crash dump window after the crash? If so, I trust you are sending reports. We are having some problems with our crash reports lately, so it might not have gotten through. Can you post a copy of the crash report here?

@dan

That’s sad, this is still a beast machine, especially with the upgrades thrown at it.:frowning:

Yes, I’ve sent reports.
See the attached file for details, I hope it helps.

200117_rhino_crash_mac pro.txt (128.9 KB)

1 Like

Thank you dan. My crash dump :

rhino_crash.txt (130.4 KB)

Thanks @petermasek.

To summarize, your crash is in Rhino 7 (RhinoWIP), on macOS High Sierra (10.13.6) and is crashing here, just after we are attempting to load the default content.

8   com.mcneel.rhinoceros.RhMaterialEditor	0x0000000155aee682 CRhRdkDefaultContentManager::LoadDefaultContent(CLBP_UUID const&) const + 464\
9   com.mcneel.rhinoceros.RhMaterialEditor	0x0000000155aee2f3 CRhRdkDefaultContentManager::EnsureDefaultContent() const + 459\
10  com.mcneel.rhinoceros.RhMaterialEditor	0x0000000155ac4b84 CRhRdk::OnNewDocument(CRhinoDoc&) + 114\

I cannot reproduce this on macOS Catalina (10.15.2), so there is good reason to suspect this is a High Sierra-only crash.

@andy if I can manage to reproduce this on High Sierra, do you guys have a machine over there that could be used to debug this?

Looking forward to seeing @Yann’s crash report (please attach it here when you get the chance) to see if we are dealing with the same issue or not.

Thanks again Peter!

Dear @dan thanks for your answer

I am running Mojave 10.14.2 and Rhino 6
Here you can find my crash dump:
Rhino crash log.txt (129.7 KB)

Thanks a lot!

Thanks @Yann for attaching the crash report.

Even thought they look the same, your crash and @petermasek’s are completely different. The good news is, I believe your crash will be fixed if you update to the latest macOS Mojave: you are running macOS Mojave 10.14.2 …I believe your crash will go away if you update to macOS Mojave 10.14.6 (@John_Brock suggested this above)

@petermasek’s crash in the RhinoWIP is something completely different and needs more investigation on our part.

1 Like

I just moved over @petermasek’s crash into this topic here as it is the same one as reported by @furtonb.

I’ll boot up a copy of 10.13.6 to see if we can reproduce this.

1 Like

Thanks @dan!
To clarify, even our newer machines (for power use) stay on High Sierra, as it turns out far more stable than even Mojave. Catalina is basically off the table due to the enormous amounts of bugs that we see in other applications.

So I’m happy to see that you are looking into the problem. Even a beefy iMac Pro crashes the Rhino 7 WIP (also on 13.6) instantly - which is sad, but with the deadlines we typically have, cannot really risk updating and potentially rolling back a production workflow between OSes. At least for the foreseeable future…

I want to set expectations low here, if possible. We might be able to figure out this particular bug, but there’s an entire class of OpenGL related driver bugs that were solved on Mojave that are making our lives very difficult.

Don’t get me wrong, I think I’ve mentioned before that we have a MacPro5,1 in the office (built in 2010!) that remains the fastest machine McNeel owns (it still builds Rhino for Mac official builds). That fact that there doesn’t seem to be a clear upgrade path on that machine (due to the boot hardware) is disappointing.

1 Like

I was able to reproduce this here:

RH-56688 RhinoWIP crashes on New Model on macOS High Sierra 10.13.6.

Sorry this took awhile to get some attention. We’ll see what we can do. The biggest challenge will likely be getting the proper developer in front of the proper machine (starting with Mojave, we now have a much better system for doing that, but this is High Sierra).

@dan, This may be a problem with the OpenEXR library used. Maybe they need to be rebuilt on a 10.13.6 machine? I don’t know, but may be worth a shot.

At McFinland we don’t have a 10.13.6 machine, so maybe I could talk you through building the libraries and use those to test?

Interesting. What is the PLATFORM_TARGET of the OpenEXR library? Or where would I hunt for that in the source?

TBH, I don’t know. I’ll check the OpenEXR sources - build system is generated with CMake. But you gave an idea to look for.

I’ve attached a zip archive to the YT item. The archive contains a bunch of OpenEXR dylib files. If there are any users who know what they’re doing could also try replacing the dylibs with the same names in their RhinoWIP.app bundle - that is if you can’t be bothered to wait for @dan to test it for you :slight_smile:

That fixed the issue. Thanks @nathan!

Awesome, I’ll commit the new libs.

1 Like