quit putting words in my responses…
I stated facts as I observe them… the topic was Xojo crashing… not OSX, not Window…
Actually, it’s pretty easy to make the IDE crash.
Open a really big project, with lots and lots of windows and modules. The one I’m typically working on has 154 windows and hundreds (maybe thousands) of methods.
Open each of those windows and modules. I used to do this when working through an app making major changes throughout. I’d open the first window, check its open event, modify it as needed, then move to the next window. Then on to modules, opening many of the methods in them to check and make changes - all while leaving the windows, etc. open in the IDE.
Eventually, the IDE will crash, it simply runs out of memory. I reported this as a bug a long time ago, and the answer was “don’t open so many things at once, the IDE can’t handle it”. So I don’t, I close almost everything as soon as I’m finished working with it.
The other thing that eventually eats up memory is stopping a running App that has used a lot of memory, instead of letting it go through its App.Close. Do this enough, and you’ll see the memory use in Activity Monitor increase until the IDE crashes.
I’ve also found that, depending on the project, if I open several projects at once, that closing them doesn’t always release the memory they were using.
I rarely find instances where Xojo actually has crashed due to an internal problem, and it doesn’t seem to matter whether it’s Windows or Mac. When Xojo does crash, I usually file a bug report, though they’re almost always impossible to reproduce, which means after a while I get tired of filing them and stop for a month or two unless they’re very easily reproducible.
Just my .02, of course…
Hopefully the 64 bit IDE will mitigate the out of memory issue.
With some projects a 32 bit IDE simply hasn’t got enough head room.
Thats a given.
But there do seem to be some leaks that I’m trying to track down that, if fixed, should help.
However, there are still going to be projects that simply need more room than a 32 bit IDE can provide.
And we did talk about this at XDC - see the Xojo Roadmap section of http://blog.xojo.com/2016/10/11/xdc-2016-recap/ where its mentioned
[i]For early 2017, Xojo is expecting 64-bit to be out of beta, enabling things such as debugging, XojoScript, Windows manifest and other features.
Later in the year, we expect 64-bit to become the default build target. But dont worry, 32-bit is not going away! We are also working on the 64-bit version of the IDE itself.
[/i]
[quote=297408:@Dave S]to me Windows is the most unstable OS the world has ever seen…
…Which is why I abandoned Windows the day Vista was released.[/quote]
This sounds like picking a fight IMO.
Don’t contradict your self. It’s frustrating.
Specifically the topic was Xojo 2016r3 crashing on Windows 10 64Bit.
Again:
Therefore I will not be replying to anymore of your replies on this topic.
I’ve had zero success doing this. Sending the crash report creates a Feedback case. The Feedback case is later closed as I couldn’t provide a working example of how to repeat the crash. Perhaps an option to submit the crash report without opening a case is needed. You’d get a better picture of how buggy the IDE has become.
I understand it is hard/impossible to debug a random crash, but you are missing out on metrics of how often this is happening.
currenty i choise to save it every 20seconds 
This might sounds like a non-sequiter BUT running the IDE on a 64 bit version of Windows DOES seem to help things a lot.
Not sure why this is - it just is.
I have the IDE in a 32 bit Windows VM its is not as nice as the same version of the IDE in a 64 bit Windows VM, and on my real Windows 7 SP 1 64 bit machine, behaves entirely differently and is vastly more stable.
The big question I also have, and that I do work at trying to figure out, is why, as this makes NO sense whatsoever.
So we are aware of it just haven’t track down any specific cause for this yet.
Oh or the other way I’ve found that makes things more reliable (which is also nuts)
Get WinDBG
Run it and inside WinDBG run the IDE
It will probably be slow as heck but even on my 32 bit VM the IDE suddenly is way more stable and what would normally make it crash for me very quickly no longer occurs
This is immensely frustrating as it makes figuring out whats happening very much more difficult
The point of running it in WinDBG is to watch the instability but …
Chai Ren is using Windows 10 x64.
Whew! A first time for this. Xojo shut down while debugging. No errors or dialogs (Xojo or otherwise). It simply just ‘went away’.
Thankfully Xojo was able to find unsaved changes when it restarted. A very necessary, life saving feature, by the way.
[quote=298109:@Neil Burkholder]Whew! A first time for this. Xojo shut down while debugging. No errors or dialogs (Xojo or otherwise). It simply just ‘went away’.
Thankfully Xojo was able to find unsaved changes when it restarted. A very necessary, life saving feature, by the way.[/quote]
yes,when it restart ,it can find the oldversions and reload it.
@Norman Palardy
I don’t know if this helps or not but I caught a gif of the crash. <https://xojo.com/issue/46006>
what it does tell me is that there’s “something” combination of projects you’re opening that seems to cause this
But without those projects & a way to replicate it I’m still no further ahead
It’s a little sporadic. Here is a link to one project that creates a problem in 2016 R3.
project
Open the project. Wait till the project is fully loaded for about 5 seconds. Close the project. (I have preferences set to keep Xojo running). Crash!
I just repeated this 5 times in a row on my Windows 10 64 bit machine. Xojo 2015 R3 was running in the background if that makes a difference.
When I try to report the error it gives me an error saying that the case could not be found. Then I get an email with the stack trace. So here it is, although it probably doesn’t help much, it at least points to the right place. I tried opening the above project on another win 10 computer, and couldn’t get it to crash. Go figure.
@Norman Palardy
I’ve attached a WinDbg report the above case.