C++11环境调用Go封装的MinIO API出现崩溃问题排查

问题背景 #

由于运行环境仅支持C11，无法直接使用要求C17的MinIO-CPP客户端，因此将minio-go客户端封装为C库供C++程序调用。但程序在正常执行几次Put操作后崩溃，崩溃发生在minioClient.PutObject调用阶段，崩溃日志显示Go runtime的GC扫描栈时出现异常。

相关代码 #

Go封装的C导出函数 #

//export SPut
func SPut(bucketName *C.char, objectName *C.char, data unsafe.Pointer, dataLen C.long) C.long {

  // byteSlice := (*[1 << 30]byte)(unsafe.Pointer(data))[:dataLen:dataLen]
  // byteSlice := C.GoBytes(unsafe.Pointer(data), C.int(dataLen))
  byteSlice := unsafe.Slice((*byte)(data), int64(dataLen))
  
  fmt.Printf("put start\n")
  _, err := minioClient.PutObject(context.TODO(), C.GoString(bucketName), C.GoString(objectName), bytes.NewReader(byteSlice), int64(dataLen), minio.PutObjectOptions{})
  fmt.Printf("put done\n")

  if err != nil {
    log.Printf("Failed to write data to MinIO: %v, name = %v\n", err, objectName)
    return -1
  } else {
    return 0;
  }
}

C++调用代码 #

size_t dataLen = 10*1024*1024;
char *data = new char[10*1024*1024];
...
SPut("test-bucket", "test-data", data, dataLen);
...

崩溃日志 #

runtime: g28: frame.sp=0xc000073750 top=0xc0000737e0
        stack=[0xc000073000-0xc000073800
fatal error: traceback did not unwind completely

runtime stack:
runtime.throw({0x7f67fa738331?, 0x0?})
        /softs-lhaaso/tests/go/src/runtime/panic.go:1077 +0x5e fp=0x7f65fa7f2478 sp=0x7f65fa7f2448 pc=0x7f67fa48a17e
runtime.(*unwinder).finishInternal(0x7f65fa7f2520?)
        /softs-lhaaso/tests/go/src/runtime/traceback.go:571 +0x12a fp=0x7f65fa7f24b8 sp=0x7f65fa7f2478 pc=0x7f67fa4ad90a
runtime.(*unwinder).next(0x7f65fa7f26e0?)
        /softs-lhaaso/tests/go/src/runtime/traceback.go:452 +0x232 fp=0x7f65fa7f2530 sp=0x7f65fa7f24b8 pc=0x7f67fa4ad712
runtime.scanstack(0xc0003221a0, 0x7f67fa472054?)
        /softs-lhaaso/tests/go/src/runtime/mgcmark.go:802 +0x272 fp=0x7f65fa7f2868 sp=0x7f65fa7f2530 pc=0x7f67fa4730f2
runtime.markroot.func1()
        /softs-lhaaso/tests/go/src/runtime/mgcmark.go:240 +0xb5 fp=0x7f65fa7f28b8 sp=0x7f65fa7f2868 pc=0x7f67fa471f75
runtime.markroot(0xc00003b240, 0x33, 0x1)
        /softs-lhaaso/tests/go/src/runtime/mgcmark.go:214 +0x1a8 fp=0x7f65fa7f2960 sp=0x7f65fa7f28b8 pc=0x7f67fa471c08
runtime.gcDrain(0xc00003b240, 0x3)
        /softs-lhaaso/tests/go/src/runtime/mgcmark.go:1069 +0x37d fp=0x7f65fa7f29c0 sp=0x7f65fa7f2960 pc=0x7f67fa473b5d
runtime.gcBgMarkWorker.func2()
        /softs-lhaaso/tests/go/src/runtime/mgc.go:1366 +0xa5 fp=0x7f65fa7f2a10 sp=0x7f65fa7f29c0 pc=0x7f67fa4702c5
traceback: unexpected SPWRITE function runtime.systemstack
runtime.systemstack()
        /softs-lhaaso/tests/go/src/runtime/asm_amd64.s:509 +0x47 fp=0x7f65fa7f2a20 sp=0x7f65fa7f2a10 pc=0x7f67fa4b9b67

goroutine 47 [GC worker (active)]:
runtime.systemstack_switch()
        /softs-lhaaso/tests/go/src/runtime/asm_amd64.s:474 +0x8 fp=0xc0002a0750 sp=0xc0002a0740 pc=0x7f67fa4b9b08
runtime.gcBgMarkWorker()
        /softs-lhaaso/tests/go/src/runtime/mgc.go:1353 +0x1f6 fp=0xc0002a07e0 sp=0xc0002a0750 pc=0x7f67fa46ff56
runtime.goexit()
        /softs-lhaaso/tests/go/src/runtime/asm_amd64.s:1650 +0x1 fp=0xc0002a07e8 sp=0xc0002a07e0 pc=0x7f67fa4bbb01
created by runtime.gcBgMarkStartWorkers in goroutine 7
        /softs-lhaaso/tests/go/src/runtime/mgc.go:1217 +0x1c
...

已尝试的操作 #

尝试了三种将C内存转换为Go内存的方式，但问题未解决：

// byteSlice := (*[1 << 30]byte)(unsafe.Pointer(data))[:dataLen:dataLen]
// byteSlice := C.GoBytes(unsafe.Pointer(data), C.int(dataLen))
byteSlice := unsafe.Slice((*byte)(data), int64(dataLen))

可能的原因及解决方案 #

1. Go runtime对非Go线程的支持问题 #

崩溃日志显示GC扫描栈时出现异常，核心原因是C++线程并非由Go runtime创建，Go无法正确管理该线程的栈结构和GC标记。当Go代码在非Go线程中执行时，runtime无法确保栈的完整性，GC扫描时会出现栈回溯失败的错误。

解决方案：

• 避免直接在C线程中调用Go导出的耗时函数（如PutObject），改为由Go启动goroutine处理请求，C仅传递参数并等待结果。可以在Go中初始化一个工作池，C++调用导出函数时将任务发送到通道，由goroutine异步执行。
• 若必须在C线程中调用，可在Go导出函数开头调用runtime.LockOSThread()，将当前C线程与Go runtime绑定，但这种方式仍存在风险，不推荐用于高并发场景。

2. minioClient的线程安全性问题 #

如果多个C++线程同时调用SPut函数，而全局的minioClient并非线程安全的，会导致内部状态混乱，进而引发内存错误。

解决方案：

• 为每个C++线程创建独立的minioClient实例，或者在SPut函数中对minioClient的访问加锁（如使用sync.Mutex）。

3. 内存生命周期不一致 #

虽然尝试了内存转换，但如果C在Go仍在使用data内存时提前释放（比如delete[] data），会导致Go访问无效内存。即使使用unsafe.Slice或切片转换，Go仍会直接引用C内存，一旦C释放，就会出现野指针。

解决方案：

• 强制使用C.GoBytes复制C内存到Go堆中，确保Go完全拥有内存所有权，同时手动释放C堆内存避免泄漏：

  byteSlice := C.GoBytes(unsafe.Pointer(data), C.int(dataLen))
  defer C.free(unsafe.Pointer(&byteSlice[0]))
  

4. Go栈大小限制 #

Go runtime默认的栈大小对于C++线程可能不足，尤其是PutObject涉及大量IO操作，可能导致栈溢出或布局异常。

解决方案：

• 将耗时操作放到goroutine中执行，goroutine的栈会自动扩容；也可在Go代码中通过runtime.StackSize显式设置栈大小。

内容的提问来源于stack exchange，提问作者Minhao Gu