1.1 Installing dlv

1.2 Disabling Inlining and Optimizations

To debug with dlv, you need to disable the compiler’s inlining and optimizations:

• For Go 1.10 and later, specify -gcflags=”all=-N -l” during compilation

• For Go versions before 1.10, specify -gcflags=”-N -l” during compilation

1.3 Defining Locations in dlv

Most commands in dlv involve locations (referred to as locspec below), and the definition of locations supports the following methods:

• Specify by Go file and line number, formatted as filename:lineNo, for example:

• Specify by package name and function name, formatted as package.function, for example:

• Specify by absolute or relative position in the current file, formatted as lineNo or +offset/-offset, for example:

1.4 Supported Expressions in dlv

Currently, dlv supports expressions (referred to as expr below), including:

• Unary and binary operations for basic types (++ and — are not supported), comparison operations, etc., such as p 1+1, p 1<<2, p 1<2 etc.;

• Type conversions, including conversions between numeric types, conversions between string and []byte, etc., such as p float32(1), p []byte(“aaa”);

• Member access, including access to struct, map, and array type members, such as p mp[“k”], p arr[1]. Note that by default, only 2 levels of data are printed for structs; to access multi-level data, you need to use member access;

• Pointer-related operations, including obtaining access addresses, dereferencing pointers, etc., such as p x.i, p *(x.i) etc.

• Some built-in functions, including cap, len, etc., such as p len(“aaa”);

• Interface type assertions, such as p iface1.(*struct astruct).B or p iface1.(data).B, note that the two expressions are equivalent;

• Some built-in variables, such as p runtime.curg.sched, specific common parameters can be seen in the following table:

Note that the above p command is a shorthand for the print command; for specifics, refer to section 2.3.1

As follows:

1.5 Ways to Start Debugging with dlv

1.5.1 Optional Parameters When Starting Debugging

• Parameter passing, when passing parameters during debugging, you need to use — (its main function is to separate commands and parameters). As follows:

• –headless, –listen start a debug server, set the debug server listening address, –headless, –listen are usually used in conjunction with dlv attach for remote debugging.

Currently, the testing environments (testing, pre) of 123 are connected to the devCloud network, allowing for remote debugging. Refer to section 1.5.3 for operational steps

1.5.2 Ways to Start Debugging

Note that the flags parameter in this section refers to the parameters in 1.5.1.

• #### dlv debug, dlv exec

By default, dlv debug will look for main.main in the current directory, compile it, and start debugging. Its format is as follows:

Note that you can specify the package to debug using package

In contrast, dlv exec requires specifying an executable program. As follows:

• #### dlv attach

dlv provides support for attaching to processes, allowing you to debug running processes. Considering that the network between the 123 testing environment and devCloud has been opened, this mechanism can facilitate remote debugging, as follows:

The steps for remote debugging between 123 and devCloud are:

1. 123 starts the debug server:

   dlv attach pid [flags]
2. devCloud connects to the remote server for debugging:

Note that devCloud can only connect to the testing and pre-release environments of 123, and cannot connect to the production environment. The office network cannot connect to the 123 environment

• #### dlv core

dlv also provides support for core dump debugging, allowing for easy debugging and analysis of online core dumps to identify related issues. Its usage is as follows:

The general steps for using dlv for core dump debugging in Go are:

1. Modify the operating system limits, omitted. Currently, related images have already been configured;

2. Set GOTRACEBACK, for 123 service set the environment variable GOTRACEBACK=crash, as follows:

Note that if the recovery mechanism is enabled at this time, panic within the coroutine will not cause a core dump; at this time, you can check the related reasons in /usr/local/app/serverHistory.log. Note that by default, core dump files will be located in the directory where the executable program resides. If you need to change the location, please modify /proc/sys/kernel/core_pattern

3. Use bt to check the call stack and locate the possible location of the issue.

4. Use the frame command to move to the relevant stack frame and collect various data at the time of the issue using args -v, locals -v, etc.

5. Based on the existing data, locate and analyze the issue.

2.1 Configuring dlv

dlv configuration includes two default methods: command-based and configuration file-based. Note that command-based modifications are session-level, and restarting the debug-related configurations will result in loss of changes.

On Linux, the dlv configuration file is typically located at $HOME/.config/dlv/config.yml, and common configuration items include:

Using substitute-path as an example (different paths for Mac compilation and devCloud debugging), the comparison before and after configuration is as follows:

Before configuration:

2.2 Running Related Commands

2.2.1 restart, exit

restart, exit are used to restart the process and exit debugging, respectively, with the following command formats:

Note that restart only restarts the process and does not actually start debugging. To start debugging, continue needs to be used

Related aliases (abbreviations) are as follows:

2.2.2 continue

continue will run until a breakpoint, location, or program ends, with the following command format:

Note that the continue command supports running directly to a certain line in a file or a certain function

The alias for the continue command is: c.

Its usage is as follows:

2.2.3 next, step, step out

2.3 Breakpoint Related Commands

2.3.1 Breakpoints in dlv

Breakpoints in dlv include the following types:

• trace breakpoints

Trace breakpoints are used to print relevant prompt information when hitting a breakpoint. They are useful when viewing implementations or call paths.

The command format for trace breakpoints is as follows:

Note that trace breakpoints will only print relevant information and will not pause program execution

• break breakpoints

Note that both trace breakpoints and break breakpoints can be named when added

• watch breakpoints

2.3.2 Breakpoint Related Commands

• condition command

The condition (abbreviated as cond) command is used to pause program execution only when the condition is met, for example, when the slice or map to be debugged contains many elements, we only care about one of them. The command is as follows:

Note that the cond command must act on an existing breakpoint

As follows:

• on command

The on command is used to execute some operations when hitting a breakpoint, currently supported operations include: print, stack, goroutine, trace, cond.

The command format is as follows:

Note that the on command can only act on existing breakpoints and can be used for trace breakpoints

For example, when hitting a breakpoint, print some variable values, the specific operation is as follows:

• Other

Other breakpoint-related commands are as follows:

2.4 Variable and Memory Viewing

2.4.1 print

print is used to print the value of a variable or expression, its usage is as follows:

Note that print supports fmt series options, commonly including: %f %x %v %T, etc.

The execution effect is as referenced in 1.4

2.4.2 args, locals, vars

args command is used to print function parameters, its usage is as follows

locals is used to print local variables, its usage is as follows:

vars is used to print package-level variables, its usage is as follows:

Note that vars can print not only custom package-level variables but also built-in package-level variables, such as runtime.curg, etc.

Using args as an example, its output is as follows:

Note that args, locals, vars, etc. are usually used together with dlv core for issue localization and analysis

Using args as an example, its output is as follows:

2.4.3 display

Display related mechanisms are similar to the on command’s print, but the on command supports more functionality than print

2.4.4 set

Note that if the related variable’s set can affect the execution path of the function, the set command needs to be executed in advance

2.4.5 whatis

2.4.6 examinemem

2.5 Stack Related

2.5.1 stack

2.5.2 frame, up, down

2.6 Query Related Commands

2.6.1 Common Query Commands

2.6.2 groutine

2.6.3 list

Goland provides support for dlv related mechanisms.

In Goland, the debug related mechanisms are located in the debug panel, which can be opened via view->tool windows->debug. The debug panel typically includes two parts, used to display goroutine information, stack information, and data information, as follows:

3.1 Breakpoint Related

Goland supports breakpoint-related features, mainly evaluate and log, condition related mechanisms, as follows:

• evaluate and log, print the value of relevant expressions or variables during debugging in the console;

• condition, the program will pause only when hitting a breakpoint && the relevant condition is met.

After adding a breakpoint in Goland, you only need to right-click on the relevant breakpoint and click More in the pop-up dialog to use the related mechanisms:

3.2 Variable and Memory Viewing

3.3 Goroutines and Stack Related