Valgrind中的内存泄漏和错误

时间:2014-02-13 08:46:20

标签: c++ memory-leaks valgrind

我是C ++的初学者,如果我正确地释放了记忆并删除了可能的悬空指针,我仍然感到非常困惑。这是我过去的学校作业之一。有这么多学生有同样的问题,没有其他人可以帮助我。 请找出我遇到问题的地方。

    ==25334== Mismatched free() / delete / delete []
==25334==    at 0x4006D21: free (vg_replace_malloc.c:446)
==25334==    by 0x80492F2: HashTable::~HashTable() (Hash.c:115)
==25334==    by 0x8049145: SymTab::~SymTab() (SymTab.h:9)
==25334==    by 0x8048E9D: main (Driver.c:170)
==25334==  Address 0x402c0b8 is 0 bytes inside a block of size 12 alloc'd
==25334==    at 0x4007862: operator new(unsigned int) (vg_replace_malloc.c:292)
==25334==    by 0x8048C73: main (Driver.c:143)
==25334==
==25334==
==25334== HEAP SUMMARY:
==25334==     in use at exit: 18 bytes in 4 blocks
==25334==   total heap usage: 10 allocs, 6 frees, 106 bytes allocated
==25334==
==25334== 18 bytes in 4 blocks are definitely lost in loss record 1 of 1
==25334==    at 0x4007D58: malloc (vg_replace_malloc.c:270)
==25334==    by 0x97E96F: strdup (strdup.c:43)
==25334==    by 0x8048FDC: UCSDStudent::UCSDStudent(char*, long) (Driver.c:36)
==25334==    by 0x8048C92: main (Driver.c:143)
==25334==
==25334== LEAK SUMMARY:
==25334==    definitely lost: 18 bytes in 4 blocks
==25334==    indirectly lost: 0 bytes in 0 blocks
==25334==      possibly lost: 0 bytes in 0 blocks
==25334==    still reachable: 0 bytes in 0 blocks
==25334==         suppressed: 0 bytes in 0 blocks
==25334==
==25334== For counts of detected and suppressed errors, rerun with: -v
==25334== ERROR SUMMARY: 5 errors from 2 contexts (suppressed: 15 from 8)

Base.h

    #ifndef BASE_H
    #define BASE_H

    #include <iostream>
    using namespace std; /* C error */

    /* TEMPLATE */
    struct Base { /* C++ struct is public class, public methods */
        /* PUBLIC SECTION */
        /* virtual: candidates for redefinition */
        virtual operator char * (void) { 
            return 0;
        }
        virtual operator long (void) {      // hash function
            return 0;
        }
        virtual long operator == (Base & base) {// isequal function
            return *this == base;
        }
        Base (void) {}              // new_element
        virtual ~Base (void) {}         // delete_element
        virtual ostream & Write (ostream & stream) = 0;// write_element
    };

    #endif

Driver.c

class UCSDStudent : public Base { /* extends Base  */
char * name;
long studentnum;

    public:
    UCSDStudent (char * nm, long sn) :
    name (strdup (nm)), studentnum (sn) {} /* Initialization */


~UCSDStudent (void) { /* Destructor */
    free (name);
}

Hash.c

    /* HashTable constructor */
    HashTable :: HashTable (int sz) : size (sz),
table_count(++counter), occupancy (0), table (new Base *[sz]), 
probeCount (new int[sz])


    HashTable :: ~HashTable (void)
    {

    /* call function to delete individual elements */
    for(int index2 = 0; index2 < size; index2++)
    {

        if(table[index2] != NULL)
      {
        free(table[index2]);
        table[index2] = NULL;
      }

        delete table[index2];
    }

    /*
     * delete table itself
     * Freed memory
     */
    delete[] table;
    delete[] probeCount;
    /* pointed dangling ptr to NULL */
    table = NULL; 
    probeCount = NULL; 
  } /* end: ~HashTable */

3 个答案:

答案 0 :(得分:2)

两个Valgrind错误(“不匹配的free()/ delete / delete []”和“4个块中的18个字节肯定会丢失”)可能是相关的。

~HashTable()中你调用free(table[index2])这可能意味着销毁UCSDStudent个对象(不确定,因为你没有发布整个程序,特别是不插入元素的代码进入HashTable)。我假设您使用UCSDStudent创建new个对象 - 在这种情况下,您还必须使用相应的销毁方法(在这种情况下为delete而不是free())。这是第一个Valgrind错误的原因。

此外,free()函数不会调用对象的析构函数,而delete会执行此操作。这可以解释为什么不调用~UCSDStudent(),导致程序泄漏学生名称的内存。因此,在delete中使用free()代替~HashTable()可以解决这两个错误。

通常,您应该尝试使用一种内存分配方式(malloc() / free()new/new[]/delete/delete[])。鉴于这是一个C ++程序,new将是合适的选择。同样,我建议您删除strdup()char*内容并转而使用std::string - 这会删除您可能会混淆的另一个位置free()delete

答案 1 :(得分:1)

你在内存上调用free似乎是使用new声明的,这是Valgrind在那里发出的主要错误。您似乎也没有遵循三条规则(尽管那似乎不是您的整个代码)。

我强烈建议您切换到使用std::shared_ptr / std::unique_ptr等智能指针,并使用std::vector / std::array创建容器。

答案 2 :(得分:0)

在我看来,你永远不会打电话给~UCSDStudent。不幸的是,从你发布的代码中判断出来是不可能的,但是析构函数本身看起来不错,所以我预计问题在于析构函数没有被调用。