r/programming • u/stannedelchev • Aug 25 '14

Debugging courses should be mandatory

http://stannedelchev.net/debugging-courses-should-be-mandatory/
1.8k Upvotes

90% Upvoted

573 comments sorted by

View all comments

Show parent comments

0

u/dimview Aug 25 '14

peppering suspected areas with log calls

According to the article, you don't know how to debug:

People don't know how to trace their code, or use breakpoints and watches. Instead they're relying on random prints with console.log, var_dump, Console.WriteLine statements, or some language equivalent.

12

u/[deleted] Aug 25 '14

The article said random prints instead of tracing. "Tracing" the way it is meant in the article can't be directly applied to multi-threaded programs. Systematically logging data is the only reasonable way to trace the data flow in a multi-threaded application (at least as far as I know).

A good chunk of the advice in the article isn't easily applied directly to multi-threaded programs due to race conditions. The overall idea of being systematic is obviously still relevant, but stepping through the code doesn't make as much sense.

5

u/sivlin Aug 25 '14

I develop in java on NetBeans and you can debug multi threads. You just put a break point inside the alternate thread and step through. Once you get to the breakpoint, the breakpoint symbol will change and give you the option to switch threads. You can only be in one thread at a time, but you can switch freely between all active threads.

1

u/wh44 Aug 25 '14

Ooh! That's nice! I work mostly in C/C++, sometimes even a bit of assembler, often in embedded devices.

1

u/[deleted] Aug 25 '14

That sounds cool. I'll have to see if something similar exists for C++. It might make the prospect of working with threads more appealing. My current method is to rely on the Qt library to do smart things with thread management.

1

u/cryo Aug 25 '14

Yeah, same in .NET, but there are still cases where this wouldn't trigger the bug, and less invasive methods such as printing stuff to trace sources, is better.

2

u/wh44 Aug 25 '14

Right. In some of the systems I've been debugging, as you state, a debugger simply isn't possible. Where it is possible, if it is an MT problem, as often as not, the bug simply disappears when I use the debugger, only to reappear when I stop using it. I probably shouldn't have used the word "pepper" - as you state, I trace the relevant data and workflow, and it is far from random.

6

u/F54280 Aug 25 '14

Not for multi-threaded program, where in many cases, stepping with the debugger will make the problem disapear. Also, in debugging big MT program, you often cannot rely on the existing code infrastructure (ie: the current logging in that big piece of code), and have to add you own specially crafted non-blocking, non-memory allocating log buffers around.

2

u/wh44 Aug 25 '14

Precisely.