This is the mail archive of the
mailing list for the libstdc++ project.
Re: Re: stl / pthreads leak, patch
- From: <desertcoder at cox dot net>
- To: libstdc++ at gcc dot gnu dot org
- Date: Wed, 14 Aug 2002 21:14:51 -0400
- Subject: Re: Re: stl / pthreads leak, patch
> From: <email@example.com>
> Date: 2002/08/14 Wed PM 09:12:49 EDT
> To: firstname.lastname@example.org
> Subject: Re: Re: stl / pthreads leak, patch
> Hi LorenThanks for responding. I realize now that neither test case I have provided demonstrates the problem well. I am not sure how to demonstrate the problem with a small program. It is possible that it can not be demonstrated with a small program.
> These things I do know:
> - A program I have written, which makes extensive use of the STL and Pthreads, consumes memory until it runs out.
> - The program continually "leaks" memory that Valgrind, reports I have a pointer to. All reports complain about source file stl_alloc.h, line 490.
> - Monitoring the system memory shows that the resident size of the program shrinks and grows, but never over an acceptable size.
> - Monitoring the system memory shows total free memory decreases until none is remaining.
> > have looked at your test cases on i386-*-freebsd* (what
> > I have available) not i386-*-linux*
> Valgrind only runs on GCC/Linux source, but tests on a freshly build, up-to-date, FreeBSD box exhibits the same problem when monitoring system memory usage.
> > I fear that you have taken insult where none was
> > intended.
> None taken. I just wanted to make it clear that memory is consumed, that I can not free, even though my program technically has a pointer to it. Too me, that is a memory leak.
> > I disagree with your analysis. Your analysis is
> > wrong IMHO since you have looked at cases where
> > threads are killed in a non-deterministic
> > manner with non-deterministic state. Anytime you
> > kill a threaded process with non-joined, detached
> > threads (such as when you fall off
> > the end of main() without joining all spawned threads)
> > it is a non-deterministic case and it could appear to have > many such "memory leaks" as Valgrind reports.
> I was hoping that was true. Last night, I rewrote portions of the code so that is now uses a pre-threaded pool model instead of a thread-per-connection model. No threads are ever destroyed. The memory "leak" from the STL still grows without limit. How can this be explained?
> > I believe that I covered this as a source
> > of your finding in my theory in the first analysis and
> > based on past experience. BTW, I believe (but I will
> > not look up a cite) that someone else had this exact
> > problem last year and eventually came around to my
> > thinking once they looked at deterministic test cases...
> I have been in very recent contact with that individual. Like me, nothing he tried ever worked. I am more persistent than most, less than others.
> > If this statement were true, someone should be able
> > to point to the exact lines of the library with a
> > bug. Or, at least, provide a test case that exposes
> > the bug. Unless there is a bug, the internal cache
> > for STL and small strings will stabilize at the maximum
> > memory profile ever used until that point in the run.
> The stabilization does not appear to be working. That is my only argument. The source file and line were mentioned above. I have a 7284 line test case. If you happen to know of someone who wouldnt mind taking a look at it, please give them my email address.
> > misfeature was in libstdc++-v2, although use of the STL> cache architecture by small strings was not in
> > place). Unless one puts non-trivial effort into
> > the cache architecture, it will not be able to
> > free stuff back to the OS.
> Can you or someone please tell me or point me to some documentation that shows me exactly how to disable the cache?