[ http://issues.apache.org/jira/browse/XERCESC-1381?page=history ]
Khaled Noaman closed XERCESC-1381:
--
> Memory Leak in GrammarResolver class
>
>
> Key: XERCESC-1381
>
> Memory Leak in GrammarResolver class
>
>
> Key: XERCESC-1381
> URL: http://issues.apache.org/jira/browse/XERCESC-1381
> Project: Xerces-C++
> Type: Bug
> Components: Validating Parser (Schema
fects, and I think that your fix is valid. When we cache
grammars, we remove it from the grammar resolver table, so I agree with you
that we should not change the table not to adopt elements.
Regards,
Khaled
> Memory Leak in GrammarResolver class
>
[ http://issues.apache.org/jira/browse/XERCESC-1381?page=history ]
Christian Will updated XERCESC-1381:
Attachment: GrammarResolver.cpp.patch
my changes...
> Memory Leak in GrammarResolver cl
Memory Leak in GrammarResolver class
Key: XERCESC-1381
URL: http://issues.apache.org/jira/browse/XERCESC-1381
Project: Xerces-C++
Type: Bug
Components: Validating Parser (Schema) (Xerces 1.5 or up only)
Versions: 2.6.0
sari (JIRA)"
wrote:
> [
>
http://issues.apache.org/jira/browse/XERCESC-1362?page=history
> ]
>
> Alberto Massari resolved XERCESC-1362:
> --
>
> Resolution: Fixed
>
> Fix is in CVS. Please verify.
&g
jesse
--- "Alberto Massari (JIRA)"
wrote:
> [
>
http://issues.apache.org/jira/browse/XERCESC-1362?page=history
> ]
>
> Alberto Massari resolved XERCESC-1362:
> --
>
> Resolution: Fixed
>
> Fix is in CVS. P
[ http://issues.apache.org/jira/browse/XERCESC-1362?page=history ]
Alberto Massari resolved XERCESC-1362:
--
Resolution: Fixed
Fix is in CVS. Please verify.
Alberto
> memory leak in reading XML
[ http://issues.apache.org/jira/browse/XERCESC-1362?page=history ]
Alberto Massari updated XERCESC-1362:
-
Assign To: Alberto Massari
Summary: memory leak in reading XMLURL (was: memory in reading XMLURL)
Version: 2.6.0
Component
issue.
> Memory leak with writeToString in DOMWriter
> ---
>
> Key: XERCESC-1279
> URL: http://issues.apache.org/jira/browse/XERCESC-1279
> Project: Xerces-C++
> Type: Bug
> Versions: 2.5.0
> R
get to the nightly build to test this fix.
Thanks
Tony Wuebben
-Original Message-
From: Alberto Massari (JIRA) [mailto:[EMAIL PROTECTED]
Sent: Friday, January 14, 2005 5:42 AM
To: [EMAIL PROTECTED]
Subject: [jira] Resolved: (XERCESC-490) Memory leak when
setCreateEntityReferenceNodes is true
Alberto:
How can we get to the nightly build to test this fix.
Thanks
Tony Wuebben
-Original Message-
From: Alberto Massari (JIRA) [mailto:[EMAIL PROTECTED]
Sent: Friday, January 14, 2005 5:42 AM
To: [EMAIL PROTECTED]
Subject: [jira] Resolved: (XERCESC-490) Memory leak when
the reference counts
on the document tree when an entity references were created. I checked in a fix
for this (even if it was the deprecated DOM); please verify.
Alberto
> Memory leak when setCreateEntityReferenceNodes is t
[
http://issues.apache.org/jira/browse/XERCESC-1279?page=comments#action_57422 ]
cargilld commented on XERCESC-1279:
---
Were you able to reproduce with DOMCount? If not lets close this bug.
> Memory leak with writeToString in DOMWri
> ICULCPTranscoder::transcode memory leak
> ---
>
> Key: XERCESC-964
> URL: http://nagoya.apache.org/jira/browse/XERCESC-964
> Project: Xerces-C++
> Type: Bug
> Components: Utilities
> Versions: 2.3.
[ http://nagoya.apache.org/jira/browse/XERCESC-964?page=history ]
Alberto Massari reopened XERCESC-964:
-
Assign To: (was: Xerces-C Developers Mailing List)
> ICULCPTranscoder::transcode memory l
GROUP organiziQ.Clerk
Server: SRVC01M
---
Jens Lauer
Ich bin abwesend bis 13.01.2005. Ihre Mail kann nicht bearbeitet werden.
[ http://nagoya.apache.org/jira/browse/XERCESC-1228?page=history ]
Alberto Massari closed XERCESC-1228:
> Memory leak when scanning multiple xmldocuments
> ---
>
> Key:
[ http://nagoya.apache.org/jira/browse/XERCESC-1307?page=history ]
Alberto Massari closed XERCESC-1307:
> memory leak in xercesc::XMLUri::operator =
> --
>
> Key: XERCESC-1307
>
[
http://nagoya.apache.org/jira/browse/XERCESC-1307?page=comments#action_56367 ]
Mariusz Popiolek commented on XERCESC-1307:
---
I've checked your fix and now everything is fine. Thanks
> memory leak in xercesc::XMLUri::
[ http://nagoya.apache.org/jira/browse/XERCESC-1307?page=history ]
Alberto Massari resolved XERCESC-1307:
--
Resolution: Fixed
A fix is in CVS. Please verify.
Alberto
> memory leak in xercesc::XMLUri::opera
memory leak in xercesc::XMLUri::operator =
--
Key: XERCESC-1307
URL: http://nagoya.apache.org/jira/browse/XERCESC-1307
Project: Xerces-C++
Type: Bug
Components: Utilities
Versions: 2.5.0
Environment: WindowsXP
[ http://nagoya.apache.org/jira/browse/XERCESC-534?page=history ]
Alberto Massari updated XERCESC-534:
Priority: Major
> Memory leak in DOMParser
>
>
> Key: XERCESC-534
> URL: http://nagoya.
[ http://nagoya.apache.org/jira/browse/XERCESC-477?page=history ]
Alberto Massari updated XERCESC-477:
Priority: Major
> Memory Leak in SAX Parser
> -
>
> Key: XERCESC-477
> URL: http://na
[ http://nagoya.apache.org/jira/browse/XERCESC-490?page=history ]
Alberto Massari updated XERCESC-490:
Priority: Major
> Memory leak when setCreateEntityReferenceNodes is true
> --
>
>
[ http://nagoya.apache.org/jira/browse/XERCESC-333?page=history ]
Alberto Massari updated XERCESC-333:
Priority: Major
> memory leak parsing xml document
>
>
> Key: XERCESC-333
>
:
-
Key: XERCESC-291
Summary: Memory Leak
Type: Bug
Status: Closed
Resolution: WON'T FIX
Project: Xerces-C++
Components:
DOM
Versions:
1.5.1
Assignee:
Reporter: Frank Balluffi
Created: Mon, 17 Dec 2001 2:17 PM
Updated: Tue, 1
:
-
Key: XERCESC-292
Summary: Memory Leak
Type: Bug
Status: Closed
Resolution: WON'T FIX
Project: Xerces-C++
Components:
DOM
Versions:
1.5.1
Assignee:
Reporter: Frank Balluffi
Created: Mon, 17 Dec 2001 2:22 PM
Updated: Tue, 1
:
-
Key: XERCESC-378
Summary: Memory leak in XMLReaderFactory::createXMLReader
Type: Bug
Status: Closed
Resolution: WON'T FIX
Project: Xerces-C++
Components:
SAX/SAX2
Versions:
1.7.0
Assignee:
Reporter: John
Created: Wed, 20 Mar
:
-
Key: XERCESC-452
Summary: Memory leak in ReaderMgr::createReader
Type: Bug
Status: Closed
Resolution: WON'T FIX
Project: Xerces-C++
Components:
SAX/SAX2
Versions:
1.7.0
Assignee:
Reporter: Georgi Kutiev
Created: Fri, 10 May 2
of the issue:
-
Key: XERCESC-1273
Summary: Memory leak with writeToString in DOMWriter..Urgent Plz
Type: Bug
Status: Closed
Priority: Critical
Resolution: DUPLICATE
Project: Xerces-C++
Versions
279
Summary: Memory leak with writeToString in DOMWriter
Type: Bug
Status: Unassigned
Priority: Critical
Project: Xerces-C++
Versions:
2.5.0
Assignee:
Reporter: Dee
Created: Wed, 29 Sep 2004 11:29 PM
Updated: Thu, 30 Sep 2004 8:51 AM
Descript
:
-
Key: XERCESC-1279
Summary: Memory leak with writeToString in DOMWriter
Type: Bug
Status: Unassigned
Priority: Critical
Project: Xerces-C++
Versions:
2.5.0
Assignee:
Reporter: Dee
Created: Wed, 29 Sep 2004 11:29 PM
Updated: Wed, 29 Sep
The following comment has been added to this issue:
Author: Dee
Created: Wed, 29 Sep 2004 11:30 PM
Body:
Hi,
i also tried using this snippet ..but the memory leak is still there..
std::string GetXmlStringNew(DOMNode *pNode)
{
std::string sXML = "";
try
{
DOMImpl
:
-
Key: XERCESC-1273
Summary: Memory leak with writeToString in DOMWriter..Urgent Plz
Type: Bug
Status: Unassigned
Priority: Critical
Project: Xerces-C++
Versions:
2.4.0
Assignee
273
Summary: Memory leak with writeToString in DOMWriter..Urgent Plz
Type: Bug
Status: Unassigned
Priority: Critical
Project: Xerces-C++
Versions:
2.4.0
Assignee:
Reporter: Dee
Created: Fri, 17 Sep 2004 1:48 AM
Updated: Thu, 23 Sep 2004 1:35
ew of the issue:
-
Key: XERCESC-1273
Summary: Memory leak with writeToString in DOMWriter..Urgent Plz
Type: Bug
Status: Unassigned
Priority: Critical
Project: Xerces-C++
Versions:
2.4
The following comment has been added to this issue:
Author: Dee
Created: Fri, 17 Sep 2004 3:15 AM
Body:
Hi,
i also tried using this snippet ..but the memory leak is still there..
std::string GetXmlStringNew(DOMNode *pNode)
{
std::string sXML = "";
:
-
Key: XERCESC-1273
Summary: Memory leak with writeToString in DOMWriter..Urgent Plz
Type: Bug
Status: Unassigned
Priority: Critical
Project: Xerces-C++
Versions:
2.4.0
Assignee:
Reporter: Dee
Created: Fri, 17 Sep 2004 1:48 AM
Updated: Fri
-
View the issue:
http://issues.apache.org/jira/browse/XERCESC-250
Here is an overview of the issue:
-
Key: XERCESC-250
Summary: Memory Leak in transcode
Type: Bug
Status
:
-
Key: XERCESC-1245
Summary: Memory Leak on Schema Validation Failure
Type: Bug
Status: Closed
Priority: Major
Resolution: FIXED
Project: Xerces-C++
Components:
Validating Parser (Schema) (Xerces 1.5 or up only)
Versions:
Nightly build
:
-
Key: XERCESC-1245
Summary: Memory Leak on Schema Validation Failure
Type: Bug
Status: Resolved
Priority: Major
Resolution: FIXED
Project: Xerces-C++
Components:
Validating Parser (Schema) (Xerces 1.5 or up
issue:
-
Key: XERCESC-1245
Summary: Memory Leak on Schema Validation Failure
Type: Bug
Status: Resolved
Priority: Major
Resolution: FIXED
Project: Xerces-C++
Components:
Validating Parser (S
:
-
Key: XERCESC-1245
Summary: Memory Leak on Schema Validation Failure
Type: Bug
Status: Unassigned
Priority: Major
Project: Xerces-C++
Components:
Validating Parser (Schema) (Xerces 1.5 or up only
issue:
-
Key: XERCESC-1245
Summary: Memory Leak on Schema Validation Failure
Type: Bug
Status: Unassigned
Priority: Major
Project: Xerces-C++
Components:
Validating Parser (Schema
overview of the issue:
-
Key: XERCESC-1245
Summary: Memory Leak on Schema Validation Failure
Type: Bug
Status: Unassigned
Priority: Major
Project: Xerces-C++
Components:
Validating Parser
:
-
Key: XERCESC-1245
Summary: Memory Leak on Schema Validation Failure
Type: Bug
Status: Unassigned
Priority: Major
Project: Xerces-C++
Components:
Validating Parser (Schema) (Xerces 1.5
The following issue has been updated:
Updater: Simon Kitching (mailto:[EMAIL PROTECTED])
Date: Mon, 26 Jul 2004 2:09 AM
Comment:
Test harness to demonstrate memory leak.
Run as
./harness simple.xsd good.xml 1000 --> no leak
./harness simple.xsd bad.xml 1
:
-
Key: XERCESC-1245
Summary: Memory Leak on Schema Validation Failure
Type: Bug
Status: Unassigned
Priority: Major
Project: Xerces-C++
Components:
Validating Parser (Schema) (Xerces 1.5 or up only)
Versions:
Nightly build (please specify the
i/Cambridge/IBM)
|
|Subject: Apparent memory leak from SAX2XMLReader o
error to the
ErrorHandler, which throws an exception), a memory leak occurs. The
VmSize field creeps steadily upward as repeated parse-fail cycles occur.
Is there some kind of "reset" method that needs to be called after an
ErrorHandler throws an exception in order for an SAX2XMLRea
berto
-
View the issue:
http://issues.apache.org/jira/browse/XERCESC-864
Here is an overview of the issue:
-
Key: XERCESC-864
Summary: Memory leak with writeToString in DOMWriter
Type: Bug
S
:
-
Key: XERCESC-1228
Summary: Memory leak when scanning multiple xmldocuments
Type: Bug
Status: Unassigned
Priority: Major
Project: Xerces-C++
Versions:
2.5.0
Assignee:
Reporter: Joep Simons
Created: Mon, 14 Jun 2004 1:17 AM
Updated: Mon, 14
ing. I tried to delete and create the parser before using
but this did not solve my problem.
Is this a memory leak.
Christian
-
This mail sent through IMP: http://horde.org/imp/
--
Hi,
no it does not. The internal memory structure of xerces is such
that this may appear to be the case. When you delete the document he
memory will be reclaimed. Search in the archives for more information.
Gareth
On Wed, 19 May 2004, Imran A R (RBIN/EDM1) * wrote:
>
>
> IN my l
IN my local function , am doing
DOMElement* lname = NULL;
lname = m_pDOMDocument->createElement(c_ElementName);
and i returns the lname , does it leaks any memory
Thanks
the issue:
http://issues.apache.org/jira/browse/XERCESC-989
Here is an overview of the issue:
-
Key: XERCESC-989
Summary: Memory Leak when remote-DTD occurs in XML-file
Type: Bug
Status: Resolved
-
View the issue:
http://issues.apache.org/jira/browse/XERCESC-987
Here is an overview of the issue:
-
Key: XERCESC-987
Summary: Memory leak in xerces library
Type: Bug
Status: Resolved
Resolution
gzilla/show_bug.cgi?id=27021
XMLGrammarPoolImpl::deserializeGrammars() has a memory leak
[EMAIL PROTECTED] changed:
What|Removed |Added
Status|NEW |RE
gzilla/show_bug.cgi?id=27021
XMLGrammarPoolImpl::deserializeGrammars() has a memory leak
--- Additional Comments From [EMAIL PROTECTED] 2004-02-18 05:53 ---
Created an attachment (id=10404)
Proposed patch for memory leak
--
gzilla/show_bug.cgi?id=27021
XMLGrammarPoolImpl::deserializeGrammars() has a memory leak
Summary: XMLGrammarPoolImpl::deserializeGrammars() has a memory
leak
Product: Xerces-C++
Version: Nightly build (please specify the date)
Platfor
gzilla/show_bug.cgi?id=26607
DOMElement::setIdAttribute*() memory leak
[EMAIL PROTECTED] changed:
What|Removed |Added
Status|NEW |RESOLVED
Reso
gzilla/show_bug.cgi?id=26648
SGXMLScanner::parseSchemaLocation() has a potential memory leak
[EMAIL PROTECTED] changed:
What|Removed |Added
Status|NEW |RE
gzilla/show_bug.cgi?id=22699
Memory Leak when remote-DTD occurs in XML-file
--- Additional Comments From [EMAIL PROTECTED] 2004-02-10 19:17 ---
Hi,
Can you retry this on the latest code to see if the problem is still there? I
tried a remote schema and didn't see any leaks using purify
gzilla/show_bug.cgi?id=22693
Memory leak in xerces library
--- Additional Comments From [EMAIL PROTECTED] 2004-02-10 18:31 ---
Hi Siddharth,
I just tried running the file thru SAX2Count with purify on Windows 2000 using
the latest code and no memory leaks were reported. Can you retry this
gzilla/show_bug.cgi?id=26648
SGXMLScanner::parseSchemaLocation() has a potential memory leak
--- Additional Comments From [EMAIL PROTECTED] 2004-02-03 23:28 ---
Created an attachment (id=10211)
Patch with fix
-
To unsubscr
gzilla/show_bug.cgi?id=26648
SGXMLScanner::parseSchemaLocation() has a potential memory leak
Summary: SGXMLScanner::parseSchemaLocation() has a potential
memory leak
Product: Xerces-C++
Version: Nightly build (please specify the date)
Platfor
gzilla/show_bug.cgi?id=26607
DOMElement::setIdAttribute*() memory leak
Summary: DOMElement::setIdAttribute*() memory leak
Product: Xerces-C++
Version: 2.4.0
Platform: All
OS/Version: All
Status: NEW
Severity: Normal
Pr
gzilla/show_bug.cgi?id=21990
ICULCPTranscoder::transcode memory leak
--- Additional Comments From [EMAIL PROTECTED] 2004-02-02 13:59 ---
I found a bug in my patch, sorry.
On the second call of ucnv_fromUChars(), converted string could not be null-
terminated. Another version of transcode(
I've got a use case where the memory leak found in DOMBuffer::expandCapacity
is causing me a problem. The source for this method states it is causing a
leak. From xercesc/dom/impl/DOMStringPool.cpp:
void DOMBuffer::expandCapacity(const unsigned int extraNeeded)
{
//not enough room. Cal
gzilla/show_bug.cgi?id=24173
Memory leak in DOMElementImpl
[EMAIL PROTECTED] changed:
What|Removed |Added
Status|RESOLVED|CLOSED
--- Additional Comment
gzilla/show_bug.cgi?id=24173
Memory leak in DOMElementImpl
[EMAIL PROTECTED] changed:
What|Removed |Added
Status|NEW |RESOLVED
Reso
gzilla/show_bug.cgi?id=24173
Memory leak in DOMElementImpl
Summary: Memory leak in DOMElementImpl
Product: Xerces-C++
Version: 2.3.0
Platform: PC
OS/Version: Windows NT/2K
Status: NEW
Severity: Critical
Priority:
gzilla/show_bug.cgi?id=23073
Memory leak in COM object xml4com when accessing "xml" property
[EMAIL PROTECTED] changed:
What|Removed |Added
Status|NEW
gzilla/show_bug.cgi?id=23073
Memory leak in COM object xml4com when accessing "xml" property
Summary: Memory leak in COM object xml4com when accessing "xml"
property
Product: Xerces-C++
Version: 2.3.0
Platform:
gzilla/show_bug.cgi?id=21990
ICULCPTranscoder::transcode memory leak
--- Additional Comments From [EMAIL PROTECTED] 2003-09-01 09:03 ---
I confirmed the source in CVS, and checked with my testcase.
Everything is OK.
Thanks f
gzilla/show_bug.cgi?id=21990
ICULCPTranscoder::transcode memory leak
[EMAIL PROTECTED] changed:
What|Removed |Added
Status|NEW |RESOLVED
Reso
gzilla/show_bug.cgi?id=21990
ICULCPTranscoder::transcode memory leak
--- Additional Comments From [EMAIL PROTECTED] 2003-08-31 15:13 ---
Hi,
I created a new patch. An error check is added to reconvert a string when ICU
does not terminate it. Null-termination by Xerces-code is no
gzilla/show_bug.cgi?id=21990
ICULCPTranscoder::transcode memory leak
--- Additional Comments From [EMAIL PROTECTED] 2003-08-31 14:51 ---
Created an attachment (id=8014)
testcase (encoding : euc-jp)
-
To unsubscribe,
gzilla/show_bug.cgi?id=21990
ICULCPTranscoder::transcode memory leak
--- Additional Comments From [EMAIL PROTECTED] 2003-08-27 17:04 ---
Thaks for your comment to Dave and Neil. :-)
To Dave,
>If you reserve a byte for null-termination, then you will not
>need the code to re-allocate
gzilla/show_bug.cgi?id=21990
ICULCPTranscoder::transcode memory leak
--- Additional Comments From [EMAIL PROTECTED] 2003-08-25 16:13 ---
OK, let me see if I can express this more coherently than I did in the previous
response.
If you reserve a byte for null-termination, then you will no
gzilla/show_bug.cgi?id=21990
ICULCPTranscoder::transcode memory leak
--- Additional Comments From [EMAIL PROTECTED] 2003-08-25 18:31 ---
I can see where Dave's coming from, but Shin'ya's patch doesn't seem to make
the code very much more complicated to me...
What I&#
gzilla/show_bug.cgi?id=22699
Memory Leak when remote-DTD occurs in XML-file
Summary: Memory Leak when remote-DTD occurs in XML-file
Product: Xerces-C++
Version: 2.3.0
Platform: Sun
OS/Version: Solaris
Status: NEW
Severity:
gzilla/show_bug.cgi?id=22693
Memory leak in xerces library
--- Additional Comments From [EMAIL PROTECTED] 2003-08-25 14:45 ---
Created an attachment (id=7937)
The XML document that was parsed in the leak test
-
To unsubscr
gzilla/show_bug.cgi?id=22693
Memory leak in xerces library
--- Additional Comments From [EMAIL PROTECTED] 2003-08-25 14:44 ---
Created an attachment (id=7936)
The DTD file used for leak test
-
To unsubscribe, e-mail:
gzilla/show_bug.cgi?id=22693
Memory leak in xerces library
Summary: Memory leak in xerces library
Product: Xerces-C++
Version: 2.3.0
Platform: Sun
OS/Version: Solaris
Status: NEW
Severity: Major
Priority:
gzilla/show_bug.cgi?id=21990
ICULCPTranscoder::transcode memory leak
--- Additional Comments From [EMAIL PROTECTED] 2003-08-23 20:18 ---
ICU's ucnv_fromUChars() does not terminate a converted string when 'given
buffer size' == 'converted string length'.
>That
gzilla/show_bug.cgi?id=21990
ICULCPTranscoder::transcode memory leak
--- Additional Comments From [EMAIL PROTECTED] 2003-08-22 21:16 ---
Wouldn't it be simpler just to exclude the extra character from the initial
call, so either case results in a buffer overflow? For example:
UEr
gzilla/show_bug.cgi?id=21990
ICULCPTranscoder::transcode memory leak
[EMAIL PROTECTED] changed:
What|Removed |Added
Summary|ICULCPTranscoder::transcode |ICULCPTranscoder::tra
gzilla/show_bug.cgi?id=21990
ICULCPTranscoder::transcode memory leak
Summary: ICULCPTranscoder::transcode memory leak
Product: Xerces-C++
Version: 2.3.0
Platform: All
OS/Version: Linux
Status: NEW
Severity: Normal
Pr
gzilla/show_bug.cgi?id=4640
Memory leak when creating nodes
[EMAIL PROTECTED] changed:
What|Removed |Added
Status|NEW |RESOLVED
Reso
gzilla/show_bug.cgi?id=5387
Memory Leak
[EMAIL PROTECTED] changed:
What|Removed |Added
Status|NEW |RESOLVED
Reso
gzilla/show_bug.cgi?id=5468
Memory Leak
[EMAIL PROTECTED] changed:
What|Removed |Added
AssignedTo|[EMAIL PROTECTED] |[EMAIL PRO
gzilla/show_bug.cgi?id=16151
Memory leak in DTDScanner with ill-formed DTD declaration
[EMAIL PROTECTED] changed:
What|Removed |Added
Status|VERIFIED|
We are using xml extensively in our application which runs on HP Unix.
When I ran purify against our application, I see a lot of memory leaks
from the xml libraries. One of such leaks is as shown below:
MLK: 193256 bytes leaked in 6902 blocks
This memory was allocated from:
gzilla/show_bug.cgi?id=16151
Memory leak in DTDScanner with ill-formed DTD declaration
[EMAIL PROTECTED] changed:
What|Removed |Added
Status|RESOLVED|VE
gzilla/show_bug.cgi?id=16151
Memory leak in DTDScanner with ill-formed DTD declaration
--- Additional Comments From [EMAIL PROTECTED] 2003-01-17 01:57 ---
Created an attachment (id=4472)
First test case
-
To unsubscribe,
gzilla/show_bug.cgi?id=16151
Memory leak in DTDScanner with ill-formed DTD declaration
--- Additional Comments From [EMAIL PROTECTED] 2003-01-17 01:58 ---
Created an attachment (id=4473)
Second test case
-
To unsubscribe,
gzilla/show_bug.cgi?id=16151
Memory leak in DTDScanner with ill-formed DTD declaration
--- Additional Comments From [EMAIL PROTECTED] 2003-01-17 01:54 ---
Here are two test files. One is for each line of code I patched.
--
gzilla/show_bug.cgi?id=16151
Memory leak in DTDScanner with ill-formed DTD declaration
[EMAIL PROTECTED] changed:
What|Removed |Added
Status|NEW |RE
1 - 100 of 261 matches
Mail list logo
