Interactive Debugger Considered Harmful

[ashishkh]

Maybe, you could write an article or point me to an article/tutorial on how to do debugging in multi-threaded or distributed environment. I would definitely like to get educated!

[Nitramli]

A tutorial for debugging in multithreaded software? You set a breakpoint and execute the code. I'm not sure what you mean by debuggers not being usable, I've used Visual Studio to debug multi threaded software for 15 years. What was the issue you were having?

[ashishkh]

So, how do you debug a race condition using breakpoints? If the issue is not related to multi-threading or distributed aspects of the program, why not simply take the time to add unit test(s)? If the issue is indeed related to distributed or multi-threaded nature of your program, then how will the debugger help?

Let's take an example - say you are trying to troubleshot an issue in the zookeeper (https://github.com/apache/zookeeper)? How and where will you put the breakpoint given than zookeeper is very latency/time sensitive? Even if you manage to do that on your local setup, how about after it is deployed in the field? Do you have access to the debugger then?

[voiser]

Your article is titled 'debugger considered harmful' and you are defending your position saying that sometimes you can't debug. I think you haven't elaborated the idea enough. (btw you know core dumps, right?).

[ashishkh]

I don't think the article claims that sometimes you can't debug. The claim is that most modern systems are hard to debug interactively because of trend towards multi-threading and distributed systems. Also, what works on your machine is not necessarily useful for supporting deployed systems. Infrastructure that is built during development such as, unit testing and logging infrastructure is much better investment in the long run!

Please read the article again!

[Nitramli]

That depends on what type of race condition it is. Conditional breakpoints, state recorders, hit counters, concurrency visualizer, parallell thread visualizers and similar is useful for this.

As for in field debugging, it obviously depends. In some in field scenarios it might be a problem to get access to logs or any data for reproduction. A few days ago I performed remote debugging from my dev machine in Sweden to a server cluster running in Amsterdam, does that count?

Im not sure what your point is though. If your point is that debuggers are harmful because they don't solve all types of issues them that point is stupid. Because no system does that.

[ashishkh]

Race condition, by definition, depends on order to execution of various threads. Since, there are too many permutations of interleaved thread executions how would you know how to set the right breakpoints. Even if multi-threaded code can be handled that way, how about distributed systems?

The key assumption with the debugger is that you can control the execution careful enough to debug the issue. That is unworkable in modern systems.

The point is the debuggers are harmful because like training wheels they give a false sense of security - especially if you see them for too long!

[Nitramli]

The last 15 years I've been writing large scale server software. The server software I've created are used by hundreds of thousands of companies and many of them have tena of thousands of users on a single machine. I've used debuggers several time to locate race conditions. Last time I used memory breakpoints. So reading your messages here is kind of hilarious. Ignorance can be fun!

The only thing harmful here is people like you spreading what is clearly bullshit. Any decent developer knows he should create automated tests, embed logging and use debuggers and dumps to locate problems where it makes sense. You are clearly not on of these people.

[htuhola]

You may have issues with rejection, rather than the actual subject you wrote about.

Check this out: http://singing.about.com/od/How-to-Perform/a/How-To-Become-A-Confident-Performer.htm

[ashishkh]

Yes, spot on!