Hi,
I have not looked at this too much but I find that Rational's Purify on NT
reports quite well.
This is with Xerces being built with MSVC.
Hope this helps,
Chris Prior
-----Original Message-----
From: Don Mastrovito [mailto:[EMAIL PROTECTED]]
Sent: 05 September 2001 13:13
To: [EMAIL PROTECTED]
Subject: RE: Borland BCB and Xerces.
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]
___________________________________________________
Email Disclaimer
This communication is for the attention of the
named recipient only and should not be passed
on to any other person. Information relating to
any company or security, is for information
purposes only and should not be interpreted as
a solicitation or offer to buy or sell any security.
The information on which this communication is based
has been obtained from sources we believe to be reliable,
but we do not guarantee its accuracy or completeness.
All expressions of opinion are subject to change
without notice. All e-mail messages, and associated attachments,
are subject to interception and monitoring for lawful business purposes.
___________________________________________________
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
