【问题标题】:Segfault in std::function destructorstd::function 析构函数中的段错误
【发布时间】:2015-04-17 15:29:15
【问题描述】:

我目前正在维护一个用 C++ 开发的 C++ REST 服务器。它提供了一些功能,例如中间件和路由。

路由存储在路由器类的内部结构中:

//! The http router
//!
//! allow us to parse route on a server using regex to match the good route for a given url
//! and extract the possible url variables
class router {
private:
    //! routes datas
    //!
    //! contains:
    //! * the regex to parse the routes
    //! * an std::vector with the list of variable inside the routes
    //! * 4 std::function, one for each REST methods
    struct rest_routes {
        std::regex regex;
        std::vector<std::string> vars_name;
        std::pair<std::function<http::response(http::request&)>, std::vector<std::string>> get;
        std::pair<std::function<http::response(http::request&)>, std::vector<std::string>> post;
        std::pair<std::function<http::response(http::request&)>, std::vector<std::string>> put;
        std::pair<std::function<http::response(http::request&)>, std::vector<std::string>> del;
    };
};

在执行过程中一切正常:可以配置路由并将其添加到路由器,如果有人在现有路由上请求服务器,则执行回调并且服务器按预期发送响应。

这是一个路由配置示例,我们为 HTTP DELETE 请求创建路由 /admin/cameras/:cam_id

// delete a camera
router.del("/admin/cameras/:cam_id",
           std::bind(&admin_service::remove_camera, service, std::placeholders::_1));

在这个例子中,admin_service::remove_camera 是一个成员函数,service 是一个 shared_ptr,包含一个指向 admin_serviceobject 的指针。如果有人请求此路由,则调用admin_service::remove_camera

但是,服务器在执行结束时出现段错误(当我们退出服务器时)。

我已经追踪了段错误的起源,它来自... std::function 的析构函数。更准确地说,它发生在 std::pairs getpostputdel 中包含的 std::function 之一的销毁期间。

我可以这样说是因为,当我输入以下调试代码时:

struct rest_routes {

    ~rest_routes() {
        std::cout << "BEGIN DTOR rest_routes" << std::endl;
        std::cout << "BEGIN get" << std::endl;
        get.first = nullptr;
        std::cout << "END get" << std::endl;
        std::cout << "BEGIN post" << std::endl;
        post.first = nullptr;
        std::cout << "END post" << std::endl;
        std::cout << "BEGIN put" << std::endl;
        put.first = nullptr;
        std::cout << "END put" << std::endl;
        std::cout << "BEGIN del" << std::endl;
        del.first = nullptr;
        std::cout << "END del" << std::endl;
        std::cout << "END DTOR rest_routes" << std::endl;
    }

    std::regex regex;
    std::vector<std::string> vars_name;
    std::pair<std::function<http::response(http::request&)>, std::vector<std::string>> get;
    std::pair<std::function<http::response(http::request&)>, std::vector<std::string>> post;
    std::pair<std::function<http::response(http::request&)>, std::vector<std::string>> put;
    std::pair<std::function<http::response(http::request&)>, std::vector<std::string>> del;
};

我得到以下输出:

BEGIN DTOR rest_routes
BEGIN get
END get
BEGIN post
END post
BEGIN put
END put
BEGIN del
Segmentation Fault

我不知道 std::function 在销毁或赋值期间如何出现段错误...

我首先想到,也许std::function 引用了std::shared_ptr service 而不是按值获取它,并多次删除了它包含的原始指针。但是当我放一些调试输出时,我可以看到shared_ptr 计数器在调用router.del 后递增。

有人知道这个问题吗?

【问题讨论】:

  • I can't figure how a std::function can segfault during destruction or assignment 更进一步,在析构函数中隔离导致段错误的代码行或步骤。然后以此为起点。
  • 这是我在第二个代码引用中所做的:我只是更改了std::function (del.first = nullptr) 中包含的值。它会在分配期间导致段错误。这个赋值运算符调用可能有一些类似于析构函数的操作(如破坏内部属性)。但是我现在已经知道如何走得更远了,除了打开标准库源代码。
  • 尝试将原始指针指向std::function 而不是shared_ptr。像这样... std::bind( &amp;admin_service::remove_camera, service.get(), std::placeholders::_1)
  • 结果是一样的。我也尝试直接传递一个对象(std::bind(&amp;admin_service::remove_camera, *(service.get()), std::placeholders::_1)),但段错误继续发生在同一位置。显然,当我删除路由配置时,程序会正确退出。
  • @SimonNinon del 实例仍然有效吗?这是我可以看到指针分配在哪里崩溃的唯一方法,那就是持有指针的底层对象无效。

标签: c++ c++11 segmentation-fault std-function stdbind


【解决方案1】:

看起来像是内存损坏问题。我会尝试:

  • valgrind 下运行它。如果可能的话,因为valgrind 模拟 CPU,因此应用程序在单个虚拟线程下运行速度慢了约 50 倍。在valgrind 下可能不会显示由竞争条件引起的错误。
  • 通过重新编译和链接-fsanitize=address 命令行选项来使用 gcc/clang address sanitizer。由于它的 overhead 相对较低,因此它的效果非常好:使用 Address Sanitizer 检测的程序的运行速度通常是未检测的对应程序的两倍,并且通常会多消耗 20% 的内存

【讨论】:

    猜你喜欢
    • 1970-01-01
    • 1970-01-01
    • 1970-01-01
    • 2012-02-05
    • 2018-09-24
    • 1970-01-01
    • 1970-01-01
    • 2018-02-14
    • 1970-01-01
    相关资源
    最近更新 更多