When Xojo App Closes Without Exception

What is the most effective way to track were these crashes come from? Is it usually a bug in the Xojo framework and therefore requires a workaround or is it often caused by a bug in my own code?

Thanks

You are a Windows guy, aren’t you? There are tools for the dark side that have been mentioned here on the forum.

For tracking on the Xojo side: the easiest way is to log at the beginning and the end of the classes/methods that you suspect with something like:

WriteToLog(currentMethodName + " open")

where writeToLog is left as exercise to the reader.

And yes, it’s usually your code :slight_smile:

ok… is there a bug in the forum, or have you posted this question 3 times in past hour??

Ah, I see that Dave was nicer than I am :wink:

Thanks. Sorry about the repost. It just got stuck on the new discussion screen and thanks for the help. Would I be better off using a Mac?

Your suggestion did not work in this case.
Thanks

@Oliver: do you really want to start a flame war?

That was not starting a flame war. I was stating that the suggestion on his earlier post (to use the UnhandledException) event did not work.

No worries… that is kinda what I thought you meant…

  1. add code that write “I am here” message to a text file (be sure to open/close the file on each message)… and then see what the last messasge was at crash time…

  2. See if the profiler gives you any hints

Normally, a bug in your code results in an UnhandledException and a true crash is caused by a framework issue.

UNLESS you are calling declares. Then it is quite easy for your own code to crash the app.

The profiler is only useful if the app quits normally. If it crashes (or if you hit Stop in the dubugger), you get no results. So that won’t help here.

The best approach is scatter System.DebugLog calls and/or breakpoints in the code and start to narrow it down using a binary search strategy. (Does it get “half way”? “One quarter”? etc.)

problem I have found with SYSTEM.DEBUGLOG (vs my own method to write to a textfile), is LAG, SYSTEM.DEBUGLOG writes sometimes lag by seconds, and this could mean a crash before the queue is flushed

Crashes can be caused though by mistakes in your code that are not exceptions. For example, this code in a Window Close event will throw a crash in Windows:

Xojo.Timer.CallLater(1000, AddressOf self.SomeMethod)

So the timer object has been instantiated out there but the window that called it is long gone. Windows will throw up a nice BEX error and notify you that the program has stopped working.

So in Windows in particular you have to make sure you are never trying to access an object AFTER it has been closed.

Another place where it just crashes on you is when you have a memory hole and run out of memory. I just experienced that this morning. A tester had notified me that in his testing of one of my apps, it would randomly crash after a while. I’d never seen this as most of the time, I run the app for a few minutes, make sure all is good and then quit. So I decided I’d let the app run for however long I could let it run. Sure enough, it crashed on me. I found it was leaking memory like crazy. The cause was a bug in my code (well, and technically it wasn’t a bug). I had a string property in a TCP socket subclass that was basically saving all the data that was coming into the socket. I was appending to this string the data available each time the DataAvailable event fired. Because I was pulling bitmap image data on several TCP sockets, the memory got eaten up in a hurry. I had put this property in the subclass previously to do some debugging so that I could view all the data that had come into the socket. Problem is I had forgotten to take it out!

So yeah, Framework bugs cause crashes, but so do stupid and sloppy coding errors. - None of which may throw an exception.

if you’re viewing it in console console buffers things
if I suspect this is going on I do a tail -f on the log file its showing and there’s no lag there

There have been cases where Cocoa exceptions are raised in the framework and end up doing very strange things - for example, I’ve seen cases were a function just ends in the middle. Very hard to debug. Fortunately, these are usually logged automatically to Console.log - so as a first step I’d try reproducing this with Console.log open.

(On review, I think Oliver is talking about Win32 apps - never mind!).

For windows, you can run your app under WinDbg which may help you get a handle (heh) on what’s going wrong:
Steps here: https://forum.xojo.com/4259-include-function-names/p1#p31657

[quote=200159:@Norman Palardy]if you’re viewing it in console console buffers things
if I suspect this is going on I do a tail -f on the log file its showing and there’s no lag there[/quote]

I agree: console does sometimes show things a few seconds delayed, but I’ve never seen it actually drop log messages - in other words I believe that

   System.DebugLog "about to crash"
   CRASH (something that hard-crashes your app

you will always get the “about to crash” message.

[quote=200212:@Michael Diehr]There have been cases where Cocoa exceptions are raised in the framework and end up doing very strange things - for example, I’ve seen cases were a function just ends in the middle. Very hard to debug. Fortunately, these are usually logged automatically to Console.log - so as a first step I’d try reproducing this with Console.log open.

(On review, I think Oliver is talking about Win32 apps - never mind!).

For windows, you can run your app under WinDbg which may help you get a handle (heh) on what’s going wrong:
Steps here: https://forum.xojo.com/4259-include-function-names/p1#p31657[/quote]
That is useful to know. Thanks

[quote=200212:@Michael Diehr]There have been cases where Cocoa exceptions are raised in the framework and end up doing very strange things - for example, I’ve seen cases were a function just ends in the middle. Very hard to debug. Fortunately, these are usually logged automatically to Console.log - so as a first step I’d try reproducing this with Console.log open.

(On review, I think Oliver is talking about Win32 apps - never mind!).

For windows, you can run your app under WinDbg which may help you get a handle (heh) on what’s going wrong:
Steps here: https://forum.xojo.com/4259-include-function-names/p1#p31657[/quote]
I get this error when I try to open the exe file. 'ERROR: Symbol file could not be found. Defaulted to export symbols for ntdll.dll - ’

Tried BUILD run and DEBUG run from xojo.

Thanks

I realized that I had a method that returned nil. I passed this into the Append function for Group2D. Xojo did not give me any information on this error however. I went and manually tracked it down. Maybe it is a bug because the Append method cannot handle nil objects. Thanks for all the help anyway.

This is not a bug. Any object can be Nil. It is your duty to check if an object is nil or not before handing it over to method like Group2D.Append(obj as Object2D).

Ok but usually in my own code I will throw an error if the passed value is nil and that is not meant to be nil. I suppose it reduces processing if you have full control over when the nil checking is done to prevent unnecessary checks.