Saturday, May 31, 2008
Thursday, May 22, 2008
Virtual destructor
My fan base quickly pointed out that in the example code I sent through valgrind the other day, that class Derived didn't allocate any dynamic memory, and that not calling its destructor would not have been expected to leak memory. All of the comments I got suggested that if I had allocated some block of dynamic memory, either with a stl vector or a raw C-style array inside the constructor, and destroyed it in the destructor, the memory would be leaked in a call to the (non-polymorphic) base class dstor.
I went ahead and coded up the suggestion and found, yes, valgrind detects the leaked memory.
This makes me wonder, though: how the hell does delete know how large the thing is that its deleting?
I went ahead and coded up the suggestion and found, yes, valgrind detects the leaked memory.
This makes me wonder, though: how the hell does delete know how large the thing is that its deleting?
Saturday, May 17, 2008
I wish I could quit you
I got stuck in emacs while using cygwin. C-x C-c did nothing. So I tried M-x to type out a bunch of possible "exit" commands.
I tried:
quit
exit
leave
These are not meaningful ways to end emacs.
How do you quit?
M-x save-buffers-kill-emacs
Thank you google. If not for you, I might still be trapped in emacs hell.
I tried:
quit
exit
leave
These are not meaningful ways to end emacs.
How do you quit?
M-x save-buffers-kill-emacs
Thank you google. If not for you, I might still be trapped in emacs hell.
Thursday, May 15, 2008
valgrind non-virtual dstor leak bug
I ran valgrind on the following code which, you'll see, leaks the data stored in the derived class.
Valgrind does not seem to notice the leak. I'm not so happy about that.
/// test.cc
#include
class Base {
public:
virtual void blah() = 0;
~Base() { std::cout << "Base dstor" << std::endl; }
private:
int data_;
};
class Derived : public Base
{
public:
virtual void blah() {}
~Derived() { std::cout << "Derived dstor" << std::endl;}
private:
int data2_;
int data3_;
};
int main()
{
Base * bptr = new Derived;
delete bptr;
return 0;
}
..........
From the command line.
>g++ test.cc -o test.out
>valgrind --tool=memcheck test.out
==31535== Memcheck, a memory error detector.
==31535== Copyright (C) 2002-2005, and GNU GPL'd, by Julian Seward et al.
==31535== Using LibVEX rev 1575, a library for dynamic binary translation.
==31535== Copyright (C) 2004-2005, and GNU GPL'd, by OpenWorks LLP.
==31535== Using valgrind-3.1.1, a dynamic binary instrumentation framework.
==31535== Copyright (C) 2000-2005, and GNU GPL'd, by Julian Seward et al.
==31535== For more details, rerun with: -v
==31535==
Base dstor
==31535==
==31535== ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 5 from 1)
==31535== malloc/free: in use at exit: 0 bytes in 0 blocks.
==31535== malloc/free: 1 allocs, 1 frees, 24 bytes allocated.
==31535== For counts of detected errors, rerun with: -v
==31535== All heap blocks were freed -- no leaks are possible.
Valgrind does not seem to notice the leak. I'm not so happy about that.
/// test.cc
#include
class Base {
public:
virtual void blah() = 0;
~Base() { std::cout << "Base dstor" << std::endl; }
private:
int data_;
};
class Derived : public Base
{
public:
virtual void blah() {}
~Derived() { std::cout << "Derived dstor" << std::endl;}
private:
int data2_;
int data3_;
};
int main()
{
Base * bptr = new Derived;
delete bptr;
return 0;
}
..........
From the command line.
>g++ test.cc -o test.out
>valgrind --tool=memcheck test.out
==31535== Memcheck, a memory error detector.
==31535== Copyright (C) 2002-2005, and GNU GPL'd, by Julian Seward et al.
==31535== Using LibVEX rev 1575, a library for dynamic binary translation.
==31535== Copyright (C) 2004-2005, and GNU GPL'd, by OpenWorks LLP.
==31535== Using valgrind-3.1.1, a dynamic binary instrumentation framework.
==31535== Copyright (C) 2000-2005, and GNU GPL'd, by Julian Seward et al.
==31535== For more details, rerun with: -v
==31535==
Base dstor
==31535==
==31535== ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 5 from 1)
==31535== malloc/free: in use at exit: 0 bytes in 0 blocks.
==31535== malloc/free: 1 allocs, 1 frees, 24 bytes allocated.
==31535== For counts of detected errors, rerun with: -v
==31535== All heap blocks were freed -- no leaks are possible.
Wednesday, May 14, 2008
Subscribe to:
Posts (Atom)