That is true of course, we don't know how many crashes go unreported. The memory corruption crash you're reporting is a well known one within McNeel. There is some kind of error somewhere that causes a memory mismatch between DotNET memory and C++ memory. Most likely, the crash happens when DotNET decides to free the memory too soon, because it is under the faulty impression that nobody else is using it anymore. Then, C++ tries to clear the memory as well, finds it is already gone and just keels over and dies. Due to the mixed-mode nature of this crash, we can't get good information about the circumstances and we have so far failed to track it down.
This is a major problem because it potentially affects all DotNET plugins, not just Grasshopper, but we haven't had a breakthrough yet... In the meantime, please do keep sending in Crash reports if at all possible. They'll probably be duplicates of ones we have already, but at the very least it helps us to understand which are the most pressing bugs. -- David Rutten [email protected] Robert McNeel & Associates On Feb 9, 11:51 am, PJ <[email protected]> wrote: > Sorry David, but I think this might not be as rare as you would hope - > I get a crash like this every couple of days (sometimes more). I > think probably the reason you aren't getting so many error reports are > that people are assuming it's so common that you're already inundated > with reports on it. Also, when the crash is the result of ExecConduit > () encountering corrupted memory (the most common apparent cause, I > find) it will usually hang without producing a crashdump anyway. > > Paul > > On Feb 8, 7:39 pm, David Rutten <[email protected]> wrote: > > > Hi Christian, > > > I get a steady trickle of display related crashes. It seems there is a > > small chance during a redraw that some buffer somewhere overflows or > > goes stale. Considering the amount of Grasshopper redraws that must > > occur during any given day worldwide and the amount of reports I get > > (about 1 every two days that's clearly display related), it is a very > > rare bug. If it happens a lot to you, that probably means you're > > suffering from this in an usual fashion. > > > During the last few iterations of the plugin I've been adding massive > > amounts of error-tracking/trapping/catching code to the display > > routines and the frequency of crashes has dropped severely. The best > > you can do is send in any crash-reports you get (after a crash Rhino > > should offer this through a message box). > > > Autosave has been requested by others as well. It's obviously not as > > good a solution as actually fixing the crash, but it will be much > > easier. > > > -- > > David Rutten > > [email protected] > > Robert McNeel & Associates > > > On Feb 8, 8:26 pm, Raun <[email protected]> wrote: > > > > Hi, > > > > I´m wondering if I am the only experiencing crashes at random. I > > > mostly happen while panning around the definition whiteboard and then > > > suddenly it crashes. I´m sorry that I don’t have any exact error > > > message as an example but I was just wondering if it was possible to > > > incorporate an autosave. Since I sometimes get caught up in figuring > > > out the definition and forget to save. I know this is not the best of > > > solutions but it would definitely help me a lot. I will post the error > > > message I get the next time it happens. > > > > Regards > > > > Christian- Hide quoted text - > > > - Show quoted text -
