At 08:13 AM 5/09/2001 -0400, Don Mastrovito wrote:
>Regarding the memory leaks ...
>
>I've seen exactly the problems you mentioned. Using the Borland project
>updates I supplied the last couple of weeks, I built DLLs, not static
>libraries. The leaks were the same. Each call to parse() lost anywhere
>from 100 to 200KB depending on the input file. I too used MemProof, both
>the current and beta versions. Telling MemProof to hook XercesLib.dll in
>addition to the Borland run-time libraries still only showed the
>LocalAlloc() call.
It's great to know that I'm not the only person who has seen this problem.
I was wondering if maybe my build process for Xerces-C under Borland was
incorrect.
>Has anyone checked for leaks in a Xerces library built with MSCV? I fail
>to see how this can be related to the compiler or run-time libraries. The
>Borland run-time libraries are known to allocate a 4K chunk that is never
>returned. That's the only BCB memory problem I am aware of. I don't see
>this type of leakage in other memory intensive BCB applications.
While I haven't tested with MSVC (our code won't compile under it -- too
much is broken/buggy with that compiler), I did build Xerces-C with an
evaluation version of the Intel C++ compiler. It exhibited the same
problem. Irrespective of this (I didn't test extensively -- it could have
been a separate issue) I don't believe the problem affects all platforms
since we don't see any leaks with the same code under Linux.
I checked the call-site where LocalAlloc() was being invoked, and it was a
call to operator new. After checking the code (and inserting statements in
the constructor/destructor of the object being allocated) I concluded that
a corresponding delete was being made correctly, so the initial memory was
being freed. For the record, Borland's operator new/new[]/delete/delete[]
simply invoke the RTL malloc/free routines.
This leads me to believe that it's possible Borland's malloc()/free()
implementation is buggy and either does not release memory to the OS or
re-use free()d memory in an efficient manner. For example, assuming an
intervening memory allocation prevents the entire LocalAlloc() chunk from
being returned, a new LocalAlloc() chunk shouldn't be allocated -- released
memory within the chunk should be re-used, unless there's incredibly
pathological memory fragmentation going on or the memory allocator doesn't
coalesce free()d chunks (when possible).
Unfortunately I didn't have time to track down the exact problem, or
determine why the external entity reference in triggered the problem. In
particular, I would have liked to plug in an alternate memory allocator and
see what happens then.
While it's possible the Xerces-C library could make more efficient use of
dynamic memory through STL-style allocators to avoid stressing operator
new/delete, the fact that these memory leaks are not observed on other
platforms or with MSVC on the same platform indicates there's no reason why
there should be such an apparently large leak.
If anyone else wishes to try and track down this problem, I don't mind
assisting with what I found along the way. Unfortunately I reached a
dead-end on my own. :)
- Andrew
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
