Rhino crashing on save after loading my .gh file, please help!

Grasshopper
1

Hello,

Everything was working correctly, but then all of a sudden my rhino file crashes. After I open my .gh file, I save the rhino file, and when I run the very next command after saving, rhino crashes. It happens even if I close the .gh file It’s like this definition primes Rhino for a crash immediately with any command run after saving. I tried a lot of different things to know what produces it, and it is opening this .gh followed by the save command in rhino.

Does anyone know what might be happening?

2

Does it happen on any file or a specific gh file or a specific rhino/gh file combination?

3

Specific .gh, I tried a brand new rhino file and a new input curve. It’s like that specific gh file primes Rhino to crash on the very next command run after saving. If I open any other .gh file, it doesn’t happen either, but once that one has been opened, upon save, it’s always does it. If I save both files and don’t save, it’s fine, if I close that .gh file and then save it does. If I close both rhino and .gh, and re/open, it doesn’t happen until I save and then it happens again, I recently agreed to go to windows 11 (and regret it) and have been getting long file path problems, but I moved everything to the root directory and it still happens, I checked the reference files path lengths and shortened them and created alternate reference geometry and it still happens.

I’ve been working around by making all the changes to my generated model, saving, closing everything and then re-opening, but that makes the work(flow) clumsy.

Thanks for taking the time to respond.

4

Hi Magnus -

In case you’re not using 3rd party plug-ins, could you post or upload that gh file?
For private uploading, use Rhino - Upload to Support and copy the link to this thread in the comments field.
-wim

5

Hello Wim,

I’m attaching both files now, the problem can be reproduced even when creating a new rhino document and poly-line input curve and feeding it into the curve container at the uppermost left of the GH definition. The only gh plug-in that I am using is Kangaroo2. Plug-ins for Rhino are Maxwell Render, VisualArq, and HDRlightstudiotexture.

Hope this helps.

Equinox generator – lightweight.gh (76.9 KB)

Equinox no. 5.3dm (1.5 MB)

6

Couldn’t generate any crashes here with your files by following the steps you’ve described.

I’m running Rhino 7 SR23 2022-10-2 (7.23.22275.09002) on MacOS.

I see you’re using the Import 3DM component to import several .3DM files that I obviously don’t have. Also see these referenced files have "\OneDrive\" in their file paths. I’ve read here that using files from cloud / cloud synced folders with Rhino can cause problems. I believe the suggested workflow is to work from local folders and copy files to your cloud / synced folder after Rhino is closed.

-Kevin

7

Kevin,

Thank you for the help. I finally came around to troubleshooting again and finally figured out that it was a corrupt object in one of my referenced files. After a bunch of trial and error, I figured out that the other referenced .3dm files loaded just fine from my One Drive, that was a good guess but wasn’t the issue in my case.

I don’t understand why, but even upon copying the bad object to a brand new rhino file, which I saved with a completely different name, the new file would still cause rhino to crash after saving – but only upon altering my base geometry input to the grasshopper file.

To fix it in my case, I was able to go back to an older version of the file, extract the curves, paste them into a brand-new file, and generate a replacement object and file that ended up loading without causing the bug.

I ended up testing my other three imported files that were originally created at the same time and they were essentially different sizes of the same form, and they did not cause the crash. I ended up creating an arbitrary object in the corrupt file, deleting the corrupt object in the file, and saving it with the same name, and it didn’t cause the crash. That is how I know the object itself has some kind of probably file reference or pointer error.

At the time when this started happening, I had just upgraded to windows 11 and was getting some strange file system errors about paths being too long when using rhino and grasshopper as well as other software. I’m guessing that the corrupted object in the file might be related to a buggy Windows 11 update, perhaps I choose to upgrade when they had a bad release, or maybe something about my computer in specific clashed with windows 11 at first. Have not been getting that error in awhile, but maybe it corrupted that one file.

It seemed like a file system issue of some sort because when Rhino was “primed” for the error, the title bar on top of the Rhino application window where the file name is listed would change from the name of the open base file to the name of the referenced imported file from grasshopper. From say: “generation model” to “100mm horn” very strangely.

It’s fascinating that the file bug was tied to the object inside the Rhino file, not just the file itself.

Strange, but documenting here in case it ends up helping anyone, and also for McNeel’s tech support QA teams.