You are viewing a plain text version of this content. The canonical link for it is here.
Posted to c-dev@xerces.apache.org by Jesse Pelton <js...@PKC.com> on 2001/09/04 18:20:45 UTC
RE: Borland BCB and Xerces.
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.
-----Original Message-----
From: Wade Chandler [mailto:wade.chandler@metrois.com]
Sent: Friday, August 31, 2001 11:56 AM
To: xerces-c-dev@xml.apache.org
Subject: Borland BCB and Xerces.
Hello,
I am writing here because the BugZilla server is down. It has always
been kind of slow though, so I'm glad to see it is moving! heh heh.
Anyways....
I've noticed that the lib has been built around unsigned int XMLCh
typedefs. This is ok and all, but borland actually calls wchar_t a keyword
and in MSVC it is a typedef. This cause some issues in some files. I had
to go through them and cast to wchar_t where appropriate. There is a
builder project in the package, but without corrections it will not compile.
Have the members thought about making a builder project that actually works
with the correct files already updated?
Also, I have my lib compiling, but I am having some strange runtime
issues. In any given process I can create two SAX2XMLReaders fine then I am
getting failures on two then I can create two more fine then I can't then I
can and so on and so on. This is of course happening inside of an ISAPI
DLL(not filter). But, that is not all. After I add a supstantial amount of
code to my DefaultHandler sub class I can parse once then fail parse once
then fail. All of the failures I am getting are results of an access error.
I am thinking, but not sure, for I have to finish my proj first then debug,
that where XMLUtils::createXMLReader() is calling new SAX2XMLReaderImpl we
are having issues with either with the XMLScanner(0) call or with the new
array of XMLDocumentHandlers and the call to memset. There is no array
check to see if new worked or didn't. I was looking for maybe some kind of
XMLException to be generated in these types of senarios. Has this
discussion come up before?
Well, if anyone else has had the same sort of issues please let me know
what you did to correct them. I would greatly appreciate it. Thank you.
Re: Borland BCB and Xerces.
Posted by Adib Taraben <Ta...@wige-mic.de>.
Regarding the memory leaks ...
I compiled the Xerces 1.5.1 using BCB5 Enterprise.
I check the memory with the build in Code Guard (which was not switched
on for the Library build). Whit that I can not found any leaks.
Did you tried with CodeGuard?
Adib.
--
Adib Taraben taraben.a@wige-mic.de
WIGE MIC Tel: +49 (0)341-4621/100
Wiesenring 11 Fax: +49 (0)341-4621/400
04159 LEIPZIG mail: office@wige-mic.de
GERMANY WWW: www.wige-mic.de
---------------------------------------------------------------------
To unsubscribe, e-mail: xerces-c-dev-unsubscribe@xml.apache.org
For additional commands, e-mail: xerces-c-dev-help@xml.apache.org
RE: Borland BCB and Xerces.
Posted by Don Mastrovito <dm...@marathontechnologies.com>.
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: xerces-c-dev-unsubscribe@xml.apache.org
>For additional commands, e-mail: xerces-c-dev-help@xml.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: xerces-c-dev-unsubscribe@xml.apache.org
For additional commands, e-mail: xerces-c-dev-help@xml.apache.org
RE: Borland BCB and Xerces.
Posted by Andrew Snare <AS...@allshare.nl>.
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: xerces-c-dev-unsubscribe@xml.apache.org
For additional commands, e-mail: xerces-c-dev-help@xml.apache.org
RE: Borland BCB and Xerces.
Posted by Andrew Snare <AS...@allshare.nl>.
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: xerces-c-dev-unsubscribe@xml.apache.org
For additional commands, e-mail: xerces-c-dev-help@xml.apache.org