In this RX-M Cloud Native Short Take, industry expert Ronald Petty reviews the Go Debugging module. In this short take, he explores the powerful Delve Go Debugger, enabling you to debug your Go programs easily.
Video Transcript
Welcome to another RX-M Cloud Native Short Take, I’m Ron Petty. In this Short Take of the RX-M Go Debugging Module we are going to have a look at Delve, the Go debugger. The game plan consists of 7 steps:
- Install Go
- Configure the PATH to include Go tools
- Install Delve
- Configure our PATH to include Delve
- Review our application
- Run the application
- Use Delve to debug
The first four steps have already been completed; from there we pick up by taking a brief look at an application just so we have some context. We run the app so we get a little more context and then we see where there’s a bug and use Delve the debugger to see if we can walk through our code and reach that same location.
There’s two primary modules; the first one is a driver called cmd.go and it’s going to load a package and run a function that’s defined inside of code.go and that’s actually where our typo lives. In addition in the driver there’s going to be some go routines and some channels being used just so we can look a little bit into the special powers that Delve provides us when we’re debugging go programs.
When we run our module one’s driver application it prints out some some kind of navigation output just so we know where we are in the code and we can see our typo: “debuggin is neat”. So where is that coming from? There’s more than one way to do this but when starting with the basics, just going to see how to navigate to it in the debugger makes sense.
To launch the debugger you type in “dlv debug” and then the name of the program, in this case “cmd.go”. The debugger has many tools. Probably the most helpful is the “help” command which you can shorthand by typing the letter “h” which provides all kinds of subcommands. It starts off with navigation; breakpoints allow us to stop execution so we can look around and see what’s happening; we can print out the variables; we can print out information about the goroutines; we can view the stack related information; we can look at the actual source code; and do other additional operations as well.
The “l” command shows us where we’re at, which may not look familiar because the debugger stops before we actually enter our application. Setting a breakpoint can be done with “b” in the “main” package on the “main” function with the command: b main.main. To list breakpoints you can type “bp” and to continue, to simply run to that break point, type “c”. Iit stops at the break point which happened to be on line 8. We are also able to do things like step through; we can step into and we can step out of function calls. In this case what we “end” for next then we keep hitting “n” until we land on line 17. We created a couple of channels and we created a couple of goroutines and they’re sending data back and forth which we can see.
We can also type in “locals” which shows us locally declared variables. Also, if our function had arguments passed in we could have typed in “args” but in our case main has nothing passed in. We can introspect these variables i can type “p weight” which will print out the “weight” variable so we can get some insight into it. We can dig deeper by typing “weight.buff” for the internal buffer in this channel to get further information.
If you lose where you are at, type “l” to see where you’re at again. In this case our actual bug comes from the Runme() function on line 19 where our typo is being returned. Before we get to there we can set up breakpoint in advance. However, if you only partially know the name of function you can type in “funcs” and give it a partial name, for example “Run”. The result shows there are a whole bunch of things with the word “Run” in them but if you know a little bit more you can filter it down. Using “funcs Runm” as our search we have a pretty good idea that it’s unique because only the Runme package returns. So we can set a breakpoint on it with “b Runme”. Instead of hitting next i can type “c” for “continue” and now we’re on it. If we type “n” we can step and see our typo. To exit we can just hit “c” to continue. Now we’ve finished our debugging session. Instead of exiting you could restart it byt typing “restart” and then start this process over again with our breakpoints in place. You can remove a breakpoint if you need to or you can add more. Typing “c” for continue stops at main; continuing again stops at Runme; continuing again exits. This time we will quit. That is the Delve Go debugger!
Delve is just one of the things you will learn in the Go Debugging module from RX-M. You can build your own custom Go course with our course builder. From the top menu, open “Training” and select “Custom Course Builder”. Scrolling down you can see the available courses and modules. Click on “Go” to open up the module selection and drag “Debugging” into your custom course outline.
That’s our cloud native short take on the Go Debugging module!