|
From: Tom H. <th...@cy...> - 2004-10-27 10:28:38
|
In message <200...@gm...>
Stephan Menzel <sm...@gm...> wrote:
> But using this class (a lot, multithreaded) valgrind 2.2.0 shows something
> like this:
>
> =12311== 309 bytes in 7 blocks are definitely lost in loss record 18 of 30
> ==12311== at 0x1B903A8B: realloc (vg_replace_malloc.c:197)
> ==12311== by 0x8085F2C: MyClass::resize(unsigned int) (../MyClass.cc:650)
> ==12311== by 0x80847FF: MyClass::append(char const *, unsigned int
> ==12311== by 0x8084723: MyClass::append(MyClass const &) (../MyClass.cc
>
> What should be lost there?
I don't think anything is lost there. That code looks fine.
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.
> Does it refer to the mem area being abandoned when
> realloc() gives a pointer different to _buf?
No, because that is expected and that abandoned area becomes part of
the free pool and can be reused.
> Am I mistaken here or is it just a warning to be safely ignored?
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.
Tom
--
Tom Hughes (th...@cy...)
Software Engineer, Cyberscience Corporation
http://www.cyberscience.com/
|