多次dlopen、dlclose含Go代码的共享库触发段错误问题咨询

崩溃原因 #

核心问题是Go运行时本身不支持动态卸载后重新初始化，你将Go代码编译的静态库打包进mylib.so时，Go运行时也被一并包含在共享库中，具体触发流程如下：

• 首次调用dlopen加载mylib.so时，Go运行时完成正常初始化，导出函数调用、dlclose流程都能正常执行
• 首次dlclose执行时，mylib.so的地址空间被系统回收，但Go运行时没有设计对应动态卸载的清理逻辑，其运行过程中注册的信号处理函数、创建的后台线程、申请的全局状态内存等资源会残留无效的悬空状态
• 第二次调用dlopen重新加载mylib.so时，加载器会尝试重新初始化Go运行时，和前一次残留的无效状态冲突，直接触发段错误。

现有现象的解释 #

• 加RTLD_NODELETE参数后运行正常：该标志会通知动态加载器，就算调用dlclose也不要释放共享库的地址空间，首次加载后的Go运行时状态会一直保留，后续dlopen仅会增加共享库的引用计数，不会触发重新初始化，自然不会出现冲突。
• 移除-Wl,-Bsymbolic后报符号冲突：该编译参数的作用是让共享库优先使用内部定义的符号，而非全局已加载的符号，去掉后第二次加载mylib.so做符号重定位时，Go运行时的全局符号会和第一次残留的符号重名冲突。

方案选型建议 #

• RTLD_NODELETE方案是合理的：只要你的业务不需要频繁加载卸载大量不同的Go编译共享库，常驻的Go运行时内存占用一般仅几十MB，绝大多数场景下都可以接受，没有明显副作用。
• 更优的替代方案：
  • 如果业务逻辑允许，不要循环重复加载卸载同一个共享库，程序启动时一次加载完成后重复调用导出函数，进程退出前再统一执行dlclose，从根源避免多次初始化的问题
  • 如果确实需要每次执行完完全清理状态，可将Go逻辑封装为独立的可执行文件，每次需要执行时启动子进程运行，执行完成后子进程退出，所有资源会被系统自动回收，不会有状态残留问题。

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