Memory leak with new / delete

[Darsant]

We have a multithreaded program that uses new and delete. We have not
over-ridden these operators. We're currently experiencing leaking for
the program.

The programmer that is currently working on it says he read an article
that stated that when new / delete (or new [n] / delete[]) are used
many times / quickly that the memory can sometimes not be freed for
use. This seems like a big problem, but the issues we are having
(threads not purging data correctly even though they seem to be
allocated and deleted via new / delete properly) seem to support this.

I was wondering if anyone else had heard of this article and whether
there was any truth behind new / delete having issues with short use on
large data?

Thanks,
Josh McFarlane

 

[Victor Bazarov]

[...]
I was wondering if [...]
there was any truth behind new / delete having issues with short use on
large data?

Nothing in the language specification supports or goes against this. How
free store is managed behind the scenes is implementation-defined and
often platform-specific. Also, remember that all the tools that "report
memory leaks" do so in some platform-specific manner and often without
considerations of implementation-specific details.

All that should give you a hint to ask either in the newsgroup that deals
with your platform or with your compiler. The only "true" leak is when
memory is allocated (using 'new' or 'new[]') and not freed using 'delete'
or 'delete[]'. If the respective operators are paired in your program,
you've done it correctly AFA C++ _language_ is concerned.

V

 

[Darsant]

Nothing in the language specification supports or goes against this. How
free store is managed behind the scenes is implementation-defined and
often platform-specific. Also, remember that all the tools that "report
memory leaks" do so in some platform-specific manner and often without
considerations of implementation-specific details.

All that should give you a hint to ask either in the newsgroup that deals
with your platform or with your compiler. The only "true" leak is when
memory is allocated (using 'new' or 'new[]') and not freed using 'delete'
or 'delete[]'. If the respective operators are paired in your program,
you've done it correctly AFA C++ _language_ is concerned.

V

Thanks for the quick response. I was afraid it might be more dependant
upon the compiler. I'll go poke around the Windows / VS newsgroups and
see what they have to say.

 

[Pete Becker]

Nothing in the language specification supports or goes against this. How
free store is managed behind the scenes is implementation-defined and
often platform-specific. Also, remember that all the tools that "report
memory leaks" do so in some platform-specific manner and often without
considerations of implementation-specific details.

All that should give you a hint to ask either in the newsgroup that deals
with your platform or with your compiler. The only "true" leak is when
memory is allocated (using 'new' or 'new[]') and not freed using 'delete'
or 'delete[]'. If the respective operators are paired in your program,
you've done it correctly AFA C++ _language_ is concerned.

V

Thanks for the quick response. I was afraid it might be more dependant
upon the compiler. I'll go poke around the Windows / VS newsgroups and
see what they have to say.

Well, that's the standards conformant version of the answer. In fact,
any implementation that leaks memory because you call new/delete "too
often" has major problems. Your leak is almost certainly somewhere else.

 

[Phil Endecott]

We have a multithreaded program that uses new and delete. We have not
over-ridden these operators. We're currently experiencing leaking for
the program.

Allocation algorithms for multi-threaded applications can make tradeoffs
between performance and memory use; if you free memory in one thread, do
you expect another thread to be able to allocate it next? - if so, more
locking is needed than if you only reallocate memory in the thread where
it was first used. On the whole, though, you have to go out of your way
to ask for an "optimised" allocator that might suffer from these
problems; your system's default allocator should have sane, if perhaps
slow, behviour. Have you tried Purify or Valgrind or something like that?

--Phil.