Stackdriver Debugger: A Story About Time Travel
This whole article intended to be a short story. I tried a tool that helped in my programmers’ work and wanted to encourage you to join it to your stacks and give it a try.
Then I started to read more and more, and the story grew.
It’s a story about debugging.
“Horse is as everyone can see” was a definition of a horse in the first polish language encyclopedia (New Athens, Benedykt Joachim Chmielowski). There was a time when defining a horse was useless because everyone knew what a horse was. It is, more or less, like debuggers for programmers. Debugging is a natural part of our work. We are traveling back in time trying to inquire what happened. Debuggers have been with us since we were born, so we can say they have been with us forever.
Debuggers survived unchanged for a long time (at least it seems to be like that), but do you know the real story behind debuggers? The story, like every debugging story, starts with a breakpoint.
ENIAC was officially the first computer ever built. It was a big machine at the University of Pennsylvania helping in ballistic calculations, nuclear weapon creation, cosmic ray research, and even weather forecasting. ENIAC was initially programmable by switching wires and plugging cables from one unit to another to set program flow. To make the program stop at a certain point, the programmer would eliminate the wire. Then the current state could be read, and such a state was called a breakpoint.
Time passed, and computers rapidly changed. Some of you should be familiar with built-in console debuggers. C, FORTRAN introduced such tools, and it was a significant change compared to looking into the state of wires or memory.
IDE’s as all-in-one tools with built-in debuggers were the last significant change in debugger architecture.
Nothing seems to have changed for 30 years. We still have debuggers with a similar set of possibilities. Let’s come back one more time to the real purpose of the debugger. With a debugger, we’re traveling back in time trying to inquire what happened. Only a few debuggers really can do such a fundamental thing.
I found a great master thesis — “Combining reverse debugging and live programming towards visual thinking in computer programming” by Abraham Liebrecht Coetzee presented in partial fulfillment of the requirements for the degree of Master of Science in Computer Science at Stellenbosch University (Matieland, South Africa). The author indicates that “forward debugging” is about manually going through the entire stop-rerun-navigate cycle to simulate a single backward step, which as we already know is an essential task of the debugger.
Solutions exist on the market that allow us to do it more naturally. We can divide such a solution into two groups.
The first one is omniscient debuggers. Such debuggers store the whole testing session record, and we can debug the recorded session later. The first invention in this area was the EXDAMS system (1969). Nowadays it’s a quite common technique. GDB in Linux or IntelliTrace in the Windows family is a usage example. The second group of debuggers is real reverse execution. I haven’t seen many implementations of such a technique available among others in GDB or commercial UndoDB. The system forks the new instance of the application with a specific state, calculates the snapshot between two processes, and store it. Despite its obviousness known pattern it’s still not common to see the “back” button in modern debuggers.
With a debugger, we’re traveling back in time trying to inquire what happened. Only a few debuggers really can do such a fundamental thing.
I’m a loyal node.js developer, and although I have moments of weakness, where I need to have an affair on the side, I miss the Microsoft time travel debugger when coming back from my mistress, .NET. I close my eyes and dream about a tester testing my application and describing a bug with a recorded test session.
One day I thought my dreams came true. I found the Google Stackdriver Debugger, and I decided to redefine my real requirements, draw essences of essences. Google Stackdriver debugger is not ideal. There is just a snapshot, no back button, no session recording, no reverse execution. It must be enough for me, and it is — it helps a lot when debugging bugs in real code.
Let’s check the real example. Bootstrap is very simple, especially for Google Cloud users, but Stackdriver Debug can be used independently on your provider. In such a case, we should install Google Cloud Debug Agent and set up all needed permissions. The whole process looks a little bit different depending on the technology used and is not a part of this article. Excellent “zero to hero” documentation can be found here.
Once installed, Stackdriver Debug allows us to add a snapshot point, being an equivalent of a breakpoint. The interface is very intuitive and somehow familiar.
The snapshot will be taken when the real application will perform the stage defined by the code, so we need to ensure that this line was “executed on production”. In our case, we need to just do the GET request to /.
Once taken, the snapshot point can be viewed on the bar on the right.
There are variables and a call stack available. We can also type a condition to snapshot point or expression to be executed during runtime. Such a possibility is limited by the application agent, so we need to turn it on. The snippet in node.js can be found below.
const agent = require("@google-cloud/debug-agent");agent.start({ allowExpressions: true});
Stackdriver Debugger is not an ideal solution, because it is limited to just a single point in time. I treat it rather as the first, important step, I’ve been waiting for. I will for sure test it in my own production applications, waiting excitedly for future improvements. I expect to add a session record possibility in the future. Is it possible? The future of time travel looks exciting.
From the point of view of the entire history of debuggers, this is just a small footprint. I think it is important considering the stagnation of the last 30 years. What is your opinion? Are you going to give the Stackdriver Debugger a chance?
If this article has been interesting and useful to you, leave👏. Thank you! You can also check out another interesting story from my colleague — First Touch to Flutter.
