Re: Memory leak: Windows DLL build only

On Nov 24, 2004, at 4:24 PM, Malcolm Melville wrote:

> It appears to me that there is a memory leak from tchar.h under 
> Windows in DLL mode. Each construct/destruct cycle of a StringBuffer 
> causes a 4 byte leak to be reported by Purify and Leak Browser.
>
> The following code fragment - a stripped out version of tchar.h with 
> just the offending code in it shows the problem. Compile with 
> gcc/linux or gcc/Mac OS X and its fine. Compile with MSVC 7.1 in Multi 
> threaded DLL mode and the process grows. Compile with MSVC 7.1 in 
> Multi threaded or single threaded mode and its fine.
>
> My reading of the STL (and Rogue Wave) docs says that its all fine to 
> call init() with your own buffer, if that is the probelm which is what 
> Purify suggests. But maybe someone else has spotted this and there is 
> a work around for what seems to be an MS problem. I see that the code 
> is pretty much the same in CVS so though I have only looked at 0.9.7, 
> I guess its true of what is coming as well.
>
> Any views/comments welcome. I am looking for a work around.
>
> malcolm


Thanks for the report.  The CVS version hasn't changed this YET, but an 
upcoming phase of the APR migration will radically change tchar.h and 
most of the internals that touch strings.  StringBuffer is likely to be 
eliminated or rewritten, java.lang.StringBuffer is actually closer to 
std::basic_string than std::basic_ostream and the ostream has pretty 
substantial construction costs.   I'm assuming the APR rewrite will 
probably replace this bug with other subtle (or not so subtle) bugs.

It will be quite helpful if you are able to test the CVS version after 
the APR migration is complete (or at least more complete).  I'll be 
running valgrind on Linux, but I don't have access to equivalent tools 
on Windows.

Just to update the list, I've completed the code changes for the APR 
thread migration but am locking up on some of the unit tests and hope 
to resolve those shortly and commit the code.  The two remaining phases 
would be to migrate to APR's XML parser support and the Unicode related 
changes.