0

最终编辑：这原来是与字符串函数和 malloc 无关的堆栈溢出问题。GDB 输出说问题出在它的位置上方几行，这让我感到困惑，但是当我花时间在 Valgrind 中运行时，我就明白了。

我编写了一个双向广度优先搜索程序，用于在一个非常大的有向图（约 600 万个节点）中查找最短路径。使用 100 个节点的测试输入文件，一切正常。有了完整的输入，就会使用更多的内存，然后程序就会出现分段错误。

GDB 说它在搜索功能开始时出现段错误，当我在n = sprintf(result, "");. 这是相关的功能：

char *bidirbfs(int x, int y, char *result){
    int n;
    n = sprintf(result, "");
    ...

这是对它的调用和result缓冲区的分配：

int main (){
    int n=0;
    char *result;
    result = (char *)malloc(sizeof(char)*2000);
    if(result == NULL){
        printf("MALLOC FAILED!"); exit(1);}

    //Methods for initializing graph
    readStructureFromFile(); 
    calcArticlesIn();

    //Search the graph
    result = bidirbfs(1,2, result);
    printf("%s\n", result);
    ...
}

同样，只需少量输入，一切正常。当我使用全尺寸输入时，程序可以正常读取所有内容，但随后会出现段错误。当我改为使用非常相似的 strncpy 调用来清空数组时，我得到了相同的行为，所以这似乎是一个普遍的问题带字符串函数。我不确定会发生什么。

似乎 sprintf 不喜欢它得到的指针，这让我想知道 malloc 是否在做一些奇怪的事情。使用完整输入时，malloc 被调用了 1300 万次*，所以我想知道它是否会因此而表现出奇怪的行为，并用奇怪的东西覆盖字符串缓冲区。同时，我也很犹豫要怪图书馆。

任何想法可能会发生什么？

*可悲的是，我认为这实际上是必要的。图中的每个元素都有一个用于入站边和出站边的数组。在读取输入之前，每个数组的大小都是未知的，因此必须通过 malloc 将其动态分配到正确的大小。

编辑： Valgrind 返回以下内容。我正在努力弄清楚它可能意味着什么，但乍一看它实际上可能是某种堆栈溢出。

==27263== Warning: client switching stacks?  SP change: 0xbea50634 --> 0xbb815340
==27263==          to suppress, use: --max-stackframe=52671220 or greater
==27263== Invalid write of size 4
==27263==    at 0x8048D78: bidirbfs (load_data.c:184)
==27263==    by 0x80491CD: main (load_data.c:304)
==27263==  Address 0xbb815348 is on thread 1's stack
==27263== 
==27263== 
==27263== Process terminating with default action of signal 11 (SIGSEGV)
==27263==  Access not within mapped region at address 0xBB815348
==27263==    at 0x8048D78: bidirbfs (load_data.c:184)
==27263==  If you believe this happened as a result of a stack
==27263==  overflow in your program's main thread (unlikely but
==27263==  possible), you can try to increase the size of the
==27263==  main thread stack using the --main-stacksize= flag.
==27263==  The main thread stack size used in this run was 8388608.
==27263== 
==27263== Process terminating with default action of signal 11 (SIGSEGV)
==27263==  Access not within mapped region at address 0xBB81533C
==27263==    at 0x401F4DD: _vgnU_freeres (vg_preloaded.c:58)
==27263==  If you believe this happened as a result of a stack
==27263==  overflow in your program's main thread (unlikely but
==27263==  possible), you can try to increase the size of the
==27263==  main thread stack using the --main-stacksize= flag.
==27263==  The main thread stack size used in this run was 8388608.
==27263== 
==27263== HEAP SUMMARY:
==27263==     in use at exit: 1,021,539,288 bytes in 13,167,791 blocks
==27263==   total heap usage: 13,167,792 allocs, 1 frees, 1,047,874,864 bytes allocated
==27263== 
==27263== LEAK SUMMARY:
==27263==    definitely lost: 0 bytes in 0 blocks
==27263==    indirectly lost: 0 bytes in 0 blocks
==27263==      possibly lost: 0 bytes in 0 blocks
==27263==    still reachable: 1,021,539,288 bytes in 13,167,791 blocks
==27263==         suppressed: 0 bytes in 0 blocks
==27263== Rerun with --leak-check=full to see details of leaked memory
==27263== 
==27263== For counts of detected and suppressed errors, rerun with: -v
==27263== ERROR SUMMARY: 1 errors from 1 contexts (suppressed: 12 from 7)

编辑 2：最终解决方案：这是堆栈溢出。在 sprintf 语句之后，我创建了一个数组，其大小与节点数成正比。因为我没有使用 malloc，所以它直接在堆栈上创建，溢出它。更改为使用 malloc 解决了问题，现在一切都按预期运行。感谢大家的建议！

4

2 回答 2

1

这是一个猜测，但试试这个简单的改变：

在将内容写入result变量的地方，尝试使用

n = snprintf(result, 2000, "...", ...);

其中 ... 代表您实际想要写入result字符串的内容。

如果你写到result's 分配的末尾，效果将是不可预测的。

于 2012-04-14T23:32:13.410 回答
1

在 valgrind 中运行你的程序。看看它说什么。我打赌你会发现输出很有启发性。

于 2012-04-14T23:51:15.980 回答