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 bu...@apache.org on 2002/05/28 21:53:47 UTC
DO NOT REPLY [Bug 9468] New: -
Memory Leak in SAX Parser
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
<http://nagoya.apache.org/bugzilla/show_bug.cgi?id=9468>.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND
INSERTED IN THE BUG DATABASE.
http://nagoya.apache.org/bugzilla/show_bug.cgi?id=9468
Memory Leak in SAX Parser
Summary: Memory Leak in SAX Parser
Product: Xerces-C++
Version: 1.6.0
Platform: Sun
OS/Version: Solaris
Status: NEW
Severity: Critical
Priority: Other
Component: SAX/SAX2
AssignedTo: xerces-c-dev@xml.apache.org
ReportedBy: tdineen@bea.com
I am experiencing a large memory leak using the Xerces 1.6 SAX Parser on a
Solaris 8.0 machine. The O.S. is installed using 32 bit mode. The code is
single threaded, built with -DAPP_NO_THREADS directive.
Schema and Namespaces are set to false. Validation is set to true. The
MemBufInputSource class is the source for the xml document.
The application is initialized using the XMLPlatform::initialize() method and a
new Parser is created for each XML buffer that gets parsed. After each use,
the XMLPlatform::terminate() method is called to force cleanup of any remaining
static data structures based upon recommendations found in the FAQ's. The
following code snippet illustrates how I am using the parser.
try {
XMLPlatformUtils::Initialize();
}catch (const XMLException& toCatch) {
....
}
// create new parser for each request
SAXParser parser;
parser.setValidationScheme(valScheme);
parser.setDoNamespaces(doNamespaces);
parser.setDoSchema(doSchema);
parser.setDocumentHandler(&handler);
parser.setErrorHandler(&handler);
const char* appName = "AppName";
MemBufInputSource* memBufIS = new MemBufInputSource
((const XMLByte*)ar->getMsg(), strlen(ar->getMsg())
, appName, false);
parser.parse(*memBufIS);
// use the terminate method based upon advice in Xerces FAQ
XMLInterface::terminate();
The process size grows rapidly as seen using the ps -efl command. The Forte
workshop environment, dbx, etc. , does not detect the leak, however.
In an attempt to isolate the leak, the code was instrumented using the ioctl()
method to get the process byte size from the system process table. Using this
primitive method, it is possible to see where the code is growing.
It appears to be occuring somewhere inside the XMLScanner class. The best I can
do to isolate it is somewhere before the constructor of the XMLReader class.
The output shows the process size increases somewhere between where the
ReaderMgr creates the new XMLReader and the constructor of the XMLReader. The
following is taken from ReaderMgr.cpp.
439 try {
440 if (src.getEncoding())
441 {
442 cerr << ": creatReader: " << getProcSizeInBytes() << endl;
443 retVal = new XMLReader
444 (
445 src.getPublicId()
446 , src.getSystemId()
447 , newStream
448 , src.getEncoding()
449 , refFrom
450 , type
451 , source
452 );
453 cerr << ": creatReader: " << getProcSizeInBytes() << endl;
454 }
455 else
456 {
457 cerr <<": creatReader: " << getProcSizeInBytes() << endl;
458 retVal = new XMLReader
459 (
460 src.getPublicId()
461 , src.getSystemId()
462 , newStream
463 , refFrom
464 , type
465 , source
466 );
cerr <<": creatReader: " << getProcSizeInBytes() << endl;
The size of the leak is not consistent either. The following data shows the
delta's in process size in between each request. Each request sends the same xml
message and gets the same response back. The column on the left details the
size of the process and the column on the right details the change in size from
the previous request.
16,850,944 0
17,817,600 966,656
18,006,016 188,416
18,006,016 0
18,006,016 0
18,006,016 0
18,104,320 98,304
18,169,856 65,536
18,194,432 24,576
18,194,432 0
18,194,432 0
18,243,584 49,152
18,259,968 16,384
18,276,352 16,384
18,276,352 0
18,276,352 0
18,276,352 0
18,341,888 65,536
18,341,888 0
18,448,384 106,496
18,538,496 90,112
18,538,496 0
18,538,496 0
18,538,496 0
18,538,496 0
18,620,416 81,920
18,644,992 24,576
18,661,376 16,384
18,677,760 16,384
18,677,760 0
18,677,760 0
18,677,760 0
18,677,760 0
18,833,408 155,648
18,833,408 0
18,833,408 0
18,833,408 0
18,833,408 0
18,833,408 0
18,833,408 0
18,874,368 40,960
18,874,368 0
18,874,368 0
18,972,672 98,304
18,972,672 0
19,062,784 90,112
19,079,168 16,384
19,161,088 81,920
19,161,088 0
19,161,088 0
19,218,432 57,344
19,234,816 16,384
19,251,200 16,384
19,267,584 16,384
19,267,584 0
19,267,584 0
19,267,584 0
19,267,584 0
19,267,584 0
19,267,584 0
19,267,584 0
19,267,584 0
19,333,120 65,536
19,415,040 81,920
19,415,040 0
19,415,040 0
19,480,576 65,536
19,480,576 0
19,570,588 90,012
19,570,588 0
19,668,992 98,404
19,668,992 0
19,668,992 0
19,668,992 0
19,775,488 106,496
19,775,488 0
19,841,024 65,536
19,841,024 0
19,841,024 0
19,922,944 81,920
19,947,520 24,576
19,963,904 16,384
19,980,288 16,384
19,980,288 0
19,980,288 0
20,037,632 57,344
20,054,016 16,384
20,054,016 0
20,054,016 0
20,054,016 0
20,054,016 0
20,054,016 0
20,119,552 65,536
20,119,552 0
20,160,512 40,960
20,176,896 16,384
20,193,280 16,384
20,217,856 24,576
20,234,240 16,384
20,250,264 16,024
20,250,264 0
20,250,264 0
20,307,968 57,704
What is interesting is that the process size does not always increase, and when
it does, it does not increase at the same rate. It almost looks like some
resizing of internal cache or hashtables is taking place at certain intervals.
As stated earlier, the debugger in workshop was not able to detect the leak.
Sun was contacted to see why this was the case. After a reviewing the problem,
they thought it might be related to some known problems with their compiler and
debugger. After installing some upgrades and patches, the memory leak was still
not showing up using their tools. At this point Sun believes it is a programming
logic problem with the xerces library.
This bug appears to be related to bug 8984 and 7278 which have not had any
change in status since they were entered back in march and early may,
respectively.
Thank you for your assistance.
Thomas
---------------------------------------------------------------------
To unsubscribe, e-mail: xerces-c-dev-unsubscribe@xml.apache.org
For additional commands, e-mail: xerces-c-dev-help@xml.apache.org