curl_slist_free_all() 在带有 Debian 8.7 的 GKE 上导致段错误
curl_slist_free_all() causes segfault on GKE w/ Debian 8.7
我已经为部署在 Google 容器引擎上的 C++ 守护程序包装了 libcurl。除了一个小问题外,一切都很好。每当我调用 curl_slist_free_all()
时它就会出现段错误。它不会发生在 Ubuntu 14s 或 16s 上,也不会发生在 macOS 上。它只发生在 GKE Docker 环境中的 Debian 8.7。这实际上是我唯一的错误,它已经困扰我好几个星期了。
我已经用 RAII 样式容器包装了资源句柄以实现异常安全(是的,是的...我使用异常)和泄漏保护。 easy_init 和 easy_cleanup 在 CurlSession 构造函数和析构函数中。 global_init 和清理在 HTTP 构造函数和析构函数中。
我验证了没有 double-free 情况,深入研究了 libcurl 代码,但仍然无法理解为什么只在这个 OS 环境中发生这种情况。我设法附加了一个调试器并将其隔离到单个 slist 清理调用。
我可以让我的代码工作的唯一方法是在所有其他环境中泄漏,这不是一个交易破坏者,我只是希望我的内存分析器给我一个干净的健康证明。
感谢任何见解或共同的痛苦。
我的 header 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);
我怀疑这是 Docker 构建映像和 Docker 部署映像之间的某种微妙的不兼容,只有在 GKE 上 运行 时才会出现。
我的情况是这样的
if ( strcmp(req->headers, ""){
curl_slist_free_all(list);// segfault
}
if ( strcmp(req->headers, ""){
// no segfault
}
和 req->headers
是 NULL
,所以每当我删除 curl_slist_free_all
行时,编译器根本不会为这个 IF 语句生成二进制代码作为优化步骤,所以strcmp
未被调用,这才是真正导致 segfault
而不是 curl_slist_free_all(list);
的原因
我已经为部署在 Google 容器引擎上的 C++ 守护程序包装了 libcurl。除了一个小问题外,一切都很好。每当我调用 curl_slist_free_all()
时它就会出现段错误。它不会发生在 Ubuntu 14s 或 16s 上,也不会发生在 macOS 上。它只发生在 GKE Docker 环境中的 Debian 8.7。这实际上是我唯一的错误,它已经困扰我好几个星期了。
我已经用 RAII 样式容器包装了资源句柄以实现异常安全(是的,是的...我使用异常)和泄漏保护。 easy_init 和 easy_cleanup 在 CurlSession 构造函数和析构函数中。 global_init 和清理在 HTTP 构造函数和析构函数中。
我验证了没有 double-free 情况,深入研究了 libcurl 代码,但仍然无法理解为什么只在这个 OS 环境中发生这种情况。我设法附加了一个调试器并将其隔离到单个 slist 清理调用。
我可以让我的代码工作的唯一方法是在所有其他环境中泄漏,这不是一个交易破坏者,我只是希望我的内存分析器给我一个干净的健康证明。
感谢任何见解或共同的痛苦。
我的 header 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);
我怀疑这是 Docker 构建映像和 Docker 部署映像之间的某种微妙的不兼容,只有在 GKE 上 运行 时才会出现。
我的情况是这样的
if ( strcmp(req->headers, ""){
curl_slist_free_all(list);// segfault
}
if ( strcmp(req->headers, ""){
// no segfault
}
和 req->headers
是 NULL
,所以每当我删除 curl_slist_free_all
行时,编译器根本不会为这个 IF 语句生成二进制代码作为优化步骤,所以strcmp
未被调用,这才是真正导致 segfault
而不是 curl_slist_free_all(list);