写出文件时出现奇怪的 glibc 错误答案

【问题标题】：Weird glibc error with writing out a file写出文件时出现奇怪的 glibc 错误
【发布时间】：2012-04-25 23:23:37
【问题描述】：

我收到一个奇怪的错误：

*** glibc detected *** findbasis: free(): invalid next size (normal): 0x0000000006a32ce0 ***

当我尝试 close() 一个 std::ofstream:

void writeEvectors(int l, parameters params, PetscReal* evectors, int basis_size)
{
    for (int n = 1 + l; n <= params.nmax(); n++)
    {
        std::stringstream fname(std::ios::out);
        fname << params.getBasisFunctionFolder() << "/evectors_n" << std::setw(4) << std::setfill('0') << n << "_l" << std::setw(3) << std::setfill('0') << l;
        std::ofstream out(fname.str().c_str(), std::ios::binary);
        std::cerr << "write out file:" << fname.str() << " ...";
        out.write((char*)( evectors + n * basis_size),sizeof(PetscReal) * basis_size);
        std::cerr << "done1" << std::endl;
        if (out.fail() || out.bad())
            std::cerr << "bad or fail..." << std::endl;
        out.close();
        std::cerr << "done2" << std::endl;
    }
    std::cout << "done writing out all evectors?" << std::endl;
}

运行时，该程序永远不会到达“done2”（或“bad or fail...”），但会到达“done1”。此外，写出的数据也很好（如我所料）。

老实说，我不知道为什么会发生这种情况，我想不出“close()”会失败的任何原因。

感谢您的帮助。

（我开始认为这是某种编译器错误/错误。我正在通过 mpicxx 运行 GCC 4.1.2（！）（我相信是 RHEL 5））

【问题讨论】：

来自malloc 或free 的错误通常在它们实际发生后很早就被检测到（如果有的话；它们可能只是段错误）；使用类似 valgrind 的东西来找出实际的无效访问发生在哪里，从而破坏了空闲阻止列表。
嗯。看起来可疑地像一个与内存相关的问题（例如，不小心覆盖了别人的内存）。你确定 evectors + n * basis_size 正在做你想做的事吗？从您的大小参数来看，我会认为像 (char*)(evectors + n) + (char*)(n * basis_size) 或只是 (char*)(evectors + n) 这样的东西是正确的。
Cameron：实际上是一个basis_size x basis_size数组，存储为一维数组。我不得不自己制作 lapack 包装器，这是最简单的方法。
感谢 geekosaur，事实证明，这是在此之前的方式......唯一奇怪的是它一直发生在代码中完全相同的位置（我认为检测会是有点随机，但我猜不是）

标签： c++ glibc

【解决方案1】：

glibc 错误听起来像是释放内存有问题。如果你在 Valgrind 中运行，一个免费的内存分析器，它应该会给你一个更有用的错误解释。

在 Valgrind 中运行相当轻松 - 只需使用 -g 选项编译可执行文件以添加调试标志（假设您使用的是 GNU 编译器），然后在您的 Linux 终端中输入 valgrind ./your_executable 看看会发生什么。

【讨论】：