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.
