|
From: Stephan M. <sm...@gm...> - 2004-10-27 10:39:45
|
=2D----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Am Mittwoch, 27. Oktober 2004 12:28 schrieb Tom Hughes:
=46irst of all, Jeroen, the destructor frees indeed.
MyClass::~MyClass() {
if (_buf)
free(_buf);
}
There's not much room for errors here.
> I think you are misunderstanding the error - that stack trace does not
> indicate the point at which the memory was lost (that is virtually
> impossible to determine) but rather the place where the memory which
> has been lost was allocated.
OK, so I did misunderstand. But anyway, is it possible to determine, where =
it=20
IS lost?=20
I think I should mention that the debugged program is a demon process and i=
t=20
initialises lots of those objects and destroys lots of them during runtime.=
=20
But some should still live when I shut down the process. Is it possible tha=
t=20
those errors refer to still existing objects when I kill the demon? That=20
wouldn't bother me as long as it's not leaking mem during normal runtime.
> It shouldn't be ignored. The memory which was allocated by that call
> to realloc has been lost, presumably because something overwrite the
> _buf pointer later on without freeing the memory first.
I checked it pretty thoroughly but I'll keep on looking for stuff like that.
Greetings...
Stephan
=2D----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.4 (GNU/Linux)
iD8DBQFBf3rbbv5p9h9J588RAkKNAJwKP5F+SEmsaW9bNGQJX26zj7v/twCgh0li
2rnSrc69z6nr0W6zD0+rSXs=3D
=3DCEdj
=2D----END PGP SIGNATURE-----
|