This is a creation in Article, where the information may have evolved or changed. program debugging is very useful for checking and understanding the process and state of the program running. A core dump file contains memory information and process state when the program process runs. It is mainly used to debug the problem of the program, and to understand the state of the program during operation. These are very helpful for diagnosing the cause of the problem and analyzing the service problem in the production environment. In this article, I will use a very simple Hello World Web Application Service example, in fact, our program will be more complex. The analysis of the core dump file is meant to help us look at how the program was running and possibly give us a chance to reproduce the procedural problems of the time. * * NOTE * *: The next operation is performed in the Linux system terminal, I am not sure whether other Unix-like systems work properly, MacOS and Windows should not be supported. Before you begin, you need to make sure that the operating system has open support for core dump files. The default value of ' Ulimit ' is 0 means that the maximum capacity of a core dump file can only be zero. I usually set the ' unlimited ' command on the development machine as follows: $ ulimit-c Unlimited Then, make sure that [delve] (Https://github.com/derekparker/delve) is already installed on your machine. This is a ' main.go ' file that contains an HTTP boot service and a handler function. "' Go$ cat main.gopackage mainimport (" FMT "" Log "" Net/http ") func Main () {http. Handlefunc ("/", Func (w http.) Responsewriter, R *http. Request) {fmt. Fprint (w, "Hello world\n")}) log. Fatal (http. Listenandserve ("localhost:7777", Nil)} "" We compiled it into binary files. $ go build. We assume that there may be problems with this service in the future, but you don't know what's going to happen. You may have used a number of methods to test the program but still can't find the reason why the program exited unexpectedly. Generally in this case, it is best to have a snapshot of the program process at that time, and then debug the snapshot with your debugging tools. There are many ways to get a core dump file for your program. You may already be familiar with the program crash Dump method, which writes the program kernel information to the disk file when the program crashes. Go default is notTurn on program crash dump, but you can set ' gotraceback ' to ' crash ' to turn on Ctrl + backslash generate crash dump file. $ gotraceback=crash./hello (ctrl+\) This allows the program to crash and print the stack trace to the core dump file. Another approach is to generate a core dump file from a running process without having to kill the process. Use the ' gcore ' option to generate a core dump file without crashing. We restarted the program: $./hello & $ gcore 546 # 546 is the PID of hello. We can already get the core dump file without crashing the program. The next step is to load the kernel dump file for analysis by delve. $ DLV core./hello core.546 This is the same as the general usage of delve. You can replay, view the code, view the variables, and so on. Some features are disabled, after all, the core dump file is just a snapshot, not a real process situation, but the execution and process state of the program is fully accessible. (DLV) bt 0 0x0000000000457774 in Runtime.raise at/usr/lib/go/src/runtime/sys_linux_amd64.s:110 1 0x000000000043f7fb in R Untime.diefromsignal at/usr/lib/go/src/runtime/signal_unix.go:323 2 0x000000000043f9a1 in Runtime.crash at/usr/lib/ go/src/runtime/signal_unix.go:409 3 0x000000000043e982 in Runtime.sighandler At/usr/lib/go/src/runtime/signal_ sighandler.go:129 4 0x000000000043f2d1 in Runtime.sigtrampgo at/usr/lib/go/src/runtime/signal_unix.go:257 5 0x00000000004579d3 in Runtime.sigtramp at/usr/lib/go/src/runtime/sys_linux_amd64.s:262 6 0x00007ff68afec330 in (nil) at:0 7 0X000000000040F2D6 in Runtime.notetsleep at/usr/lib/go/src/runtime/lock_futex.go:209 8 0x0000000000435be5 in Runtime.sysmon at/usr/lib/go/src/runtime/proc.go:3866 9 0x000000000042ee2e in Runtime.mstart1 at/usr/lib/go/src/ runtime/proc.go:1182 0x000000000042ed04 in Runtime.mstart at/usr/lib/go/src/runtime/proc.go:1152 (DLV) ls > Runtime.raise ()/usr/lib/go/src/runtime/sys_linux_amd64.s:110 (pc:0x457774) 105:syscall 106:MOVLAX, DI//Arg 1 tid 107: Movlsig+0 (FP), si//Arg 2 108:movl$200, ax//syscall-tkill 109:syscall = 110:ret 111:112:text runtime Raiseproc (SB) , nosplit,$0 113:movl$39, ax//syscall-getpid 114:syscall 115:movlax, di//ARG 1 PID
via:https://rakyll.org/coredumps/
Author: rakyll Translator: jzhongming proofreading: Unknwon
This article by GCTT original compilation, go language Chinese network honor launches
This article was originally translated by GCTT and the Go Language Chinese network. Also want to join the ranks of translators, for open source to do some of their own contribution? Welcome to join Gctt!
Translation work and translations are published only for the purpose of learning and communication, translation work in accordance with the provisions of the CC-BY-NC-SA agreement, if our work has violated your interests, please contact us promptly.
Welcome to the CC-BY-NC-SA agreement, please mark and keep the original/translation link and author/translator information in the text.
The article only represents the author's knowledge and views, if there are different points of view, please line up downstairs to spit groove
1073 reads ∙2 likes
