Re: Re: stl / pthreads leak, patch

[<desertcoder at cox dot net>]

> 
> From: <desertcoder@cox.net>
> Date: 2002/08/14 Wed PM 09:12:49 EDT
> To: rittle@labs.mot.com
> 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?
> 
> Ken
>