for the past week, anything i do with planes consistently crushes rhino.
if i check my auto save folder i have so many files to prove it
please check latest update R6 > i find it very unstable
For example? Can you provide a step-by-step recipe to crash Rhino so people can test? --Mitch
1 Like
few days ago i got this error log i made a printscreen out of.
as fort the def, i cant share my work but even when i make a simple def like attached i get the same issue of crashcrash simple def.gh (8.9 KB)
Changed category to Grasshopper…
pls explain
(rhino6 latest +win10)
Because your screenshot shows you using Grasshopper and the errors are from Grasshopper, not from creating Rhino native geometry as far as I can tell.
I can load that file and am experiencing no crashes. Where do the planes come into this?
same for me. Everything works fine here.
Maybe some other plugin causing this?
I can find one crash report you submitted 2 days ago. It’s got a bit of Grasshopper and then goes into OpenGL display code where it ultimately crashes trying to allocate textures (if you can believe the callstack that is, you can’t always). Please just keep submitting these crashes using the same name/email. The more data we have the easier it becomes to figure out what part of a crash report is a fluke and what part is relevant.
even before making planes it crashes contently
i guess some bugs with gh i cant figure what
This is the info from 2 days ago. If you submitted newer reports since then I haven’t been able to find them yet.
As the callstack shows the crash happened when the OpenGL texture was enabled. It doesn’t necessarily mean that method was at fault, it could be that something else crashed on some other thread at the same time as this Enable() method. That’s why it would be handy to have multiple reports, so we can see whether the lead up to the crash is always the same (and therefore probably buggy) or whether it’s often different (indicating the problem is elsewhere).
1 Like
ok, so when it happens again ill send. i kind of gave up sending the error…
but i guess its the same old issue im having the past week
also i have noticed anemone loop keeps generating data which might trigger overkill on the system
it thinks it has the limit iteration but keeps creating data nonstop
it thinks it has the limit iteration but keeps creating data nonstop
i tried blocking in many ways but i think this is one of the bugs i can pin point.
however in the def i gave, i did not even get to use anemone.
i guess its the opengl
Yep, always send in those crash reports. The system we use now is reasonably automated and clever enough to combine similar crashes so we get a good overview of how often it happens and how wide-spread it is. Is it a single user crashing every 5 minutes, is it different people crashing at different times?
It is also tied in to our bug tracking system so the more data we have the better. Apart from user name and email (that you provide in the window) the system does not store your personal files.
1 Like
The display often gets blamed for crashes that aren’t its fault, because display code is almost always running. So whenever a crash happens out of the blue, the computer looks around and finds that the screen is redrawing and thinks “hey! that must be it!”.
i use “only draw preview geometry…” to reduce the crashes.
it crashes regardless to that, but it fairly reduces the effect.
What if you disable the preview entirely?
sent a new crash
didnt get the the point where i totally disable the preview
i do think its the loop
Yup, got it. Same error message, completely different call stack. I’ll have to confer with my esteemed colleagues in the Seattle main office to see if they have any ideas on how to proceed.
1 Like
ok. So… had hard time doing a clean install , but after that, most of the issues are gone.
i dont understand how rhino and grasshopper got kind of corupted
anyway, hope i wont be posting more crazy bugs here
cheers.