Valgrind崩溃,并给我这个无效的重新分配警告

时间:2018-11-28 19:48:37

标签: c memory-leaks valgrind

t_syntaxTree是一种结构,定义为:

typedef struct t_syntaxTree {
    char nodeName[16];
    int nodesLen;
    struct t_syntaxTree** nodes;
} t_syntaxTree;

我编写了函数treeToStr来转换字符串中的语法树,该代码应该可以自我解释。输出字符串格式类似于Lisp,例如,输出字符串可以为(or (and true true) (> b 3))。 以下代码可以工作,但是如果我使用valgrind执行程序,则会因分段错误而崩溃。 此外,在崩溃之前,valgrind告诉我我的一些realloc调用无效。

int recTreeToStr(t_syntaxTree* t, char* str, int len) {
    if (t->nodesLen == 0) {
        int nLen = len + strlen(t->nodeName);
        str = realloc(str, sizeof(char) * nLen);
        strcat(str, t->nodeName);
        return nLen;
    }
    else {
        int nLen = len + strlen(t->nodeName) + 1;
        str = realloc(str, sizeof(char) * nLen);
        strcat(str, "(");
        strcat(str, t->nodeName);

        for (int i=0; i<t->nodesLen; i++) {
            nLen++;
            str = realloc(str, sizeof(char) * nLen);
            strcat(str, " ");
            nLen = recTreeToStr(t->nodes[i], str, nLen);
        }

        nLen++;
        str = realloc(str, sizeof(char) * nLen);
        strcat(str, ")");

        return nLen;
    }
}

char* treeToStr(t_syntaxTree* tree) {
    char* str=malloc(sizeof(char));
    str[0] = '\0';
    recTreeToStr(tree, str, 1);
    return str;
}

这是崩溃之前的valgrind报告(此消息之后,程序立即崩溃并出现分段错误):

==26561== Invalid free() / delete / delete[] / realloc()
==26561==    at 0x4839D7B: realloc (vg_replace_malloc.c:826)
==26561==    by 0x10B3C4: recTreeToStr (cooper.c:443)
==26561==    by 0x10B420: recTreeToStr (cooper.c:445)
==26561==    by 0x10B420: recTreeToStr (cooper.c:445)
==26561==    by 0x10B420: recTreeToStr (cooper.c:445)
==26561==    by 0x10B4C0: treeToStr (cooper.c:459)
==26561==    by 0x10B4F2: cooper (cooper.c:467)
==26561==    by 0x10922E: main (test.c:6)
==26561==  Address 0x4a6aee0 is 0 bytes inside a block of size 15 free'd
==26561==    at 0x4839D7B: realloc (vg_replace_malloc.c:826)
==26561==    by 0x10B310: recTreeToStr (cooper.c:431)
==26561==    by 0x10B420: recTreeToStr (cooper.c:445)
==26561==    by 0x10B420: recTreeToStr (cooper.c:445)
==26561==    by 0x10B420: recTreeToStr (cooper.c:445)
==26561==    by 0x10B420: recTreeToStr (cooper.c:445)
==26561==    by 0x10B4C0: treeToStr (cooper.c:459)
==26561==    by 0x10B4F2: cooper (cooper.c:467)
==26561==    by 0x10922E: main (test.c:6)
==26561==  Block was alloc'd at
==26561==    at 0x4839D7B: realloc (vg_replace_malloc.c:826)
==26561==    by 0x10B3C4: recTreeToStr (cooper.c:443)
==26561==    by 0x10B420: recTreeToStr (cooper.c:445)
==26561==    by 0x10B420: recTreeToStr (cooper.c:445)
==26561==    by 0x10B420: recTreeToStr (cooper.c:445)
==26561==    by 0x10B4C0: treeToStr (cooper.c:459)
==26561==    by 0x10B4F2: cooper (cooper.c:467)
==26561==    by 0x10922E: main (test.c:6)
==26561== 
==26561== Invalid read of size 1
==26561==    at 0x10B3DF: recTreeToStr (cooper.c:444)
==26561==    by 0x10B420: recTreeToStr (cooper.c:445)
==26561==    by 0x10B420: recTreeToStr (cooper.c:445)
==26561==    by 0x10B420: recTreeToStr (cooper.c:445)
==26561==    by 0x10B4C0: treeToStr (cooper.c:459)
==26561==    by 0x10B4F2: cooper (cooper.c:467)
==26561==    by 0x10922E: main (test.c:6)
==26561==  Address 0x0 is not stack'd, malloc'd or (recently) free'd
==26561== 
==26561== 
==26561== Process terminating with default action of signal 11 (SIGSEGV): dumping core
==26561==  Access not within mapped region at address 0x0
==26561==    at 0x10B3DF: recTreeToStr (cooper.c:444)
==26561==    by 0x10B420: recTreeToStr (cooper.c:445)
==26561==    by 0x10B420: recTreeToStr (cooper.c:445)
==26561==    by 0x10B420: recTreeToStr (cooper.c:445)
==26561==    by 0x10B4C0: treeToStr (cooper.c:459)
==26561==    by 0x10B4F2: cooper (cooper.c:467)
==26561==    by 0x10922E: main (test.c:6)
==26561==  If you believe this happened as a result of a stack
==26561==  overflow in your program's main thread (unlikely but
==26561==  possible), you can try to increase the size of the
==26561==  main thread stack using the --main-stacksize= flag.
==26561==  The main thread stack size used in this run was 8388608.
==26561== 
==26561== HEAP SUMMARY:
==26561==     in use at exit: 1,249 bytes in 46 blocks
==26561==   total heap usage: 224 allocs, 178 frees, 21,257 bytes allocated
==26561== 
==26561== 17 bytes in 1 blocks are definitely lost in loss record 2 of 11
==26561==    at 0x4839D7B: realloc (vg_replace_malloc.c:826)
==26561==    by 0x10B310: recTreeToStr (cooper.c:431)
==26561==    by 0x10B420: recTreeToStr (cooper.c:445)
==26561==    by 0x10B420: recTreeToStr (cooper.c:445)
==26561==    by 0x10B420: recTreeToStr (cooper.c:445)
==26561==    by 0x10B420: recTreeToStr (cooper.c:445)
==26561==    by 0x10B4C0: treeToStr (cooper.c:459)
==26561==    by 0x10B4F2: cooper (cooper.c:467)
==26561==    by 0x10922E: main (test.c:6)
==26561== 
==26561== LEAK SUMMARY:
==26561==    definitely lost: 17 bytes in 1 blocks
==26561==    indirectly lost: 0 bytes in 0 blocks
==26561==      possibly lost: 0 bytes in 0 blocks
==26561==    still reachable: 1,232 bytes in 45 blocks
==26561==         suppressed: 0 bytes in 0 blocks
==26561== Reachable blocks (those to which a pointer was found) are not shown.
==26561== To see them, rerun with: --leak-check=full --show-leak-kinds=all
==26561== 
==26561== For counts of detected and suppressed errors, rerun with: -v
==26561== ERROR SUMMARY: 3 errors from 3 contexts (suppressed: 0 from 0)

2 个答案:

答案 0 :(得分:2)

首次致电realloc后,您释放了str。它已被新分配代替。然后,您的函数将返回,而不会在任何地方存储str的新值。

是的,您是在str返回后使用recTreeToStr的无效值。

答案 1 :(得分:1)

要成功重新分配char *,实际上您需要传递char **。您的方法中的char *是您认为要重新分配的真实指针的副本。

类似的东西:

int recTreeToStr(t_syntaxTree* t, char** str, int len) {
...
    *str = realloc(*str, sizeof(char) * nLen);
...
}

recTreeToStr(tree, &str, 1);

我还担心您正在为现有字符串+节点名称的长度分配内存,但同时还包括'('和')'和'',而没有为它们分配空间。 (除非我是盲人。)