Linux环境下boost::shared_ptr指向插件对象异常消失引发SIGSEGV问题求助

看起来你遇到的问题是典型的动态库生命周期管理或符号导出不规范导致的，Windows和Linux的动态链接机制差异放大了这个问题。下面是具体的分析和解决方案：

核心原因分析 #

Windows和Linux的动态库加载/卸载逻辑有本质区别：

• Windows下动态库默认导出符号，且卸载后内存不会立即被回收（或访问时的容错性更强）；
• Linux下默认符号是局部的（需要显式导出），且动态库被卸载后，其占用的内存会被立即释放，此时访问原内存地址就会触发SIGSEGV。

你的问题中第一次访问正常、后续崩溃，大概率是插件的动态库被意外卸载，或者符号导出不规范导致shared_ptr指向的内存本身就无效（第一次访问只是巧合没触发崩溃）。

具体排查与修复步骤 #

1. 检查插件的符号导出是否规范 #

这是Linux下最常见的坑：如果插件中的my_plugin_api实现类/实例没有用BOOST_DLL_EXPORT或BOOST_DLL_ALIAS显式导出，boost::dll无法正确获取到符号，返回的shared_ptr可能指向无效内存（第一次访问时内存尚未被覆盖，后续被其他操作占用就崩溃）。

插件代码修复示例：

#include <boost/dll/alias.hpp>
#include "my_plugin_api.hpp"

// 实现插件类
class MyPlugin : public my_plugin_api {
public:
    bool onCommand(const char* command) override {
        // 你的业务逻辑
        return true;
    }
};

// 用BOOST_DLL_ALIAS导出插件实例（对应import时的pluginType参数）
BOOST_DLL_ALIAS(
    MyPlugin(),  // 创建插件实例
    plugin_instance  // 导出名称，需和你loadPlugin中的pluginType参数一致
)

2. 确认动态库的生命周期未被意外终止 #

boost::dll::import返回的shared_ptr自带自定义删除器：当最后一个持有该插件的shared_ptr被销毁时，动态库会被自动卸载。如果你的Plugin容器中的元素被意外删除，或者PluginManager对象被销毁，都会导致库被卸载，后续访问就会崩溃。

排查点：

• 在onCommand函数中打印Plugin.size()，确认容器中的插件实例是否还存在；
• 在loadPlugin和onCommand中打印plugin.use_count()/a->second.use_count()，查看引用计数是否正常（正常情况下至少为1，因为容器持有一个引用）；
• 检查代码中是否有其他地方调用Plugin.erase(pluginName)或清空容器的逻辑。

3. 验证动态库加载路径的正确性 #

虽然你第一次访问正常，但仍需确认libPath / pluginName加上append_decorations后是否正确指向了目标.so文件。可以在import前添加路径打印：

boost::filesystem::path fullPluginPath = libPath / pluginName;
std::cout << "Attempting to load plugin from: " << fullPluginPath << std::endl;

然后手动检查该路径下的.so文件是否存在，用ldd命令验证其依赖是否完整：

ldd your_plugin.so

4. 排查线程安全问题 #

如果你的程序是多线程的，且多个线程同时操作Plugin容器（比如一个线程卸载插件，另一个线程查找访问），Linux下更激进的线程调度会触发Windows下不易出现的竞态条件，导致迭代器失效或元素被意外删除。

修复方案：
给Plugin容器加锁保护，比如在loadPlugin和onCommand中使用std::mutex：

#include <mutex>

class PluginManager {
private:
    std::map<std::string, boost::shared_ptr<my_plugin_api>> Plugin;
    std::mutex pluginMutex;  // 新增互斥锁
public:
    bool loadPlugin(...) {
        std::lock_guard<std::mutex> lock(pluginMutex);
        // 原loadPlugin逻辑
    }

    bool onCommand(...) {
        std::lock_guard<std::mutex> lock(pluginMutex);
        // 原onCommand逻辑
    }
};

5. 提前校验shared_ptr的有效性 #

在loadPlugin中添加对plugin的空指针检查，避免无效指针被存入容器：

plugin = boost::dll::import<my_plugin_api>(...);
if (!plugin) {
    std::cerr << "Failed to obtain valid plugin instance for " << pluginName << std::endl;
    return false;
}
Plugin.insert({pluginName, plugin});

关于boost::shared_ptr的兼容性问题 #

boost::shared_ptr和std::shared_ptr是兼容的，如果你后续想切换到std::shared_ptr，可以直接转换：

std::shared_ptr<my_plugin_api> std_plugin = boost::static_pointer_cast<my_plugin_api>(plugin);

不过这不是你当前问题的根源，先解决前面的符号导出和生命周期问题即可。

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