Crash on file open.

Replies to This Discussion

Permalink Reply by Andrew Heumann on May 19, 2016 at 9:06am

Something has corrupted your file - it is no longer a valid representation of a grasshopper document. it even crashes the FileViewer that ships w/ grasshopper. 

I am hopeful that this doesn't have anything to do with Human, but if you notice a repeatable sequence of events that causes this issue please let me know! 

Permalink Reply by Andrew Heumann on May 19, 2016 at 9:08am

You might also look at your autosave folder to see if a version of the file before corruption is available. 

Permalink Reply by epee du bois on May 19, 2016 at 9:13am

Thanks for responding. I had friend open on his machine and it opened. He does not have Human installed. Still not sure if Human is the problem but I will let you know. I am only using your pull down menu component and the text bake and hatch bake. I had just finished restructuring my script to be able to send grafted data to the hatch bake component for more efficient way of coloring my hatches. I'll keep you posted.

Permalink Reply by epee du bois on May 19, 2016 at 10:37am

I think it might be something to do with the Human Baking functions. I should say that I am not so skilled at managing data but I will try and explain what is happening. My friend was able to open and resave the file without the human plugin and resave as ghx. I have started rebuilding and I think it might have something to do with sending grafted data through the attributes and hatch bake. Basically I am using Human to bake some maps for visualizing where data appears in a grid of values. I'll spare you the details but I can say already that sending unflattened data through hatch component is running very slowly. BTW really looking forward to Doodlebug. Thanks! I'll let you know if I figure any more out.

Permalink Reply by Andrew Heumann on May 19, 2016 at 11:16am

This is really good info. I will try to troubleshoot!

Permalink Reply by Andrew Heumann on May 19, 2016 at 12:35pm

So I think I've figured out the problem. I was able to open the file on my mac, and dig in a little bit. It doesn't appear to have anything to do with any of the plugins in the file (Human, Firefly, and SonicString)

A number of your "List item" components had MASSIVE data sets internalized inside them. Even though you were feeding wires into them, the internalized data persisted in the file. Each one was storing a copy of 186000 integer values. All these data sets look identical - I suspect you copy-pasted a component with a large number of internalized values without realizing it. When I saved the .gh as a .ghx it was a whopping 340MB - you should never have that much data stored inside a file. 

I wrote a python script to strip all internalized data from all components + params in the file - and it no longer crashes on my machine when I open it. See attached (python script included as well). The file size went from 1.8 MB (340 MB as XML) to 70kb (2MB as XML).

Attachments:

• workingPreviewSquare_stripped.gh, 79 KB

Permalink Reply by epee du bois on May 19, 2016 at 1:11pm

Thanks so much. I have a bad habit of build scripts on top of older projects. 186k was from the previous work. Sometimes I internalize data that is coming from excel or an operation that takes a long time to run. I didn't know that they wouldn't clear if you plug new data in. 

I rebuild what I was working on with your components and it seemed fine. I still struggle with fully utilizing the data tree structures effectively but I worked it out. How's grasshopper on the Mac running? I haven't had the courage to switch yet though I thought I might see a performance increase.

Thanks again for your help