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.
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.
Don
At 09:22 AM 9/5/2001 +0200, you wrote:
>At 12:20 PM 4/09/2001 -0400, Jesse Pelton wrote:
>>There's been considerable work on BCB support in the last couple of
>>weeks. Check out the mailing list archive at
>><http://marc.theaimsgroup.com/?l=xerces-c-dev>http://marc.theaimsgroup.com/?l=xerces-c-dev.
>>
>>As for the runtime issues, make sure that you are calling
>>XMLPlatformUtils::Initialize() once when your ISA loads and
>>XMLPlatformUtils::Terminate() once when it unloads. (Or don't call
>>Terminate() at all. Yes, it's safe to skip it.) Once you've called
>>Terminate(), you can't call Initialize() again.
>
>I'm curious as to how the Borland support progresses; my own efforts at
>building 1.4/1.5/1.5.1 have always resulted in a library that leaks
>memory. I described the symptoms on this list a while back, but I think
>the lack of experience with Borland scared people away.
>
>At any rate, I was building with Borland C++ 5.5 (command-line tools)
>using Makefiles that I generated from scratch, to result in a static
>library (we had problems with Borland-generated DLLs at the time).
>Unfortunately, this library leaked considerable amounts of memory with
>each call to parse() _if_ the document referenced a DTD -- about 128KB of
>memory each time, in fact. Not only our programs leaked, but also the
>DOMPrint and ThreadTest examples included in the Xerces-C distribution.
>After noticing the leak due to extravagent memory use, MemProof
>(http://www.automatedqa.com/downloads/memproof.asp) also showed there was
>a problem, although it only showed the LocalAlloc() call for the memory,
>and didn't track the internal malloc()/free() usage.
>
>This problem is still plaguing us. Even the following program leaked memory:
>
>#include <iostream>
>#include <util/PlatformUtils.hpp>
>#include <parsers/DOMParser.hpp>
>
>int main(int argc, char *argv[])
>{
> if(argv[1])
> {
> XMLPlatformUtils::Initialize();
> DOMParser *parser = new DOMParser;
> parser->setValidationScheme(DOMParser::Val_Never);
> try
> {
> parser->parse(argv[1]);
> }
> catch(...)
> {
> std::cerr << "Warning: XML errors encountered."
> << std::endl;
> }
> delete parser;
> XMLPlatformUtils::Terminate();
> }
> else
> std::cout << "No filename given." << std::endl;
> return 0;
>}
>
>With the following XML file:
><?xml version="1.0"?>
><!DOCTYPE group SYSTEM "team.dtd">
><group name="department">
> <team name="project">
> <person name="A" leader="true"/>
> <person name="B"/>
> <person name="C"/>
> <person name="D"/>
> </team>
></group>
>
>And DTD:
><!-- DTD for our sample xml stuff -->
><!ELEMENT group (team*) >
><!ATTLIST group name CDATA #REQUIRED >
><!ELEMENT team (person*) >
><!ATTLIST team name CDATA #REQUIRED >
><!ELEMENT person EMPTY >
><!ATTLIST person name CDATA #REQUIRED >
><!ATTLIST person leader CDATA "false" >
>
>If the <!DOCTYPE> is removed from the XML file, the program no longer
>leaks. Therefore I concluded that the problem lay somewhere in the
>external entity resolver, but was unable to further isolate the problem.
>
>I'd be interested to hear if the DLLs that people build with BCB also
>exhibit the same problems. :)
>
>Cheers and good luck,
>
> - Andrew
>
>
>
>---------------------------------------------------------------------
>To unsubscribe, e-mail: [EMAIL PROTECTED]
>For additional commands, e-mail: [EMAIL PROTECTED]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
