ARM CortexA9架构下Go通过CGO调用Clips库运行时触发SIGSEGV段错误

我正在构建可运行在CortexA9 CPU上的Go应用，该应用调用3个不同的C/C共享库（我通过C封装调用C代码），调用其中Clips规则引擎时偶发SIGSEGV, Segmentation fault错误。该库是经过长期验证的成熟库，且相同代码在amd64架构下运行正常。错误触发位置随机性强，修改代码规避特定行后，错误会出现在其他函数内部。

库的编译方式 #

我使用arm-buildroot-linux-gnueabi工具链，C编译器为arm-buildroot-linux-gnueabihf-gcc，编译CFLAGS为：-Wall -std=c99 -O3 -fno-strict-aliasing -fPIC -march=armv7-a -mcpu=cortex-a9 -mfpu=neon -mfloat-abi=hard --sysroot=${some path}
若用该工具链将Clips编译为独立二进制文件，运行规则测试一切正常。

Go应用编译方式 #

我在内置了对应工具链的docker golang:1.16-buster镜像中编译应用
编译命令为：go clean && env CGO_CFLAGS="-march=armv7-a -mfpu=neon -mfloat-abi=hard -mtune=cortex-a9 --sysroot={some path}" CGO_ENABLED=1 GOOS="linux" GOARM=7 GOARCH=arm go build --tags=with_libs,arm -o ./out/$app_name .
CC变量设置为arm-buildroot-linux-gnueabihf-gcc
项目中通过如下arm.go文件引入库：

// +build arm

package clips

// #cgo LDFLAGS: -L../../libs/arm -lclips -lm -Wl,-rpath -Wl,../libs/arm
import "C"

程序运行过程中无异常信号抛出。

应用运行过程中，通过cgo调用so库时收到gdb报错：
Thread 1 "myapp-arm" received signal SIGSEGV, Segmentation fault.

gdb回溯栈如下：

#0  0x76d6fa6c in PrintTemplateFact (theEnv=0x4c8b90, logicalName=0x76d79184 "FactPPForm", theFact=0x4c6dd8, seperateLines=0, ignoreDefaults=0) at /myapp/clips_source/tmpltutl.c:387
#1  0x76cbfa70 in PrintFact (theEnv=0x4c8b90, logicalName=0x76d79184 "FactPPForm", factPtr=0x4c6dd8, seperateLines=0, ignoreDefaults=0) at /myapp/clips_source/factmngr.c:445
#2  0x76cbf704 in PrintFactWithIdentifier (theEnv=0x4c8b90, logicalName=0x76d79184 "FactPPForm", factPtr=0x4c6dd8) at /myapp/clips_source/factmngr.c:328
#3  0x76cc1950 in EnvGetFactPPForm (theEnv=0x4c8b90, buffer=0x535290 "f--1    (attribute (id ) (comment ) (code ) (path", bufferLength=1023, theFact=0x4c6dd8) at /myapp/clips_source/factmngr.c:1590
#4  0x002661e8 in _cgo_4cadad88d928_Cfunc_EnvGetFactPPForm ()
#5  0x000823d8 in runtime.asmcgocall () at /usr/local/go/src/runtime/asm_arm.s:596
#6  0x00a16050 in ?? ()

gdb汇编信息如下：

...
   0x76d6fa3c <+616>:   mov r2, r1
   0x76d6fa40 <+620>:   ldr r1, [r11, #-60] ; 0xffffffc4
   0x76d6fa44 <+624>:   ldr r0, [r11, #-56] ; 0xffffffc8
   0x76d6fa48 <+628>:   bl  0x76c68edc <PrintAtom@plt>
   0x76d6fa4c <+632>:   b   0x76d6fad0 <PrintTemplateFact+764>
   0x76d6fa50 <+636>:   ldr r3, [r11, #-8]
   0x76d6fa54 <+640>:   lsl r3, r3, #3
   0x76d6fa58 <+644>:   ldr r2, [r11, #-24] ; 0xffffffe8
   0x76d6fa5c <+648>:   add r3, r2, r3
   0x76d6fa60 <+652>:   ldr r3, [r3, #4]
   0x76d6fa64 <+656>:   str r3, [r11, #-28] ; 0xffffffe4
   0x76d6fa68 <+660>:   ldr r3, [r11, #-28] ; 0xffffffe4
=> 0x76d6fa6c <+664>:   ldr r3, [r3, #4]
   0x76d6fa70 <+668>:   cmp r3, #0
   0x76d6fa74 <+672>:   ble 0x76d6fad0 <PrintTemplateFact+764>
   0x76d6fa78 <+676>:   ldr r3, [pc, #232]  ; 0x76d6fb68 <PrintTemplateFact+916>
   0x76d6fa7c <+680>:   add r3, pc, r3
   0x76d6fa80 <+684>:   mov r2, r3
   0x76d6fa84 <+688>:   ldr r1, [r11, #-60] ; 0xffffffc4
   0x76d6fa88 <+692>:   ldr r0, [r11, #-56] ; 0xffffffc8
   0x76d6fa8c <+696>:   bl  0x76c68c3c <EnvPrintRouter@plt>
   0x76d6fa90 <+700>:   ldr r3, [r11, #-8]
...

仅运行如下最简测试代码也会触发SEGFAULT：

func SelfHealthCheck(deftemplate string) {
    env := C.CreateEnvironment()

    // Create deftemplate
    cconstruct := C.CString(deftemplate)
    defer C.free(unsafe.Pointer(cconstruct))
    if C.EnvBuild(env, cconstruct) != 1 {
        log.Println("error")
        return
    }

    // Obtain pointer on it
    cname := C.CString("attribute")
    defer C.free(unsafe.Pointer(cname))
    tplptr := C.EnvFindDeftemplate(env, cname)
    if tplptr == nil {
        log.Println("error")
        return
    }

    // Create fact
    factptr := C.EnvCreateFact(env, tplptr)

    // print it
    var bufsize C.size_t = 1024
    buf := (*C.char)(C.malloc(C.sizeof_char * bufsize))
    defer C.free(unsafe.Pointer(buf))
    C.EnvGetFactPPForm(env, buf, bufsize-1, unsafe.Pointer(factptr))
    log.Infoln(C.GoString(buf))
}

核心原因推断 #

1. ARM栈对齐问题：这是该场景下最高概率的诱因。ARMv7架构要求函数调用时栈必须8字节对齐，但Go 1.16版本的runtime在ARM架构下的CGO调用场景中，存在栈对齐处理缺陷，默认只保证4字节对齐。当C侧代码（尤其是带NEON指令、需要8字节对齐变量的逻辑）运行在未对齐的栈上时，就会出现随机段错误，这也符合“错误位置随机、纯C二进制运行正常”的特征。
2. 编译参数不一致：编译Clips库时用了-mcpu=cortex-a9指定CPU特性，而CGO_CFLAGS里仅用了-mtune=cortex-a9做调度优化，两者指令集生成规则存在差异，可能生成不兼容的二进制代码。
3. O3激进优化问题：Clips编译用的O3优化在ARM架构下可能生成了带有对齐假设的代码，和CGO运行环境不兼容。

排查修复步骤 #

• 第一步：统一编译参数，将CGO_CFLAGS中的-mtune=cortex-a9替换为-mcpu=cortex-a9，和库的编译参数完全对齐，同时添加-mstack-alignment=8强制栈8字节对齐，重新编译Go程序测试。
• 第二步：调整Clips编译优化级别，将-O3改为-O2或者-O0，排除激进优化导致的未定义行为。
• 第三步：在测试代码的CGO调用逻辑开头添加runtime.LockOSThread()，将当前goroutine绑定到系统线程，避免Go调度切换导致的上下文问题，同时增加EnvCreateFact的返回值空判断，排除空指针调用风险。
• 第四步：如果上述操作仍未解决，建议升级Go版本到1.17及以上，该版本修复了大量ARM架构下CGO的栈对齐相关缺陷。

内容的提问来源于stack exchange，提问作者Kirill Solokhov