单进程能否动态链接多Go运行时？macOS x86_64崩溃排查

升级到Go 1.21版本后，我将两个采用动态链接方式的Go库接入Swift应用，仅在macOS x86_64平台出现崩溃（ARM或Windows平台无异常）。为复现该场景，我编写了以下测试代码：

库#1 #

package main

/*
#include <stdlib.h>

typedef const char const_char_t;
*/
import "C"
import (
    "fmt"
)

func main() {}

//export GetFirstString
func GetFirstString() *C.const_char_t {
    fmt.Println("Call to golib1.GetFirstString()")
    return C.CString("Hello from golib1")
}

库#2 #

package main

/*
#include <stdlib.h>

typedef const char const_char_t;
*/
import "C"
import (
    "fmt"
)

func main() {}

//export GetSecondString
func GetSecondString() *C.const_char_t {
    fmt.Println("Call to golib2.GetSecondString()")
    s := fmt.Sprintf(`{"data":%s}`, "golib2")

    return C.CString(s)
}

main.cpp #

#include <iostream>

#include "build/libgolib1.h"
#include "build/libgolib2.h"

int main() {
    std::cout << "Starting the test app" << std::endl;

    const char* string1 = GetFirstString();
    std::cout << "First string: " << string1 << std::endl;
    free((void*)string1);

    const char* string2 = GetSecondString();
    std::cout << "Second string: " << string2 << std::endl;
    free((void*)string2);
}

构建命令 #

cd golib1 && go build -o ../build/libgolib1.so -buildmode=c-shared .
cd golib2 && \
    GOTRACEBACK=all \
    GOEXPERIMENT=cgocheck2 \
    go build -o ../build/libgolib2.so -buildmode=c-shared .
clang++ -std=c++20 -g -I. -L./build -o test_app main.cpp \
    -lgolib1 \
    -lgolib2 \
    -framework CoreFoundation \
    -framework Security

实际输出（非必现） #

> DYLD_LIBRARY_PATH=./build ./test_app
Starting the test app
Call to golib1.GetFirstString()
First string: Hello from golib1
write of unpinned Go pointer 0x1c00009a000 to non-Go memory 0xc000190050
fatal error: unpinned Go pointer stored into non-Go memory

runtime stack:
runtime.throw({0x10c370cee?, 0x7ff8123ee54e?})
    /usr/local/Cellar/go/1.22.3/libexec/src/runtime/panic.go:1023 +0x5c fp=0x7ff7b469c460 sp=0x7ff7b469c430 pc=0x10c3091bc
runtime.cgoCheckPtrWrite.func1()
    /usr/local/Cellar/go/1.22.3/libexec/src/runtime/cgocheck.go:68 +0x85 fp=0x7ff7b469c490 sp=0x7ff7b469c460 pc=0x10c2d9b05
runtime.systemstack(0xc000056008)
    /usr/local/Cellar/go/1.22.3/libexec/src/runtime/asm_amd64.s:509 +0x4a fp=0x7ff7b469c4a0 sp=0x7ff7b469c490 pc=0x10c338aca
...

使用环境 #

• go version go1.22.3 darwin/amd64
• Homebrew clang version 18.1.6

补充说明 #

即使不使用fmt包也会出现崩溃问题。

预期输出 #

Starting the test app v2
Call to golib1.GetFirstString()
First string: Hello from golib1
Call to golib2.GetSecondString()
Second string: {"data":golib2}

核心结论 #

不能。Go官方明确不支持在单个进程中运行多个独立的Go运行时实例。每个通过-buildmode=c-shared构建的Go共享库都会包含完整的Go运行时（包括内存分配器、调度器、垃圾回收器等核心组件），当多个这类库被加载到同一进程时，运行时组件会发生冲突，导致内存管理混乱、指针校验失败等未定义行为，这正是你在macOS x86_64上遇到崩溃的根本原因。

崩溃原因分析 #

你遇到的unpinned Go pointer stored into non-Go memory错误，本质是两个独立Go运行时的内存管理边界被打破：

• 每个Go运行时维护自己的堆内存和指针校验规则
• 当一个运行时的指针被错误地写入另一个运行时管理的内存区域（或非Go内存被错误标记），CGO的指针校验机制会触发崩溃
• macOS x86_64平台的内存布局、运行时实现细节加剧了这种冲突，而ARM/Windows平台的内存模型或运行时行为恰好规避了该问题，但这属于偶然现象，不代表该场景合法。

解决方案 #

1. 合并Go库：将两个Go库的功能合并为一个单独的c-shared库，只加载一个Go运行时实例，从根源避免冲突。
2. 使用进程隔离：将其中一个Go库封装为独立进程，通过IPC（如管道、套接字）与主应用通信，彻底隔离两个Go运行时。
3. 静态链接调整：如果业务允许，考虑将Go库静态链接到主程序，但需注意静态链接c-shared库仍会包含完整运行时，多库共存仍会冲突，因此合并库仍是最优解。

临时规避方案（不推荐用于生产） #

如果暂时无法合并库，可以尝试关闭CGO的指针校验（会引入内存安全风险）：

• 构建时添加CGO_CFLAGS="-g -O2 -Wno-pointer-to-int-cast"，或设置GODEBUG=cgocheck=0运行程序
• 该方案仅能掩盖问题，无法解决运行时冲突的根本问题，可能导致更隐蔽的内存错误。

内容的提问来源于stack exchange，提问作者Anton Shkindzer