Dias Saparov

check your remote debug bro

Sometimes when you are working with code that works in production on some server, you can encounter a problem which you cannot trace just looking at the code, running tests or even running the whole project locally. In this case, the obvious choice would be to remotely debug it using the debugger of the IDE of your choice. I am not going to tell you how to do that (you can google it) but will warn you about a couple of pitfalls that I personally came across and that served me as lessons.

lesson 1

Well, first of all, remote debugging should be your last resort because debugging code that is running in production can affect production if you’re not very careful. One wrong move and you can halt the whole project.

Sometimes you need to debug remotely, but before you do this, try:

  • Carefully reading through the code. Sometimes you can identify a silly bug just by looking at the code
  • Writing a test to attempt to replicate the problem
  • Setting breakpoints on the problem code and running tests in debug mode. If existing tests don’t cover it, write new tests
  • Setting breakpoints and running the project locally

When you’ve tried all of that but still can’t replicate the problem, it’s time to consider attaching a remote debugger.

lesson 2

In the case of the IntelliJ Idea debugger, when you set a breakpoint it pauses all threads that are using that particular piece of code by default. You probably don’t want to completely pause all threads while you are debugging, so you have to change it by right-clicking on the breakpoint and changing its setting.

Screen Shot 2016-02-24 at 14.34.53

lesson 3

The last lesson that I learned was quite painful for me as it was a while before I learnt it: be sure that your local code is exactly the same as the code that is running remotely. The problem arises when you made a change to the code, but never actually deployed it on a server or when you switched branch and forgot about it.

It is rarely obvious to you because the code continues executing and doesn’t produce any warning messages about a code mismatch. If it doesn’t hit the breakpoint that it obviously should have hit, it probably means that you have a different version of the code. If the line of code that does something is actually doing something completely different, you probably have a code mismatch. Always make sure that local and remote code match.

I would like to finish this post with the quote:

“Only a fool learns from his own mistakes[sic]. The wise man learns from the mistakes of others.”

If you enjoyed the read, drop us a comment below or share the article, follow us on Twitter or subscribe to our #MetaBeers newsletter. Before you go, grab a PDF of the article, and let us know if it’s time we worked together.

blog comments powered by Disqus