Making an app that self debugs

[Red Squirrel]

Is it possible to make it so when my program crashes it produces a crash log? I've seen some C# programs do this. Basically, a stack dump showing line numbers of bad code (ex: in event of going past the end of an array, division by 0 etc).

[Lindley]

Well, you can catch exceptions when they occur. That's probably the best you can hope for.

[Red Squirrel]

Yeah was looking at that, but you still have to manually check for exceptions, so it kind of defeats the purpose. Perfect code won't need to throw exceptions as its handled properly.

Basically what I want to do is say I write code like this:


int i=10/b;

If I execute and b happens to be 0 then it will crash but produce a log as to why it did. I would see that and realize I should go and have a check to ensure b can never be 0. I know in C# this is possible so just wondering if C++ has this capability as well.

[Paul McKenzie]

Basically what I want to do is say I write code like this:


int i=10/b;

If I execute and b happens to be 0 then it will crash but produce a log as to why it did.

If you're working with Windows, then there are numerous articles on how your program can create crash dump files using dbghelp.dll.

Regards,

Paul McKenzie

[Red Squirrel]

I speaking more in general, so windows/linux. There is a great debugger in linux which will do the crash dump thing if I call the program with it, so wondering if theres a way to somehow tie it into a program.

[macabre13]

@Red Squirrel - if you find the solution, please post it here

I think that so long as it's not managed code, there isn't way to self debug and self fix code. And like Lindley said, in my opinion try/catch is the best(only?) way to achieve similar functionality.
But, hey I always could be wrong

[Liche]

Perfect code won't need to throw exceptions as its handled properly.

No. Perfect code handles things properly *by* throwing exceptions. What would a "perfect" program do if it ran out of memory? If the database it was working on crashed? If it lost network connectivity? These are exceptional cases, and this is precisely what exceptions are for.

you still have to manually check for exceptions

No more than you have to manually check that a for-loop is ready to terminate. If you rule out code techniques which require you to write checks and then act accordingly, you're not going to get very far...

Anyway, logging errors (good!) does not debug your code for you, it merely gives you more information to help you do it yourself. The information you are given can only be as good as the error/exception handling that you have written - if you don't put in a check for the circumstances that occur, you don't get anything useful. If you put in a check based on erroneous assumptions, then what gets logged may actually be misleading. Ever seen an application crash citing "unknown error"? This means something bad happened that the programmers didn't think of, and therefore didn't handle correctly. I think this is probably what you mean when you talk of perfect code, but I think that you are assuming that your code will always have total control over its environment, which is never the case.

[Edders]

You probably want to read this page - it explains how to add the code (given as a download in the article) to your C++ project, which in turn will make your application create an ERRORLOG.TXT file if it crashes. In this file the contents of stack, registers and so on are printed as well as the location of the crash.

[kempofighter]

@Red Squirrel - if you find the solution, please post it here

I think that so long as it's not managed code, there isn't way to self debug and self fix code. And like Lindley said, in my opinion try/catch is the best(only?) way to achieve similar functionality.
But, hey I always could be wrong

I don't believe that try..catch would catch the divide by zero error. There are certain types of problems that will simply cause a program to crash and not throw an exception. Not all run-time problems can be caught and re-thrown. Obviously, this is why code has to be tested. Unit testing might flush out a lot of obvious problems but when running a full blown executable, try..catch can only do so much. If you have dangling pointer / reference issues, or code that is trying to make function calls on NULL pointers, or using an improper index into an array.

By the way, I hope that there is no such thing as code that fixes itself because it'd put a lot of programmers out of work very quickly. If programming/debugging was totally automatic most of us would have to find a new line of work.

Another thing you can do in a program is develop a log system with log levels. If a program crashes, you can at least look at the log leading up to the crash to see what types of warnings/messages were printed (in addition to implementing exception handling mechanisms or dumping call stack info).

[Ajay Vijay]

My few cents:

1. Check return values of all functions. If not all functions, alteast the imporatant ones. Do appropriate action on return values.

2. Use asserts (assert/ASSERT) - they may be irrirating initially, but they are great self-debugging tool.

3. Write success logs and error logs (preferbly in separate files, with date-time mapped filenamed). For each function success/failure write the function name, and error code, in case of errors. This will greatly help in finding trace-back to the problem, specially when program is not being debugged.

4. Fully test run the Release build too - may be with debugging information enabled. You may also distribute Release build with 'Debug' information.

5. Don't use Try-Catch, unless library demands so. MFC has TRY/CATCH/END_CATCH - which are kind of self-healing - you may not need to use them too, if flow of code is cascading the error values to other functions (callers), rather than one of the function in call stack is dropping the error-code and continuing as if nothing happened.

There are many other points, which are generally gained by self experience, trial and error results.