Very few things actually “crash” the IDE - and by that I mean you get an Apple Crash Reporter report dialog
That’s a “crash”
Anything that is an “unhandled exception” isn’t a “crash” in that sense
A failure of the IDE for sure - but its not “crashed”
I suspect a fair number of the things being mentioned on this thread are related to <https://xojo.com/issue/49847>
A most curious issue whereby you can have lots of free memory but a memoryblock of a certain size cant be created - and so you get an OutOfMemoryException
@Norman: I said crash and I meant crash. Like a hard crash. I monitored the memory and Xojo crashes with about 1 GB of memory used. At least it does for me. And no, the spawn thing doesn’t look like 49847.
Note I said “related to Feedback Case #49847”
Not “exactly the same issue”
We got lots of reports about out of memory exceptions (which is what the spawn compiler one is as well)
I’m fairly sure I finally tracked this down
What appears to be happening is that memory is getting fragmented in such a way that despite the IDE not using up that much memory and not exceeding its process bounds when it needs a block of a certain size the request fails and things fail badly at that point.
Why it fails is curious but I can illustrate
if you happen to now need 4 units despite having enough free memory its not contiguous and so the request fails and you get an out of memory exception.
At least this seems to be whats going on
With 49847 what seems to be contributing is the autosave functionality
And so we’ve revised it to work differently to avoid this memory fragmentation situation
In my testing it made it possible for me to run the IDE sources many many many times without getting an out of memory exception
Just to chime in here; I’ve found since I wiped my El Cap installation and did a clean re-install, using migration assistant to copy back my apps and data, that my system has been a lot more stable. I can run 2017r2.1 for days weeks without it crashing.
I was having terrible trouble when going over the built-in (and not upgradeable) 16GB of ram, but since the re-install things have stabilised somewhat, even when a leak in my app caused it to go over 36GB of ram, everything grinder to a halt as OS X crapped its pants, but it didn’t crash!
I have tons of crash reports of Xojo2017r2.1
Mostly happens when compiling a bigger project at least ones to 64bit and then quit Xojo.
The feedback is still Needs Review.
What I find weird is when the IDE crashes while in the background what could be happening there?!
Most common hard crash is when I Save and Run in quick succession.
Read the date on that report
Until I bumped into it running sources we had no idea HOW to reproduce it reliably - we’d seen it but thats it. Reproduction was key.
And since I was running sources I got a nice stack trace & finally then spent several days figuring out what was going on and what was causing it. And then a couple more figuring out how to avoid this situation. And 2 more implementing it.
The best I can say is “Check the release notes when the betas are released”
[quote=356779:@Sam Rowlands]Just to chime in here; I’ve found since I wiped my El Cap installation and did a clean re-install, using migration assistant to copy back my apps and data, that my system has been a lot more stable. I can run 2017r2.1 for days weeks without it crashing.
I was having terrible trouble when going over the built-in (and not upgradeable) 16GB of ram, but since the re-install things have stabilised somewhat, even when a leak in my app caused it to go over 36GB of ram, everything grinder to a halt as OS X crapped its pants, but it didn’t crash![/quote]
Debugging projects as 32 bit doesn’t, for some god forsaken reason, seem to suffer from this issue.
But debugging projects as 64 bit does seem to much more rapidly
[quote=356782:@Christoph De Vocht]I have tons of crash reports of Xojo2017r2.1
Mostly happens when compiling a bigger project at least ones to 64bit and then quit Xojo.
The feedback is still Needs Review.[/quote]
There are still situations where there’s not a lot we can do about them.
Methods that are thousands of lines long do take more memory and time to optimize - even when set to “default”.
Anything more aggressive just takes more memory & time.
Layouts with thousands of controls on them suffer from the same issue as they are, for compilation, also thousands of lines of code.
So layouts with thousands of controls and lots of methods that are thousands of lines long are going to be problematic.
But this is something Xojo users can influence by using container controls & factoring methods out to not be thousands of lines long.