我已经为我在Google Container Engine上部署的C++守护进程包装了libcurl。除了一个小问题外,一切都很好。每当我打电话给curl_slist_free_all()
时,它都会出现段错误。它不会发生在 Ubuntu 14s 或 16s 或 macOS 上。它只发生在 Debian 8.7 的 GKE Docker 环境中。这实际上是我唯一的错误,它已经困扰了我数周。
我已经用 RAII 样式容器包装了资源句柄以确保异常安全(是的,是的......我使用例外)和泄漏保护。easy_init和easy_cleanup位于 CurlSession 构造函数和析构函数中。global_init和清理位于HTTP构造函数和析构函数中。
我验证了没有双重自由的情况,探索了 libcurl 代码,但仍然无法理解为什么这只发生在这个操作系统环境中。我设法附加了一个调试器并将其隔离到单个列表清理调用中。
我可以让我的代码工作的唯一方法是泄漏每个其他环境,这不是一个交易破坏者,我只是宁愿我的内存分析器给我一个干净的健康账单。
任何见解或共同的痛苦都值得赞赏。
我的标头列表包装器:
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);