Go Program Stops Unexpectedly

Fault Locating

The Go process is not executed according to the design requirements and ends unexpectedly. Error similar to "unexpected fault address and signal SIGSEGV: segmentation violation code=0x32XXXX" is reported. Figure 1 shows how to locate and rectify the fault.

Figure 1 Fault locating of the abnormal Go program stop

1. Confirm that the Go program ends unexpectedly.
2. Run the go mod init {Project folder} command to generate the go.mod file
3. Use the dlv debugging tool to debug the Go program and locate the cause.
4. Modify the code. Compile the code again to verify the modification.
5. Incorporate the code if the verification is successful. The problem is resolved.
6. Add location information to the code if the problem persists. Recompile the code to locate the problem.

Case: Unexpected Program End Caused by Machine Code Difference

Symptom

When software is developed based on the Go language, the test ends unexpectedly after the software is ported to Kunpeng for testing.

Fault Locating

1. Check the error log, as shown in the following figure.

   

   The "unexpected fault address" error is reported, indicating that the program exits unexpectedly.

2. Generate the go.mod file. The subsequent dlv debugging depends on the go.mod file in the project folder.

   1	go mod init main

   

   In the preceding command, main indicates the project folder.

3. Enter the debugging mode. Set breakpoints and perform step-by-step debugging.

   1	dlv debug test.go

   

   In the preceding command, test.go is the source code file.

4. Confirm that a segment of machine code exists in the assembleJump function, as shown in the following figure.

   

   

5. Analyze the code. It can be seen that the code is incorporated into the monkey patch from the open source community. It is mainly used to replace functions.

   For example, the monkey.patch(A, B) processes functions A and B. When function A is executed, function B is actually executed. That is, A () à B ().

6. Trace the machine code. It can be seen that the code comes from the following two assembly statements:

   1 2	mov rdx, main.b.f; jmp [rdx];

   It is used to assign an RDX register to the address of the main.b.f function. The jump instruction jmp is used to jump to the RDX register for execution.

7. Use the Kunpeng assembly instructions to reconstruct related assembly statements and translate them into machine code.

   1 2 3

   mov x10, main.b.f; ldr x11, [x10] br x11;

   

8. Perform the operation in four times. The reason is that the mov instruction can process only 16 bits at a time on the Kunpeng. The x86 platform can process 64 bits at a time, and main.b.f is a 64-bit immediate.

   

9. Recompile and verify the code.

   

   

10. Incorporate the code. The problem is resolved.