Question

我已经为我在Google容器引擎上部署的C ++守护程序包装了libcurl。除了一个小问题外，一切都很棒。每当我拨打curl_slist_free_all()时，它就会出现段错误。它不会发生在Ubuntu 14s或16s上，也不会发生在macOS上。它只发生在Debian 8.7的GKE Docker环境中。这实际上是我唯一的错误，它几周来一直困扰着我。

我用RAII样式容器包装资源句柄以确保异常安全（是的，是的......我使用异常）和泄漏保护。 easy_init和easy_cleanup位于CurlSession构造函数和析构函数中。 global_init＆amp;清理在HTTP构造函数和析构函数中。

我验证了没有双重自由的情况，使用了libcurl代码，并且仍然无法理解为什么这只发生在这个OS环境中。我设法附加一个调试器并将其隔离到单个slist清理调用。

我可以让我的代码工作的唯一方法是泄漏其他所有env，这不是一个交易破坏者，我只是宁愿我的记忆分析器给了我一个干净的健康状况。

任何见解或共同的痛苦都会受到赞赏。

我的标题slist包装：

HTTP::Headers::Headers() : slist{nullptr} {}

HTTP::Headers::Headers(const HeaderKeyValues &headers)
    : slist{nullptr}
{
    for (const auto& header : headers) add(header.first, header.second);
}

HTTP::Headers::~Headers() {
    curl_slist_free_all(slist); // <- seems to crash on Google's Debian image
    slist = nullptr;
};

void HTTP::Headers::add(const std::string& key, const std::string& value) 
{
    std::ostringstream os;
    os << key << ": " << value;

    slist = curl_slist_append(slist, os.str().c_str());
    if (!slist) {
        LOG(fatal) << "Failed appending to header list";
        throw std::runtime_error{"Failed appending to header list"};
    }
}

调度员的子集：

HTTP::Response HTTP::dispatch(const Request& req) const {
    CurlSession session;
    const auto handle = session.handle;

    Headers headerList{req.headers};
    if (req.chunked)
        headerList.add("Transfer-Encoding", "chunked");

    // more ... //

    if (headerList.notEmpty())
        curl_easy_setopt(handle, CURLOPT_HTTPHEADER, headerList.slist);

    // perform the actual request
    CURLcode result = curl_easy_perform(handle);

Answer 1

我怀疑这是Docker构建映像和Docker部署映像之间的某种微妙的不兼容性，只有在GKE上运行时才会出现。

Answer 2

就我而言，就是这样

if ( strcmp(req->headers, ""){
    curl_slist_free_all(list);// segfault
}

if ( strcmp(req->headers, ""){
   // no segfault
}

，而req->headers是NULL，因此，每当我删除curl_slist_free_all行时，作为优化步骤，编译器根本不会为该IF语句生成二进制代码，因此{{ 1}}未被调用，实际上是导致strcmp而不是segfault

的原因

curl_slist_free_all（）导致GKE w / Debian 8.7上的段错误

2 个答案: