The one thing I’ve learned is to NOT step through code while anything other than local variables are showing in the debugger window. If you’re in an array or (heaven help you) a class with multiple properties or (even worse) a picture whose content is shown, Xojo WILL crash when you step through, even slowly.
The other thing I’ve learned, but unfortunately forget too often, is don’t run Xojo all day without quitting it and re-launching it. Going for 6-8 hours at a stretch, it will crash during a project save or run.
I’ve also learned that almost none of this is reproducible by the Xojo engineers, so I’ve pretty much stopped filing bug reports on Xojo crashes in these circumstances.
Well if the Apple crash reporter shows up those are useful
Doesn’t mean we can always fix the bug - that’s a different problem - but a crash without a crash log is very difficult to do much with
It’s not really about licenses, unless you count the EULA. In the past, there were third party developers that reverse engineered portions of the runtime and released products to users that relied on the implementation details (typically without them knowing it). Having the symbol information around makes this easier.
However, there is a more practical reason: performance. There are ~19000 defined symbols in the GUI framework, but only ~3500 of them need exporting. All those extra symbols have overhead and just aren’t worth it.
Visual Studio’s C runtime sources are incomplete and the C++ runtime bits don’t have sources available.
The temptation to pull off a major rant along the lines of “it will probably be forgotten anyways, save yourself the trouble of submitting those crashers” is very strong in me, but I will refrain from it anyway. Sort of.
On the one hand I’m glad that Joe looked at my report again (thanks!) on a sunday evening (he changed the summary) on the other hand I’m disappointed that my strategy of trying to be a good Xojo citizen and quietly reporting bugs along with projects that show the problem and not ranting about it on the forum is so unsuccessful. Matter of fact is that ranting on the forum does help, which shows that there is a problem in how that whole bug reporting thing works. With every Xojo release I look at the release notes and wonder how you Xojo guys prioritize your schedule when reproducible crashers are just not fixed.
If we can’t reproduce it, chances are that the case didn’t have enough information to work from. Cases with steps to reproduce or an example project to go with the crash log have a much better chance of being fixed.
Unfortunately I haven’t had the time to resolve these specific debugger crashes yet, but knowing about them is important. When I find the time, I can see all of the reported bugs that are similar and get them all in one go - but only if they are in Feedback.
Some bugs are nontrivial to fix. I investigated your crash when it was first filed and it fell into that bucket. There’s an internal note about three paragraphs long explaining how to go about solving it.
Complaining on the forums doesn’t help much. At best the forum post refers to a bug that’s personally interesting and one of us decides to tackle it as a break from the rest of the fixes and features planned for the release cycle.
I’ve found that going deep into almost any kind of data structure (except simple numeric or string arrays) can cause crashes if the data is left visible while stepping through code. I’ve had it happen with dictionaries, arrays of class properties, graphics, and pictures, particularly when you’re viewing a property that is several layers deep - for instance, a dictionary key whose dictionary is a property of a class which is a property of another class that is a property of a window.
I’ve never been able to reliably reproduce any of these crashes, which is why I try to save often and stay vigilant about switching the debugger back to simple variables before moving to the next step in code. Sometimes rather than dig down through variables in these cases, I’ll often add a local variable that contains the deep-down data I need to monitor. That almost always works without a threat of crashing.
