Were you taught debugging

Quote:

---

Originally Posted by dc_2000

You normally do it like this:

Code:

---

//On a global scale
#define DO_LOG_MY_EVENTS  //Comment this line if logging is not necessary

#ifdef DO_LOG_MY_EVENTS
    #define LOG_MY_EVENT(a, b, c) LogMyEvent(a, b, c)
#else
    #define LOG_MY_EVENT(a, b, c)
#endif

---

Code:

---

//And then when you need to log an event:
LOG_MY_EVENT(__LINE__, __FILE__, _T("Whatever else"));

---

In most cases it will not interfere with the original flow of the code.

---

That's exactly what I do too, thank god for preprocessor :D

Quote:

---

Declaring any global variables would not be good in case of multi-threading.

---

Agreed.

Quote:

---

Originally Posted by ninja9578

Quote:

---

Declaring any global variables would not be good in case of multi-threading.

---

Agreed.

---

It depends. If they are set at program startup and only read from that point on, then there's no problem. If they are changed during program operation and multiple threads are reading them, then there's a problem.

The thing that I hate the most is when the log alters the results of the execution. It usually only happens while multithreading, but I've been fighting a bug for the past 4 hours in a single threaded app where my log makes it run correctly, but turning the log off causes it to crash.

Quote:

---

Originally Posted by ninja9578

The thing that I hate the most is when the log alters the results of the execution. It usually only happens while multithreading, but I've been fighting a bug for the past 4 hours in a single threaded app where my log makes it run correctly, but turning the log off causes it to crash.

---

Turning on the log can do that sometimes, regardless of whether it's a single thread or multi-threaded app.

I've had my share of those very same issues, where running with logging turned on makes everything "work". If it's a crash, the crash or core dump is a valuable piece of information.

Regards,

Paul McKenzie

Quote:

---

Originally Posted by Arjay

I prefer a framework that has multiple output targets (Console, debug trace, logfile, event log, etc) and on that you can externally change settings such as what components to log, detail level and so on.

---

That's very much what our home grown one does too. There are four levels (Critical/Warning/Info/Debug) and four output channels (Win32 debug output/memory log/stream/console).
There can be many debug 'sections', each one identified by a unique string, usually based on the namespace & class name. Sections are enabled in a file. The code calls the Get_Log function to get a reference to its log, or a null log if not enabled.
As our code is often very time critical the log also contains a high resolution timestamp.

Having an external file is very important as we may want to turn options on & off out in the field. Uploading new versions of code with new debug options may not be contractually allowed.

Yeah, good point. What if at times you cannot debug a project? (Like when a bug happens in a module that is already in a customer's possession and you get a tech support message on par to this, "There's a glitch. Fix it!") Logs can be very useful in that case. How do you handle a situation like this, by the way?

Another application for log files could be tracking down the "race condition", when obviously a good ol' debugging won't cut it (well, unless you run it through a kernel debugger.) Good example where such may occur would be ending complex worker threads.

Quote:

---

Originally Posted by dc_2000

What if at times you cannot debug a project? (Like when a bug happens in a module that is already in a customer's possession

---

We have a small amount of debugging enabled by default in the config file. We would ask the customer to send us the log. If it didn't highlight the problem then we would either send them an updated config file and get them to try to replicate the bug or we would attempt to run our application in simulation mode with data logged from a real system.

Quote:

---

Originally Posted by Arjay

I have a preferred list of debugging techiques.
Message box

---

It is not wise to use message boxes for printing results; in the unfortunate event you do get stuck in an infinite loop you're stuffed.

Most of us here will be good enough to avoid infinite loop situations but they do happen from time to time. Most of all it isn't a good technique to show new programmers.

The debug output windows is the way to go for such messages.

why call it a bug?

"hey chris, this line is bugging me" -1940

Quote:

---

Originally Posted by Ayyubid

why call it a bug?

"hey chris, this line is bugging me" -1940

---

This was in my college text book if I remember correctly.

The first actual case of a computer bug was caused by a moth which had died in a computer case.

http://www.worldwidewords.org/qa/qa-bug1.htm

The worst case is this: I remember a few months ago I was writing a small app for someone, it ran fine 99% of the time, but crashed 1% of the time. In one thread, and it never ever happened when the debugger was running. That one took 3 days to figure out. Turns out I was double deleting a pointer.

Quote:

---

Originally Posted by Ayyubid

why call it a bug?

"hey chris, this line is bugging me" -1940

---

http://catb.org/jargon/html/B/bug.html

Quote:

---

Originally Posted by Rich2189

It is not wise to use message boxes for printing results; in the unfortunate event you do get stuck in an infinite loop you're stuffed.

Most of us here will be good enough to avoid infinite loop situations but they do happen from time to time. Most of all it isn't a good technique to show new programmers.

The debug output windows is the way to go for such messages.

---

You'll notice it was last in my list because it's basically a last resort type of tactic. In this scenario, you might have access to the source for modification, but can't run the debugger in production. Debug output is only good for a debug build and (besides when debugging in a debugger) when running an external debug capture tool such as dbgview. You may only be able to run a release build without the ability to spew debug output.

As far as infinite loop - having a message box inside an infinite loop isn't going to cause any more trouble than an infinite loop without a message box. At any rate, if this occurs you can always just kill the app.

As I said, peppering the code with message boxes is a valid debugging technique - it's just not one that I would use if I had other options.

Quote:

---

Originally Posted by Arjay

You'll notice it was last in my list because it's basically a last resort type of tactic. In this scenario, you might have access to the source for modification, but can't run the debugger in production. Debug output is only good for a debug build and (besides when debugging in a debugger) when running an external debug capture tool such as dbgview. You may only be able to run a release build without the ability to spew debug output.

---

Good point.

Quote:

---

Originally Posted by Arjay

As I said, peppering the code with message boxes is a valid debugging technique - it's just not one that I would use if I had other options.

---

Agreed, not the best.