【问题标题】:Segmentation fault on the second call of the function?第二次调用函数时出现分段错误?
【发布时间】:2018-05-04 12:19:55
【问题描述】:

编辑(解决方案)

我遵循了使用 -fsanitize=address & valgrind 进行调试的建议。我只使用了 -fsanitize (我以前从未听说过)并发现了问题所在,在另一个函数中有一个对析构函数的剩余调用,并且该对象被销毁了两次。此时内存已完全受损。

非常感谢您的帮助和其他建议。


我正在用 C++ 编写代码以使用套接字与 CouchDB 通信(CouchDB 是 Apache 开发的具有 HTTP API 的数据库)。我创建了一个完整的类来处理它,它基本上是一个连接和关闭的套接字客户端。

我的一个功能是发送一个 HTTP 请求,然后读取响应并使用它,它在第一次调用时运行良好,但在我第二次调用时失败。

但它在失败的地方是不一致的,有时它是一个字符串函数中的 SEGFAULT,有时它是返回中的 SIGABORT。我已经用-> 发出了崩溃的信号

最糟糕的是,它仅在运行“第二”次时才会失败,这实际上是第 10 次。说明:当类被实例化时,创建了一个套接字,sendRequest 被调用 8 次(所有工作,总是),我关闭了套接字。然后我有另一个控制套接字服务器的类,它接收命令并创建执行命令的远程用户对象,然后远程用户命令调用 CouchDB 类来操作数据库。第一次请求命令时有效,但第二次失败并导致程序崩溃。

额外信息:在short int httpcode 行中,gdb 跟踪显示substr 上的崩溃,SIGABORT 崩溃跟踪显示free() 上的问题。

我已经调试了很多次,对在哪里以及如何实例化字符串和缓冲区进行了一些更改,但我迷路了。任何人都知道为什么它可以正常工作很多次但在随后的调用中崩溃?

CouchDB::response CouchDB::sendRequest(std::string req_method, std::string req_doc, std::string msg)
{
    std::string responseBody;
    char buffer[1024];
    // zero message buffer
    memset(buffer, 0, sizeof(buffer));

    std::ostringstream smsg;
    smsg << req_method << " /" << req_doc << " HTTP/1.1\r\n"
         << "Host: " << user_agent << "\r\n"
         << "Accept: application/json\r\n"
         << "Content-Length: " << msg.size() << "\r\n"
         << (msg.size() > 0 ? "Content-Type: application/json\r\n" : "")
         << "\r\n"
         << msg;

    /*std::cout << "========== Request ==========\n"
              << smsg.str() << std::endl;*/

    if (sendData((void*)smsg.str().c_str(), smsg.str().size())) {
        perror("@CouchDB::sendRequest, Error writing to socket");
        std::cerr << "@CouchDB::sendRequest, Make sure CouchDB is running in " << user_agent << std::endl;
        return {-1, "ERROR"};
    }

    // response
    int len = recv(socketfd, buffer, sizeof(buffer), 0);

    if (len < 0) {
        perror("@CouchDB::sendRequest, Error reading socket");
        return {-1, "ERROR"};
    }
    else if (len == 0) {
        std::cerr << "@CouchDB::sendRequest, Connection closed by server\n";
        return {-1, "ERROR"};
    }

    responseBody.assign(buffer);
    // HTTP code is the second thing after the protocol name and version
->  short int httpcode = std::stoi(responseBody.substr(responseBody.find(" ") + 1));

    bool chunked = responseBody.find("Transfer-Encoding: chunked") != std::string::npos;
    /*std::cout << "========= Response =========\n"
              << responseBody << std::endl;*/
    // body starts after two CRLF
    responseBody = responseBody.substr(responseBody.find("\r\n\r\n") + 4);

    // chunked means that the response comes in multiple packets
    // we must keep reading the socket until the server tells us it's over, or an error happen
    if (chunked) {
        std::string chunkBody;
        unsigned long size = 1;

        while (size > 0) {
            while (responseBody.length() > 0) {
                // chunked requests start with the size of the chunk in HEX
                size = std::stoi(responseBody, 0, 16);
                // the chunk is on the next line
                size_t chunkStart = responseBody.find("\r\n") + 2;
                chunkBody += responseBody.substr(chunkStart, size);
                // next chunk might be in this same request, if so, there must have something after the next CRLF
                responseBody = responseBody.substr(chunkStart + size + 2);
            }

            if (size > 0) {
                len = recv(socketfd, buffer, sizeof(buffer), 0);

                if (len < 0) {
                    perror("@CouchDB::sendRequest:chunked, Error reading socket");
                    return {-1, "ERROR"};
                }
                else if (len == 0) {
                    std::cerr << "@CouchDB::sendRequest:chunked, Connection closed by server\n";
                    return {-1, "ERROR"};
                }

                responseBody.assign(buffer);
            }
        }
        // move created body from chunks to responseBody
->      responseBody = chunkBody;
    }
    return {httpcode, responseBody};
}

调用上述函数的函数,有时会调用 SIGABORT

bool CouchDB::find(Database::db db_type, std::string keyValue, std::string &value)
{
    if (!createSocket()) {
        return false;
    }
    std::ostringstream doc;
    std::ostringstream json;
    doc << db_name << db_names[db_type] << "/_find";
    json << "{\"selector\":{" << keyValue << "},\"limit\":1,\"use_index\":\"index\"}";
->  CouchDB::response status = sendRequest("POST", doc.str(), json.str());
    close(socketfd);

    if (status.httpcode == 200) {
        value = status.body;
        return true;
    }
    return false;
}

您可能对以下几点有疑问:

  • CouchDB::responsestruct {httpcode: int, body: std::string}
  • CouchDB::dbenum 用于选择不同的数据库
  • sendData 仅将任何内容作为字节发送,直到所有字节都发送完毕

【问题讨论】:

  • 你怎么知道错误不完全是在其他地方,例如破坏内存导致程序在半小时后崩溃?
  • @user4581301 我没有想到这个。我需要对其中一个可能有问题的类进行一些更改,以查看它是否存在。如果您对我如何找到它有任何建议,请告诉我。
  • 老实说,这主要是我在开玩笑,因为您提供了两个 sn-ps 代码,而我们在这里无法知道在输入提供的代码时程序是否正常。目前我的怀疑更多的是recv 调用没有返回你认为的那么多数据。没有失败或断开连接的 recv 可以返回从 0 到 sizeof(buffer) 的任何数量,因此第一个 recv 可能包含的内容太少,您无法找到和读取有效整数或分块标记。它还可能包含您希望在下一个recv 中找到的数据。
  • recv成功时返回接收到的字符数,这个数是必不可少的,使用它。缓冲区没有自动空终止。
  • 也不能保证通过一次调用recv 就能阅读您的整个消息,即使它的大小不大于请求的字符数.

标签: c++ string c++11 segmentation-fault stdstring


【解决方案1】:

设为int len = recv(socketfd, buffer, sizeof(buffer), 0); 可能会覆盖缓冲区中的最后一个'\0'。有人可能会想使用sizeof(buffer) - 1,但这是错误的,因为您可能会在流中得到空字节。所以,改为:responseBody.assign(buffer, len);。当然,只有在您确定了len &gt;= 0 之后才这样做,您在错误检查中会这样做。

你必须在你打电话给recv的每个地方都这样做。不过,为什么你使用recv 而不是read 是我无法理解的,因为你没有使用任何标志。

另外,如果你按照我的方式做,你的缓冲区memset 毫无意义。您还应该在使用之前声明您的缓冲区。我必须通读一半的函数才能确定你是否对它做了任何事情。当然,您最终还是会再次使用它。

哎呀,由于您的错误处理在这两种情况下基本相同,所以我会创建一个函数来完成它。不要重复自己。

最后,您可以使用find 的结果快速轻松地玩。您可能实际上找不到您要查找的内容,而可能会返回 string::npos,这也会给您带来一些有趣的问题。

另外,如果您使用 gcc 或 clang,请尝试 -fsanitize=address(或其中记录的其他一些清理选项)。和/或在 valgrind 下运行它。您的内存错误可能与崩溃的代码相差甚远。这些可能会帮助您接近它。

还有,最后一点。你的逻辑完全混乱。您必须将阅读数据和解析分开,并为每个数据保留不同的状态机。无法保证您的第一次读取会获得整个 HTTP 标头,无论该读取有多大。而且也不能保证您的标头小于某个大小。

您必须继续阅读,直到您阅读的标题超过您愿意阅读的内容并将其视为错误,或者直到您在标题末尾获得 CR LN CR LN。

最后几位不会导致您的代码崩溃,但会导致您收到虚假错误,尤其是在某些流量场景中,这意味着它们可能不会出现在测试中。

【讨论】:

    猜你喜欢
    • 1970-01-01
    • 1970-01-01
    • 1970-01-01
    • 1970-01-01
    • 1970-01-01
    • 1970-01-01
    • 1970-01-01
    • 2022-01-12
    • 1970-01-01
    相关资源
    最近更新 更多