Shulou(Shulou.com)11/24 Report--

There is no silver bullet to destroy everything, and there is no program that can guarantee that it will never go wrong. How should we catch Go program errors? I think the students' first reaction is to log in.

But the ability of error logging is limited. First, the log is the print information defined by the developer in the code, and there is no guarantee that the log information will contain all the error conditions. Second, when panic occurs in Go programs, we are not always able to capture it through recover (there is no way to insert log code).

Is there any other way to troubleshoot when the log record does not cover the error scene after the online Go program suddenly crashes?

Core dumpcore dump, also known as core dump, is simply a snapshot of memory generated when a program terminates unexpectedly. We can debug the program through the core dump file to find out the cause of its crash.

On the linux platform, you can view the core dump configuration through the ulimit-c command. The system defaults to 0, indicating that core dump logging is not enabled.

$ulimit-c0 can use the ulimit-c [size] command to specify the size of the record core dump file, that is, to open the core dump record. Of course, if you have enough computer resources to avoid core dump loss or incomplete records, you can also execute ulimit-c unlimited without limiting the size of the core dump file.

So how to open core dump in the Go program?

GOTRACEBACK We discussed the dark magic of turning string into [] byte in the article do you really understand the conversion between string and [] byte, as shown in the following example.

Package mainimport ("reflect"unsafe") func String2Bytes (s string) [] byte {sh: = (* reflect.StringHeader) (unsafe.Pointer (& s)) bh: = reflect.SliceHeader {Data: sh.Data, Len: sh.Len, Cap: sh.Len } return * (* [] byte) (unsafe.Pointer (& bh))} func Modify () {a: = "hello" b: = String2Bytes (a) b [0] ='H'} func main () {Modify ()} string cannot be modified When we change the string type to [] byte through dark magic and attempt to change its value, the program will have an error that cannot be caught by recover.

$go run main.gounexpected fault address 0x106a6a4fatal error: fault [signal SIGBUS: bus error code=0x2 addr=0x106a6a4 pc=0x105b01a] goroutine 1 [running]: runtime.throw ({0x106a68b 0x0}) / usr/local/go/src/runtime/panic.go:1198 + 0x71 fp=0xc000092ee8 sp=0xc000092eb8 pc=0x102bad1runtime.sigpanic () / usr/local/go/src/runtime/signal_unix.go:732 + 0x1d6 fp=0xc000092f38 sp=0xc000092ee8 pc=0x103f2f6main.Modify (...) / Users/slp/github/PostDemo/coreDemo/main.go:21main.main () / Users/slp/github/PostDemo/coreDemo/main.go:25 + 0x5a fp=0xc000092f80 sp=0xc000092f38 pc=0x105b01aruntime.main () / usr/local/go/src/runtime/proc.go: The stack information of 0x227 fp=0xc000092fe0 sp=0xc000092f80 pc=0x102e167runtime.goexit () / usr/local/go/src/runtime/asm_64.s:1581 + 0x1 fp=0xc000092fe8 sp=0xc000092fe0 pc=0x1052dc1exit status 2 is controlled by the GOTRACEBACK variable. It has five levels.

None, showing no goroutine stack information

Single, default level, displays current goroutine stack information

All, displaying goroutine stack information created by all user (excluding runtime)

System, displaying all goroutine stack information created by user + runtime

Crash, which is consistent with system printing, but generates an core dump file (on Unix systems, a crash can trigger SIGABRT to trigger core dump)

If we set GOTRACEBACK to system, we will see all the goroutine status information when the program crashes

$GOTRACEBACK=system go run main.gounexpected fault address 0x106a6a4fatal error: fault [signal SIGBUS: bus error code=0x2 addr=0x106a6a4 pc=0x105b01a] goroutine 1 [running]: runtime.throw ({0x106a68b, 0x0})... goroutine 2 [force gc (idle)]: runtime.gopark (0x0, 0x0, 0x0, 0x0, 0x0). Created by runtime.init.7 / usr/local/go/src/runtime/proc.go:294 + 0x25goroutine 3 [GC sweep wait]: runtime.gopark (0x0, 0x0, 0x0, 0x0) 0x0)... created by runtime.gcenable / usr/local/go/src/runtime/mgc.go:181 + 0x55goroutine 4 [GC scavenge wait]: runtime.gopark (0x0, 0x0, 0x0, 0x0, 0x0)... created by runtime.gcenable / usr/local/go/src/runtime/mgc.go:182 + 0x65exit status 2 if you want to get core dump files Then you should set the GOTRACEBACK value to crash. Of course, we can also set the stack print level through the SetTraceback method in the runtime / debug package.

Delve debugging delve is a Go program debugger written in Go language. We can debug core dump through the dlv core command.

First, install delve with the following command

Go get-u github.com/go-delve/delve/cmd/dlv still takes the example above as an example. We get the core dump file by setting GOTRACEBACK to the crash level.

$tree. └── main.go$ ulimit-c unlimited$ go build main.go$ GOTRACEBACK=crash. / main...Aborted (core dumped) $tree. ├── core ├── main └── main.go$ ls-alh core-rw- 1 slp slp 41m Oct 31 22:15 core at this time, the core dump file core is obtained in the same directory (the file name, storage path, and whether or not to add the process number can be configured and modified).

Debug the core file through the dlv debugger, execute the command format dlv core executable file name core file

$dlv core main coreType 'help' for list of commands. (dlv) commands goroutines to get all goroutine related information

Dlv) goroutines* Goroutine 1-User:. / main.go:21 main.main (0x45b81a) (thread 18061) Goroutine 2-User: / usr/local/go/src/runtime/proc.go:367 runtime.gopark (0x42ed96) [force gc (idle)] Goroutine 3-User: / usr/local/go/src/runtime/proc.go:367 runtime.gopark (0x42ed96) [GC sweep wait] Goroutine 4-User: / usr/local/go/src/runtime/proc. Go:367 runtime.gopark (0x42ed96) [GC scavenge wait] [4 goroutines] dlv) Goroutine 1 is the problem goroutine (with * for the current frame) Switch to its stack frame with the command goroutine 1

Dlv) goroutine 1Switched from 1 to 1 (thread 18061) dlv) execute the command bt (breakpoints trace) to view the current stack frame details

(dlv) bt0 0x0000000000454bc1 in runtime.raise at / usr/local/go/src/runtime/sys_linux_64.s:1651 0x0000000000452f60 in runtime.systemstack_switch at / usr/local/go/src/runtime/asm_64.s:3502 0x000000000042c530 in runtime.fatalthrow at / usr/local/go/src/runtime/panic.go:12503 0x000000000042c2f1 in runtime.throw at / usr/local/go/src/runtime/panic.go:11984 0x000000000043fa76 in runtime.sigpanic at / usr/local/go/src/ Runtime/signal_unix.go:7425 0x000000000045b81a in main.Modify at. / main.go:216 0x000000000045b81a in main.main at. / main.go:257 0x000000000042e9c7 in runtime.main at / usr/local/go/src/runtime/proc.go:2558 0x0000000000453361 in runtime.goexit at / usr/local/go/src/runtime/asm_64.s:1581 (dlv) found the function where the error code is located through 5 0x000000000045b81a in main.Modify Execute the command frame 5 to enter the specific code of the function

Dlv) frame 5 > runtime.raise () / usr/local/go/src/runtime/sys_linux_64.s:165 (PC: 0x454bc1) Warning: debugging optimized functionFrame 5:. / main.go:21 (PC: 45b81a) 16: 17: 18: func Modify () {19: a: = "hello" 20: B: = String2Bytes (a) = > 21: B [0] ='H' 22: 23: 24: Func main () {25: Modify () 26: dlv) since then If the case is solved, the problem lies in modifying the underlying value of string without authorization.

One thing to note that Mac can't be used is that I finished the example generated by core dump above under the linux system, and the mac amd64 system can't do it (very angry, it took me two nights).

This is because Go under the mac system restricts the generation of core dump files, which is explained in the Go source code src / runtime / signal_unix.go.

/ / go:nosplitfunc crash () {/ / OS X core dumps are linear dumps of the med memory, / / from the first virtual byte to the last, with zeros in the gaps / / Because of the way we arrange the address space on 64-bit systems, / / this means the OS X core file will be 128GB and even on a zippy / / workstation can take OS X well over an hour to write (uninterruptible). / / Save users from making that mistake. If GOOS = = "darwin" & & GOARCH = = "64" {return} dieFromSignal (_ SIGABRT)} Summary core dump file is a sharp weapon provided to us by the operating system, which is a memory snapshot generated when the program terminates unexpectedly. With core dump, we can better recover the accident scene after the program crashes and protect us for troubleshooting.

Of course, the generation of core dump files also has drawbacks. The core dump file is large, and if the online service itself has a high memory footprint, it will cost a lot of memory and time to generate the core dump file. In addition, we tend to deploy service daemons, and if our program crashes and restarts frequently, it will generate a large number of core dump files (core+pid naming rules are set), resulting in the risk of disk filling (if the kernel restriction ulimit-c unlimited is released).

Finally, if worrying about error logs won't help us locate problems with Go code, we can turn on core dump for it and add Raiders to hotfix. For services with daemons, it is recommended that you set a ulimt-c size limit.

This article comes from the official account of Wechat: Golang Technology sharing (ID:GolangShare), author: machine bell chopping kitchen knife

Welcome to subscribe "Shulou Technology Information " to get latest news, interesting things and hot topics in the IT industry, and controls the hottest and latest Internet news, technology news and IT industry trends.