[jira] [Resolved] (XERCESC-2234) Xerces does not correctly interpret negative jaxp processing limits as "NO LIMIT"
[
https://issues.apache.org/jira/browse/XERCESC-2234?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Alberto Massari resolved XERCESC-2234.
--
Resolution: Invalid
This is the JIRA for Xerces-C++, not Xerces-J. Please report it to the correct
project
> Xerces does not correctly interpret negative jaxp processing limits as "NO
> LIMIT"
> --
>
> Key: XERCESC-2234
> URL: https://issues.apache.org/jira/browse/XERCESC-2234
> Project: Xerces-C++
> Issue Type: Bug
> Components: Validating Parser (XML Schema)
>Affects Versions: 3.2.3
>Reporter: Spencer Stecko
>Priority: Minor
>
> According to the oracle documentation, many of the limits to jaxp processing
> settings can be set to zero or a number less than zero to indicate no limit:
> [https://docs.oracle.com/javase/tutorial/jaxp/limits/limits.html]
>
> However, when I do this (with jdk.xml.maxOccurLimit), I get the following
> stack trace:
>
> {code:java}
> Caused by: org.xml.sax.SAXParseException: Current configuration of the parser
> doesn't allow the expansion of a content model for a complex type to contain
> more than -1 nodes.
> at
> com.sun.org.apache.xerces.internal.util.ErrorHandlerWrapper.createSAXParseException(ErrorHandlerWrapper.java:204)
> at
> com.sun.org.apache.xerces.internal.util.ErrorHandlerWrapper.fatalError(ErrorHandlerWrapper.java:178)
> at
> com.sun.org.apache.xerces.internal.impl.XMLErrorReporter.reportError(XMLErrorReporter.java:400)
> at
> com.sun.org.apache.xerces.internal.impl.xs.traversers.XSDHandler.reportSchemaErr(XSDHandler.java:4253)
> at
> com.sun.org.apache.xerces.internal.impl.xs.traversers.XSDHandler.reportSchemaFatalError(XSDHandler.java:4232)
> at
> com.sun.org.apache.xerces.internal.impl.xs.traversers.XSAttributeChecker.reportSchemaFatalError(XSAttributeChecker.java:1569)
> at
> com.sun.org.apache.xerces.internal.impl.xs.traversers.XSAttributeChecker.checkAttributes(XSAttributeChecker.java:1201)
> at
> com.sun.org.apache.xerces.internal.impl.xs.traversers.XSAttributeChecker.checkAttributes(XSAttributeChecker.java:960)
> at
> com.sun.org.apache.xerces.internal.impl.xs.traversers.XSDAbstractParticleTraverser.traverseSeqChoice(XSDAbstractParticleTraverser.java:204)
> at
> com.sun.org.apache.xerces.internal.impl.xs.traversers.XSDAbstractParticleTraverser.traverseSequence(XSDAbstractParticleTraverser.java:160)
> at
> com.sun.org.apache.xerces.internal.impl.xs.traversers.XSDComplexTypeTraverser.processComplexContent(XSDComplexTypeTraverser.java:1043)
> at
> com.sun.org.apache.xerces.internal.impl.xs.traversers.XSDComplexTypeTraverser.traverseComplexTypeDecl(XSDComplexTypeTraverser.java:335)
> at
> com.sun.org.apache.xerces.internal.impl.xs.traversers.XSDComplexTypeTraverser.traverseGlobal(XSDComplexTypeTraverser.java:191)
> at
> com.sun.org.apache.xerces.internal.impl.xs.traversers.XSDHandler.traverseSchemas(XSDHandler.java:1479)
> at
> com.sun.org.apache.xerces.internal.impl.xs.traversers.XSDHandler.parseSchema(XSDHandler.java:662)
> at
> com.sun.org.apache.xerces.internal.impl.xs.XMLSchemaLoader.loadSchema(XMLSchemaLoader.java:617)
> at
> com.sun.org.apache.xerces.internal.impl.xs.XMLSchemaLoader.loadGrammar(XMLSchemaLoader.java:576)
> at
> com.sun.org.apache.xerces.internal.impl.xs.XMLSchemaLoader.loadGrammar(XMLSchemaLoader.java:542)
> at
> com.sun.org.apache.xerces.internal.jaxp.validation.XMLSchemaFactory.newSchema(XMLSchemaFactory.java:276)
> at javax.xml.validation.SchemaFactory.newSchema(SchemaFactory.java:669)
> {code}
>
> I have no idea what this repo I found is, but it appears to include some sort
> of mirror of the apache xerces codebase, and the bug is clearly visible here:
> [https://github.com/elastic/openjdkMirror/blob/f437b1097e6a395e91382cdfc7ec94355b554c51/jaxp/src/com/sun/org/apache/xerces/internal/utils/XMLSecurityManager.java#L378]
>
>
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
-
To unsubscribe, e-mail: c-dev-unsubscr...@xerces.apache.org
For additional commands, e-mail: c-dev-h...@xerces.apache.org
[jira] [Resolved] (XERCESC-2177) invalid windows version check for `onXPOrLater`
[
https://issues.apache.org/jira/browse/XERCESC-2177?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Alberto Massari resolved XERCESC-2177.
--
Resolution: Fixed
> invalid windows version check for `onXPOrLater`
> ---
>
> Key: XERCESC-2177
> URL: https://issues.apache.org/jira/browse/XERCESC-2177
> Project: Xerces-C++
> Issue Type: Bug
> Components: Utilities
>Affects Versions: 3.2.0, 3.2.1, 3.2.2
> Environment: win10 x64
>Reporter: Vvv
>Assignee: Alberto Massari
>Priority: Minor
> Labels: beginner, easyfix, windows
> Fix For: 3.2.3
>
> Original Estimate: 5m
> Remaining Estimate: 5m
>
> in
> {{xerces-c-3.2.2\src\xercesc\util\Transcoders\Win32\Win32TransService.cpp:324}}
>
> {{ if ((OSVer.dwPlatformId == VER_PLATFORM_WIN32_NT) &&}}
> {{ ((OSVer.dwMajorVersion == 5) && (OSVer.dwMinorVersion > 0)))}}
> {{ {}}
> {{ onXPOrLater = true;}}
> {{ }}}
> on win10 {{OSVer.dwMajorVersion = 6}}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: c-dev-unsubscr...@xerces.apache.org
For additional commands, e-mail: c-dev-h...@xerces.apache.org
[jira] [Assigned] (XERCESC-2177) invalid windows version check for `onXPOrLater`
[
https://issues.apache.org/jira/browse/XERCESC-2177?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Alberto Massari reassigned XERCESC-2177:
Assignee: Alberto Massari
> invalid windows version check for `onXPOrLater`
> ---
>
> Key: XERCESC-2177
> URL: https://issues.apache.org/jira/browse/XERCESC-2177
> Project: Xerces-C++
> Issue Type: Bug
> Components: Utilities
>Affects Versions: 3.2.0, 3.2.1, 3.2.2
> Environment: win10 x64
>Reporter: Vvv
>Assignee: Alberto Massari
>Priority: Minor
> Labels: beginner, easyfix, windows
> Fix For: 3.2.3
>
> Original Estimate: 5m
> Remaining Estimate: 5m
>
> in
> {{xerces-c-3.2.2\src\xercesc\util\Transcoders\Win32\Win32TransService.cpp:324}}
>
> {{ if ((OSVer.dwPlatformId == VER_PLATFORM_WIN32_NT) &&}}
> {{ ((OSVer.dwMajorVersion == 5) && (OSVer.dwMinorVersion > 0)))}}
> {{ {}}
> {{ onXPOrLater = true;}}
> {{ }}}
> on win10 {{OSVer.dwMajorVersion = 6}}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: c-dev-unsubscr...@xerces.apache.org
For additional commands, e-mail: c-dev-h...@xerces.apache.org
[jira] [Resolved] (XERCESC-2179) access violation in win32transservice.cpp with 64 bit compile
[ https://issues.apache.org/jira/browse/XERCESC-2179?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alberto Massari resolved XERCESC-2179. -- Resolution: Not A Problem This seems a problem due to multiple Initialize/Terminate calls > access violation in win32transservice.cpp with 64 bit compile > - > > Key: XERCESC-2179 > URL: https://issues.apache.org/jira/browse/XERCESC-2179 > Project: Xerces-C++ > Issue Type: Bug > Components: DOM >Affects Versions: 3.2.2 >Reporter: martin goodall >Assignee: Alberto Massari >Priority: Blocker > Fix For: 3.2.3 > > Attachments: Win32TransService.cpp > > > calls to ::Reg... to get registry info are passing in stack variables that > are 8 bytes long into functions that overwrite 16 bytes, causing memory > overwrite and very random segs. -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: c-dev-unsubscr...@xerces.apache.org For additional commands, e-mail: c-dev-h...@xerces.apache.org
[jira] [Resolved] (XERCESC-2180) Handle surrogate pairs when reading a QName instead of ASSERTing
[
https://issues.apache.org/jira/browse/XERCESC-2180?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Alberto Massari resolved XERCESC-2180.
--
Resolution: Fixed
> Handle surrogate pairs when reading a QName instead of ASSERTing
>
>
> Key: XERCESC-2180
> URL: https://issues.apache.org/jira/browse/XERCESC-2180
> Project: Xerces-C++
> Issue Type: Bug
> Components: Miscellaneous
>Affects Versions: 3.2.0, 3.2.1, 3.2.2
>Reporter: Alberto Massari
>Assignee: Alberto Massari
>Priority: Major
> Fix For: 3.2.3
>
> Attachments: crash.xml
>
>
> As discovered by Vincent Ulitzsch:
> {quote}The assertion fails when parsing a malformed xml-file, we attached a
> crashing testcase. We would suggest fixing this assertion, since it opens up
> the possibility
> for Denial of Service attacks via malformed xml files.{quote}
> The code expects that tre transcoder places a pair of surrogate characters in
> the Unicode buffers, but the UTF16 transcoder simply copies the data without
> checking if it ends in the middle of a surrogate pair. So the fix is to
> replace the assertion with a request for more data, and if there is no data
> or if it's not the other part of the surrogate, exit the method as we would
> be doing if we found the invalid character inside the buffer
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: c-dev-unsubscr...@xerces.apache.org
For additional commands, e-mail: c-dev-h...@xerces.apache.org
[jira] [Assigned] (XERCESC-2180) Handle surrogate pairs when reading a QName instead of ASSERTing
[
https://issues.apache.org/jira/browse/XERCESC-2180?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Alberto Massari reassigned XERCESC-2180:
Assignee: Alberto Massari
> Handle surrogate pairs when reading a QName instead of ASSERTing
>
>
> Key: XERCESC-2180
> URL: https://issues.apache.org/jira/browse/XERCESC-2180
> Project: Xerces-C++
> Issue Type: Bug
> Components: Miscellaneous
>Affects Versions: 3.2.0, 3.2.1, 3.2.2
>Reporter: Alberto Massari
>Assignee: Alberto Massari
>Priority: Major
> Fix For: 3.2.3
>
> Attachments: crash.xml
>
>
> As discovered by Vincent Ulitzsch:
> {quote}The assertion fails when parsing a malformed xml-file, we attached a
> crashing testcase. We would suggest fixing this assertion, since it opens up
> the possibility
> for Denial of Service attacks via malformed xml files.{quote}
> The code expects that tre transcoder places a pair of surrogate characters in
> the Unicode buffers, but the UTF16 transcoder simply copies the data without
> checking if it ends in the middle of a surrogate pair. So the fix is to
> replace the assertion with a request for more data, and if there is no data
> or if it's not the other part of the surrogate, exit the method as we would
> be doing if we found the invalid character inside the buffer
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: c-dev-unsubscr...@xerces.apache.org
For additional commands, e-mail: c-dev-h...@xerces.apache.org
[jira] [Commented] (XERCESC-2180) Handle surrogate pairs when reading a QName instead of ASSERTing
[
https://issues.apache.org/jira/browse/XERCESC-2180?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16991800#comment-16991800
]
Alberto Massari commented on XERCESC-2180:
--
I have a fix in the ReaderMgr; I added a test in the regression suite, but I
need to make some changes in the test suite to avoid using the XMLSchema
support for XML-only tests
> Handle surrogate pairs when reading a QName instead of ASSERTing
>
>
> Key: XERCESC-2180
> URL: https://issues.apache.org/jira/browse/XERCESC-2180
> Project: Xerces-C++
> Issue Type: Bug
> Components: Miscellaneous
>Affects Versions: 3.2.0, 3.2.1, 3.2.2
>Reporter: Alberto Massari
>Priority: Major
> Fix For: 3.2.3
>
> Attachments: crash.xml
>
>
> As discovered by Vincent Ulitzsch:
> {quote}The assertion fails when parsing a malformed xml-file, we attached a
> crashing testcase. We would suggest fixing this assertion, since it opens up
> the possibility
> for Denial of Service attacks via malformed xml files.{quote}
> The code expects that tre transcoder places a pair of surrogate characters in
> the Unicode buffers, but the UTF16 transcoder simply copies the data without
> checking if it ends in the middle of a surrogate pair. So the fix is to
> replace the assertion with a request for more data, and if there is no data
> or if it's not the other part of the surrogate, exit the method as we would
> be doing if we found the invalid character inside the buffer
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: c-dev-unsubscr...@xerces.apache.org
For additional commands, e-mail: c-dev-h...@xerces.apache.org
[jira] [Created] (XERCESC-2180) Handle surrogate pairs when reading a QName instead of ASSERTing
Alberto Massari created XERCESC-2180:
Summary: Handle surrogate pairs when reading a QName instead of
ASSERTing
Key: XERCESC-2180
URL: https://issues.apache.org/jira/browse/XERCESC-2180
Project: Xerces-C++
Issue Type: Bug
Components: Utilities
Reporter: Alberto Massari
Assignee: Alberto Massari
Attachments: crash.xml
As discovered by Vincent Ulitzsch:
{quote}The assertion fails when parsing a malformed xml-file, we attached a
crashing testcase. We would suggest fixing this assertion, since it opens up
the possibility
for Denial of Service attacks via malformed xml files.{quote}
The code expects that tre transcoder places a pair of surrogate characters in
the Unicode buffers, but the UTF16 transcoder simply copies the data without
checking if it ends in the middle of a surrogate pair. So the fix is to replace
the assertion with a request for more data, and if there is no data or if it's
not the other part of the surrogate, exit the method as we would be doing if we
found the invalid character inside the buffer
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: c-dev-unsubscr...@xerces.apache.org
For additional commands, e-mail: c-dev-h...@xerces.apache.org
[jira] [Commented] (XERCESC-2179) access violation in win32transservice.cpp with 64 bit compile
[
https://issues.apache.org/jira/browse/XERCESC-2179?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16966771#comment-16966771
]
Alberto Massari commented on XERCESC-2179:
--
That code is correct too:
{code}
362 unsigned long theSize;
...
405 unsigned long theType;
406 unsigned int CPId;
407 unsigned int IEId;
408
409 theSize = sizeof(unsigned int);
410 if (::RegQueryValueExA
411 (
412 encodingKey
413 , "Codepage"
414 , 0
415 , &theType
416 , (unsigned char*)&CPId
417 , &theSize) != ERROR_SUCCESS)
418 {
419 ::RegCloseKey(encodingKey);
420 continue;
421 }
{code}
The Codepage (and the InternetEncoding quried later) are defined as REG_DWORD,
so they need just 32 bit to be stored, and both the CPId and the
sizeof(unsigned int) are enough to hold its value, with no need to add space
for a NULL terminator that in any case would be a wrong value to add just to
theSize (because CPId would not have room for 5 bytes, only for 4).
Changing the code to use the Windows macros would help reading the code, but I
don't see an actual issue here
> access violation in win32transservice.cpp with 64 bit compile
> -
>
> Key: XERCESC-2179
> URL: https://issues.apache.org/jira/browse/XERCESC-2179
> Project: Xerces-C++
> Issue Type: Bug
> Components: DOM
>Affects Versions: 3.2.2
>Reporter: martin goodall
>Assignee: Alberto Massari
>Priority: Blocker
> Fix For: 3.2.3
>
> Attachments: Win32TransService.cpp
>
>
> calls to ::Reg... to get registry info are passing in stack variables that
> are 8 bytes long into functions that overwrite 16 bytes, causing memory
> overwrite and very random segs.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: c-dev-unsubscr...@xerces.apache.org
For additional commands, e-mail: c-dev-h...@xerces.apache.org
[jira] [Comment Edited] (XERCESC-2179) access violation in win32transservice.cpp with 64 bit compile
[
https://issues.apache.org/jira/browse/XERCESC-2179?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16966771#comment-16966771
]
Alberto Massari edited comment on XERCESC-2179 at 11/4/19 3:50 PM:
---
That code is correct too:
{code}
362 unsigned long theSize;
...
405 unsigned long theType;
406 unsigned int CPId;
407 unsigned int IEId;
408
409 theSize = sizeof(unsigned int);
410 if (::RegQueryValueExA
411 (
412 encodingKey
413 , "Codepage"
414 , 0
415 , &theType
416 , (unsigned char*)&CPId
417 , &theSize) != ERROR_SUCCESS)
418 {
419 ::RegCloseKey(encodingKey);
420 continue;
421 }
{code}
The Codepage (and the InternetEncoding queried later) are defined as REG_DWORD,
so they need just 32 bit to be stored, and both the CPId and the
sizeof(unsigned int) are enough to hold its value, with no need to add space
for a NULL terminator that in any case would be a wrong value to add just to
theSize (because CPId would not have room for 5 bytes, only for 4).
Changing the code to use the Windows macros would help reading the code, but I
don't see an actual issue here
was (Author: amassari):
That code is correct too:
{code}
362 unsigned long theSize;
...
405 unsigned long theType;
406 unsigned int CPId;
407 unsigned int IEId;
408
409 theSize = sizeof(unsigned int);
410 if (::RegQueryValueExA
411 (
412 encodingKey
413 , "Codepage"
414 , 0
415 , &theType
416 , (unsigned char*)&CPId
417 , &theSize) != ERROR_SUCCESS)
418 {
419 ::RegCloseKey(encodingKey);
420 continue;
421 }
{code}
The Codepage (and the InternetEncoding quried later) are defined as REG_DWORD,
so they need just 32 bit to be stored, and both the CPId and the
sizeof(unsigned int) are enough to hold its value, with no need to add space
for a NULL terminator that in any case would be a wrong value to add just to
theSize (because CPId would not have room for 5 bytes, only for 4).
Changing the code to use the Windows macros would help reading the code, but I
don't see an actual issue here
> access violation in win32transservice.cpp with 64 bit compile
> -
>
> Key: XERCESC-2179
> URL: https://issues.apache.org/jira/browse/XERCESC-2179
> Project: Xerces-C++
> Issue Type: Bug
> Components: DOM
>Affects Versions: 3.2.2
>Reporter: martin goodall
>Assignee: Alberto Massari
>Priority: Blocker
> Fix For: 3.2.3
>
> Attachments: Win32TransService.cpp
>
>
> calls to ::Reg... to get registry info are passing in stack variables that
> are 8 bytes long into functions that overwrite 16 bytes, causing memory
> overwrite and very random segs.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: c-dev-unsubscr...@xerces.apache.org
For additional commands, e-mail: c-dev-h...@xerces.apache.org
[jira] [Comment Edited] (XERCESC-2179) access violation in win32transservice.cpp with 64 bit compile
[
https://issues.apache.org/jira/browse/XERCESC-2179?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16966743#comment-16966743
]
Alberto Massari edited comment on XERCESC-2179 at 11/4/19 3:23 PM:
---
The current code in the trunk is here:
[http://svn.apache.org/viewvc/xerces/c/trunk/src/xercesc/util/Transcoders/Win32/Win32TransService.cpp?view=markup#l159]
{code}
{
163 unsigned long theType;
164 unsigned long theSize = nameBufSz;
165 return (::RegQueryValueExA
166 (
167 encodingKey
168 , "AliasForCharset"
169 , 0
170 , &theType
171 , (unsigned char*)aliasBuf
172 , &theSize
173 ) == ERROR_SUCCESS);
174 }
{code}
theType is not unsigned int, it's unsigned long that is identical to DWORD
theType after the preprocessor expands the macro.
was (Author: amassari):
The current code in the trunk is here:
[http://svn.apache.org/viewvc/xerces/c/trunk/src/xercesc/util/Transcoders/Win32/Win32TransService.cpp?view=markup#l159]
|{|
|[163|http://svn.apache.org/viewvc/xerces/c/trunk/src/xercesc/util/Transcoders/Win32/Win32TransService.cpp?view=markup#l163]|unsigned
long theType;|
|[164|http://svn.apache.org/viewvc/xerces/c/trunk/src/xercesc/util/Transcoders/Win32/Win32TransService.cpp?view=markup#l164]|unsigned
long theSize = nameBufSz;|
|[165|http://svn.apache.org/viewvc/xerces/c/trunk/src/xercesc/util/Transcoders/Win32/Win32TransService.cpp?view=markup#l165]|return
(::RegQueryValueExA|
|[166|http://svn.apache.org/viewvc/xerces/c/trunk/src/xercesc/util/Transcoders/Win32/Win32TransService.cpp?view=markup#l166]|(|
|[167|http://svn.apache.org/viewvc/xerces/c/trunk/src/xercesc/util/Transcoders/Win32/Win32TransService.cpp?view=markup#l167]|encodingKey|
|[168|http://svn.apache.org/viewvc/xerces/c/trunk/src/xercesc/util/Transcoders/Win32/Win32TransService.cpp?view=markup#l168]|,
"AliasForCharset"|
|[169|http://svn.apache.org/viewvc/xerces/c/trunk/src/xercesc/util/Transcoders/Win32/Win32TransService.cpp?view=markup#l169]|,
0|
|[170|http://svn.apache.org/viewvc/xerces/c/trunk/src/xercesc/util/Transcoders/Win32/Win32TransService.cpp?view=markup#l170]|,
&theType|
|[171|http://svn.apache.org/viewvc/xerces/c/trunk/src/xercesc/util/Transcoders/Win32/Win32TransService.cpp?view=markup#l171]|,
(unsigned char*)aliasBuf|
|[172|http://svn.apache.org/viewvc/xerces/c/trunk/src/xercesc/util/Transcoders/Win32/Win32TransService.cpp?view=markup#l172]|,
&theSize|
|[173|http://svn.apache.org/viewvc/xerces/c/trunk/src/xercesc/util/Transcoders/Win32/Win32TransService.cpp?view=markup#l173]|)
== ERROR_SUCCESS);|
|[174|http://svn.apache.org/viewvc/xerces/c/trunk/src/xercesc/util/Transcoders/Win32/Win32TransService.cpp?view=markup#l174]|}|
theType is not unsigned int, it's unsigned long that is identical to DWORD
theType after the preprocessor expands the macro.
> access violation in win32transservice.cpp with 64 bit compile
> -
>
> Key: XERCESC-2179
> URL: https://issues.apache.org/jira/browse/XERCESC-2179
> Project: Xerces-C++
> Issue Type: Bug
> Components: DOM
>Affects Versions: 3.2.2
>Reporter: martin goodall
>Assignee: Alberto Massari
>Priority: Blocker
> Fix For: 3.2.3
>
> Attachments: Win32TransService.cpp
>
>
> calls to ::Reg... to get registry info are passing in stack variables that
> are 8 bytes long into functions that overwrite 16 bytes, causing memory
> overwrite and very random segs.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: c-dev-unsubscr...@xerces.apache.org
For additional commands, e-mail: c-dev-h...@xerces.apache.org
[jira] [Commented] (XERCESC-2179) access violation in win32transservice.cpp with 64 bit compile
[
https://issues.apache.org/jira/browse/XERCESC-2179?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16966743#comment-16966743
]
Alberto Massari commented on XERCESC-2179:
--
The current code in the trunk is here:
[http://svn.apache.org/viewvc/xerces/c/trunk/src/xercesc/util/Transcoders/Win32/Win32TransService.cpp?view=markup#l159]
|{|
|[163|http://svn.apache.org/viewvc/xerces/c/trunk/src/xercesc/util/Transcoders/Win32/Win32TransService.cpp?view=markup#l163]|unsigned
long theType;|
|[164|http://svn.apache.org/viewvc/xerces/c/trunk/src/xercesc/util/Transcoders/Win32/Win32TransService.cpp?view=markup#l164]|unsigned
long theSize = nameBufSz;|
|[165|http://svn.apache.org/viewvc/xerces/c/trunk/src/xercesc/util/Transcoders/Win32/Win32TransService.cpp?view=markup#l165]|return
(::RegQueryValueExA|
|[166|http://svn.apache.org/viewvc/xerces/c/trunk/src/xercesc/util/Transcoders/Win32/Win32TransService.cpp?view=markup#l166]|(|
|[167|http://svn.apache.org/viewvc/xerces/c/trunk/src/xercesc/util/Transcoders/Win32/Win32TransService.cpp?view=markup#l167]|encodingKey|
|[168|http://svn.apache.org/viewvc/xerces/c/trunk/src/xercesc/util/Transcoders/Win32/Win32TransService.cpp?view=markup#l168]|,
"AliasForCharset"|
|[169|http://svn.apache.org/viewvc/xerces/c/trunk/src/xercesc/util/Transcoders/Win32/Win32TransService.cpp?view=markup#l169]|,
0|
|[170|http://svn.apache.org/viewvc/xerces/c/trunk/src/xercesc/util/Transcoders/Win32/Win32TransService.cpp?view=markup#l170]|,
&theType|
|[171|http://svn.apache.org/viewvc/xerces/c/trunk/src/xercesc/util/Transcoders/Win32/Win32TransService.cpp?view=markup#l171]|,
(unsigned char*)aliasBuf|
|[172|http://svn.apache.org/viewvc/xerces/c/trunk/src/xercesc/util/Transcoders/Win32/Win32TransService.cpp?view=markup#l172]|,
&theSize|
|[173|http://svn.apache.org/viewvc/xerces/c/trunk/src/xercesc/util/Transcoders/Win32/Win32TransService.cpp?view=markup#l173]|)
== ERROR_SUCCESS);|
|[174|http://svn.apache.org/viewvc/xerces/c/trunk/src/xercesc/util/Transcoders/Win32/Win32TransService.cpp?view=markup#l174]|}|
theType is not unsigned int, it's unsigned long that is identical to DWORD
theType after the preprocessor expands the macro.
> access violation in win32transservice.cpp with 64 bit compile
> -
>
> Key: XERCESC-2179
> URL: https://issues.apache.org/jira/browse/XERCESC-2179
> Project: Xerces-C++
> Issue Type: Bug
> Components: DOM
>Affects Versions: 3.2.2
>Reporter: martin goodall
>Assignee: Alberto Massari
>Priority: Blocker
> Fix For: 3.2.3
>
> Attachments: Win32TransService.cpp
>
>
> calls to ::Reg... to get registry info are passing in stack variables that
> are 8 bytes long into functions that overwrite 16 bytes, causing memory
> overwrite and very random segs.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: c-dev-unsubscr...@xerces.apache.org
For additional commands, e-mail: c-dev-h...@xerces.apache.org
[jira] [Commented] (XERCESC-2179) access violation in win32transservice.cpp with 64 bit compile
[
https://issues.apache.org/jira/browse/XERCESC-2179?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16966649#comment-16966649
]
Alberto Massari commented on XERCESC-2179:
--
Don't get me wrong, I'm not questioning the size of the data. I am saying that
the code
unsigned long theSize;
and
DWORD theSize;
are identical, and calling RegQueryValueExA using &theSize is still creating
the correct 64 bit pointer to a variable of the expected size.
As for adding the the +1, it would make a difference only when attempting to
read a string from the registry that is exaclty 1024 characters long. In that
case, by invoking the API with a value of 1024 (even if the buffer has been
allocated with a storage for 1025 bytes), we would get a ERROR_MORE_DATA
instead of a ERROR_SUCCESS. No memory overrun, just a failure to load that
registry entry (but there should be no encoding with a name so big).
When the registry key is a number, the space for the NULL terminator is not
added ("If the data has the REG_SZ, REG_MULTI_SZ or REG_EXPAND_SZ type, this
size includes any terminating *null* character or characters unless the data
was stored without them")
> access violation in win32transservice.cpp with 64 bit compile
> -
>
> Key: XERCESC-2179
> URL: https://issues.apache.org/jira/browse/XERCESC-2179
> Project: Xerces-C++
> Issue Type: Bug
> Components: DOM
>Affects Versions: 3.2.2
>Reporter: martin goodall
>Assignee: Alberto Massari
>Priority: Blocker
> Fix For: 3.2.3
>
> Attachments: Win32TransService.cpp
>
>
> calls to ::Reg... to get registry info are passing in stack variables that
> are 8 bytes long into functions that overwrite 16 bytes, causing memory
> overwrite and very random segs.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: c-dev-unsubscr...@xerces.apache.org
For additional commands, e-mail: c-dev-h...@xerces.apache.org
[jira] [Commented] (XERCESC-2179) access violation in win32transservice.cpp with 64 bit compile
[
https://issues.apache.org/jira/browse/XERCESC-2179?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16966506#comment-16966506
]
Alberto Massari commented on XERCESC-2179:
--
The definition for RegQueryValueExA
([https://docs.microsoft.com/en-us/windows/win32/api/winreg/nf-winreg-regqueryvalueexa)]
uses LPDWORD, but DWORD is defined as "unsigned long"
([https://docs.microsoft.com/en-us/windows/win32/winprog/windows-data-types)]
|*DWORD*|A 32-bit unsigned integer. The range is 0 through 4294967295 decimal.
This type is declared in IntSafe.h as follows:
{{typedef unsigned long DWORD;}}|
So, there should be no difference between an unsigned long and a DWORD.
As for the changes that add a +1 to some string lengths, the size of the buffer
is set to 1024, and it should be big enough to hold any possible encoding name;
in other cases the data to be read is a number, so the NULL terminator would
not be added.
Are you targeting a non-desktop version of Windows? I don't see how that code
could fail
> access violation in win32transservice.cpp with 64 bit compile
> -
>
> Key: XERCESC-2179
> URL: https://issues.apache.org/jira/browse/XERCESC-2179
> Project: Xerces-C++
> Issue Type: Bug
> Components: DOM
>Affects Versions: 3.2.2
>Reporter: martin goodall
>Assignee: Alberto Massari
>Priority: Blocker
> Fix For: 3.2.3
>
> Attachments: Win32TransService.cpp
>
>
> calls to ::Reg... to get registry info are passing in stack variables that
> are 8 bytes long into functions that overwrite 16 bytes, causing memory
> overwrite and very random segs.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: c-dev-unsubscr...@xerces.apache.org
For additional commands, e-mail: c-dev-h...@xerces.apache.org
[jira] [Assigned] (XERCESC-2179) access violation in win32transservice.cpp with 64 bit compile
[ https://issues.apache.org/jira/browse/XERCESC-2179?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alberto Massari reassigned XERCESC-2179: Assignee: Alberto Massari > access violation in win32transservice.cpp with 64 bit compile > - > > Key: XERCESC-2179 > URL: https://issues.apache.org/jira/browse/XERCESC-2179 > Project: Xerces-C++ > Issue Type: Bug > Components: DOM >Affects Versions: 3.2.2 >Reporter: martin goodall >Assignee: Alberto Massari >Priority: Blocker > Fix For: 3.2.3 > > Attachments: Win32TransService.cpp > > > calls to ::Reg... to get registry info are passing in stack variables that > are 8 bytes long into functions that overwrite 16 bytes, causing memory > overwrite and very random segs. -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: c-dev-unsubscr...@xerces.apache.org For additional commands, e-mail: c-dev-h...@xerces.apache.org
[jira] [Commented] (XERCESC-2088) Bad casting from DOMTextImpl to DOMElementImpl
[
https://issues.apache.org/jira/browse/XERCESC-2088?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15991421#comment-15991421
]
Alberto Massari commented on XERCESC-2088:
--
Let's say "we're depending", I am not the author of that code...
> Bad casting from DOMTextImpl to DOMElementImpl
> --
>
> Key: XERCESC-2088
> URL: https://issues.apache.org/jira/browse/XERCESC-2088
> Project: Xerces-C++
> Issue Type: Bug
> Components: DOM
>Affects Versions: 3.1.1, 3.1.2, 3.1.3, 3.1.4
> Environment: ubuntu 16.04 LTS, Intel(R) Core(TM) i7-6700 CPU @
> 3.40GHz, 16GB
>Reporter: Yuseok Jeon
> Fix For: 3.2.0
>
> Attachments: Actual_result.txt, relationship_tree.jpeg
>
>
> Hi all,
> Our recently developed type confusion detection tool reports a type_confusion
> error in the "xercesc/dom/imple/DOMCasts.hpp"
> xercesc/dom/imple/DOMCasts.hpp, line 146
> static inline DOMNodeImpl *castToNodeImpl(const DOMNode *p)
> {
> DOMElementImpl *pE = (DOMElementImpl *)p;
> return &(pE->fNode);
> }
> p is pointing to the object allocated as DOMTextImpl, and it is casted into
> DOMElementImpl. However, since DOMElementImpl is not a subobject of
> DOMTextImpl, it is violating C++ standard rules 5.2.9/11 (down casting is
> undefined if the object that the pointer to be casted points to is not a
> suboject of down casting type) and causes undefined behaviors.
> There are similar type-confusion cases as below links.
> - (libstdc++) https://gcc.gnu.org/bugzilla/show_bug.cgi?id=60734
> - (Firefox) https://bugzilla.mozilla.org/show_bug.cgi?id=1074280
> I attached a actual type confusion report and object relationship
> information.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
-
To unsubscribe, e-mail: c-dev-unsubscr...@xerces.apache.org
For additional commands, e-mail: c-dev-h...@xerces.apache.org
[jira] [Commented] (XERCESC-2088) Bad casting from DOMTextImpl to DOMElementImpl
[
https://issues.apache.org/jira/browse/XERCESC-2088?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15991345#comment-15991345
]
Alberto Massari commented on XERCESC-2088:
--
This is a cast required by the fact that each implementation class derives only
from the interface class, and includes the implementation of the basic methods
from DOMNode by embedding a DOMNodeImpl instance. This instance is always the
first member of the implementation class, so actually it doesn't matter that
the method does a cast to DOMElementImpl, as any other class would be just
fine. If the compiler doesn't accept a C-style cast, maybe a
reinterpret_cast could work
> Bad casting from DOMTextImpl to DOMElementImpl
> --
>
> Key: XERCESC-2088
> URL: https://issues.apache.org/jira/browse/XERCESC-2088
> Project: Xerces-C++
> Issue Type: Bug
> Components: DOM
>Affects Versions: 3.1.1, 3.1.2, 3.1.3, 3.1.4
> Environment: ubuntu 16.04 LTS, Intel(R) Core(TM) i7-6700 CPU @
> 3.40GHz, 16GB
>Reporter: Yuseok Jeon
> Attachments: Actual_result.txt, relationship_tree.jpeg
>
>
> Hi all,
> Our recently developed type confusion detection tool reports a type_confusion
> error in the "xercesc/dom/imple/DOMCasts.hpp"
> xercesc/dom/imple/DOMCasts.hpp, line 146
> static inline DOMNodeImpl *castToNodeImpl(const DOMNode *p)
> {
> DOMElementImpl *pE = (DOMElementImpl *)p;
> return &(pE->fNode);
> }
> p is pointing to the object allocated as DOMTextImpl, and it is casted into
> DOMElementImpl. However, since DOMElementImpl is not a subobject of
> DOMTextImpl, it is violating C++ standard rules 5.2.9/11 (down casting is
> undefined if the object that the pointer to be casted points to is not a
> suboject of down casting type) and causes undefined behaviors.
> There are similar type-confusion cases as below links.
> - (libstdc++) https://gcc.gnu.org/bugzilla/show_bug.cgi?id=60734
> - (Firefox) https://bugzilla.mozilla.org/show_bug.cgi?id=1074280
> I attached a actual type confusion report and object relationship
> information.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
-
To unsubscribe, e-mail: c-dev-unsubscr...@xerces.apache.org
For additional commands, e-mail: c-dev-h...@xerces.apache.org
[jira] [Deleted] (XERCESC-2067) 844-307-5701 Outlook tech support phone number Outlook tech support telephone number here.Describe ((( Outlook support phone number.
[ https://issues.apache.org/jira/browse/XERCESC-2067?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alberto Massari deleted XERCESC-2067: - > 844-307-5701 Outlook tech support phone number Outlook tech support telephone > number here.Describe ((( Outlook support phone number. > > > Key: XERCESC-2067 > URL: https://issues.apache.org/jira/browse/XERCESC-2067 > Project: Xerces-C++ > Issue Type: Bug >Reporter: annaadiwar0123 > > escribe Call+1844-307-5701 Outlook tech support phone number Outlook tech > support telephone number here.Describe ((( Outlook support phone number... > ~Help Usa@ 844-307-5701..((( Outlook support number.. here.Outlook tech((1 > 844-307-5701 Outlook pro c.u.s.t.o.m.e.r s.u.p.p.o.r.t n.u.m.b.e.r Outlook > T.e.c.h s.u.p.p.o.r.t ph.one n.u.m.b.e.r WBP Outlook technical support > number!!844-307-5701!!(( Outlook Tech Support phone number Outlook TECH > SUPPORT NUMBER!!844-307-5701!!((Outlook Customer Support Phone NUmber > Outlook Customer Service Number !!844-307-5701!!Outlook support Phone Number > Outlook help number-Outlook Helpline Number; Outlook help phone number, > Outlook Helpline Number, Outlook Tech Support Toll free Number, Outlook > Support Telephone Number, Outlook Tech Support Telephone number, Outlook Tech > Support contact number, Outlook support contact number, Outlook technical > support contact number, Outlook support phone number, Outlook support phone > number. Outlook customer support phone number Outlook Support Helpline > Number, Outlook contact number Outlook tech support phone number ~Help Usa@ > 844-307-5701..((( Outlook support phone number... ~Help Usa@ > 844-307-5701..((( Outlook support phone number... ~Help Usa@ > 844-307-5701..((( Outlook support phone number... ~Help Usa@ 844-307-5701.. > ((( Outlook support number... ~Help Usa@ 844-307-5701..((( Outlook help desk > phone number... ~Help Usa@ 1- 844-307-5701..((( Outlook help desk phone > number... ~Help Usa@ 844-307-5701..((( Outlook help desk phone number... > Contents [hide] Outlook support 1 844-307-5701 team phone numberGet Instant > Help Usa & Canada at 1 844-307-5701 Outlook customer support phone number , > Outlook customer service number , Outlook tech support number, Outlook > technical support number, Outlook customer care number , > Q.B1.844-307-5701Outlook pro help desk number , Outlook pro support phone > number Q.B1.844-307-5701 Outlook pro help desk number , Outlook pro support > phone number Outlook customer care phoe number , Outlook helpdesk support > phone number, Outlook helpdesk support number, Outlook helpdesk number, > Outlook support help number, Outlook support help number ~Help Usa@ > 844-307-5701..((( Outlook support phone number... ~Help Usa@ 1- > 844-307-5701..((( Outlook support phone number... ~Help Usa@ > 844-307-5701..((( Outlook support phone number... ~Help Usa@ > 844-307-5701..((( Outlook support number... ~Help Usa@ 844-307-5701.. ((( > Outlook help desk phone number... ~Help Usa@ 844-307-5701..((( Outlook help > desk phone number... ~Help Usa@ 844-307-5701..((( Outlook help desk phone > number... Contents [hide] 1 ::~Help Usa@ 844-307-5701..((( Outlook tech > support phone number... 2 ::~Help Usa@ 844-307-5701..((( Outlook tech support > number... 3 ::~Help Usa@ 844-307-5701..((( Outlook customer support number... > 4 Intuit Help... 844-307-5701 Outlook tech support phone number , Outlook > technical support phone number 5 Intuit Help... 844-307-5701 Outlook tech > support phone number , Outlook technical support phone number 6 Intuit > Help... 844-307-5701 Outlook tech support phone number , Outlook technical > support phone number ~Help Usa@ 1-844-307-5701...((( Outlook tech support > phone number...[edit] ~Help Usa@ 844-307-5701..((( Outlook tech support > number...[edit] == ~Help Usa@ 844-307-5701..((( Outlook tech support phone > number..==. Contents [hide] 1 ~Help Usa@ 844-307-5701..((( Outlook tech > support phone number... 2 ~Help Usa@ 844-307-5701.. ((( Outlook tech support > phone number... 3 ~Help Usa@ 844-307-5701..((( Outlook tech support phone > number... 4 ~Help Usa@ 844-307-5701..((( Outlook tech support phone number... > 5 ~Help Usa@ 1- 844-307-5701..((( Outlook tech support phone number... 6 > ~Help Usa@ 844-307-5701..((( Outlook tech support phone number... 7 ~Help > Usa@ 844-307-5701..((( Outlook tech support phone number... 8 ~Help Usa@ > 844-307-5701..((( Outlook tech support phone number... 9 ~Help Usa@ > 844-307-5701.. ((( Outlook tech support phone number... 10 ~Help Usa@ > 844-307-5701..((( Outlook tech support phone number... 11 ~Help Usa@ > 844-307-5701..((( Outlook tech support phone number... 12 ~Help Usa@ 1- >
[jira] [Resolved] (XERCESC-2052) TranscodeToStr constructor throws TranscodingException claiming an invalid multi byte sequence when it is valid
[ https://issues.apache.org/jira/browse/XERCESC-2052?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alberto Massari resolved XERCESC-2052. -- Resolution: Fixed Assignee: Alberto Massari Fix Version/s: 3.2.0 > TranscodeToStr constructor throws TranscodingException claiming an invalid > multi byte sequence when it is valid > --- > > Key: XERCESC-2052 > URL: https://issues.apache.org/jira/browse/XERCESC-2052 > Project: Xerces-C++ > Issue Type: Bug > Components: Utilities >Affects Versions: 3.1.2 > Environment: Windows 32 and 64 bit compiled with VS2010 >Reporter: Nigel Meachen >Assignee: Alberto Massari > Fix For: 3.2.0 > > > The following constructor throws an EncodingException > TranscodeToStr tTransCoder (L"中国制造 / 中國製造","UTF-8", > XMLPlatformUtils::fgMemoryManager); > The code in TranscodeToStr::transcode allocates 26 bytes when 27 are needed, > however, it does not reach the reallocation logic as charsRead is returned by > trans->transcodeTo as zero. This only occurs in a Release build. -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: c-dev-unsubscr...@xerces.apache.org For additional commands, e-mail: c-dev-h...@xerces.apache.org
[jira] [Updated] (XERCESC-2050) wrong use of delete keyword in DTest.cpp
[ https://issues.apache.org/jira/browse/XERCESC-2050?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alberto Massari updated XERCESC-2050: - Fix Version/s: (was: 3.1.3) 3.2.0 > wrong use of delete keyword in DTest.cpp > > > Key: XERCESC-2050 > URL: https://issues.apache.org/jira/browse/XERCESC-2050 > Project: Xerces-C++ > Issue Type: Bug > Components: Samples/Tests >Affects Versions: 3.1.2 >Reporter: Hanno Böck >Assignee: Alberto Massari >Priority: Minor > Fix For: 3.2.0 > > Attachments: xerces-c-fix-alloc-dealloc.diff > > > In the file DTest.cpp there is a wrong use of the delete keyword. The > variable hugeString is allocated with: > char* hugeString=new char[HUGE_STRING+1]; > It gets deallocated with: > delete hugeString; > When allocating a variable with "new type[size]" one has to deallocate with > "delete [] variable". These kinds of errors can be seen when compiling with > address sanitizer. I'll attach a patch. -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: c-dev-unsubscr...@xerces.apache.org For additional commands, e-mail: c-dev-h...@xerces.apache.org
[jira] [Updated] (XERCESC-2053) typo in the documentation: "InputSource resolveEntity" -> "InputSource* resolveEntity"
[ https://issues.apache.org/jira/browse/XERCESC-2053?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alberto Massari updated XERCESC-2053: - Fix Version/s: (was: 3.1.3) 3.2.0 > typo in the documentation: "InputSource resolveEntity" -> "InputSource* > resolveEntity" > -- > > Key: XERCESC-2053 > URL: https://issues.apache.org/jira/browse/XERCESC-2053 > Project: Xerces-C++ > Issue Type: Bug > Components: Documentation >Reporter: Erik Sjölund >Assignee: Alberto Massari >Priority: Trivial > Fix For: 3.2.0 > > Attachments: svn-diff.txt > > > The code examples in the documentation does not match the EntityResolver > interface. There is a missing "*". I attach the output from the command "svn > diff" from a fresh svn checkout with the typos corrected. -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: c-dev-unsubscr...@xerces.apache.org For additional commands, e-mail: c-dev-h...@xerces.apache.org
[jira] [Resolved] (XERCESC-2053) typo in the documentation: "InputSource resolveEntity" -> "InputSource* resolveEntity"
[ https://issues.apache.org/jira/browse/XERCESC-2053?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alberto Massari resolved XERCESC-2053. -- Resolution: Fixed Assignee: Alberto Massari Fix Version/s: 3.1.3 > typo in the documentation: "InputSource resolveEntity" -> "InputSource* > resolveEntity" > -- > > Key: XERCESC-2053 > URL: https://issues.apache.org/jira/browse/XERCESC-2053 > Project: Xerces-C++ > Issue Type: Bug > Components: Documentation >Reporter: Erik Sjölund >Assignee: Alberto Massari >Priority: Trivial > Fix For: 3.1.3 > > Attachments: svn-diff.txt > > > The code examples in the documentation does not match the EntityResolver > interface. There is a missing "*". I attach the output from the command "svn > diff" from a fresh svn checkout with the typos corrected. -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: c-dev-unsubscr...@xerces.apache.org For additional commands, e-mail: c-dev-h...@xerces.apache.org
[jira] [Resolved] (XERCESC-2051) Overlapping memcpy call
[ https://issues.apache.org/jira/browse/XERCESC-2051?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alberto Massari resolved XERCESC-2051. -- Resolution: Duplicate > Overlapping memcpy call > --- > > Key: XERCESC-2051 > URL: https://issues.apache.org/jira/browse/XERCESC-2051 > Project: Xerces-C++ > Issue Type: Bug >Affects Versions: 3.1.2 >Reporter: Hanno Böck >Priority: Minor > Attachments: xerces-c-overlapping-memcpy.diff > > > When running the test suite with address sanitizer enabled it will report an > overlapping memcpy call: > < = > < ==8236==ERROR: AddressSanitizer: memcpy-param-overlap: memory ranges > [0x006678c0,0x006678ca) and [0x006678c2, 0x006678cc) overlap > < #0 0x7f1025853f24 > (/usr/lib/gcc/x86_64-pc-linux-gnu/4.9.2/libasan.so.1+0x2ff24) > < #1 0x7f1024df4bf8 in xercesc_3_1::XMLString::moveChars(unsigned short*, > unsigned short const*, unsigned long) xercesc/util/XMLString.hpp:1446 > < #2 0x7f1024e627eb in xercesc_3_1::XMLString::collapseWS(unsigned > short*, xercesc_3_1::MemoryManager*) xercesc/util/XMLString.cpp:1813 > < #3 0x44a098 in DOMTest::testUtilFunctions() > src/DOM/DOMTest/DTest.cpp:5752 > < #4 0x412865 in main src/DOM/DOMTest/DTest.cpp:984 > < #5 0x7f10209b5f9f in __libc_start_main (/lib64/libc.so.6+0x1ff9f) > < #6 0x405848 (/tmp/xerces-c-3.1.2/tests/.libs/DOMTest+0x405848) > < > < 0x006678c0 is located 0 bytes inside of global variable 'tempStr' from > 'src/DOM/DOMTest/DTest.cpp' (0x6678c0) of size 8000 > < 0x006678c2 is located 2 bytes inside of global variable 'tempStr' from > 'src/DOM/DOMTest/DTest.cpp' (0x6678c0) of size 8000 > < SUMMARY: AddressSanitizer: memcpy-param-overlap ??:0 ?? > < ==8236==ABORTING > memcpy calls to overlapping memory areas are not allowed. memmove can be used > in such instances. (I'll attach a patch that changes that, but I'd ask for it > to be reviewed by someone familiar with the code and check whether the > overlapping copying is really intended.) -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: c-dev-unsubscr...@xerces.apache.org For additional commands, e-mail: c-dev-h...@xerces.apache.org
[jira] [Resolved] (XERCESC-2050) wrong use of delete keyword in DTest.cpp
[ https://issues.apache.org/jira/browse/XERCESC-2050?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alberto Massari resolved XERCESC-2050. -- Resolution: Fixed Fix Version/s: 3.1.3 > wrong use of delete keyword in DTest.cpp > > > Key: XERCESC-2050 > URL: https://issues.apache.org/jira/browse/XERCESC-2050 > Project: Xerces-C++ > Issue Type: Bug > Components: Samples/Tests >Affects Versions: 3.1.2 >Reporter: Hanno Böck >Assignee: Alberto Massari >Priority: Minor > Fix For: 3.1.3 > > Attachments: xerces-c-fix-alloc-dealloc.diff > > > In the file DTest.cpp there is a wrong use of the delete keyword. The > variable hugeString is allocated with: > char* hugeString=new char[HUGE_STRING+1]; > It gets deallocated with: > delete hugeString; > When allocating a variable with "new type[size]" one has to deallocate with > "delete [] variable". These kinds of errors can be seen when compiling with > address sanitizer. I'll attach a patch. -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: c-dev-unsubscr...@xerces.apache.org For additional commands, e-mail: c-dev-h...@xerces.apache.org
[jira] [Assigned] (XERCESC-2050) wrong use of delete keyword in DTest.cpp
[ https://issues.apache.org/jira/browse/XERCESC-2050?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alberto Massari reassigned XERCESC-2050: Assignee: Alberto Massari > wrong use of delete keyword in DTest.cpp > > > Key: XERCESC-2050 > URL: https://issues.apache.org/jira/browse/XERCESC-2050 > Project: Xerces-C++ > Issue Type: Bug > Components: Samples/Tests >Affects Versions: 3.1.2 >Reporter: Hanno Böck >Assignee: Alberto Massari >Priority: Minor > Fix For: 3.1.3 > > Attachments: xerces-c-fix-alloc-dealloc.diff > > > In the file DTest.cpp there is a wrong use of the delete keyword. The > variable hugeString is allocated with: > char* hugeString=new char[HUGE_STRING+1]; > It gets deallocated with: > delete hugeString; > When allocating a variable with "new type[size]" one has to deallocate with > "delete [] variable". These kinds of errors can be seen when compiling with > address sanitizer. I'll attach a patch. -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: c-dev-unsubscr...@xerces.apache.org For additional commands, e-mail: c-dev-h...@xerces.apache.org
[jira] [Resolved] (XERCESC-2049) memcpy used on overlapping memory regions causes sanity test failure
[ https://issues.apache.org/jira/browse/XERCESC-2049?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alberto Massari resolved XERCESC-2049. -- Resolution: Fixed Fix Version/s: 3.2.0 3.1.3 Assignee: Alberto Massari > memcpy used on overlapping memory regions causes sanity test failure > > > Key: XERCESC-2049 > URL: https://issues.apache.org/jira/browse/XERCESC-2049 > Project: Xerces-C++ > Issue Type: Bug > Components: Utilities >Affects Versions: 3.1.2 > Environment: Debian unstable (sid) and Debian stable (jessie) on amd64 >Reporter: Bill Blough >Assignee: Alberto Massari > Fix For: 3.1.3, 3.2.0 > > Attachments: moveChars_overlap.diff > > > On Debian Jessie (libc6 2.19, libstdc++ 4.9.2) and newer, sanityTest.pl fails > its tests of XMLString::collapseWS. > Tracing with GDB shows that XMLString::moveChars is corrupting the string. I > think this is likely due to memcpy being used on overlapping memory regions. > Replacing the memcpy in moveChars with memmove fixes the issue on my > systems. -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: c-dev-unsubscr...@xerces.apache.org For additional commands, e-mail: c-dev-h...@xerces.apache.org
[jira] [Resolved] (XERCESC-2024) LocalFileFormatTarget leaks file handle
[ https://issues.apache.org/jira/browse/XERCESC-2024?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alberto Massari resolved XERCESC-2024. -- Resolution: Fixed Sorry, this bug is a zombie... > LocalFileFormatTarget leaks file handle > --- > > Key: XERCESC-2024 > URL: https://issues.apache.org/jira/browse/XERCESC-2024 > Project: Xerces-C++ > Issue Type: Bug > Components: Miscellaneous >Reporter: Vemund Handeland >Assignee: Alberto Massari > Fix For: 3.2.0 > > Attachments: LocalFileFormatTarget.cpp.patch > > > The call to XMLPlatformUtils::writeBufferToFile in the LocalFileFormatTarget > destructor might throw an exception. A typical use case is running out of > disk space. > In this case the file handle will not be closed -- This message was sent by Atlassian JIRA (v6.2#6252) - To unsubscribe, e-mail: c-dev-unsubscr...@xerces.apache.org For additional commands, e-mail: c-dev-h...@xerces.apache.org
[jira] [Commented] (XERCESC-1235) Xerces-C++ does not build with gcc 3.4.0
[ https://issues.apache.org/jira/browse/XERCESC-1235?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14007166#comment-14007166 ] Alberto Massari commented on XERCESC-1235: -- This looks like a missing #include , but you should ask the Xalan team... > Xerces-C++ does not build with gcc 3.4.0 > > > Key: XERCESC-1235 > URL: https://issues.apache.org/jira/browse/XERCESC-1235 > Project: Xerces-C++ > Issue Type: Bug > Components: Build >Affects Versions: 2.5.0 > Environment: Gcc 3.4.0 > Slackware GNU/Linux 10.0 >Reporter: ismail dönmez > > When trying to build xerces-c with gcc 3.4.0 I get error : > make -C impl > make[2]: Entering directory > `/home/cartman/WS/xerces-c-src_2_5_0/src/xercesc/dom/impl' > mkdir -p /home/cartman/WS/xerces-c-src_2_5_0/include/xercesc/dom/impl > cp -fp DOMDeepNodeListPool.c > /home/cartman/WS/xerces-c-src_2_5_0/include/xercesc/dom/impl > g++ -fPIC -DLINUX -D_REENTRANT -c > -I/home/cartman/WS/xerces-c-src_2_5_0/include -g -O2 -o > /home/cartman/WS/xerces-c-src_2_5_0/obj/LINUX/DOMAttrImpl.o DOMAttrImpl.cpp > In file included from > /home/cartman/WS/xerces-c-src_2_5_0/include/xercesc/util/RefArrayOf.hpp:221, > from DOMDocumentImpl.hpp:73, > from DOMAttrImpl.hpp:77, > from DOMAttrImpl.cpp:64: > /home/cartman/WS/xerces-c-src_2_5_0/include/xercesc/util/RefArrayOf.c: In > constructor `xercesc_2_5::RefArrayOf::RefArrayOf(unsigned int, > xercesc_2_5::MemoryManager*)': > /home/cartman/WS/xerces-c-src_2_5_0/include/xercesc/util/RefArrayOf.c:111: > error: invalid use of undefined type `struct xercesc_2_5::MemoryManager' > /home/cartman/WS/xerces-c-src_2_5_0/include/xercesc/util/XMemory.hpp:70: > error: forward declaration of `struct xercesc_2_5::MemoryManager' > /home/cartman/WS/xerces-c-src_2_5_0/include/xercesc/util/RefArrayOf.c: In > constructor `xercesc_2_5::RefArrayOf::RefArrayOf(TElem**, unsigned > int, xercesc_2_5::MemoryManager*)': > /home/cartman/WS/xerces-c-src_2_5_0/include/xercesc/util/RefArrayOf.c:125: > error: invalid use of undefined type `struct xercesc_2_5::MemoryManager' > /home/cartman/WS/xerces-c-src_2_5_0/include/xercesc/util/XMemory.hpp:70: > error: forward declaration of `struct xercesc_2_5::MemoryManager' > /home/cartman/WS/xerces-c-src_2_5_0/include/xercesc/util/RefArrayOf.c: In > copy constructor `xercesc_2_5::RefArrayOf::RefArrayOf(const > xercesc_2_5::RefArrayOf&)': > /home/cartman/WS/xerces-c-src_2_5_0/include/xercesc/util/RefArrayOf.c:137: > error: invalid use of undefined type `struct xercesc_2_5::MemoryManager' > /home/cartman/WS/xerces-c-src_2_5_0/include/xercesc/util/XMemory.hpp:70: > error: forward declaration of `struct xercesc_2_5::MemoryManager' > /home/cartman/WS/xerces-c-src_2_5_0/include/xercesc/util/RefArrayOf.c: In > destructor `xercesc_2_5::RefArrayOf::~RefArrayOf()': > /home/cartman/WS/xerces-c-src_2_5_0/include/xercesc/util/RefArrayOf.c:144: > error: invalid use of undefined type `struct xercesc_2_5::MemoryManager' > /home/cartman/WS/xerces-c-src_2_5_0/include/xercesc/util/XMemory.hpp:70: > error: forward declaration of `struct xercesc_2_5::MemoryManager' > /home/cartman/WS/xerces-c-src_2_5_0/include/xercesc/util/RefArrayOf.c: In > member function `xercesc_2_5::RefArrayOf& > xercesc_2_5::RefArrayOf::operator=(const > xercesc_2_5::RefArrayOf&)': > /home/cartman/WS/xerces-c-src_2_5_0/include/xercesc/util/RefArrayOf.c:176: > error: invalid use of undefined type `struct xercesc_2_5::MemoryManager' > /home/cartman/WS/xerces-c-src_2_5_0/include/xercesc/util/XMemory.hpp:70: > error: forward declaration of `struct xercesc_2_5::MemoryManager' > /home/cartman/WS/xerces-c-src_2_5_0/include/xercesc/util/RefArrayOf.c:178: > error: invalid use of undefined type `struct xercesc_2_5::MemoryManager' > /home/cartman/WS/xerces-c-src_2_5_0/include/xercesc/util/XMemory.hpp:70: > error: forward declaration of `struct xercesc_2_5::MemoryManager' > /home/cartman/WS/xerces-c-src_2_5_0/include/xercesc/util/RefArrayOf.c: In > member function `void xercesc_2_5::RefArrayOf::resize(unsigned int)': > /home/cartman/WS/xerces-c-src_2_5_0/include/xercesc/util/RefArrayOf.c:276: > error: invalid use of undefined type `struct xercesc_2_5::MemoryManager' > /home/cartman/WS/xerces-c-src_2_5_0/include/xercesc/util/XMemory.hpp:70: > error: forward declaration of `struct xercesc_2_5::MemoryManager' > /home/cartman/WS/xerces-c-src_2_5_0/include/xercesc/util/RefArrayOf.c:290: > error: invalid use of undefined type `struct xercesc_2_5::MemoryManager' > /home/cartman/WS/xerces-c-src_2_5_0/include/xercesc/util/XMemory.hpp:70: > error: forward declaration of `struct xercesc_2_5::MemoryManager' > In file included from DOMAttrImpl.cpp:67: > DOMCasts.hpp: In function `xercesc_2_5::DOMNode
[jira] [Resolved] (XERCESC-2031) Janitor::~Janitor() throws in unwind
[ https://issues.apache.org/jira/browse/XERCESC-2031?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alberto Massari resolved XERCESC-2031. -- Resolution: Fixed Fix Version/s: 3.2.0 Assignee: Alberto Massari A fix is in SVN. Pplease verify. > Janitor::~Janitor() throws in unwind > > > Key: XERCESC-2031 > URL: https://issues.apache.org/jira/browse/XERCESC-2031 > Project: Xerces-C++ > Issue Type: Bug > Components: Utilities >Affects Versions: 3.1.1 > Environment: Solaris 10, x86 >Reporter: Jimmie Högklint >Assignee: Alberto Massari > Fix For: 3.2.0 > > > If PosixFileMgr::fileClose() receives an invalid file handler or if its > unable to close a file handler it will throw an exception. If this is done in > an unwind of, for example, Janitor noone is around to catch > that exception before the process is terminated. (Leaving a destructor with a > throw during unwind is rewarded with termination of the process) > This happens when variable "streamJanitor" goes out of scope in > ReaderMgr::createReader(...) > Callstack looks like this: > [6] std::terminate(0xfeafd2e3, 0xfe7eb940, 0xfc5c5ce8, 0xfe7eb940, 0x0, > 0xfe7eb940), at 0xfe7d471f > [7] __Cimpl::ex_terminate(0xfedf9290, 0xfee69fd0, 0x2, 0xfe7ec658, > 0xfe7ec4a0, 0x0), at 0xfe7d4b82 > [8] _ex_throw_body(0xfe7ec658, 0xfeafd2e3, 0xfc5c5d60, 0xfe7d546e), at > 0xfe7d5561 > [9] __Crun::ex_throw(0xfe7ec6a4, 0xfed84ab8, 0xfeb04488, 0xfed82da2), at > 0xfe7d54ca > [10] xercesc_3_1::PosixFileMgr::fileClose(this = 0x8f69a18, f = 0xfe3f2d00, > manager = 0x8f69618) (optimized), at 0xfed82e40 (line ~81) in > "PosixFileMgr.cpp" > [11] xercesc_3_1::XMLPlatformUtils::closeFile(theFile = 0xfe3f2d00, memmgr = > 0x8f69618) (optimized), at 0xfeb021b9 (line ~578) in "PlatformUtils.cpp" > [12] xercesc_3_1::BinFileInputStream::~BinFileInputStream(this = 0x91df400) > (optimized), at 0xfeafd2de (line ~64) in "BinFileInputStream.cpp" > [13] __SLIP.DELETER__A(this = 0x91df400, delete = 1) (optimized), at > 0xfeafd53e (line ~61) in "BinFileInputStream.cpp" > [14] xercesc_3_1::Janitor::reset(this = > 0xfc5c5e84, p = (nil)) (optimized), at 0xfec16fd6 (line ~90) in "Janitor.c" > [15] xercesc_3_1::Janitor::~Janitor(this = > 0xfc5c5e84) (optimized), at 0xfec166f8 (line ~43) in "Janitor.c" > [16] xercesc_3_1::ReaderMgr::createReader(this = 0x930a604, src = CLASS, > _ARG3 = true, refFrom = RefFrom_NonLiteral, type = Type_General, source = > Source_External, calcSrcOfs = false, lowWaterMark = 100U) (optimized), at > 0xfec12ee4 (line ~440) in "ReaderMgr.cpp" > [17] xercesc_3_1::IGXMLScanner::scanReset(this = 0x930a578, src = CLASS) > (optimized), at 0xfec08e7c (line ~1275) in "IGXMLScanner2.cpp" > [18] xercesc_3_1::IGXMLScanner::scanDocument(this = 0x930a578, src = CLASS) > (optimized), at 0xfebfb52e (line ~198) in "IGXMLScanner.cpp" > [19] xercesc_3_1::AbstractDOMParser::parse(this = 0xfc5c6018, source = CLASS) > (optimized), at 0xfec67c34 (line ~545) in "AbstractDOMParser.cpp" > [20] xercesc_3_1::IGXMLScanner::resolveSchemaGrammar(this = 0x9283f68, loc = > 0x93c4b3c, uri = 0x93c5020, ignoreLoadSchema = true) (optimized), at > 0xfec0a8d0 (line ~1859) in "IGXMLScanner2.cpp" > [21] xercesc_3_1::IGXMLScanner::parseSchemaLocation(this = 0x9283f68, > schemaLocationStr = 0x9627e10, ignoreLoadSchema = true) (optimized), at > 0xfec0a0b4 (line ~1727) in "IGXMLScanner2.cpp" > [22] xercesc_3_1::IGXMLScanner::scanStartTagNS(this = 0x9283f68, gotData = > true) (optimized), at 0xfebff71a (line ~2205) in "IGXMLScanner.cpp" > [23] xercesc_3_1::IGXMLScanner::scanContent(this = 0x9283f68) (optimized), at > 0xfebfcb7b (line ~890) in "IGXMLScanner.cpp" > [24] xercesc_3_1::IGXMLScanner::scanDocument(this = 0x9283f68, src = CLASS) > (optimized), at 0xfebfb571 (line ~217) in "IGXMLScanner.cpp" > [25] xercesc_3_1::AbstractDOMParser::parse(this = 0x92e6e50, source = CLASS) > (optimized), at 0xfec67c34 (line ~545) in "AbstractDOMParser.cpp" > [26] xercesc_3_1::DOMLSParserImpl::parse(this = 0x92e6e50, source = > 0xfc5c6718) (optimized), at 0xfec714ce (line ~754) in "DOMLSParserImpl.cpp" > This applies to WindowsFileMgr as well. > If additional information is needed I'm happy to provide it. -- This message was sent by Atlassian JIRA (v6.2#6252) - To unsubscribe, e-mail: c-dev-unsubscr...@xerces.apache.org For additional commands, e-mail: c-dev-h...@xerces.apache.org
[jira] [Commented] (XERCESC-1235) Xerces-C++ does not build with gcc 3.4.0
[ https://issues.apache.org/jira/browse/XERCESC-1235?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14005874#comment-14005874 ] Alberto Massari commented on XERCESC-1235: -- What version are you trying to compile? 2.5? Can you paste the output of your compiler? > Xerces-C++ does not build with gcc 3.4.0 > > > Key: XERCESC-1235 > URL: https://issues.apache.org/jira/browse/XERCESC-1235 > Project: Xerces-C++ > Issue Type: Bug > Components: Build >Affects Versions: 2.5.0 > Environment: Gcc 3.4.0 > Slackware GNU/Linux 10.0 >Reporter: ismail dönmez > > When trying to build xerces-c with gcc 3.4.0 I get error : > make -C impl > make[2]: Entering directory > `/home/cartman/WS/xerces-c-src_2_5_0/src/xercesc/dom/impl' > mkdir -p /home/cartman/WS/xerces-c-src_2_5_0/include/xercesc/dom/impl > cp -fp DOMDeepNodeListPool.c > /home/cartman/WS/xerces-c-src_2_5_0/include/xercesc/dom/impl > g++ -fPIC -DLINUX -D_REENTRANT -c > -I/home/cartman/WS/xerces-c-src_2_5_0/include -g -O2 -o > /home/cartman/WS/xerces-c-src_2_5_0/obj/LINUX/DOMAttrImpl.o DOMAttrImpl.cpp > In file included from > /home/cartman/WS/xerces-c-src_2_5_0/include/xercesc/util/RefArrayOf.hpp:221, > from DOMDocumentImpl.hpp:73, > from DOMAttrImpl.hpp:77, > from DOMAttrImpl.cpp:64: > /home/cartman/WS/xerces-c-src_2_5_0/include/xercesc/util/RefArrayOf.c: In > constructor `xercesc_2_5::RefArrayOf::RefArrayOf(unsigned int, > xercesc_2_5::MemoryManager*)': > /home/cartman/WS/xerces-c-src_2_5_0/include/xercesc/util/RefArrayOf.c:111: > error: invalid use of undefined type `struct xercesc_2_5::MemoryManager' > /home/cartman/WS/xerces-c-src_2_5_0/include/xercesc/util/XMemory.hpp:70: > error: forward declaration of `struct xercesc_2_5::MemoryManager' > /home/cartman/WS/xerces-c-src_2_5_0/include/xercesc/util/RefArrayOf.c: In > constructor `xercesc_2_5::RefArrayOf::RefArrayOf(TElem**, unsigned > int, xercesc_2_5::MemoryManager*)': > /home/cartman/WS/xerces-c-src_2_5_0/include/xercesc/util/RefArrayOf.c:125: > error: invalid use of undefined type `struct xercesc_2_5::MemoryManager' > /home/cartman/WS/xerces-c-src_2_5_0/include/xercesc/util/XMemory.hpp:70: > error: forward declaration of `struct xercesc_2_5::MemoryManager' > /home/cartman/WS/xerces-c-src_2_5_0/include/xercesc/util/RefArrayOf.c: In > copy constructor `xercesc_2_5::RefArrayOf::RefArrayOf(const > xercesc_2_5::RefArrayOf&)': > /home/cartman/WS/xerces-c-src_2_5_0/include/xercesc/util/RefArrayOf.c:137: > error: invalid use of undefined type `struct xercesc_2_5::MemoryManager' > /home/cartman/WS/xerces-c-src_2_5_0/include/xercesc/util/XMemory.hpp:70: > error: forward declaration of `struct xercesc_2_5::MemoryManager' > /home/cartman/WS/xerces-c-src_2_5_0/include/xercesc/util/RefArrayOf.c: In > destructor `xercesc_2_5::RefArrayOf::~RefArrayOf()': > /home/cartman/WS/xerces-c-src_2_5_0/include/xercesc/util/RefArrayOf.c:144: > error: invalid use of undefined type `struct xercesc_2_5::MemoryManager' > /home/cartman/WS/xerces-c-src_2_5_0/include/xercesc/util/XMemory.hpp:70: > error: forward declaration of `struct xercesc_2_5::MemoryManager' > /home/cartman/WS/xerces-c-src_2_5_0/include/xercesc/util/RefArrayOf.c: In > member function `xercesc_2_5::RefArrayOf& > xercesc_2_5::RefArrayOf::operator=(const > xercesc_2_5::RefArrayOf&)': > /home/cartman/WS/xerces-c-src_2_5_0/include/xercesc/util/RefArrayOf.c:176: > error: invalid use of undefined type `struct xercesc_2_5::MemoryManager' > /home/cartman/WS/xerces-c-src_2_5_0/include/xercesc/util/XMemory.hpp:70: > error: forward declaration of `struct xercesc_2_5::MemoryManager' > /home/cartman/WS/xerces-c-src_2_5_0/include/xercesc/util/RefArrayOf.c:178: > error: invalid use of undefined type `struct xercesc_2_5::MemoryManager' > /home/cartman/WS/xerces-c-src_2_5_0/include/xercesc/util/XMemory.hpp:70: > error: forward declaration of `struct xercesc_2_5::MemoryManager' > /home/cartman/WS/xerces-c-src_2_5_0/include/xercesc/util/RefArrayOf.c: In > member function `void xercesc_2_5::RefArrayOf::resize(unsigned int)': > /home/cartman/WS/xerces-c-src_2_5_0/include/xercesc/util/RefArrayOf.c:276: > error: invalid use of undefined type `struct xercesc_2_5::MemoryManager' > /home/cartman/WS/xerces-c-src_2_5_0/include/xercesc/util/XMemory.hpp:70: > error: forward declaration of `struct xercesc_2_5::MemoryManager' > /home/cartman/WS/xerces-c-src_2_5_0/include/xercesc/util/RefArrayOf.c:290: > error: invalid use of undefined type `struct xercesc_2_5::MemoryManager' > /home/cartman/WS/xerces-c-src_2_5_0/include/xercesc/util/XMemory.hpp:70: > error: forward declaration of `struct xercesc_2_5::MemoryManager' > In file included from DOMAttrImpl.cpp:67: > DOMCasts.hpp: In function `xerce
[jira] [Resolved] (XERCESC-2030) failed to do validation when there's Japanese words in the xml file
[
https://issues.apache.org/jira/browse/XERCESC-2030?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Alberto Massari resolved XERCESC-2030.
--
Resolution: Not a Problem
Your code is doing a dangerous thing: using XMLString::trascode in the SAX
callback. This tries to convert a Unicode string into a locale that you cannot
control and that, in your case, is unable to represent non-European characters.
If you really need to store non-Unicode strings in a stack, please convert them
into UTF-8, and never use XMLString::transcode, unless you are preparing to
print data to the console
> failed to do validation when there's Japanese words in the xml file
> ---
>
> Key: XERCESC-2030
> URL: https://issues.apache.org/jira/browse/XERCESC-2030
> Project: Xerces-C++
> Issue Type: Bug
> Components: SAX/SAX2
> Environment: SunOS 5.10 Generic_139555-08 sun4u sparc
> SUNW,Sun-Fire-V245
> xerces C++ 3.1.1
>Reporter: ocean_helen
>
> Hi owners,
> I got a problem when using Xerces C++ 3.1.1 to do schema validation
> which has Japanese words in the xml file. it raised FatalError: invalid
> multi-byte sequence and stop validation.
> Environment: Linux
> Locale:
> LANG=
> LC_CTYPE=en_GB.ISO8859-1
> LC_NUMERIC=C
> LC_TIME=en_GB.ISO8859-1
> LC_COLLATE=en_GB.ISO8859-1
> LC_MONETARY=en_GB.ISO8859-1
> LC_MESSAGES=C
> LC_ALL=
> The xml file is generated in linux and because of the business, we
> couldn't change characterset from ISO8859-1 to UTF-8 from the system side, so
> do we have any workaround to skip this kind of error, or is it possible to
> modify characterset to pass the validation in C++?
> All the source codes are attached at below, please let me know if you
> need any more information.
> Looking forward to your reply and thank you so much in advance.
> Source Code:
> a.xsd:
>
>
> http://www.w3.org/2001/XMLSchema";>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
> a.xml:
>
>
> http://www.w3.org/2001/XMLSchema-instance";
> xsi:noNamespaceSchemaLocation=
> "gobitan.xsd">
>
> 円短期
>
>
> val.cpp
>
> #include
> #include
> #include
> #include
> #include
> #include
> #include
> #include
> #include "MyHandler.hpp"
> #if defined(XERCES_NEW_IOSTREAMS)
> #include
> #else
> #include
> #endif
> using namespace std;
> using namespace xercesc;
> //XERCES_CPP_NAMESPACE_USE
> int main( int argc , char** argv )
> {
>XMLPlatformUtils::Initialize(); //.
>SAX2XMLReader* parser = XMLReaderFactory::createXMLReader();
>parser->setFeature(XMLUni::fgSAX2CoreNameSpaces, true);
> parser->setFeature(XMLUni::fgSAX2CoreNameSpacePrefixes, true);
>parser->setFeature(XMLUni::fgXercesValidationErrorAsFatal, true);
>parser->setFeature(XMLUni::fgSAX2CoreValidation, true);
> parser->setFeature(XMLUni::fgXercesSchema, true);
> parser->setFeature(XMLUni::fgXercesSchemaFullChecking, true);
> parser->setFeature(XMLUni::fgXercesLoadSchema,true);
> parser->setExitOnFirstFatalError(false);
> parser->loadGrammar ("a.xsd", Grammar::SchemaGrammarType, true);
> MyHandler* handler=new MyHandler();
> parser->setContentHandler(handler);
> parser->setErrorHandler(handler);
>try
>{
>parser->parse("a.xml");
> vector errs=handler->getSchemaErrorContent();
> if(errs.size()>0)
> {
> cout<<"ERROR MESSAGE OF SCHEMA VALIDATION="< for (unsigned int i = 0; i < errs.size();i++)
> {
> cout< }
> }
> cout<<"END TRY"< }
> catch (const XMLException& toCatch) {
> char* message = XMLString::transcode(toCatch.getMessage());
> cout << "Exception message is: \n"
> << message << "\n";
> XMLString::release(&message);
> return -1;
> }
> catch (const SAXParseException& toCatch) {
> char* message = XMLString::transcode(toCatch.getMessage());
> cout << "Exception message is: \n"
> << message << "\n";
> XMLString::release(&message);
> return -1;
> }
> catch (...) {
> cout << "Unexpected Exception \n" ;
> return -1;
> }
> cout<<"FINISH"return 0;
> }
> MyHandler.cpp
>
> #include "MyHandler.hpp"
> #include
> #include
> #include
> #if defined(XERCES_NEW_IOSTREAMS)
> #i
[jira] [Resolved] (XERCESC-2028) Curl Checking
[ https://issues.apache.org/jira/browse/XERCESC-2028?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alberto Massari resolved XERCESC-2028. -- Resolution: Fixed Fix Version/s: 3.2.0 Assignee: Alberto Massari Fix is in SVN > Curl Checking > - > > Key: XERCESC-2028 > URL: https://issues.apache.org/jira/browse/XERCESC-2028 > Project: Xerces-C++ > Issue Type: Bug >Affects Versions: 3.1.1 > Environment: mingw >Reporter: Zane U. Ji >Assignee: Alberto Massari > Fix For: 3.2.0 > > Attachments: xerces_curl_prefix.m4.patch > > > The problem is quite similar to the one reported at > https://issues.apache.org/jira/browse/XERCESC-2006 > configure can't find the CURL library installed on the system. -- This message was sent by Atlassian JIRA (v6.2#6252) - To unsubscribe, e-mail: c-dev-unsubscr...@xerces.apache.org For additional commands, e-mail: c-dev-h...@xerces.apache.org
[jira] [Commented] (XERCESC-2029) The schema URL support doesn't support
[ https://issues.apache.org/jira/browse/XERCESC-2029?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13982862#comment-13982862 ] Alberto Massari commented on XERCESC-2029: -- The different options are listed at http://xerces.apache.org/xerces-c/build-3.html The default choice is "plain socket", and that only supports very simple HTTP requests > The schema URL support doesn't support > -- > > Key: XERCESC-2029 > URL: https://issues.apache.org/jira/browse/XERCESC-2029 > Project: Xerces-C++ > Issue Type: Bug > Components: Validating Parser (XML Schema) >Affects Versions: 3.1.0 >Reporter: Alexandru Stefanescu > Labels: patch > Fix For: 3.1.0 > > > When the input file has 'schemaLocation' with an URL like : > https://aarembargo.railinc.com/epdb/xsd/Embargo.xsd (the https is the issue) > then xerces throws this fatal error Message: "unsupported protocol in URL". > This is blocking our product to parse/validate XML files received from > another party which have these URL's. -- This message was sent by Atlassian JIRA (v6.2#6252) - To unsubscribe, e-mail: c-dev-unsubscr...@xerces.apache.org For additional commands, e-mail: c-dev-h...@xerces.apache.org
[jira] [Resolved] (XERCESC-2029) The schema URL support doesn't support
[ https://issues.apache.org/jira/browse/XERCESC-2029?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alberto Massari resolved XERCESC-2029. -- Resolution: Not a Problem The default, built-in NetAccessor doesn't support https protocol. You will have to build the sources specifying the cURL or the Winsock accessor > The schema URL support doesn't support > -- > > Key: XERCESC-2029 > URL: https://issues.apache.org/jira/browse/XERCESC-2029 > Project: Xerces-C++ > Issue Type: Bug > Components: Validating Parser (XML Schema) >Affects Versions: 3.1.0 >Reporter: Alexandru Stefanescu > Labels: patch > Fix For: 3.1.0 > > > When the input file has 'schemaLocation' with an URL like : > https://aarembargo.railinc.com/epdb/xsd/Embargo.xsd (the https is the issue) > then xerces throws this fatal error Message: "unsupported protocol in URL". > This is blocking our product to parse/validate XML files received from > another party which have these URL's. -- This message was sent by Atlassian JIRA (v6.2#6252) - To unsubscribe, e-mail: c-dev-unsubscr...@xerces.apache.org For additional commands, e-mail: c-dev-h...@xerces.apache.org
[jira] [Resolved] (XERCESC-2026) typo in validators ContentSpecNode::getMaxTotalRange()
[ https://issues.apache.org/jira/browse/XERCESC-2026?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alberto Massari resolved XERCESC-2026. -- Resolution: Duplicate Duplicate of XERCESC-1994 > typo in validators ContentSpecNode::getMaxTotalRange() > -- > > Key: XERCESC-2026 > URL: https://issues.apache.org/jira/browse/XERCESC-2026 > Project: Xerces-C++ > Issue Type: Bug > Components: Validating Parser (XML Schema) >Affects Versions: 3.2.0 > Environment: Windows 7 64 >Reporter: Maks Naumov >Priority: Minor > > .\src\xercesc\validators\common\ContentSpecNode.cpp 262 > I think here the error. > max = max * (maxFirst > maxSecond) ? maxFirst : maxSecond; > '?' operator has lower priority than '*' > Must be: > max = max * (maxFirst > maxSecond ? maxFirst : maxSecond); -- This message was sent by Atlassian JIRA (v6.1.5#6160) - To unsubscribe, e-mail: c-dev-unsubscr...@xerces.apache.org For additional commands, e-mail: c-dev-h...@xerces.apache.org
[jira] [Commented] (XERCESC-2019) Error in memory allocation for even small messages.
[ https://issues.apache.org/jira/browse/XERCESC-2019?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13818089#comment-13818089 ] Alberto Massari commented on XERCESC-2019: -- There is the limitation of the memory required to keep the data in memory; there is the overhead of the DOM nodes, and the data of the XML is kept in Unicode format, so assuming your XML is almost entirely a single text node, at a certain point you could have allocated the 179Mb*sizeof(XMLCh) of the previous buffer plus a 2*179Mb*sizeof(XMLCh) new buffer, that is more than 1Gb of memory > Error in memory allocation for even small messages. > --- > > Key: XERCESC-2019 > URL: https://issues.apache.org/jira/browse/XERCESC-2019 > Project: Xerces-C++ > Issue Type: Bug > Components: DOM >Affects Versions: 3.1.1 > Environment: windows XP vc9, linux and solaris >Reporter: mahalakshmi >Assignee: Alberto Massari > Labels: patch > Fix For: 3.2.0 > > Attachments: zippedfiles.zip > > > I have my xsd schema using which i have created my standard xml. > After creating the xml i fill the values for each tag in my xml. > I get memory allocation error when i try to traverse through the xml and set > the values for each tag in my xml. > I get allocation error when my program calls the setTextcontent() of > xerces.It is crashing in DOMDocumentImpl.cpp allocate(size).(2nd if condition > in that function) > Is there any setting that needs to be done for memory allocation? How much is > the maximum size of xml that xerces can parse?how do we manage the memory > allocation and deallocation in DOM? -- This message was sent by Atlassian JIRA (v6.1#6144) - To unsubscribe, e-mail: c-dev-unsubscr...@xerces.apache.org For additional commands, e-mail: c-dev-h...@xerces.apache.org
[jira] [Resolved] (XERCESC-2015) Fix warnings under g++ 4.7.2 with -Wall
[
https://issues.apache.org/jira/browse/XERCESC-2015?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Alberto Massari resolved XERCESC-2015.
--
Resolution: Won't Fix
Version 2.8 is not maintained anymore, and the current 3.1 code base already
has these fixes in
> Fix warnings under g++ 4.7.2 with -Wall
> ---
>
> Key: XERCESC-2015
> URL: https://issues.apache.org/jira/browse/XERCESC-2015
> Project: Xerces-C++
> Issue Type: Improvement
> Components: Validating Parser (XML Schema)
>Affects Versions: 2.8.0
>Reporter: Mike Giroux
>Priority: Minor
> Fix For: 2.8.0
>
> Attachments: xercesc-2015.patch
>
>
> SchemaAttDef.hpp and SchemaElementDecl.hpp both trigger warnings under -Wall
> with g++ 4.7.2. In our environment, since we use -Werror for validation,
> these become a more serious issue.
> There are 2 categories of fixes - a signed/unsigned comparison mismatch in
> SchemaElementDecl::isGlobalDecl, and some missing parens in if statements in
> SchemaAttDef::getMemberTypeAnonymous() and bool
> SchemaElementDecl::isTypeDefinitionUnion().
> Here's a patch:
> ---
> src/xercesc/validators/schema/SchemaAttDef.hpp | 4 ++--
> src/xercesc/validators/schema/SchemaElementDecl.hpp | 6 +++---
> 2 files changed, 5 insertions(+), 5 deletions(-)
> diff --git a/src/xercesc/validators/schema/SchemaAttDef.hpp
> b/src/xercesc/validators/schema/SchemaAttDef.hpp
> index 7648de0..2c069b7 100644
> --- a/src/xercesc/validators/schema/SchemaAttDef.hpp
> +++ b/src/xercesc/validators/schema/SchemaAttDef.hpp
> @@ -401,8 +401,8 @@ inline bool SchemaAttDef::getMemberTypeAnonymous() const {
> }
> inline bool SchemaAttDef::isTypeDefinitionUnion() const {
> - if(fAnyDatatypeValidator && fAnyDatatypeValidator->getType() ==
> DatatypeValidator::Union ||
> - fDatatypeValidator && fDatatypeValidator->getType() ==
> DatatypeValidator::Union)
> + if( (fAnyDatatypeValidator && fAnyDatatypeValidator->getType() ==
> DatatypeValidator::Union)
> + || (fDatatypeValidator && fDatatypeValidator->getType() ==
> DatatypeValidator::Union))
> return true;
> return false;
> }
> diff --git a/src/xercesc/validators/schema/SchemaElementDecl.hpp
> b/src/xercesc/validators/schema/SchemaElementDecl.hpp
> index 9ffc2f2..5f9ad8f 100644
> --- a/src/xercesc/validators/schema/SchemaElementDecl.hpp
> +++ b/src/xercesc/validators/schema/SchemaElementDecl.hpp
> @@ -506,7 +506,7 @@ inline SchemaAttDef* SchemaElementDecl::getAttWildCard() {
> inline bool SchemaElementDecl::isGlobalDecl() const {
> -return (fEnclosingScope == Grammar::TOP_LEVEL_SCOPE);
> +return (static_cast(fEnclosingScope) ==
> Grammar::TOP_LEVEL_SCOPE);
> }
> inline SchemaElementDecl*
> @@ -591,8 +591,8 @@ inline bool SchemaElementDecl::getMemberTypeAnonymous()
> const {
> inline bool SchemaElementDecl::isTypeDefinitionUnion() const {
> // removing fXsi* references would break DOMTypeInfo implementation
> completely;
> // will have to wait for now
> - if(fXsiSimpleTypeInfo && fXsiSimpleTypeInfo->getType() ==
> DatatypeValidator::Union ||
> - fDatatypeValidator && fDatatypeValidator->getType() ==
> DatatypeValidator::Union)
> + if( (fXsiSimpleTypeInfo && fXsiSimpleTypeInfo->getType() ==
> DatatypeValidator::Union)
> + || (fDatatypeValidator && fDatatypeValidator->getType() ==
> DatatypeValidator::Union))
> return true;
> return false;
> }
> --
--
This message was sent by Atlassian JIRA
(v6.1#6144)
-
To unsubscribe, e-mail: c-dev-unsubscr...@xerces.apache.org
For additional commands, e-mail: c-dev-h...@xerces.apache.org
[jira] [Closed] (XERCESC-2022) README and INSTALL files contain non-existing link
[ https://issues.apache.org/jira/browse/XERCESC-2022?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alberto Massari closed XERCESC-2022. Resolution: Not A Problem The README and INSTALL files are using the references to the documentation that is shipped with the product in the binary releases. If you download the SVN trunk you should use http://xerces.apache.org/xerces-c/build-3.html to get the correct instructions for building the product > README and INSTALL files contain non-existing link > -- > > Key: XERCESC-2022 > URL: https://issues.apache.org/jira/browse/XERCESC-2022 > Project: Xerces-C++ > Issue Type: Bug > Components: Documentation >Affects Versions: 3.1.0 > Environment: ubuntu 12.04LTS >Reporter: jan iversen >Priority: Minor > > I downloaded Xerces C trunk, and wanted to find how to install it. > file INSTALL and file README in /xerces/c/trunk ask me to: > "See doc/html/index.html for installation instructions and other > relevant documentation." > but doc/html does not contain a index.html or anything else that look like > installation options. > rgds > jani -- This message was sent by Atlassian JIRA (v6.1#6144) - To unsubscribe, e-mail: c-dev-unsubscr...@xerces.apache.org For additional commands, e-mail: c-dev-h...@xerces.apache.org
[jira] [Resolved] (XERCESC-2023) Use icu, which is built with features
[ https://issues.apache.org/jira/browse/XERCESC-2023?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alberto Massari resolved XERCESC-2023. -- Resolution: Fixed Fix Version/s: 3.2.0 Assignee: Alberto Massari > Use icu, which is built with features > - > > Key: XERCESC-2023 > URL: https://issues.apache.org/jira/browse/XERCESC-2023 > Project: Xerces-C++ > Issue Type: Bug > Components: Utilities >Affects Versions: 3.1.1 >Reporter: Aleksey Dobrunov >Assignee: Alberto Massari > Labels: icu, patch > Fix For: 3.2.0 > > Attachments: ICUTransService.cpp.diff > > > if the library 'icu' compiled with the flag U_NO_DEFAULT_INCLUDE_UTF_HEADERS > (http://source.icu-project.org/repos/icu/icu/trunk/readme.html#RecBuild), > then build 'xercesc' fails. > attached patche solve these problem -- This message was sent by Atlassian JIRA (v6.1#6144) - To unsubscribe, e-mail: c-dev-unsubscr...@xerces.apache.org For additional commands, e-mail: c-dev-h...@xerces.apache.org
[jira] [Resolved] (XERCESC-2024) LocalFileFormatTarget leaks file handle
[ https://issues.apache.org/jira/browse/XERCESC-2024?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alberto Massari resolved XERCESC-2024. -- Resolution: Fixed Fix Version/s: 3.2.0 Assignee: Alberto Massari A fix is in SVN. Please verify. > LocalFileFormatTarget leaks file handle > --- > > Key: XERCESC-2024 > URL: https://issues.apache.org/jira/browse/XERCESC-2024 > Project: Xerces-C++ > Issue Type: Bug > Components: Miscellaneous >Reporter: Vemund Handeland >Assignee: Alberto Massari > Fix For: 3.2.0 > > Attachments: LocalFileFormatTarget.cpp.patch > > > The call to XMLPlatformUtils::writeBufferToFile in the LocalFileFormatTarget > destructor might throw an exception. A typical use case is running out of > disk space. > In this case the file handle will not be closed -- This message was sent by Atlassian JIRA (v6.1#6144) - To unsubscribe, e-mail: c-dev-unsubscr...@xerces.apache.org For additional commands, e-mail: c-dev-h...@xerces.apache.org
[jira] [Commented] (XERCESC-2019) Error in memory allocation for even small messages.
[ https://issues.apache.org/jira/browse/XERCESC-2019?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13790187#comment-13790187 ] Alberto Massari commented on XERCESC-2019: -- You need to get the current trunk of the repository from https://svn.apache.org/repos/asf/xerces/c/trunk > Error in memory allocation for even small messages. > --- > > Key: XERCESC-2019 > URL: https://issues.apache.org/jira/browse/XERCESC-2019 > Project: Xerces-C++ > Issue Type: Bug > Components: DOM >Affects Versions: 3.1.1 > Environment: windows XP vc9, linux and solaris >Reporter: mahalakshmi >Assignee: Alberto Massari > Labels: patch > Fix For: 3.2.0 > > Attachments: zippedfiles.zip > > > I have my xsd schema using which i have created my standard xml. > After creating the xml i fill the values for each tag in my xml. > I get memory allocation error when i try to traverse through the xml and set > the values for each tag in my xml. > I get allocation error when my program calls the setTextcontent() of > xerces.It is crashing in DOMDocumentImpl.cpp allocate(size).(2nd if condition > in that function) > Is there any setting that needs to be done for memory allocation? How much is > the maximum size of xml that xerces can parse?how do we manage the memory > allocation and deallocation in DOM? -- This message was sent by Atlassian JIRA (v6.1#6144) - To unsubscribe, e-mail: c-dev-unsubscr...@xerces.apache.org For additional commands, e-mail: c-dev-h...@xerces.apache.org
[jira] [Resolved] (XERCESC-1988) memory leak DOMBuffer::expandCapacity
[
https://issues.apache.org/jira/browse/XERCESC-1988?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Alberto Massari resolved XERCESC-1988.
--
Resolution: Duplicate
Duplicate of XERCESC-2019
> memory leak DOMBuffer::expandCapacity
> -
>
> Key: XERCESC-1988
> URL: https://issues.apache.org/jira/browse/XERCESC-1988
> Project: Xerces-C++
> Issue Type: Bug
> Components: DOM
>Affects Versions: 3.1.0
> Environment: all
>Reporter: Reinier vos
>
> in src/xercesc/dom/impl/DOMStringPool.cpp
> DOMBuffer::expandCapacity
> a new buffer of the required size is created while leaving the original
> buffer in memory (comented as a know issue). This posses serious memory
> issues for large strings ( e.g. base64 strings). Creating a text node of 60MB
> requires like 600MB memory.
> I poked a little change in the mentioned function which by no means is a neat
> way but for this application it does the trick (and it describes the issue):
> // Copy over the old stuff
> memcpy(newBuf, fBuffer, fCapacity * sizeof(XMLCh));
> // in DOMDocumentImpl::allocate a standard block
> (header+buffer[kHeapAllocSize]) is used for allocations <=
> kMaxSubAllocationSize
> // Anything bigger is put into its own block (with its own buffer[cap])
> // Check if the buffer we expaned was in its own block, this can be
> deleted safely after a reallocate
> if ( fCapacity * sizeof(XMLCh) > 4096 )
> {
> size_t sizeOfHeader =
> XMLPlatformUtils::alignPointerForNewBlockAllocation(sizeof(void *));
> //retrieve the location of the buffer preceding the one we're
> about to delete
> //set this location in the new header
> *(void **)( (char *)newBuf-sizeOfHeader )=*(void **)( (char
> *)fBuffer-sizeOfHeader );
> delete(((char *)fBuffer-sizeOfHeader));
> }
> // store new stuff
> fBuffer = newBuf;
> fCapacity = newCap;
--
This message was sent by Atlassian JIRA
(v6.1#6144)
-
To unsubscribe, e-mail: c-dev-unsubscr...@xerces.apache.org
For additional commands, e-mail: c-dev-h...@xerces.apache.org
[jira] [Resolved] (XERCESC-2019) Error in memory allocation for even small messages.
[ https://issues.apache.org/jira/browse/XERCESC-2019?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alberto Massari resolved XERCESC-2019. -- Resolution: Fixed Fix Version/s: (was: 3.1.1) 3.2.0 Assignee: Alberto Massari Xerces has always been conservative with the memory it had allocated, i.e. it never deallocated the memory of a DOMText node when an append() was called, to avoid crashing the client code that had retrieved the previous pointer via a call to getNodeValue(). In your case this implied allocating a lot of intermediate memory blocks before the 250Mb needed by your Base64 string were finally allocated. I have checked in a workaround that allows the parser (and only the parser) to deallocate them. > Error in memory allocation for even small messages. > --- > > Key: XERCESC-2019 > URL: https://issues.apache.org/jira/browse/XERCESC-2019 > Project: Xerces-C++ > Issue Type: Bug > Components: DOM >Affects Versions: 3.1.1 > Environment: windows XP vc9, linux and solaris >Reporter: mahalakshmi >Assignee: Alberto Massari > Labels: patch > Fix For: 3.2.0 > > Attachments: zippedfiles.zip > > > I have my xsd schema using which i have created my standard xml. > After creating the xml i fill the values for each tag in my xml. > I get memory allocation error when i try to traverse through the xml and set > the values for each tag in my xml. > I get allocation error when my program calls the setTextcontent() of > xerces.It is crashing in DOMDocumentImpl.cpp allocate(size).(2nd if condition > in that function) > Is there any setting that needs to be done for memory allocation? How much is > the maximum size of xml that xerces can parse?how do we manage the memory > allocation and deallocation in DOM? -- This message was sent by Atlassian JIRA (v6.1#6144) - To unsubscribe, e-mail: c-dev-unsubscr...@xerces.apache.org For additional commands, e-mail: c-dev-h...@xerces.apache.org
[jira] [Resolved] (XERCESC-2016) XML 1.0 5th edition support
[
https://issues.apache.org/jira/browse/XERCESC-2016?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Alberto Massari resolved XERCESC-2016.
--
Resolution: Fixed
Fix Version/s: (was: 3.1.2)
3.2.0
Assignee: Alberto Massari
I have gone through the 5th edition specs and implemented a good part of it;
the XML Test suite still reports 16 failures mainly due to URI rules
> XML 1.0 5th edition support
> ---
>
> Key: XERCESC-2016
> URL: https://issues.apache.org/jira/browse/XERCESC-2016
> Project: Xerces-C++
> Issue Type: Improvement
> Components: Non-Validating Parser
>Affects Versions: 3.1.1
> Environment: All
>Reporter: Rob Cameron
>Assignee: Alberto Massari
> Fix For: 3.2.0
>
> Attachments: diff5e
>
>
> Xerces-C currently applies XML 1.0 4th edition rules to name characters
> in XML 1.0 documents.XML 1.0 5th edition permits a broader class
> of name characters, based on those permitted in XML 1.1.
> Proposal: that Xerces-C 3.2.0 be updated to include support for XML 1.0
> 5th edition.
> Although our main work is with icXML, we've looked at making this change
> in Xerces-C original code base so that icXML support for XML 1.0 5e is
> compatible with us.
> I'm not entirely sure that I've handled everything, but the following change
> works in our test. The change plan is below and a svn diff file is
> attached.
> Here is the change plan.
> --
> (1) internal/CharTypeTables.hpp
> Rename gFirstNameChars1_1 to be gFirstNameChars
> Rename gNameChars1_1 to be gNameChars
> (2) util/XMLChar.cpp
> (2a)
>Update initCharFlagTable1_1() to use the gFirstNameChars, gNameChars
>Update initCharFlagTable() to use the set-ups from initCharFlagTable1_1()
> to define gNameCharMask, gNCNameCharMask, and gFirstNameCharMask.
> //
> // Name characters are special. A name is made up of a number of
> // different tables and some special case characters.
> //
> initOneTable(gNameChars, gNameCharMask);
> //
> // Name characters are special. A name is made up of a number of
> // different tables and some special case characters.
> //
> initOneTable(gNameChars, gNCNameCharMask);
> gTmpCharTable[chColon] &= ~gNCNameCharMask;
> //
> // Then do the first name char
> //
> initOneTable(gFirstNameChars, gFirstNameCharMask);
> (2b) #define NEED_TO_GEN_TABLE
> compile and do a sample run of a Xerces app, generate table.out
> (2c) Replace the XMLChar1_0::fgCharCharsTable1_0 definition pf XMLChar.cpp
> with that from table.out.
> (3) XMLChar.hpp
> Modify XMLChar1_0::isFirstNameChar, XMLChar1_0::isFirstNCNameChar,
> XMLChar1_0::isNameChar, XMLChar1_0::isNCNameChar
> to each check for and allow characters in the #x1-#xE range
> else {
> if ((toCheck >= 0xD800) && (toCheck <= 0xDB7F))
>if ((toCheck2 >= 0xDC00) && (toCheck2 <= 0xDFFF))
>return true;
> }
> (4) Modify XMLReader::getName and XMLReader::getNCName
>to allow surrogate pairs in Names and NCNames
>(i.e., use the version 1.1 logic for both 1.0 and 1.1).
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
-
To unsubscribe, e-mail: c-dev-unsubscr...@xerces.apache.org
For additional commands, e-mail: c-dev-h...@xerces.apache.org
[jira] [Resolved] (XERCESC-2017) Xerces-C++ is not always able to handle W3C standard keyref
[ https://issues.apache.org/jira/browse/XERCESC-2017?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alberto Massari resolved XERCESC-2017. -- Resolution: Fixed Fix Version/s: 3.2.0 Assignee: Alberto Massari A fix is in SVN. Please verify > Xerces-C++ is not always able to handle W3C standard keyref > --- > > Key: XERCESC-2017 > URL: https://issues.apache.org/jira/browse/XERCESC-2017 > Project: Xerces-C++ > Issue Type: Bug > Components: Validating Parser (XML Schema) >Affects Versions: 3.1.1 >Reporter: Mihran Hovsepyan >Assignee: Alberto Massari > Fix For: 3.2.0 > > > I use *Xerces-C++ 3.1.1* to validate schema of xml files. Bellow is example > of some such file. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > And in its schema the following key and keyref are defined for the root > element `CONFIG`. > >xpath="./DBS/DB|./DBS/VDB|./DBS/VDB/PARTS/PART_DB" /> > > > >/> > > > So, though the file meets requirements of the schema according to *W3C* and > some validators understand that (for instance XML validator of *MS Visual > Studio*), *Xerces-C++ 3.1.1* unable to do that. It complains: > identity constraint key for element 'CONFIG' not found (last_line, > last_column_of_last_line) -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: c-dev-unsubscr...@xerces.apache.org For additional commands, e-mail: c-dev-h...@xerces.apache.org
[jira] [Commented] (XERCESC-2019) Error in memory allocation for even small messages.
[ https://issues.apache.org/jira/browse/XERCESC-2019?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13743283#comment-13743283 ] Alberto Massari commented on XERCESC-2019: -- Can you attach the XML and the code that you use to populate each tag? > Error in memory allocation for even small messages. > --- > > Key: XERCESC-2019 > URL: https://issues.apache.org/jira/browse/XERCESC-2019 > Project: Xerces-C++ > Issue Type: Bug > Components: DOM >Affects Versions: 3.1.1 > Environment: windows XP vc9, linux and solaris >Reporter: mahalakshmi > Labels: patch > Fix For: 3.1.1 > > > I have my xsd schema using which i have created my standard xml. > After creating the xml i fill the values for each tag in my xml. > I get memory allocation error when i try to traverse through the xml and set > the values for each tag in my xml. > I get allocation error when my program calls the setTextcontent() of > xerces.It is crashing in DOMDocumentImpl.cpp allocate(size).(2nd if condition > in that function) > Is there any setting that needs to be done for memory allocation? How much is > the maximum size of xml that xerces can parse?how do we manage the memory > allocation and deallocation in DOM? -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: c-dev-unsubscr...@xerces.apache.org For additional commands, e-mail: c-dev-h...@xerces.apache.org
[jira] [Resolved] (XERCESC-2021) pdb file extension fullpdb not compatible with symbol server
[ https://issues.apache.org/jira/browse/XERCESC-2021?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alberto Massari resolved XERCESC-2021. -- Resolution: Fixed Fix Version/s: 3.2.0 Assignee: Alberto Massari I opted for a .full.pdb extension, to keep the stripped database as the default PDB for release versions > pdb file extension fullpdb not compatible with symbol server > > > Key: XERCESC-2021 > URL: https://issues.apache.org/jira/browse/XERCESC-2021 > Project: Xerces-C++ > Issue Type: Improvement > Components: Build >Affects Versions: 3.1.1 > Environment: Visual Studio >Reporter: Vemund Handeland >Assignee: Alberto Massari >Priority: Minor > Fix For: 3.2.0 > > Attachments: pdb_file_extension.patch > > > Release builds of XercesLib creates pdb file "xerces-c_3_1.fullpdb" + > stripped pdb file "xerces-c_3_1.pdb". > Full path to the first file is included in the dll, and the debugger uses > this information to locate the symbols. The stripped version must be renamed > before it can be used. > The extension fullpdb is not compatible with Microsoft Symbol Server > (http://msdn.microsoft.com/en-us/library/ms680693(v=vs.85).aspx). (I've not > been able to add the file with symstore.exe, and the debuggers are unable to > fetch a copy I've manually added to my symbol server). -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: c-dev-unsubscr...@xerces.apache.org For additional commands, e-mail: c-dev-h...@xerces.apache.org
[jira] [Resolved] (XERCESC-2020) Off-by-one error in TranscodeFromStr (with ICU)
[
https://issues.apache.org/jira/browse/XERCESC-2020?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Alberto Massari resolved XERCESC-2020.
--
Resolution: Fixed
Fix Version/s: 3.2.0
A fix is in SVN. Please verify
> Off-by-one error in TranscodeFromStr (with ICU)
> ---
>
> Key: XERCESC-2020
> URL: https://issues.apache.org/jira/browse/XERCESC-2020
> Project: Xerces-C++
> Issue Type: Bug
> Components: Utilities
>Affects Versions: 3.1.1
> Environment: ICU, Visual C++ 2012
>Reporter: Martin Raiber
>Assignee: Alberto Massari
> Fix For: 3.2.0
>
>
> The char-Array charSizes in TranscodeFromStr::transcode is initialized with
> length csSize.
> ICUTranscoder::transcodeFrom is called with maxChars=csSize+1.
> For a fixed length encoding charSizes is set via memset(charSizes, fillSize,
> maxChars); writing one character too much.
> To reproduce:
> xercesc::TranscodeFromStr transcoder(reinterpret_cast("foo"),
> 3, "ISO-8859-15");
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
-
To unsubscribe, e-mail: c-dev-unsubscr...@xerces.apache.org
For additional commands, e-mail: c-dev-h...@xerces.apache.org
[jira] [Assigned] (XERCESC-2020) Off-by-one error in TranscodeFromStr (with ICU)
[
https://issues.apache.org/jira/browse/XERCESC-2020?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Alberto Massari reassigned XERCESC-2020:
Assignee: Alberto Massari
> Off-by-one error in TranscodeFromStr (with ICU)
> ---
>
> Key: XERCESC-2020
> URL: https://issues.apache.org/jira/browse/XERCESC-2020
> Project: Xerces-C++
> Issue Type: Bug
> Components: Utilities
>Affects Versions: 3.1.1
> Environment: ICU, Visual C++ 2012
>Reporter: Martin Raiber
>Assignee: Alberto Massari
>
> The char-Array charSizes in TranscodeFromStr::transcode is initialized with
> length csSize.
> ICUTranscoder::transcodeFrom is called with maxChars=csSize+1.
> For a fixed length encoding charSizes is set via memset(charSizes, fillSize,
> maxChars); writing one character too much.
> To reproduce:
> xercesc::TranscodeFromStr transcoder(reinterpret_cast("foo"),
> 3, "ISO-8859-15");
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
-
To unsubscribe, e-mail: c-dev-unsubscr...@xerces.apache.org
For additional commands, e-mail: c-dev-h...@xerces.apache.org
[jira] [Closed] (XERCESC-2006) build xerces-c with icu on mingw gcc 4.7.2
[ https://issues.apache.org/jira/browse/XERCESC-2006?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alberto Massari closed XERCESC-2006. > build xerces-c with icu on mingw gcc 4.7.2 > -- > > Key: XERCESC-2006 > URL: https://issues.apache.org/jira/browse/XERCESC-2006 > Project: Xerces-C++ > Issue Type: Bug > Environment: mingw > icu 5 from trunk > xerces-c from trunk > gcc 4.7.2 >Reporter: Aleksey Dobrunov >Assignee: Alberto Massari > Fix For: 3.2.0 > > Attachments: xerces_icu_prefix.m4.diff > > > i am trying build xerces-c with icu > reconf > ./configure --enable-transcoder-icu --enable-msgloader-icu --disable-network > in the end > configure:21971: Report: > configure:21973: File Manager: Windows > configure:21975: Mutex Manager: Windows > configure:21977: Transcoder: windows > configure:21979: NetAccessor: disabled > configure:21981: Message Loader: inmemory > in config.log > configure:18085: checking for ucnv_open in -licuuc > configure:18103: g++ -o conftest.exe -O2 -mthreads -I/icu1/include > -lpthread -lm -L/icu1/lib -licui18n -licuuc -licudata -lpthread -lm > conftest.cpp >&5 > C:\Users\ALEKSE~1.DOB\AppData\Local\Temp\ccg1wi5K.o:conftest.cpp:(.text.startup+0x1e): > undefined reference to `ucnv_open_51' > collect2.exe: error: ld returned 1 exit status > This error occurs because conftest.cpp specified later runtime libraries on > which it depends. > this command work fine > g++ -o conftest.exe -O2 conftest.cpp -mthreads -I/icu1/include-lpthread > -lm -L/icu1/lib -licui18n -licuuc -licudata -lpthread -lm -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: c-dev-unsubscr...@xerces.apache.org For additional commands, e-mail: c-dev-h...@xerces.apache.org
[jira] [Resolved] (XERCESC-1998) Add support for GNU/Hurd by using POSIX.1-2001 and POSIX.1-2008 functions
[ https://issues.apache.org/jira/browse/XERCESC-1998?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alberto Massari resolved XERCESC-1998. -- Resolution: Fixed Fix Version/s: (was: 3.1.1) 3.2.0 Assignee: Alberto Massari I added a test for PATH_MAX in the configure script. Please verify. > Add support for GNU/Hurd by using POSIX.1-2001 and POSIX.1-2008 functions > - > > Key: XERCESC-1998 > URL: https://issues.apache.org/jira/browse/XERCESC-1998 > Project: Xerces-C++ > Issue Type: Bug > Components: Utilities >Affects Versions: 3.1.1 > Environment: Debian GNU/Hurd i386 >Reporter: Svante Signell >Assignee: Alberto Massari > Labels: patch > Fix For: 3.2.0 > > Attachments: use_posix_fcns.patch > > Original Estimate: 1h > Remaining Estimate: 1h > > Hello, > The attached patch solves the build problems for GNU/Hurd due to > unconditional use of PATH_MAX which is not defined on Hurd (and is optional > in POSIX). The functions used are realpath (newSrc, NULL) from POSIX.1-2008 > and getcwd (NULL, 0) from glibc-based systems. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: c-dev-unsubscr...@xerces.apache.org For additional commands, e-mail: c-dev-h...@xerces.apache.org
[jira] [Resolved] (XERCESC-2006) build xerces-c with icu on mingw gcc 4.7.2
[ https://issues.apache.org/jira/browse/XERCESC-2006?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alberto Massari resolved XERCESC-2006. -- Resolution: Fixed Fix Version/s: 3.2.0 Assignee: Alberto Massari The patch is in SVN. Please verify. > build xerces-c with icu on mingw gcc 4.7.2 > -- > > Key: XERCESC-2006 > URL: https://issues.apache.org/jira/browse/XERCESC-2006 > Project: Xerces-C++ > Issue Type: Bug > Environment: mingw > icu 5 from trunk > xerces-c from trunk > gcc 4.7.2 >Reporter: Aleksey Dobrunov >Assignee: Alberto Massari > Fix For: 3.2.0 > > Attachments: xerces_icu_prefix.m4.diff > > > i am trying build xerces-c with icu > reconf > ./configure --enable-transcoder-icu --enable-msgloader-icu --disable-network > in the end > configure:21971: Report: > configure:21973: File Manager: Windows > configure:21975: Mutex Manager: Windows > configure:21977: Transcoder: windows > configure:21979: NetAccessor: disabled > configure:21981: Message Loader: inmemory > in config.log > configure:18085: checking for ucnv_open in -licuuc > configure:18103: g++ -o conftest.exe -O2 -mthreads -I/icu1/include > -lpthread -lm -L/icu1/lib -licui18n -licuuc -licudata -lpthread -lm > conftest.cpp >&5 > C:\Users\ALEKSE~1.DOB\AppData\Local\Temp\ccg1wi5K.o:conftest.cpp:(.text.startup+0x1e): > undefined reference to `ucnv_open_51' > collect2.exe: error: ld returned 1 exit status > This error occurs because conftest.cpp specified later runtime libraries on > which it depends. > this command work fine > g++ -o conftest.exe -O2 conftest.cpp -mthreads -I/icu1/include-lpthread > -lm -L/icu1/lib -licui18n -licuuc -licudata -lpthread -lm -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: c-dev-unsubscr...@xerces.apache.org For additional commands, e-mail: c-dev-h...@xerces.apache.org
[jira] [Closed] (XERCESC-2009) crosscompilation fails in revision 1458655
[ https://issues.apache.org/jira/browse/XERCESC-2009?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alberto Massari closed XERCESC-2009. Resolution: Won't Fix Assignee: Alberto Massari It is required to run the test program, as the function must be present AND behave as expected (i.e. set the input pointer to NULL if the conversion reached the end of the buffer) > crosscompilation fails in revision 1458655 > -- > > Key: XERCESC-2009 > URL: https://issues.apache.org/jira/browse/XERCESC-2009 > Project: Xerces-C++ > Issue Type: Bug > Components: Build >Affects Versions: 3.1.0, 3.1.1 > Environment: Cross compiling for android on linux >Reporter: Michael >Assignee: Alberto Massari >Priority: Trivial > Original Estimate: 0h > Remaining Estimate: 0h > > Cross compiling Xerces-c fails since the current configure.ac relies on > AC_RUN_IFELSE when it checks for wcsrtombs and mbsrtowcs. > The fix is: > mkm@mkm:~/sandbox/build/android_external/xerces-c-trunk$ svn diff > configure.ac > Index: configure.ac > === > --- configure.ac(revision 1458655) > +++ configure.ac(working copy) > @@ -161,7 +161,7 @@ > ] > ) > AC_MSG_CHECKING([for wcsrtombs]) > -AC_RUN_IFELSE( [AC_LANG_PROGRAM([[#include > +AC_COMPILE_IFELSE( [AC_LANG_PROGRAM([[#include > #include ]], > [[ > mbstate_t st; > @@ -183,7 +183,7 @@ > ] > ) > AC_MSG_CHECKING([for mbsrtowcs]) > -AC_RUN_IFELSE( [AC_LANG_PROGRAM([[#include > +AC_COMPILE_IFELSE( [AC_LANG_PROGRAM([[#include > #include ]], > [[ > mbstate_t st; > Best regards, Michael -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: c-dev-unsubscr...@xerces.apache.org For additional commands, e-mail: c-dev-h...@xerces.apache.org
[jira] [Closed] (XERCESC-2013) Xerces SAX parser gives segmentation fault, while parsing message
[
https://issues.apache.org/jira/browse/XERCESC-2013?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Alberto Massari closed XERCESC-2013.
Resolution: Cannot Reproduce
Assignee: Alberto Massari
I couldn't reproduce it with Xerces 3.1 on Windows: I have modified the
personal.xsd that ships with the Xerces samples to define the 'email' field as
a simple type similar to your case (I just added the @ and the . character to
the allowed characters)
Then I invoked
saxprint -n -s -f -v=always samples\data\personal-schema.xml
and I didn't see any segmentation fault.
Can you try testing your schema with Xerces 3.1?
> Xerces SAX parser gives segmentation fault, while parsing message
> -
>
> Key: XERCESC-2013
> URL: https://issues.apache.org/jira/browse/XERCESC-2013
> Project: Xerces-C++
> Issue Type: Bug
> Components: SAX/SAX2, Validating Parser (XML Schema)
>Affects Versions: 2.8.0
> Environment: Linux
>Reporter: sunny
>Assignee: Alberto Massari
> Labels: patch, performance
>
> I'm validating an xml message with an xsd which contains the following
> element.
>
>
>
>
>
>
> I'm using sax parser for validation. For validating the data present in the
> above element xerces parser gives segmentation fault. If i remove '*' from
> pattern it is working fine.
> I replaced "" with value="([a-zA-Z0-9_\-]){1,10}"/>, then it works fine but consumes lot of
> memory and CPU.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
-
To unsubscribe, e-mail: c-dev-unsubscr...@xerces.apache.org
For additional commands, e-mail: c-dev-h...@xerces.apache.org
[jira] [Resolved] (XERCESC-2011) Xerces 3.1.1 Xerces.Lib fails to build with new Visual Studio 2012 Update 1 when v110_xp platform is chosen
[ https://issues.apache.org/jira/browse/XERCESC-2011?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alberto Massari resolved XERCESC-2011. -- Resolution: Fixed Fix Version/s: 3.2.0 Assignee: Alberto Massari A fix is in SVN. Please verify. > Xerces 3.1.1 Xerces.Lib fails to build with new Visual Studio 2012 Update 1 > when v110_xp platform is chosen > --- > > Key: XERCESC-2011 > URL: https://issues.apache.org/jira/browse/XERCESC-2011 > Project: Xerces-C++ > Issue Type: Bug > Components: Build >Affects Versions: 3.1.1 > Environment: VS2012 Update 1, platform set to V110_xp (introduced by > Update 1) instead of the pre-update V110. > Windows 32-bit builds. >Reporter: DK >Assignee: Alberto Massari > Fix For: 3.2.0 > > > Same issue as defined in: > http://social.msdn.microsoft.com/Forums/en-US/vcgeneral/thread/ea289832-c48c-475b-a922-bf94d2ee54e4/ > Static Debug & Static Release compile without issue. Normal Debug and > Release both have this issue. Not tested 64-bit builds. > Compilation output has: > 1>C:\Program Files (x86)\Microsoft Visual Studio > 11.0\VC\include\string.h(57): warning RC4011: identifier truncated to > '_CRT_SECURE_CPP_OVERLOAD_STANDA' > 1> > 1>C:\Program Files (x86)\Microsoft Visual Studio > 11.0\VC\include\string.h(79): warning RC4011: identifier truncated to > '_CRT_SECURE_CPP_OVERLOAD_SECURE' > 1> > 1>C:\Program Files (x86)\Microsoft Visual Studio > 11.0\VC\include\string.h(115): fatal error RC10056: -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: c-dev-unsubscr...@xerces.apache.org For additional commands, e-mail: c-dev-h...@xerces.apache.org
[jira] [Closed] (XERCESC-1987) Transcoding Issue with single XMLCh to utf8
[ https://issues.apache.org/jira/browse/XERCESC-1987?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alberto Massari closed XERCESC-1987. Resolution: Won't Fix The code in the trunk works correctly; we are not backporting fixes to 2.8 though > Transcoding Issue with single XMLCh to utf8 > --- > > Key: XERCESC-1987 > URL: https://issues.apache.org/jira/browse/XERCESC-1987 > Project: Xerces-C++ > Issue Type: Bug > Components: Utilities >Affects Versions: 2.8.0 > Environment: Windows XP >Reporter: Simon White > > There appears to be an issue with transcoding to utf8. Conditions: > Input string = Single Chinese Character (XmlCh holds value 27493). > Problem code in TranscodeToStr::transcode: > unsigned int allocSize = len * sizeof(XMLCh); > fString = (XMLByte*)fMemoryManager->allocate(allocSize); > This code sets the output buffer to be two bytes. The issue here is that the > character in question converts to a 3 byte utf8 character. It therefore hits > this in XMLUTF8Transcoder.cpp: > // If we cannot fully get this char into the output buffer, > // then leave it for the next time. > // > if (outPtr + encodedBytes > outEnd) > break; > Since this is only a single character being converted it returns 0 and then > hits this since nothing could be decoded: > if(charsRead == 0) > ThrowXMLwithMemMgr(TranscodingException, > XMLExcepts::Trans_BadSrcSeq, fMemoryManager); > The sequence is not invalid, only output buffer has been limited to input > buffer size. Is simply adding a few spare characters to allocSize the > correct fix? -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: c-dev-unsubscr...@xerces.apache.org For additional commands, e-mail: c-dev-h...@xerces.apache.org
[jira] [Resolved] (XERCESC-1984) TranscodeToStr::transcode throws an exception when transcoding to UTF-8
[ https://issues.apache.org/jira/browse/XERCESC-1984?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alberto Massari resolved XERCESC-1984. -- Resolution: Fixed Fix Version/s: 3.2.0 Assignee: Alberto Massari A fix is in SVN. Please verify. > TranscodeToStr::transcode throws an exception when transcoding to UTF-8 > --- > > Key: XERCESC-1984 > URL: https://issues.apache.org/jira/browse/XERCESC-1984 > Project: Xerces-C++ > Issue Type: Bug > Components: Utilities >Affects Versions: 3.2.0, 4.0.0 > Environment: Bug reproducible on a Red Hat 5 based platform. The bug > doesn't seem to be platform specific though. >Reporter: Dan PV >Assignee: Alberto Massari > Labels: exception, transcode > Fix For: 3.2.0 > > Attachments: transtest2.cpp > > > This issue relates to the bug fix for issue XERCESC-1947. There are still > cases where the method will fail in providing a transcoded version without > throwing an exception. See the attached "transtest2.cpp" to reproduce the > issue. > The cause seems to come from the added "if((allocSize - fBytesWritten) < (len > - charsDone))" condition in "TranscodeToStr::transcode" . In my provided test > case I have a string composed of 6 Japanese characters (i.e. "絞り込み検索"). Once > the first call to "XMLUTF8Transcoder::transcodeTo" is done, "charsRead" will > return a count of 5 XMLCh readed. Since the initial allocated buffer for this > string was set to 16 bytes, the condition will check against the following > values "if((16 - 15) < (6 - 5))" which avoids the reallocation of a larger > buffer for the UTF-8 encoded version of the string. > Since the reallocation doesn't take place, the code will recall > "XMLUTF8Transcoder::transcodeTo" but this time the "charsRead" count will be > set to 0 because there is insufficient space in the buffer and this will > trigger an exception of type "Trans_BadSrcSeq". > I suppose that the goal of this added condition was to avoid an unnecessary > reallocation of a buffer but unfortunately it doesn’t work when transcoding > to variable length encoding like UTF-8. The solution is probably to simply > replace the condition with "if(charsDone < len)". > Regards, > Dan -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: c-dev-unsubscr...@xerces.apache.org For additional commands, e-mail: c-dev-h...@xerces.apache.org
[jira] [Updated] (XERCESC-2000) enumeration value ‘Loop’ not handled in switch src/SEnumVal/SEnumVal.cpp:
[ https://issues.apache.org/jira/browse/XERCESC-2000?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alberto Massari updated XERCESC-2000: - Fix Version/s: (was: 3.1.2) 3.2.0 > enumeration value ‘Loop’ not handled in switch src/SEnumVal/SEnumVal.cpp: > - > > Key: XERCESC-2000 > URL: https://issues.apache.org/jira/browse/XERCESC-2000 > Project: Xerces-C++ > Issue Type: Bug >Reporter: james michael dupont >Assignee: Alberto Massari >Priority: Trivial > Fix For: 3.2.0 > > > src/SEnumVal/SEnumVal.cpp: In function ‘void processContentSpecNode(const > xercesc_3_1::ContentSpecNode*, bool)’: > src/SEnumVal/SEnumVal.cpp:494:11: warning: enumeration value ‘Loop’ not > handled in switch -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: c-dev-unsubscr...@xerces.apache.org For additional commands, e-mail: c-dev-h...@xerces.apache.org
[jira] [Updated] (XERCESC-2001) no return statement in function returning non-void xercesc_3_1::formatNodeHolder& xercesc_3_1::formatNodeHolder::operator=(const xercesc_3_1::formatNodeHolder*)
[ https://issues.apache.org/jira/browse/XERCESC-2001?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alberto Massari updated XERCESC-2001: - Fix Version/s: (was: 3.1.2) 3.2.0 > no return statement in function returning non-void > xercesc_3_1::formatNodeHolder& xercesc_3_1::formatNodeHolder::operator=(const > xercesc_3_1::formatNodeHolder*) > - > > Key: XERCESC-2001 > URL: https://issues.apache.org/jira/browse/XERCESC-2001 > Project: Xerces-C++ > Issue Type: Bug >Reporter: james michael dupont >Assignee: Alberto Massari > Fix For: 3.2.0 > > > xercesc/validators/common/ContentSpecNode.cpp: In member function > ‘xercesc_3_1::formatNodeHolder& > xercesc_3_1::formatNodeHolder::operator=(const > xercesc_3_1::formatNodeHolder*)’: > xercesc/validators/common/ContentSpecNode.cpp:108:2: warning: no return > statement in function returning non-void -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: c-dev-unsubscr...@xerces.apache.org For additional commands, e-mail: c-dev-h...@xerces.apache.org
[jira] [Updated] (XERCESC-1997) VS2012 Project
[ https://issues.apache.org/jira/browse/XERCESC-1997?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alberto Massari updated XERCESC-1997: - Fix Version/s: (was: 3.1.2) 3.2.0 > VS2012 Project > -- > > Key: XERCESC-1997 > URL: https://issues.apache.org/jira/browse/XERCESC-1997 > Project: Xerces-C++ > Issue Type: Improvement > Components: Build >Affects Versions: 3.1.1 >Reporter: Pedro Larroy >Assignee: Alberto Massari > Fix For: 3.2.0 > > Attachments: xerces_vc11proj.zip > > > Hi > I attach project files for Visual studio 2012 for xerces-3.1.1 -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: c-dev-unsubscr...@xerces.apache.org For additional commands, e-mail: c-dev-h...@xerces.apache.org
[jira] [Closed] (XERCESC-1989) Xerces 3.1.1 Xerces.Lib fails to build with new Visual Studio 2012 RC
[ https://issues.apache.org/jira/browse/XERCESC-1989?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alberto Massari closed XERCESC-1989. Resolution: Cannot Reproduce I was able to compile the sources with the final version of Visual Studio 2012 > Xerces 3.1.1 Xerces.Lib fails to build with new Visual Studio 2012 RC > - > > Key: XERCESC-1989 > URL: https://issues.apache.org/jira/browse/XERCESC-1989 > Project: Xerces-C++ > Issue Type: Bug > Components: Build >Affects Versions: 3.1.1 > Environment: Windows 7, new Visual Studio 2012 RC. Building x86 > XercesLib. >Reporter: DK >Priority: Minor > Original Estimate: 5m > Remaining Estimate: 5m > > Error during resource compile. I raised it as an issue with MS Connect and > the response states that it is due to a change in "winnt.h" where previous > warning messages are now error messages. > Text from MS reply is: > The reason this is a build error now, instead of a build warning, is due to a > change in winnt.h. If you look at line 141, you'll reach the #error > statement on this line because none of the architecture constants are defined. > There are a couple of ways to work around this build error, in order of > preference: > 1. Remove the #include statement from your .rc files if it's not > needed. > 2. Replace the #include statement with #include or > #include > 3. If you really need to keep the #include statement in place, you > can define one of the architecture constants before the #include line, for > example: > #define _X86_ > #include > I have tested '2' by changing 'winnt.h' to 'winnt.rh' on lines 11 & 87 in > xerces-c-3.1.1\src\xercesc\util\MsgLoaders\Win32\Version.rc and it now > compiles and links without error. > Obviously, your choice of option suggested by MS that you wish to employ. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: c-dev-unsubscr...@xerces.apache.org For additional commands, e-mail: c-dev-h...@xerces.apache.org
[jira] [Updated] (XERCESC-1997) VS2012 Project
[ https://issues.apache.org/jira/browse/XERCESC-1997?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alberto Massari updated XERCESC-1997: - Fix Version/s: 3.1.2 > VS2012 Project > -- > > Key: XERCESC-1997 > URL: https://issues.apache.org/jira/browse/XERCESC-1997 > Project: Xerces-C++ > Issue Type: Improvement > Components: Build >Affects Versions: 3.1.1 >Reporter: Pedro Larroy >Assignee: Alberto Massari > Fix For: 3.1.2 > > Attachments: xerces_vc11proj.zip > > > Hi > I attach project files for Visual studio 2012 for xerces-3.1.1 -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: c-dev-unsubscr...@xerces.apache.org For additional commands, e-mail: c-dev-h...@xerces.apache.org
[jira] [Resolved] (XERCESC-2000) enumeration value ‘Loop’ not handled in switch src/SEnumVal/SEnumVal.cpp:
[ https://issues.apache.org/jira/browse/XERCESC-2000?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alberto Massari resolved XERCESC-2000. -- Resolution: Fixed Fix Version/s: 3.1.2 Assignee: Alberto Massari A fix is in SVN. Please verify. Alberto > enumeration value ‘Loop’ not handled in switch src/SEnumVal/SEnumVal.cpp: > - > > Key: XERCESC-2000 > URL: https://issues.apache.org/jira/browse/XERCESC-2000 > Project: Xerces-C++ > Issue Type: Bug >Reporter: james michael dupont >Assignee: Alberto Massari >Priority: Trivial > Fix For: 3.1.2 > > > src/SEnumVal/SEnumVal.cpp: In function ‘void processContentSpecNode(const > xercesc_3_1::ContentSpecNode*, bool)’: > src/SEnumVal/SEnumVal.cpp:494:11: warning: enumeration value ‘Loop’ not > handled in switch -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: c-dev-unsubscr...@xerces.apache.org For additional commands, e-mail: c-dev-h...@xerces.apache.org
[jira] [Resolved] (XERCESC-2001) no return statement in function returning non-void xercesc_3_1::formatNodeHolder& xercesc_3_1::formatNodeHolder::operator=(const xercesc_3_1::formatNodeHolder*)
[ https://issues.apache.org/jira/browse/XERCESC-2001?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alberto Massari resolved XERCESC-2001. -- Resolution: Fixed Fix Version/s: 3.1.2 Assignee: Alberto Massari A fix is in SVN. Please verify. Alberto > no return statement in function returning non-void > xercesc_3_1::formatNodeHolder& xercesc_3_1::formatNodeHolder::operator=(const > xercesc_3_1::formatNodeHolder*) > - > > Key: XERCESC-2001 > URL: https://issues.apache.org/jira/browse/XERCESC-2001 > Project: Xerces-C++ > Issue Type: Bug >Reporter: james michael dupont >Assignee: Alberto Massari > Fix For: 3.1.2 > > > xercesc/validators/common/ContentSpecNode.cpp: In member function > ‘xercesc_3_1::formatNodeHolder& > xercesc_3_1::formatNodeHolder::operator=(const > xercesc_3_1::formatNodeHolder*)’: > xercesc/validators/common/ContentSpecNode.cpp:108:2: warning: no return > statement in function returning non-void -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: c-dev-unsubscr...@xerces.apache.org For additional commands, e-mail: c-dev-h...@xerces.apache.org
[jira] [Closed] (XERCESC-2008) xsi:type whiteSpace facet
[ https://issues.apache.org/jira/browse/XERCESC-2008?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alberto Massari closed XERCESC-2008. Resolution: Duplicate Duplicate of XERCESC-1945 > xsi:type whiteSpace facet > - > > Key: XERCESC-2008 > URL: https://issues.apache.org/jira/browse/XERCESC-2008 > Project: Xerces-C++ > Issue Type: Bug > Components: Validating Parser (XML Schema) >Affects Versions: 2.8.0, 3.0.0, 3.1.0, 3.1.1 > Environment: Windows 7, Command Prompt, example program DOMCount. >Reporter: Herbert Oppmann >Priority: Minor > > With the example below, the validation returns "type ' ItemT' specified in > 'xsi:type' cannot be resolved". > Obviously, Xerces does not do Attribute Value Normalization applying > whiteSpace="collapse" on the attribute 'xsi:type'. > The value of the attribute 'xsi:type' is QName (see > http://www.w3.org/TR/xmlschema-1/#xsi_type). QName is an atomic type (see > http://www.w3.org/TR/xmlschema-2/#built-in-datatypes). For atomic datatypes > the value of the whiteSpace facet is 'collapse' (see > http://www.w3.org/TR/xmlschema-2/#rf-whiteSpace). > The command line used is: DOMCount.exe -v=always -s -f -n Type.xml > Schema Type.xsd: > > http://www.w3.org/2001/XMLSchema"; > xmlns:test="http://www.example.com/Type"; > targetNamespace="http://www.example.com/Type"; elementFormDefault="qualified" > attributeFormDefault="unqualified"> > > > >maxOccurs="unbounded"/> > > > > > > > > Example Type.xml: > > http://www.w3.org/2001/XMLSchema-instance"; > xmlns="http://www.example.com/Type"; > xsi:schemaLocation="http://www.example.com/Type Type.xsd"> > > > -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: c-dev-unsubscr...@xerces.apache.org For additional commands, e-mail: c-dev-h...@xerces.apache.org
[jira] [Resolved] (XERCESC-1997) VS2012 Project
[ https://issues.apache.org/jira/browse/XERCESC-1997?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alberto Massari resolved XERCESC-1997. -- Resolution: Fixed Assignee: Alberto Massari I finally got VS2012 installed and could perform the upgrade myself. Thanks > VS2012 Project > -- > > Key: XERCESC-1997 > URL: https://issues.apache.org/jira/browse/XERCESC-1997 > Project: Xerces-C++ > Issue Type: Improvement > Components: Build >Affects Versions: 3.1.1 >Reporter: Pedro Larroy >Assignee: Alberto Massari > Attachments: xerces_vc11proj.zip > > > Hi > I attach project files for Visual studio 2012 for xerces-3.1.1 -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: c-dev-unsubscr...@xerces.apache.org For additional commands, e-mail: c-dev-h...@xerces.apache.org
[jira] [Commented] (XERCESC-1975) InvalidDatatypeValueException thrown when parsing a UnionDataType
[ https://issues.apache.org/jira/browse/XERCESC-1975?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13551226#comment-13551226 ] Alberto Massari commented on XERCESC-1975: -- Yes, the exception is expected, and handled: the UnionDatatypeValidator::checkContent attempts to validate the incoming data with every child validator, and stops when one of them accepts it. If all of them throw a validation error, then a different exception (VALUE_no_match_memberType) is thrown. > InvalidDatatypeValueException thrown when parsing a UnionDataType > - > > Key: XERCESC-1975 > URL: https://issues.apache.org/jira/browse/XERCESC-1975 > Project: Xerces-C++ > Issue Type: Bug > Components: Validating Parser (XML Schema) >Affects Versions: 3.1.1 >Reporter: Ashish Singhal >Priority: Blocker > Attachments: TestDoc.xml, TestSchema.xsd > > > InvalidDatatypeValueException is thrown when parsing an XML document that > contains a Union data type and the union is contains another simple data > type, eg: > Given this schema: > http://www.w3.org/2001/XMLSchema"; > elementFormDefault="qualified" attributeFormDefault="unqualified"> > > > > > > > > > > > > > > > > > > This XML should be valid: > > xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"; > testAttribute="true" > > > > > However an InvalidDatatypeValueException is thrown when validating this > document. > Changing my schema to remove SubPattern from the SubString union, fixes the > issue, but it's not the solution I'm looking for. > I would like xerces-c to validate the document correctly. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: c-dev-unsubscr...@xerces.apache.org For additional commands, e-mail: c-dev-h...@xerces.apache.org
[jira] [Resolved] (XERCESC-2004) bit operation error in DOMNodeImpl::reverseTreeOrderBitPattern
[
https://issues.apache.org/jira/browse/XERCESC-2004?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Alberto Massari resolved XERCESC-2004.
--
Resolution: Fixed
Fix Version/s: 3.2.0
Assignee: Alberto Massari
Thanks for spotting this; the fix is now in SVN
> bit operation error in DOMNodeImpl::reverseTreeOrderBitPattern
> ---
>
> Key: XERCESC-2004
> URL: https://issues.apache.org/jira/browse/XERCESC-2004
> Project: Xerces-C++
> Issue Type: Bug
> Components: DOM
>Affects Versions: 3.1.1
> Environment: any
>Reporter: 朱亚东
>Assignee: Alberto Massari
> Fix For: 3.2.0
>
>
> code like below:
> short DOMNodeImpl::reverseTreeOrderBitPattern(short pattern) const {
> if(pattern & DOMNode::DOCUMENT_POSITION_PRECEDING) {
> pattern &= !DOMNode::DOCUMENT_POSITION_PRECEDING;
> pattern |= DOMNode::DOCUMENT_POSITION_FOLLOWING;
> }
> I think it should be:
> short DOMNodeImpl::reverseTreeOrderBitPattern(short pattern) const {
> if(pattern & DOMNode::DOCUMENT_POSITION_PRECEDING) {
> pattern &= ~DOMNode::DOCUMENT_POSITION_PRECEDING;
> pattern |= DOMNode::DOCUMENT_POSITION_FOLLOWING;
> }
> because !DOMNode::DOCUMENT_POSITION_PRECEDING always be 0.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
-
To unsubscribe, e-mail: c-dev-unsubscr...@xerces.apache.org
For additional commands, e-mail: c-dev-h...@xerces.apache.org
[jira] [Closed] (XERCESC-2005) Cannot possible to append imported node
[
https://issues.apache.org/jira/browse/XERCESC-2005?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Alberto Massari closed XERCESC-2005.
Resolution: Invalid
Please don't open bugs to ask questions: use c-us...@xerces.apache.org instead
> Cannot possible to append imported node
> ---
>
> Key: XERCESC-2005
> URL: https://issues.apache.org/jira/browse/XERCESC-2005
> Project: Xerces-C++
> Issue Type: Bug
> Components: DOM
>Affects Versions: 3.1.1
> Environment: Windows XP
>Reporter: subins jose
> Labels: Exception, appendchild, importNode
> Fix For: 3.1.1
>
>
> I have one node, that is imported from second document. When I try to append
> this node to first node, it throws an exception.
> DOMImplementation* pDOMImplementation =
> DOMImplementationRegistry::getDOMImplementation(XMLString::transcode( "CORE"
> ));
> pDOMParser =
> pDOMImplementation->createLSParser(DOMImplementationLS::MODE_SYNCHRONOUS, 0);
> if( pDOMParser->getDomConfig()->canSetParameter( XMLUni::fgDOMValidate,
> true ) )
> pDOMParser->getDomConfig()->setParameter(
> XMLUni::fgDOMValidate, true );
> if( pDOMParser->getDomConfig()->canSetParameter(
> XMLUni::fgDOMNamespaces, true ) )
> pDOMParser->getDomConfig()->setParameter(
> XMLUni::fgDOMNamespaces, true );
> if( pDOMParser->getDomConfig()->canSetParameter(
> XMLUni::fgDOMDatatypeNormalization, true ) )
> pDOMParser->getDomConfig()->setParameter(
> XMLUni::fgDOMDatatypeNormalization, true );
> pFirstDOMDocumnt = pDOMParser->parseURI(path);
> pSecondDOMDocumnt = pDOMParser->parseURI(path);
>
> ..
> try
> {
> DOMNode* pImportedNode =pSecondDOMDocumnt->importNode(pChild, true);
> pParent->appendChild(pChildElement);
> }
> catch(DOMException exe)
> {
> fprintf(stdout,"Exception : %S\n",exe.getMessage());
> }
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
-
To unsubscribe, e-mail: c-dev-unsubscr...@xerces.apache.org
For additional commands, e-mail: c-dev-h...@xerces.apache.org
[jira] [Commented] (XERCESC-2002) XMLString::transcode for multi-byte characters are returning null on Linux
[
https://issues.apache.org/jira/browse/XERCESC-2002?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13480227#comment-13480227
]
Alberto Massari commented on XERCESC-2002:
--
I am still waiting for an answer to the "If that fails, check which transcoder
has been selected when building Xerces, because that changes what is considered
the default locale" part of the comment
> XMLString::transcode for multi-byte characters are returning null on Linux
> ---
>
> Key: XERCESC-2002
> URL: https://issues.apache.org/jira/browse/XERCESC-2002
> Project: Xerces-C++
> Issue Type: Bug
> Components: Miscellaneous
>Affects Versions: 2.7.0
>Reporter: Ratnesh Nath
>Priority: Critical
>
> XMLCh *tag1 = XMLString::transcode("test-in-english");
> Printing: CsEws::XmlChToString(tag1).c_str()); >>> output is :
> test-in-english
> XMLCh *tag2 = XMLString::transcode("ã«ã¯");
> Printing: CsEws::XmlChToString(tag1).c_str()); >>> output is : <<< NULL
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
-
To unsubscribe, e-mail: c-dev-unsubscr...@xerces.apache.org
For additional commands, e-mail: c-dev-h...@xerces.apache.org
[jira] [Commented] (XERCESC-2002) XMLString::transcode for multi-byte characters are returning null on Linux
[
https://issues.apache.org/jira/browse/XERCESC-2002?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13479224#comment-13479224
]
Alberto Massari commented on XERCESC-2002:
--
No, I am saying not to use non-ASCII characters in a C++ source file, as you
never know how they are read by the compiler; in your case, it should be
something like \xC3\xA3\xC2\xAB\xC3\xA3\xC2\xAF (assuming you want to transcode
the string ã«ã¯ )
> XMLString::transcode for multi-byte characters are returning null on Linux
> ---
>
> Key: XERCESC-2002
> URL: https://issues.apache.org/jira/browse/XERCESC-2002
> Project: Xerces-C++
> Issue Type: Bug
> Components: Miscellaneous
>Affects Versions: 2.7.0
>Reporter: Ratnesh Nath
>Priority: Critical
>
> XMLCh *tag1 = XMLString::transcode("test-in-english");
> Printing: CsEws::XmlChToString(tag1).c_str()); >>> output is :
> test-in-english
> XMLCh *tag2 = XMLString::transcode("ã«ã¯");
> Printing: CsEws::XmlChToString(tag1).c_str()); >>> output is : <<< NULL
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
-
To unsubscribe, e-mail: c-dev-unsubscr...@xerces.apache.org
For additional commands, e-mail: c-dev-h...@xerces.apache.org
[jira] [Commented] (XERCESC-2002) XMLString::transcode for multi-byte characters are returning null on Linux
[
https://issues.apache.org/jira/browse/XERCESC-2002?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13479199#comment-13479199
]
Alberto Massari commented on XERCESC-2002:
--
Try with a) writing the string to transcode using escape characters ("\x80")
and b) printing the single XMLCh character instead of going through
CsEws::XmlChToString so that we can rule out other possibilities. If that
fails, check which transcoder has been selected when building Xerces, because
that changes what is considered the default locale
> XMLString::transcode for multi-byte characters are returning null on Linux
> ---
>
> Key: XERCESC-2002
> URL: https://issues.apache.org/jira/browse/XERCESC-2002
> Project: Xerces-C++
> Issue Type: Bug
> Components: Miscellaneous
>Affects Versions: 2.7.0
>Reporter: Ratnesh Nath
>Priority: Critical
>
> XMLCh *tag1 = XMLString::transcode("test-in-english");
> Printing: CsEws::XmlChToString(tag1).c_str()); >>> output is :
> test-in-english
> XMLCh *tag2 = XMLString::transcode("ã«ã¯");
> Printing: CsEws::XmlChToString(tag1).c_str()); >>> output is : <<< NULL
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
-
To unsubscribe, e-mail: c-dev-unsubscr...@xerces.apache.org
For additional commands, e-mail: c-dev-h...@xerces.apache.org
[jira] [Closed] (XERCESC-2002) XMLString::transcode for multi-byte characters are returning null on Linux
[
https://issues.apache.org/jira/browse/XERCESC-2002?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Alberto Massari closed XERCESC-2002.
Resolution: Invalid
XMLString::transcode converts to/from the current locale. It's up to the user
to guarantee that the char* specified as argument is a valid string for the
current locale. I guess your locale is not UTF-8, and so the conversion fails.
You should create a transcoder for the encoding of the input string, and use
XMLString::transcode only for data coming from stdin, or being printed to stdout
> XMLString::transcode for multi-byte characters are returning null on Linux
> ---
>
> Key: XERCESC-2002
> URL: https://issues.apache.org/jira/browse/XERCESC-2002
> Project: Xerces-C++
> Issue Type: Bug
> Components: Miscellaneous
>Affects Versions: 2.7.0
>Reporter: Ratnesh Nath
>Priority: Critical
>
> XMLCh *tag1 = XMLString::transcode("test-in-english");
> Printing: CsEws::XmlChToString(tag1).c_str()); >>> output is :
> test-in-english
> XMLCh *tag2 = XMLString::transcode("ã«ã¯");
> Printing: CsEws::XmlChToString(tag1).c_str()); >>> output is : <<< NULL
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
-
To unsubscribe, e-mail: c-dev-unsubscr...@xerces.apache.org
For additional commands, e-mail: c-dev-h...@xerces.apache.org
[jira] [Commented] (XERCESC-1996) Chinese characters are not parsed correctly
[ https://issues.apache.org/jira/browse/XERCESC-1996?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13462571#comment-13462571 ] Alberto Massari commented on XERCESC-1996: -- Could you specify which string isn't represented correctly, and what should be the correct label? Thanks > Chinese characters are not parsed correctly > --- > > Key: XERCESC-1996 > URL: https://issues.apache.org/jira/browse/XERCESC-1996 > Project: Xerces-C++ > Issue Type: Bug > Components: DOM >Affects Versions: 3.1.1 > Environment: Windows 2008 R2 64 bit >Reporter: Shreedhara Udupa > Attachments: ChineseXML.xml > > > When xml file (Refer attached) with chinese characters are parsed few > character are missed. In the attached xml group names are not parsed . Few > character are missed -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: c-dev-unsubscr...@xerces.apache.org For additional commands, e-mail: c-dev-h...@xerces.apache.org
[jira] [Commented] (XERCESC-1995) Allow compiling Xerces-C using C++11 (especially Clang)
[ https://issues.apache.org/jira/browse/XERCESC-1995?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13455660#comment-13455660 ] Alberto Massari commented on XERCESC-1995: -- Yes, we try to avoid newer keywords unless they are really needed, to avoid dropping old compilers for unnecessary reasons > Allow compiling Xerces-C using C++11 (especially Clang) > --- > > Key: XERCESC-1995 > URL: https://issues.apache.org/jira/browse/XERCESC-1995 > Project: Xerces-C++ > Issue Type: Improvement > Components: Utilities >Affects Versions: 3.1.1 > Environment: Shouldn't matter (FreeBSD9.1 RC1) >Reporter: Michael Gmelin >Assignee: Alberto Massari >Priority: Minor > Labels: patch > Fix For: 3.2.0 > > Attachments: CompileXercersC++11.patch > > Original Estimate: 0.5h > Remaining Estimate: 0.5h > > gcc issues a couple of warnings in C++11 about narrowing conversions, clang > refuses to build for the same reason. > The attached patch solves this trivial problem by adding a few static casts > in the right places. > While you're on it you might also want to apply XERCESC-1994, which had been > revealed by compiling xerces-c using Clang. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: c-dev-unsubscr...@xerces.apache.org For additional commands, e-mail: c-dev-h...@xerces.apache.org
[jira] [Resolved] (XERCESC-1994) ContentSpecNode::getMaxTotalRange: Operator precedence flaw
[
https://issues.apache.org/jira/browse/XERCESC-1994?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Alberto Massari resolved XERCESC-1994.
--
Resolution: Fixed
Fix Version/s: 3.2.0
Assignee: Alberto Massari
A fix is in SVN. Please verify.
> ContentSpecNode::getMaxTotalRange: Operator precedence flaw
> ---
>
> Key: XERCESC-1994
> URL: https://issues.apache.org/jira/browse/XERCESC-1994
> Project: Xerces-C++
> Issue Type: Bug
> Components: Validating Parser (XML Schema)
>Affects Versions: 3.1.1
> Environment: Not relevant, C++ syntax problem
>Reporter: Michael Gmelin
>Assignee: Alberto Massari
> Fix For: 3.2.0
>
> Attachments: ContentSpecNode.cpp.patch
>
> Original Estimate: 0.25h
> Remaining Estimate: 0.25h
>
> ContentSpecType.cpp says at about line 260:
> if ((fType & 0x0f) == ContentSpecNode::Choice) {
> max = max * (maxFirst > maxSecond) ? maxFirst : maxSecond;
> }
> Thanks to operator precedence max evaluates either to maxFirst or maxSecond,
> but never to max*maxFirst or max*maxSecond.
> Adding parenthesis makes this do the right thing:
> max = max * ((maxFirst > maxSecond) ? maxFirst :
> maxSecond);
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
-
To unsubscribe, e-mail: c-dev-unsubscr...@xerces.apache.org
For additional commands, e-mail: c-dev-h...@xerces.apache.org
[jira] [Resolved] (XERCESC-1995) Allow compiling Xerces-C using C++11 (especially Clang)
[ https://issues.apache.org/jira/browse/XERCESC-1995?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alberto Massari resolved XERCESC-1995. -- Resolution: Fixed Fix Version/s: 3.2.0 Assignee: Alberto Massari A fix is in SVN. Please verify. > Allow compiling Xerces-C using C++11 (especially Clang) > --- > > Key: XERCESC-1995 > URL: https://issues.apache.org/jira/browse/XERCESC-1995 > Project: Xerces-C++ > Issue Type: Improvement > Components: Utilities >Affects Versions: 3.1.1 > Environment: Shouldn't matter (FreeBSD9.1 RC1) >Reporter: Michael Gmelin >Assignee: Alberto Massari >Priority: Minor > Labels: patch > Fix For: 3.2.0 > > Attachments: CompileXercersC++11.patch > > Original Estimate: 0.5h > Remaining Estimate: 0.5h > > gcc issues a couple of warnings in C++11 about narrowing conversions, clang > refuses to build for the same reason. > The attached patch solves this trivial problem by adding a few static casts > in the right places. > While you're on it you might also want to apply XERCESC-1994, which had been > revealed by compiling xerces-c using Clang. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: c-dev-unsubscr...@xerces.apache.org For additional commands, e-mail: c-dev-h...@xerces.apache.org
[jira] [Resolved] (XERCESC-1985) I get empty strings from the startElements
[
https://issues.apache.org/jira/browse/XERCESC-1985?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Alberto Massari resolved XERCESC-1985.
--
Resolution: Invalid
In the startElement call, you get data either in the pair uri+localname, or in
the qname variable. If localname is always empty, it means you didn't turn on
namespace processing and you should look to the qname
> I get empty strings from the startElements
> --
>
> Key: XERCESC-1985
> URL: https://issues.apache.org/jira/browse/XERCESC-1985
> Project: Xerces-C++
> Issue Type: Bug
> Components: Validating Parser (XML Schema)
>Affects Versions: 3.1.1
> Environment: Linux Ubuntu 12.04
>Reporter: Jean-Michel Richer
>Priority: Minor
>
> I have installed xerces 3.1.1 and xalan 1.11. I have developped a simple
> Handler (inherited from DefaultHandler) but when I parse an xml file I don't
> get the tag which should be reported by the startElement function. Here is
> the code :
> void XMLIOHandler::startElement(const XMLCh* consturi,
> const XMLCh* constlocalname,
> const XMLCh* constqname,
> const Attributes& attrs) {
> char *element_ptr = NULL;
> element_ptr = XMLString::transcode(localname);
> first_element = element_ptr;
> cerr << first_element << endl;
> XMLString::release(&element_ptr);
> }
> it always display an empty string. I really don't know how to solve this. I
> am doing something wrong ?
> Best regards,
> JM
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
-
To unsubscribe, e-mail: c-dev-unsubscr...@xerces.apache.org
For additional commands, e-mail: c-dev-h...@xerces.apache.org
[jira] [Closed] (XERCESC-1950) Build-in UCS4 transcoder does not respect endianess
[ https://issues.apache.org/jira/browse/XERCESC-1950?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alberto Massari closed XERCESC-1950. Resolution: Cannot Reproduce Fix Version/s: (was: 3.1.2) (was: 3.2.0) I tested a modified version of your file (Xerces now doesn't serialize invalid XML characters, so my sample contained a 각 reference), but the output files I get back are different. Looking at them with a binary editor, they show either 01 AC 00 00 (little endian) or 00 00 AC 01 (big endian) > Build-in UCS4 transcoder does not respect endianess > --- > > Key: XERCESC-1950 > URL: https://issues.apache.org/jira/browse/XERCESC-1950 > Project: Xerces-C++ > Issue Type: Bug > Components: Utilities >Affects Versions: 3.1.1 > Environment: any >Reporter: Boris Kolpackov > Attachments: test.xml > > > Built-in UCS4 transcoder does not respect endianess of the requested > encoding. Try this on the attached test file: > DOMPrint -wenc=UCS-4LE -wfile=le.xml test.xml > DOMPrint -wenc=UCS-4BE -wfile=be.xml test.xml > The resulting two files will have the same representations for "long" > characters, little-endian if run on LE machine, and big-endian if run on a BE > machine. The UTF-32 transcoder doesn't seem to have this problem. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: c-dev-unsubscr...@xerces.apache.org For additional commands, e-mail: c-dev-h...@xerces.apache.org
[jira] [Closed] (XERCESC-1953) extra newline after declaration in 1st use of DOMWriter
[ https://issues.apache.org/jira/browse/XERCESC-1953?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alberto Massari closed XERCESC-1953. Resolution: Won't Fix The 2.x branch will not be updated anymore > extra newline after declaration in 1st use of DOMWriter > --- > > Key: XERCESC-1953 > URL: https://issues.apache.org/jira/browse/XERCESC-1953 > Project: Xerces-C++ > Issue Type: Bug > Components: DOM >Affects Versions: 2.8.0 > Environment: Solaris 10 >Reporter: tommy klehr >Priority: Minor > > the sample program produces different output from DOMWriter although it's > using the same input. > The first output has an extra newline after the declaration. The second > output has the document element on the same line as the declaration. > - > [mynah63.dev.sol10] $ ./tc > impl = 4df4c > theSerializer = 58764 > can set it to discarddefaultcontent > can set it to formatprettyprint > rc from writeNote() = 1 > value = > ' > > Tove > Jani > Reminder > Dear > Don't forget me this weekend! > > ' > next take... > impl = 4df4c > theSerializer = 5a144 > can set it to discarddefaultcontent > can set it to formatprettyprint > rc from writeNote() = 1 > value = > ' > Tove > Jani > Reminder > Dear > Don't forget me this weekend! > > ' > $ > - > #include > #include > #include > #include > #include > #include > #include > #include > #include > #include > #include > #include > #include > #include > #include > #include > #include > #include > #include > #include > #include > #include > #include > #include > #include > #include > #include > #include > #include > #include > #include > #include > //These includes are for converting XML document into String > #include > #include > #include > #include > #include > #include > #include > #include > #include > #include > #include > #include > //#include > //For Xerces DOM usage > #include > #include > #include > #include > #include > #include > //#include > #include > #include > #include // This is needed for > const LocalFileInputSource theInputSource(theFileName.c_str()); > #include // This is needed for > const MemBufInputSource theInputSource(theFileName.c_str()); > #include > #include > //#include > #include > #include > #include > #include > #include > #include > #include > #include > XALAN_USING_STD(cerr) > XALAN_USING_STD(endl) > XALAN_USING_STD(ostream) > XALAN_USING_STD(ifstream) > XALAN_USING_XALAN(XalanDocument) > XALAN_USING_XALAN(XPathEvaluator) > XALAN_USING_XALAN(XalanDOMString) > XALAN_USING_XALAN(XalanSourceTreeInit) > XALAN_USING_XALAN(XercesDOMSupport) > XALAN_USING_XALAN(XercesParserLiaison) > XALAN_USING_XALAN(XalanVector) > XALAN_USING_XALAN(ExecutionContext) > XALAN_USING_XALAN(MemoryManagerType) > //For Xerces DOM usage > XALAN_USING_XERCES(XMLPlatformUtils) > XALAN_USING_XERCES(DOMNode) > XALAN_USING_XERCES(DOMNamedNodeMap) > XALAN_USING_XERCES(XMLString) > XALAN_USING_XERCES(DOMImplementation) > XALAN_USING_XERCES(DOMImplementationRegistry) > XALAN_USING_XERCES(DOMWriter) > XALAN_USING_XERCES(DOMImplementationLS) > XALAN_USING_XERCES(XMLUni) > //XALAN_USING_XERCES(DOMWriterFilter) > XALAN_USING_XERCES(DOMErrorHandler) > XALAN_USING_XERCES(XMLFormatTarget) > //XALAN_USING_XERCES(DOMWriterFilter) > XALAN_USING_XERCES(LocalFileInputSource) //const LocalFileInputSource > theInputSource(theFileName.c_str()); > XALAN_USING_XERCES(MemBufInputSource) > XALAN_USING_XERCES(MemBufFormatTarget) > XALAN_USING_XERCES(XMLException) > XALAN_USING_XERCES(DOMException) > XALAN_USING_XERCES(DOMNodeFilter) > XALAN_USING_XERCES(LocalFileFormatTarget) > //For XPath > XALAN_USING_XALAN(XPathEvaluator) > XALAN_USING_XALAN(XObjectPtr) > XALAN_USING_XALAN(XalanNode) > XALAN_USING_XALAN(XalanElement) > XALAN_USING_XALAN(XalanDOMException) > XALAN_USING_XALAN(XalanXPathException) > XALAN_USING_XALAN(XPathParserException) > XALAN_USING_XALAN(NodeRefList) > //For Transformer > XALAN_USING_XALAN(XalanCompiledStylesheet) > XALAN_USING_XALAN(XalanDOMString) > XALAN_USING_XALAN(XalanTransformer) > XALAN_USING_XALAN(XSLTInputSource) > XALAN_USING_XALAN(XSLTResultTarget) > XALAN_USING_XALAN(XalanNamedNodeMap) > XALAN_USING_XALAN(XalanStdOutputStream) > XALAN_USING_XALAN(XalanOutputStreamPrintWriter) > XALAN_USING_XALAN(FormatterToXML) > XALAN_USING_XALAN(FormatterTreeWalker) > XALAN_USING_XERCES(DOMDocument); > XALAN_USING_XERCES(DOMElement); > //XALAN_USING_XERCES(DOM_Node) > XALAN_USING_XERCES(DOMText) > XALAN_USING_XERCES(DOMDocumentType) > XALAN_USING_XERCES(DOMDocumentF
[jira] [Resolved] (XERCESC-1962) memory leak with XInclude
[
https://issues.apache.org/jira/browse/XERCESC-1962?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Alberto Massari resolved XERCESC-1962.
--
Resolution: Fixed
Fix Version/s: 3.2.0
Assignee: Alberto Massari
A fix is in SVN. Please verify
> memory leak with XInclude
> -
>
> Key: XERCESC-1962
> URL: https://issues.apache.org/jira/browse/XERCESC-1962
> Project: Xerces-C++
> Issue Type: Bug
> Components: XInclude
>Affects Versions: 3.1.1
> Environment: Linux Ubuntu 10.10 i386
>Reporter: Paulo Zanoni
>Assignee: Alberto Massari
> Labels: example, leak, patch,
> Fix For: 3.2.0
>
> Attachments: xinclude-example.xml, xinclude-leak.patch,
> xinclude_leak.cpp
>
> Original Estimate: 2h
> Remaining Estimate: 2h
>
> When xerces-c++ is parsing files with XInclude, it leaks memory. You can
> check the memory leak by running "valgrind".
> This behavior can be reproduced both with the "XInclude" binary and with
> custom code.
> All you need to do is:
> - create a parser
> - set validation scheme to Val_Auto
> - setDoNamespaces(true)
> - setDoXInclude(true)
> - parser.parse("example.xml");
> I have tracked the bug. The "actual" leak is inside
> XIncludeUtils::reportError. It uses XMLPlatformUtils::loadMsgSet, which calls
> loadAMsgSet, which allocates memory and returns to its callee (see
> XMLPlatformUtils::loadAMsgSet inside utils/PlatformUtils.cpp). The memory
> allocated by loadAMsgSet is never freed.
> The solution:
> In file xinclude/XIncludeUtils.cpp, function XIncludeUtils::reportError, the
> pointer allocated by XMLPlatformUtils::loadMsgSet should be freed. For my
> testings, I just added a "delete erMsgLoader" at the end of the scope, but I
> am not sure this is enough (since I'm not sure if any of the functions
> between loadMsgSet and the end of the scope can throw exceptions). It is up
> to you, developers, find a proper solution =D
> I'll attach examples.
> I locally tested my patch (I rebuild the Ubuntu package) and it seems to have
> worked, but I didn't test much. I am not familiar with xerces-c code so I'm
> not sure if it can break anything.
> Thanks,
> Paulo
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
-
To unsubscribe, e-mail: c-dev-unsubscr...@xerces.apache.org
For additional commands, e-mail: c-dev-h...@xerces.apache.org
[jira] [Commented] (XERCESC-1979) OutOfMemoryException being thrown on creation of an LS Serializer
[
https://issues.apache.org/jira/browse/XERCESC-1979?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13259612#comment-13259612
]
Alberto Massari commented on XERCESC-1979:
--
Mainly to avoid an extra test when allocating memory, for a case that now
should never occur (unless the user invokes our allocator directly) and that on
every platform but AIX is producing a valid pointer
> OutOfMemoryException being thrown on creation of an LS Serializer
> -
>
> Key: XERCESC-1979
> URL: https://issues.apache.org/jira/browse/XERCESC-1979
> Project: Xerces-C++
> Issue Type: Bug
> Components: Miscellaneous
>Affects Versions: 3.1.1
> Environment: AIX 6.1 and AIX 7.1
> 32-bit binary distribution libraries of Xerces 3.1.1
> Compiler (on AIX 6.1):
> IBM XL C/C++ for AIX, V11.1 (5724-X13)
> Version: 11.01..
> Driver Version: 11.01(C/C++) Level: 100304
> C Front End Version: 11.00(C/C++) Level: 100301
> C++ Front End Version: 11.01(C/C++) Level: 100304
> High-Level Optimizer Version: 11.01(C/C++) and 13.01(Fortran) Level: 100301
> Low-Level Optimizer Version: 11.01(C/C++) and 13.01(Fortran) Level: 100304
>Reporter: Matt Dissinger
>Assignee: Alberto Massari
> Fix For: 3.2.0
>
> Attachments: Xerces MemoryManagerImpl Patch.zip
>
>
> I am seeing with one of my companies' unit test binaries an
> OutOfMemoryException being thrown when attempting to create an LS serializer.
> The program code in question is:
> {code}
> xercesc::DOMImplementation* impl =
> DOMImplementationRegistry::getDOMImplementation(XMLString::transcode("LS"));
> impl->createLSSerializer();
> {code}
> We are currently only seeing this with one of our unit test binaries, and
> only on AIX. We haven't seen this yet on our production binaries or on
> Solaris, RedHat Enterprise Linux, or Windows. The root cause is an
> allocation of 0 bytes for which the ::operator new is returning a NULL
> pointer, and the MemoryManagerImpl throws an OutOfMemoryException when this
> occurs. This happens as a result of the DOMLSSerializerImpl object
> allocating a RefVectorOf with an initial size of 0, and the base class
> BaseRefVectorOf's constructor calling allocate with 0 bytes.
> Even though the C++ standard does allow for allocations of 0 bytes, it is a
> potential point of failure that can be avoided by not attempting the 0 byte
> allocation. Since the standard does define that dereferencing a pointer
> returned as a request for zero size is undefined, it should be safe to return
> NULL for 0 byte allocations (3.7.4.1 - Allocation functions, point 2, from
> the draft version here:
> http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2010/n3035.pdf).
> I've tested a change to the MemoryManagerImpl class which checks for 0 byte
> allocations and immediately returns NULL rather than attempting an ::operator
> new (0), and it has fixed the issue in our AIX environments.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
-
To unsubscribe, e-mail: c-dev-unsubscr...@xerces.apache.org
For additional commands, e-mail: c-dev-h...@xerces.apache.org
[jira] [Closed] (XERCESC-1940) Problem in prefix parsing while creating Documnet, Element, Attributes on all platforms : Issue is in poolString creation
[
https://issues.apache.org/jira/browse/XERCESC-1940?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Alberto Massari closed XERCESC-1940.
Resolution: Duplicate
Same issue of XERCESC-1978
> Problem in prefix parsing while creating Documnet, Element, Attributes on all
> platforms : Issue is in poolString creation
> -
>
> Key: XERCESC-1940
> URL: https://issues.apache.org/jira/browse/XERCESC-1940
> Project: Xerces-C++
> Issue Type: Bug
> Components: DOM
>Affects Versions: 3.0.1, 3.1.1
> Environment: ALL Platform, ALL OS
>Reporter: Anil G Pandge
>Priority: Critical
> Fix For: 3.1.2, 3.2.0
>
> Attachments: DOMDocumentImpl.hpp.patch, MainPro.cpp
>
>
> Description:
>
> When I create a DOM document using xerces APIs, for very specific input its
> creating wrong payload. This is observable on 64-bit but on 32-bit. For
> testing I have written sample with createDocument API which creates DOM
> document and print it in string format.
> I ran the test on following inputs:
> createDocument("types:statusSet","http://xyz.com";);
> createDocument function just create dom document and prints payloads.
> Following is the outputs of above string on 32-bit machine.
> 32 bit platforms output:
> prefix = types:statusSet
> LocalName = statusSet
> doc = http://xyz.com"/>
> ===
> Severity : Critical
> ===
> Platforms: ALL
> ==
> Cause and resolution
>
> I debugged xerces code, issue is in
> File : "DOMDocumentImpl.hpp"
> Function : "DOMDocumentImpl::getPooledNString(const XMLCh *in, XMLSize_t n)"
> Patch:
> ==
> --- DOMDocumentImpl.hpp2008-07-24 15:58:29.0 +0530
> +++
> /data/eclipse_workspace/CppIT-3.1.0/XercesTEst/src/xercesc/dom/impl/DOMDocumentImpl.hpp
> 2010-08-22 10:36:18.0 +0530
> @@ -401,9 +401,11 @@
>pspe = &fNameTable[inHash];
>while (*pspe != 0)
>{
> -if (XMLString::equalsN((*pspe)->fString, in, n))
> - return (*pspe)->fString;
> -pspe = &((*pspe)->fNext);
> + XMLCh firstN[n];
> + XMLString::copyNString(firstN,in,n);
> + if (XMLString::equals((*pspe)->fString, firstN))
> + return (*pspe)->fString;
> + pspe = &((*pspe)->fNext);
>}
> Issue:
> ==
> 1. getPooledNString computes hash of prefix and searches in fNameTable.
> 2. Once hash is found, code cheks pooledString and 'n' characters of
> qualifiedString. ! WRONG !
> 3. if comparision is true it returns the pooled string.
> Ex:
> In case of "types:statusSet", it will compare "types:statusSet"
> and first 6 characters of "types:", it found comparision true. It return
> pooled string "types:statusSet" as prefix ! WRONG !
> How to reporduce:
> =
> Very easy to reproduce. Run the sample program I have attached.
>
> Resolution:
> ===
> I have attached patch file with resolution.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
-
To unsubscribe, e-mail: c-dev-unsubscr...@xerces.apache.org
For additional commands, e-mail: c-dev-h...@xerces.apache.org
[jira] [Closed] (XERCESC-1980) type 'derivationControl' not found when using XMLSchema.xsd
[ https://issues.apache.org/jira/browse/XERCESC-1980?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alberto Massari closed XERCESC-1980. Resolution: Invalid >From the error message it looks that the schema contains an extra character >(represend by the ' entity). In any case, the XMLSchema.xsd is not >supposed to be validated by the schema validator, as it defines the same types >that are pre-defined inside the Xerces code > type 'derivationControl' not found when using XMLSchema.xsd > --- > > Key: XERCESC-1980 > URL: https://issues.apache.org/jira/browse/XERCESC-1980 > Project: Xerces-C++ > Issue Type: Bug > Components: Validating Parser (XML Schema) >Affects Versions: 3.1.1 > Environment: Ubuntu 11.10 Linux default libxerces-c3.1 version > 3.1.1-1build1 Intel 64bit >Reporter: Cezar Andrei >Priority: Critical > > Using Xerces C++ API to load XMLSchema.xsd from > http://www.w3.org/2001/XMLSchema.xsd , I get the following error even if the > type 'derivationControl' is defined later in the same file at line 2082. > "Error in schema with system id file:///home/c/XMLSchema.xsd, line 177, > column 47. > type 'http://www.w3.org/2001/XMLSchema:derivationControl' not found" > There are also several warnings: > Warning at file file:///home/c/XMLSchema.xsd, line 99, char 7 > Message: attribute 'id' has already been declared for element > 'xs:simpleType' > Warning at file file:///home/c/XMLSchema.xsd, line 122, char 7 > Message: attribute 'id' has already been declared for element 'xs:list' > Warning at file file:///home/c/XMLSchema.xsd, line 130, char 7 > Message: attribute 'id' has already been declared for element 'xs:union' > Warning at file file:///home/c/XMLSchema.xsd, line 140, char 20 > Message: attribute 'id' has already been declared for element > 'xs:maxExclusive' > Warning at file file:///home/c/XMLSchema.xsd, line 145, char 20 > Message: attribute 'id' has already been declared for element > 'xs:minExclusive' > Warning at file file:///home/c/XMLSchema.xsd, line 151, char 20 > Message: attribute 'id' has already been declared for element > 'xs:maxInclusive' > Warning at file file:///home/c/XMLSchema.xsd, line 156, char 20 > Message: attribute 'id' has already been declared for element > 'xs:minInclusive' > Warning at file file:///home/c/XMLSchema.xsd, line 162, char 20 > Message: attribute 'id' has already been declared for element > 'xs:totalDigits' > Warning at file file:///home/c/XMLSchema.xsd, line 167, char 20 > Message: attribute 'id' has already been declared for element > 'xs:fractionDigits' > Warning at file file:///home/c/XMLSchema.xsd, line 173, char 20 > Message: attribute 'id' has already been declared for element 'xs:length' > Warning at file file:///home/c/XMLSchema.xsd, line 178, char 20 > Message: attribute 'id' has already been declared for element 'xs:minLength' -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: c-dev-unsubscr...@xerces.apache.org For additional commands, e-mail: c-dev-h...@xerces.apache.org
[jira] [Closed] (XERCESC-1979) OutOfMemoryException being thrown on creation of an LS Serializer
[
https://issues.apache.org/jira/browse/XERCESC-1979?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Alberto Massari closed XERCESC-1979.
Resolution: Fixed
Fix Version/s: 3.2.0
Assignee: Alberto Massari
A fix is in SVN. Please verify
> OutOfMemoryException being thrown on creation of an LS Serializer
> -
>
> Key: XERCESC-1979
> URL: https://issues.apache.org/jira/browse/XERCESC-1979
> Project: Xerces-C++
> Issue Type: Bug
> Components: Miscellaneous
>Affects Versions: 3.1.1
> Environment: AIX 6.1 and AIX 7.1
> 32-bit binary distribution libraries of Xerces 3.1.1
> Compiler (on AIX 6.1):
> IBM XL C/C++ for AIX, V11.1 (5724-X13)
> Version: 11.01..
> Driver Version: 11.01(C/C++) Level: 100304
> C Front End Version: 11.00(C/C++) Level: 100301
> C++ Front End Version: 11.01(C/C++) Level: 100304
> High-Level Optimizer Version: 11.01(C/C++) and 13.01(Fortran) Level: 100301
> Low-Level Optimizer Version: 11.01(C/C++) and 13.01(Fortran) Level: 100304
>Reporter: Matt Dissinger
>Assignee: Alberto Massari
> Fix For: 3.2.0
>
> Attachments: Xerces MemoryManagerImpl Patch.zip
>
>
> I am seeing with one of my companies' unit test binaries an
> OutOfMemoryException being thrown when attempting to create an LS serializer.
> The program code in question is:
> {code}
> xercesc::DOMImplementation* impl =
> DOMImplementationRegistry::getDOMImplementation(XMLString::transcode("LS"));
> impl->createLSSerializer();
> {code}
> We are currently only seeing this with one of our unit test binaries, and
> only on AIX. We haven't seen this yet on our production binaries or on
> Solaris, RedHat Enterprise Linux, or Windows. The root cause is an
> allocation of 0 bytes for which the ::operator new is returning a NULL
> pointer, and the MemoryManagerImpl throws an OutOfMemoryException when this
> occurs. This happens as a result of the DOMLSSerializerImpl object
> allocating a RefVectorOf with an initial size of 0, and the base class
> BaseRefVectorOf's constructor calling allocate with 0 bytes.
> Even though the C++ standard does allow for allocations of 0 bytes, it is a
> potential point of failure that can be avoided by not attempting the 0 byte
> allocation. Since the standard does define that dereferencing a pointer
> returned as a request for zero size is undefined, it should be safe to return
> NULL for 0 byte allocations (3.7.4.1 - Allocation functions, point 2, from
> the draft version here:
> http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2010/n3035.pdf).
> I've tested a change to the MemoryManagerImpl class which checks for 0 byte
> allocations and immediately returns NULL rather than attempting an ::operator
> new (0), and it has fixed the issue in our AIX environments.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
-
To unsubscribe, e-mail: c-dev-unsubscr...@xerces.apache.org
For additional commands, e-mail: c-dev-h...@xerces.apache.org
[jira] [Closed] (XERCESC-1960) Application crashing in the XMLString::transcode
[ https://issues.apache.org/jira/browse/XERCESC-1960?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alberto Massari closed XERCESC-1960. Resolution: Incomplete Your report is missing the XML that you are parsing. In any case, the crash happens inside a call to malloc(), so it's possible that you are running out of memory. > Application crashing in the XMLString::transcode > - > > Key: XERCESC-1960 > URL: https://issues.apache.org/jira/browse/XERCESC-1960 > Project: Xerces-C++ > Issue Type: Bug > Components: Miscellaneous >Affects Versions: 1.6.0 > Environment: Uname -a > SunOS MUMCTSarc01 5.10 Generic_141444-09 sun4v sparc SUNW,T5240 > Showrev output > Hostname: MUMCTSarc01 > Hostid: 84f8e614 > Release: 5.10 > Kernel architecture: sun4v > Application architecture: sparc > Hardware provider: Sun_Microsystems > Domain: > Kernel version: SunOS 5.10 Generic_141444-09 >Reporter: Mangesh Narulkar >Priority: Blocker > Labels: function, transcode > > hi > We are using xerces 1.6 in our application. Our appilication crashes > frequently in XMLString::transcode function. > Following is the stack trace of the core > ff0d7264 _smalloc (8, 0, d9200, ff0d73f4, fff9, ff1b929c) + 98 > ff0d72d0 malloc (7, 1, d914c, ff142f40, ff1b03d8, ff1ba5a0) + 4c > fe7570a8 __1c2n6FI_pv_ (7, ffbfb330, 30, 14ea8, fe76bf28, 6) + 2c > fe897aa4 __1cSIconvLCPTranscoderJtranscode6MkpkH_pc_ (c961c0, 90858, > fe9d8c0c, c961c0, fe992f7c, fe8979dc) + c8 > fed2d564 __1cKXMLHandlerMstartElement6MkpkHkp1k4rknKAttributes__v_ (613e8, > 8f5c8, 32a68, 32a40, 92ec4, 8f5c8) + 2e0c > fe8bcee0 > __1cRSAX2XMLReaderImplMstartElement6MrknOXMLElementDecl_kIkpkHrknLRefVectorOf4nHXMLAttr___4kb9C_v_ > (92eb0, c93d18, 1, 5ce50, 92a18, 2) + 25c > fe90097c __1cKXMLScannerOscanStartTagNS6Mrb_b_ (0, c93d18, fe8be500, 1, 2, > fe98fd78) + 1264 > fe8fd828 __1cKXMLScannerLscanContent6Mkb_b_ (92fb0, 1, 1, fe9d8f74, > fe9d8f9c, fe9c88b1) + 180 > fe8fb3a0 __1cKXMLScannerMscanDocument6MrknLInputSource_kb_v_ (92fb0, 92eb4, > fe9c38e4, fe8be514, 92eb4, 0) + 80 > fe8fb1c4 __1cKXMLScannerMscanDocument6MkpkHkb_v_ (92fb0, 65460, 0, c961c0, > fe992f7c, fe897bf0) + 84 > fe8fb2f0 __1cKXMLScannerMscanDocument6Mkpkckb_v_ (92fb0, fead0ea0, 0, > e03b8e3f, c1800, 1dc71f8) + 28 > fe8bc528 __1cRSAX2XMLReaderImplFparse6Mkpkc_v_ (92eb0, fead0ea0, fed38098, > fed380a5, ffbfca9c, ff142f40) + 7c > fed292f8 ParseXML (fead0ea0, 1, fea4e2db, fea4e2e9, ffbfcef4, 1) + f8 > fea300cc PMStart (1, 0, 0, fea78924, ffbfd180, ff041170) + f3c > fea1f544 ProcessFile (ff041170, ffbfd894, 3, 80808080, ff00, 80808080) + 5fc > fea200f4 XMLInlibMain (ff04, ffbfdc80, ffbffc24, ffbffc44, 49e0, 274bc) > + 7d4 > 00014698 main (ffbfdbf8, ffbffc24 > Please let us know the resolution for the issue in version 1.6 itself ,as we > cannot upgrade to higher versions of xerces. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: c-dev-unsubscr...@xerces.apache.org For additional commands, e-mail: c-dev-h...@xerces.apache.org
[jira] [Resolved] (XERCESC-1947) XMLUTF8Transcoder::transcodeTo fails with an exception when transcoding single characters that require 3 or more bytes as UTF8.
[
https://issues.apache.org/jira/browse/XERCESC-1947?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Alberto Massari resolved XERCESC-1947.
--
Resolution: Fixed
Fix Version/s: (was: 3.1.2)
Assignee: Alberto Massari
A fix is in SVN; please verify
> XMLUTF8Transcoder::transcodeTo fails with an exception when transcoding
> single characters that require 3 or more bytes as UTF8.
>
>
> Key: XERCESC-1947
> URL: https://issues.apache.org/jira/browse/XERCESC-1947
> Project: Xerces-C++
> Issue Type: Bug
> Components: Utilities
>Affects Versions: 3.1.0, 3.1.1
> Environment: Tested on mac os and debian linux. The failure is only
> manifest on v3.1.x
>Reporter: Ben Griffin
>Assignee: Alberto Massari
>Priority: Minor
> Fix For: 3.2.0
>
> Attachments: TransService.cpp.patch, TransService.patch, transtest.cpp
>
>
> This can be demonstrated with the following 2 lines of code.
> const XMLCh uval [] = { 0x254B, 0x}; //BOX DRAWINGS HEAVY VERTICAL
> AND HORIZONTAL (needs 3 bytes for utf-8)
> char* uc = (char*)TranscodeToStr(uval,"UTF-8").adopt(); cout << uc <<
> endl << flush; XMLString::release(&uc); //faulty exception;
> The error is: "terminate called after throwing an instance of
> 'xercesc_3_1::TranscodingException'"
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
-
To unsubscribe, e-mail: c-dev-unsubscr...@xerces.apache.org
For additional commands, e-mail: c-dev-h...@xerces.apache.org
[jira] [Resolved] (XERCESC-1967) Xerces ignores (deletes, swallow, ignores) the UTF-8 BOM and also ignores the charset parameter of the HTTP content-type: header
[ https://issues.apache.org/jira/browse/XERCESC-1967?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alberto Massari resolved XERCESC-1967. -- Resolution: Fixed Fix Version/s: 3.2.0 Assignee: Alberto Massari A fix is in SVN; please verify. > Xerces ignores (deletes, swallow, ignores) the UTF-8 BOM and also ignores the > charset parameter of the HTTP content-type: header > > > Key: XERCESC-1967 > URL: https://issues.apache.org/jira/browse/XERCESC-1967 > Project: Xerces-C++ > Issue Type: Bug > Components: Non-Validating Parser >Affects Versions: 3.1.1 > Environment: Mac OS X Snow Leopard (Intel). > (http://mirrorservice.nomedia.no/apache.org//xerces/c/3/binaries/xerces-c-3.1.1-x86-macosx-gcc-4.0.tar.gz) > And also tested the XMLmind XML editor on same platorm. >Reporter: Leif Halvard Silli >Assignee: Alberto Massari > Fix For: 3.2.0 > > Original Estimate: 4h > Remaining Estimate: 4h > > [1] http://www.w3.org/mid/20110609033243875895.0f711...@xn--mlform-iua.no > [2] http://www.w3.org/mid/20110609090401531862.04ce1...@xn--mlform-iua.no > It is a XML 1.0 spec vioation. well-formed violation. > Test cases without XML declaration: http://malform.no/testing/html5/bom/ > Test cases *with* XML declartion to be added later. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: c-dev-unsubscr...@xerces.apache.org For additional commands, e-mail: c-dev-h...@xerces.apache.org
[jira] [Commented] (XERCESC-1967) Xerces ignores (deletes, swallow, ignores) the UTF-8 BOM and also ignores the charset parameter of the HTTP content-type: header
[ https://issues.apache.org/jira/browse/XERCESC-1967?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13046508#comment-13046508 ] Alberto Massari commented on XERCESC-1967: -- I don't agree on your request of reversing the priorities, but that's a discussion that shouldn't be done here. Good luck in trying to convince W3C. The XML spec says that the BOM+internal encoding have the precedence when the XML is in a *file*, because it is likely that no transcoding has been performed on top of it. For all the other scenarios (when the XML is in a byte stream) the component that does the wrapping should take care of telling the parser the new setting. This is what Xerces is doing now, and in my opinion it's correct and shouldn't be changed. What is missing in Xerces is the capability of propagating the content-type read from the HTTP stream to the parser; whether the content type is text/xml vs application/xml, this is simply affecting what is the default encoding when the content-type is not specified. And in case 8.20 there is an encoding specified, so it doesn't matter which one (text/xml or application/xml) was specified. In short, if you think that pparse (or saxcount) should refuse to parse your web page (that has an HTTP content type specifying Korean, plus an UTF-8 BOM), I agree and I will try to fix it. > Xerces ignores (deletes, swallow, ignores) the UTF-8 BOM and also ignores the > charset parameter of the HTTP content-type: header > > > Key: XERCESC-1967 > URL: https://issues.apache.org/jira/browse/XERCESC-1967 > Project: Xerces-C++ > Issue Type: Bug > Components: Non-Validating Parser >Affects Versions: 3.1.1 > Environment: Mac OS X Snow Leopard (Intel). > (http://mirrorservice.nomedia.no/apache.org//xerces/c/3/binaries/xerces-c-3.1.1-x86-macosx-gcc-4.0.tar.gz) > And also tested the XMLmind XML editor on same platorm. >Reporter: Leif Halvard Silli > Original Estimate: 4h > Remaining Estimate: 4h > > [1] http://www.w3.org/mid/20110609033243875895.0f711...@xn--mlform-iua.no > [2] http://www.w3.org/mid/20110609090401531862.04ce1...@xn--mlform-iua.no > It is a XML 1.0 spec vioation. well-formed violation. > Test cases without XML declaration: http://malform.no/testing/html5/bom/ > Test cases *with* XML declartion to be added later. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: c-dev-unsubscr...@xerces.apache.org For additional commands, e-mail: c-dev-h...@xerces.apache.org
[jira] [Commented] (XERCESC-1967) Xerces ignores (deletes, swallow, ignores) the UTF-8 BOM and also ignores the charset parameter of the HTTP content-type: header
[ https://issues.apache.org/jira/browse/XERCESC-1967?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13046487#comment-13046487 ] Alberto Massari commented on XERCESC-1967: -- No, I believe that RFC3023 is correct, but I am making a distinction between the parser and the code invoking the parser. The XML parser is responsible for providing a parse(stream) function, and only knows what is written inside the stream; so, it expects a BOM, an encoding declaration and an XML-compliant sequence of bytes. If the BOM and/or the encoding is missing, it has its own fallback machanism in place to determine the encoding to be used in parsing. It only obeys to the XML specifications. It also allows the stream to state "this is the encoding you should use, regardless of what you think", that someone from outside takes care of setting. RFC3023 regulates how an HTTP transport can specify an encoding for the HTTP communication of an XML fragment, and is correct in saying that the HTTP envelope has the precedence over the XML content. After all, it's the HTTP transport that took the original payload and decided to re-encode it (case 8.20 in the RFC), so the client should trust the HTTP content type more than the internal XML fragment. In the Xerces case, the NetAccessor is the piece of code, external to the parser, that should take care of setting in the stream the setting "this is your encoding, ignore what you find in the XML". > Xerces ignores (deletes, swallow, ignores) the UTF-8 BOM and also ignores the > charset parameter of the HTTP content-type: header > > > Key: XERCESC-1967 > URL: https://issues.apache.org/jira/browse/XERCESC-1967 > Project: Xerces-C++ > Issue Type: Bug > Components: Non-Validating Parser >Affects Versions: 3.1.1 > Environment: Mac OS X Snow Leopard (Intel). > (http://mirrorservice.nomedia.no/apache.org//xerces/c/3/binaries/xerces-c-3.1.1-x86-macosx-gcc-4.0.tar.gz) > And also tested the XMLmind XML editor on same platorm. >Reporter: Leif Halvard Silli > Original Estimate: 4h > Remaining Estimate: 4h > > [1] http://www.w3.org/mid/20110609033243875895.0f711...@xn--mlform-iua.no > [2] http://www.w3.org/mid/20110609090401531862.04ce1...@xn--mlform-iua.no > It is a XML 1.0 spec vioation. well-formed violation. > Test cases without XML declaration: http://malform.no/testing/html5/bom/ > Test cases *with* XML declartion to be added later. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: c-dev-unsubscr...@xerces.apache.org For additional commands, e-mail: c-dev-h...@xerces.apache.org
[jira] [Commented] (XERCESC-1967) Xerces ignores (deletes, swallow, ignores) the UTF-8 BOM and also ignores the charset parameter of the HTTP content-type: header
[ https://issues.apache.org/jira/browse/XERCESC-1967?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13046454#comment-13046454 ] Alberto Massari commented on XERCESC-1967: -- In my opinion, the parser should obey only to the encoding seen in the XML declaration, as it has no control on whatever envelope was used to transmit the XML. It's up to the code involved in the transmission of the XML to decide how to encode/decode the data for its communication channel; so, speaking of Xerces, the entity resolver that reads from HTTP should read the content-type and force this encoding in the parser. I'll check if this is working as expected. > Xerces ignores (deletes, swallow, ignores) the UTF-8 BOM and also ignores the > charset parameter of the HTTP content-type: header > > > Key: XERCESC-1967 > URL: https://issues.apache.org/jira/browse/XERCESC-1967 > Project: Xerces-C++ > Issue Type: Bug > Components: Non-Validating Parser >Affects Versions: 3.1.1 > Environment: Mac OS X Snow Leopard (Intel). > (http://mirrorservice.nomedia.no/apache.org//xerces/c/3/binaries/xerces-c-3.1.1-x86-macosx-gcc-4.0.tar.gz) > And also tested the XMLmind XML editor on same platorm. >Reporter: Leif Halvard Silli > Original Estimate: 4h > Remaining Estimate: 4h > > [1] http://www.w3.org/mid/20110609033243875895.0f711...@xn--mlform-iua.no > [2] http://www.w3.org/mid/20110609090401531862.04ce1...@xn--mlform-iua.no > It is a XML 1.0 spec vioation. well-formed violation. > Test cases without XML declaration: http://malform.no/testing/html5/bom/ > Test cases *with* XML declartion to be added later. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: c-dev-unsubscr...@xerces.apache.org For additional commands, e-mail: c-dev-h...@xerces.apache.org
[jira] [Commented] (XERCESC-1967) Xerces ignores (deletes, swallow, ignores) the UTF-8 BOM and also ignores the charset parameter of the HTTP content-type: header
[ https://issues.apache.org/jira/browse/XERCESC-1967?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13046411#comment-13046411 ] Alberto Massari commented on XERCESC-1967: -- In the mailing list thread you reference I see that you complain about HTML5, IE, Webkit, XML and "also Xerces". Can you narrow down your report to a sentence like "I ran SAXCount and it reported valid/invalid data instead of invalid/valid"? > Xerces ignores (deletes, swallow, ignores) the UTF-8 BOM and also ignores the > charset parameter of the HTTP content-type: header > > > Key: XERCESC-1967 > URL: https://issues.apache.org/jira/browse/XERCESC-1967 > Project: Xerces-C++ > Issue Type: Bug > Components: Non-Validating Parser >Affects Versions: 3.1.1 > Environment: Mac OS X Snow Leopard (Intel). > (http://mirrorservice.nomedia.no/apache.org//xerces/c/3/binaries/xerces-c-3.1.1-x86-macosx-gcc-4.0.tar.gz) > And also tested the XMLmind XML editor on same platorm. >Reporter: Leif Halvard Silli > Original Estimate: 4h > Remaining Estimate: 4h > > [1] http://www.w3.org/mid/20110609033243875895.0f711...@xn--mlform-iua.no > [2] http://www.w3.org/mid/20110609090401531862.04ce1...@xn--mlform-iua.no > It is a XML 1.0 spec vioation. well-formed violation. > Test cases without XML declaration: http://malform.no/testing/html5/bom/ > Test cases *with* XML declartion to be added later. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: c-dev-unsubscr...@xerces.apache.org For additional commands, e-mail: c-dev-h...@xerces.apache.org
[jira] [Resolved] (XERCESC-1966) XMLURL.cpp: isHexDigit() and xlatHexDigit() accept whole alphabet
[ https://issues.apache.org/jira/browse/XERCESC-1966?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alberto Massari resolved XERCESC-1966. -- Resolution: Fixed Fix Version/s: (was: 3.1.2) 2.9.0 Assignee: Alberto Massari Fix is in SVN. Please verify. Alberto > XMLURL.cpp: isHexDigit() and xlatHexDigit() accept whole alphabet > - > > Key: XERCESC-1966 > URL: https://issues.apache.org/jira/browse/XERCESC-1966 > Project: Xerces-C++ > Issue Type: Bug > Components: Utilities >Affects Versions: 3.1.1 >Reporter: Lee Doron >Assignee: Alberto Massari >Priority: Minor > Fix For: 2.9.0, 3.2.0 > > Original Estimate: 1h > Remaining Estimate: 1h > > These two static local functions are used by XMLURL::makeNewStream(). They > should only allow [0-9a-fA-F], but instead they accept [0-9a-zA-Z]! > Note that XMLString::isHex(), used in XMLUri.cpp, gets it right. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: c-dev-unsubscr...@xerces.apache.org For additional commands, e-mail: c-dev-h...@xerces.apache.org
[jira] [Closed] (XERCESC-1965) why importNode result in coredump on aix 5.3??
[
https://issues.apache.org/jira/browse/XERCESC-1965?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Alberto Massari closed XERCESC-1965.
Resolution: Incomplete
Please use the c-us...@xerces.apache.org for asking help troubleshooting a
problem. Bugs should be open only for confirmed problems in the Xerces library
> why importNode result in coredump on aix 5.3??
> --
>
> Key: XERCESC-1965
> URL: https://issues.apache.org/jira/browse/XERCESC-1965
> Project: Xerces-C++
> Issue Type: Bug
> Components: DOM
> Environment: AIX 5.3 32bit
> xerces c++ 3.1.1
>Reporter: lin
>
> On AIX 5.3, using xerces c++ 3.1.1, I want to use importNode to import a Node
> in doc2 to doc1, But when I run my program, it coredump with "Illegal
> instrunction(coredump)";
> My program is:
>XMLCh tempStr[100];
> XMLString::transcode("LS", tempStr, 99);
> DOMImplementation *impl =
> DOMImplementationRegistry::getDOMImplementation(tempStr);
> DOMLSParser* parser =
> ((DOMImplementationLS*)impl)->createLSParser(DOMImplementationLS::MODE_SYNCHRONOUS,
> 0);
> DOMLSParser* parser2 =
> ((DOMImplementationLS*)impl)->createLSParser(DOMImplementationLS::MODE_SYNCHRONOUS,
> 0);
> // optionally you can set some features on this builder
> if (parser->getDomConfig()->canSetParameter(XMLUni::fgDOMValidate,
> true))
> parser->getDomConfig()->setParameter(XMLUni::fgDOMValidate, true);
> if (parser->getDomConfig()->canSetParameter(XMLUni::fgDOMNamespaces,
> true))
> parser->getDomConfig()->setParameter(XMLUni::fgDOMNamespaces,
> true);
> if
> (parser->getDomConfig()->canSetParameter(XMLUni::fgDOMDatatypeNormalization,
> true))
>
> parser->getDomConfig()->setParameter(XMLUni::fgDOMDatatypeNormalization,
> true);
> if
> (parser->getDomConfig()->canSetParameter(XMLUni::fgDOMElementContentWhitespace
>, false))
>
> parser->getDomConfig()->setParameter(XMLUni::fgDOMElementContentWhitespace
> , false);
> char* xmlFile = "/home/easyeai/tmp/lll.xml";
> char* xmlFile2 = "/home/easyeai/tmp/kk.xml";
> DOMDocument *doc1 = 0;
> DOMDocument *doc2 = 0;
> try {
> doc1 = parser->parseURI(xmlFile);
> doc2 = parser2->parseURI(xmlFile2);
>
> DOMNodeList *list =
> doc1->getElementsByTagName(XMLString::transcode("MSN")) ;
> DOMNode *node = list->item(0);
> doc2->importNode( node, true);
> }
> catch (const XMLException& toCatch) {
> char* message = XMLString::transcode(toCatch.getMessage());
> cout << "Exception message is: \n"
> << message << "\n";
> XMLString::release(&message);
> return -1;
> }
> catch (const DOMException& toCatch) {
> char* message = XMLString::transcode(toCatch.msg);
> cout << "Exception message is: \n"
> << message << "\n";
> XMLString::release(&message);
> return -1;
> }
> catch (...) {
> cout << "Unexpected Exception \n" ;
> return -1;
> }
> It compiled OK, but when run to importNode , it run into coredump with
> message "Illegal instruction(coredump)"??
> WHY??
> Help me please
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
-
To unsubscribe, e-mail: c-dev-unsubscr...@xerces.apache.org
For additional commands, e-mail: c-dev-h...@xerces.apache.org
[jira] [Closed] (XERCESC-1964) This is a backport request of the issue XERCESC-1935 to xerces version 2.8
[ https://issues.apache.org/jira/browse/XERCESC-1964?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alberto Massari closed XERCESC-1964. Resolution: Invalid The fix is already in the 2.x branch > This is a backport request of the issue XERCESC-1935 to xerces version 2.8 > -- > > Key: XERCESC-1964 > URL: https://issues.apache.org/jira/browse/XERCESC-1964 > Project: Xerces-C++ > Issue Type: Sub-task > Components: Validating Parser (DTD) >Affects Versions: 2.8.0 >Reporter: Prajeesh Thirunala > Fix For: 2.8.0 > > > This is a backport request of the issue XERCESC-1935 to xerces version 2.8 -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: c-dev-unsubscr...@xerces.apache.org For additional commands, e-mail: c-dev-h...@xerces.apache.org
[jira] [Resolved] (XERCESC-1935) Xerces 2.8 sax parser crashes for nested DTD inputs.
[ https://issues.apache.org/jira/browse/XERCESC-1935?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alberto Massari resolved XERCESC-1935. -- Resolution: Fixed Fix Version/s: 3.2.0 2.9.0 A fix in SVN. Please verify. > Xerces 2.8 sax parser crashes for nested DTD inputs. > > > Key: XERCESC-1935 > URL: https://issues.apache.org/jira/browse/XERCESC-1935 > Project: Xerces-C++ > Issue Type: Bug > Components: Validating Parser (DTD) >Affects Versions: 2.8.0 > Environment: Linux 2.6.18-92.e165xen >Reporter: Sharda Khubchandani >Assignee: Alberto Massari > Fix For: 2.9.0, 3.2.0 > > Attachments: sample_project.zip > > > Xerces parser crashes with attached sample -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: c-dev-unsubscr...@xerces.apache.org For additional commands, e-mail: c-dev-h...@xerces.apache.org
[jira] [Assigned] (XERCESC-1935) Xerces 2.8 sax parser crashes for nested DTD inputs.
[ https://issues.apache.org/jira/browse/XERCESC-1935?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alberto Massari reassigned XERCESC-1935: Assignee: Alberto Massari > Xerces 2.8 sax parser crashes for nested DTD inputs. > > > Key: XERCESC-1935 > URL: https://issues.apache.org/jira/browse/XERCESC-1935 > Project: Xerces-C++ > Issue Type: Bug > Components: Validating Parser (DTD) >Affects Versions: 2.8.0 > Environment: Linux 2.6.18-92.e165xen >Reporter: Sharda Khubchandani >Assignee: Alberto Massari > Attachments: sample_project.zip > > > Xerces parser crashes with attached sample -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: c-dev-unsubscr...@xerces.apache.org For additional commands, e-mail: c-dev-h...@xerces.apache.org
[jira] Resolved: (XERCESC-1958) XMLUni::fgXercesLoadSchema[] is not null-terminated in XMLUni.cpp
[ https://issues.apache.org/jira/browse/XERCESC-1958?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alberto Massari resolved XERCESC-1958. -- Resolution: Fixed Fix Version/s: (was: 3.0.0) 3.2.0 Assignee: Alberto Massari Fixed. Thanks for spotting this. Alberto > XMLUni::fgXercesLoadSchema[] is not null-terminated in XMLUni.cpp > - > > Key: XERCESC-1958 > URL: https://issues.apache.org/jira/browse/XERCESC-1958 > Project: Xerces-C++ > Issue Type: Bug > Components: Validating Parser (XML Schema) >Affects Versions: 3.0.0 > Environment: Solaris >Reporter: Niall Tierney >Assignee: Alberto Massari >Priority: Minor > Fix For: 3.2.0 > > Attachments: xmluni.cpp.patch > > Original Estimate: 1m > Remaining Estimate: 1m > > The XMLUni::fgXercesLoadSchema XMLCh[] in /util/XMLUni.cpp is not > null-terminated. > This causes an "Unknown Feature" exception to be thrown by the parser. > The array should be terminated with the chNull character to avoid this > exception. > Note that i've tested on 3.0.0, but i can see in the SVN repository that this > bug still exists in the head of the tree. -- This message is automatically generated by JIRA. - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: c-dev-unsubscr...@xerces.apache.org For additional commands, e-mail: c-dev-h...@xerces.apache.org
[jira] Commented: (XERCESC-1955) Xerces is poping up exception while parsing a Unicode file, but same is working fine for an ANSI file
[
https://issues.apache.org/jira/browse/XERCESC-1955?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12984801#action_12984801
]
Alberto Massari commented on XERCESC-1955:
--
Jojo, running "DOMCount R21.xml" prints
r21.xml: 735 ms (7580 elems).
So your file can be parsed by Xerces; please look at what the DOMCount sample
does that your code doesn't.
> Xerces is poping up exception while parsing a Unicode file, but same is
> working fine for an ANSI file
> -
>
> Key: XERCESC-1955
> URL: https://issues.apache.org/jira/browse/XERCESC-1955
> Project: Xerces-C++
> Issue Type: Bug
> Components: DOM
>Affects Versions: 3.1.0
> Environment: Windows XP 32Bit
> Windows7 64bit
>Reporter: Jojo Jose
>Priority: Blocker
> Fix For: 3.1.0
>
> Attachments: R21.zip
>
> Original Estimate: 20h
> Remaining Estimate: 20h
>
> Hi All,
> Please let me know, if anybody can provide some clue on this.
> I have been using Xerces as XML parser in my C++ application and I have
> recently migrated my Xerces version from 1.3 (very old) to 3.1.
> After that, when I call AbstractDOMParser::parse(const
> xercesc_3_1::InputSource & source={...}) and passing a Unicode file as input,
> it pops up exception. However the same works ok for ANSI.
> The call stack is as shown below.
> xerces-c_3_1.dll!xercesc_3_1::XMLScanner::scanProlog() Line 1227 + 0x25 bytes
> xerces-c_3_1.dll!xercesc_3_1::IGXMLScanner::scanDocument(const
> xercesc_3_1::InputSource & src={...}) Line 210
> xerces-c_3_1.dll!xercesc_3_1::AbstractDOMParser::parse(const
> xercesc_3_1::InputSource & source={...}) Line 549
> EPConfigTool.dll!XCfgXMLParser::parse() Line 66 - My application code
> In the code, it is reaching at
> else
> {
> emitError(XMLErrs::InvalidDocumentStructure);
> ...
> }
> The function at parse fail is as shown below:
> void XMLScanner::scanProlog()
> {
> bool sawDocTypeDecl = false;
> // Get a buffer for whitespace processing
> XMLBufBid bbCData(&fBufMgr);
> // Loop through the prolog. If there is no content, this could go all
> // the way to the end of the file.
> try
> {
> while (true)
> {
> const XMLCh nextCh = fReaderMgr.peekNextChar();
> if (nextCh == chOpenAngle)
> {
> // Ok, it could be the xml decl, a comment, the doc type
> line,
> // or the start of the root element.
> if (checkXMLDecl(true))
> {
> // There shall be at lease --ONE-- space in between
> // the tag ' //
> // If we are not at line 1, col 6, then the decl was not
> // the first text, so its invalid.
> const XMLReader* curReader =
> fReaderMgr.getCurrentReader();
> if ((curReader->getLineNumber() != 1)
> || (curReader->getColumnNumber() != 7))
> {
> emitError(XMLErrs::XMLDeclMustBeFirst);
> }
> scanXMLDecl(Decl_XML);
> }
> else if (fReaderMgr.skippedString(XMLUni::fgPIString))
> {
> scanPI();
> }
> else if (fReaderMgr.skippedString(XMLUni::fgCommentString))
> {
> scanComment();
> }
> else if (fReaderMgr.skippedString(XMLUni::fgDocTypeString))
> {
> if (sawDocTypeDecl) {
> emitError(XMLErrs::DuplicateDocTypeDecl);
> }
> scanDocTypeDecl();
> sawDocTypeDecl = true;
> // if reusing grammar, this has been validated already in
> first scan
> // skip for performance
> if (fValidate && fGrammar && !fGrammar->getValidated()) {
> // validate the DTD scan so far
> fValidator->preContentValidation(fUseCachedGrammar,
> true);
> }
> }
> else
> {
> // Assume its the start of the root element
> return;
> }
> }
> else if (fReaderMgr.getCurrentReader()->isWhitespace(nextCh))
> {
> // If we have a document handler then gather up the
> // whitespace and call back. Otherwise just skip over spaces.
> if (fDocHandler)
> {
> fReaderMgr.getSpaces(bbCData.getBuffer());
>
[jira] Closed: (XERCESC-1955) Xerces is poping up exception while parsing a Unicode file, but same is working fine for an ANSI file
[
https://issues.apache.org/jira/browse/XERCESC-1955?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Alberto Massari closed XERCESC-1955.
Resolution: Cannot Reproduce
As you say, the exception occurs with an XML file only, and you didn't provide
it. Before opening a bug in JIRA, can you check it's a bug in Xerces, and not
in your XML or code?
> Xerces is poping up exception while parsing a Unicode file, but same is
> working fine for an ANSI file
> -
>
> Key: XERCESC-1955
> URL: https://issues.apache.org/jira/browse/XERCESC-1955
> Project: Xerces-C++
> Issue Type: Bug
> Components: DOM
>Affects Versions: 3.1.0
> Environment: Windows XP 32Bit
> Windows7 64bit
>Reporter: Jojo Jose
>Priority: Blocker
> Fix For: 3.1.0
>
> Original Estimate: 20h
> Remaining Estimate: 20h
>
> Hi All,
> Please let me know, if anybody can provide some clue on this.
> I have been using Xerces as XML parser in my C++ application and I have
> recently migrated my Xerces version from 1.3 (very old) to 3.1.
> After that, when I call AbstractDOMParser::parse(const
> xercesc_3_1::InputSource & source={...}) and passing a Unicode file as input,
> it pops up exception. However the same works ok for ANSI.
> The call stack is as shown below.
> xerces-c_3_1.dll!xercesc_3_1::XMLScanner::scanProlog() Line 1227 + 0x25 bytes
> xerces-c_3_1.dll!xercesc_3_1::IGXMLScanner::scanDocument(const
> xercesc_3_1::InputSource & src={...}) Line 210
> xerces-c_3_1.dll!xercesc_3_1::AbstractDOMParser::parse(const
> xercesc_3_1::InputSource & source={...}) Line 549
> EPConfigTool.dll!XCfgXMLParser::parse() Line 66 - My application code
> In the code, it is reaching at
> else
> {
> emitError(XMLErrs::InvalidDocumentStructure);
> ...
> }
> The function at parse fail is as shown below:
> void XMLScanner::scanProlog()
> {
> bool sawDocTypeDecl = false;
> // Get a buffer for whitespace processing
> XMLBufBid bbCData(&fBufMgr);
> // Loop through the prolog. If there is no content, this could go all
> // the way to the end of the file.
> try
> {
> while (true)
> {
> const XMLCh nextCh = fReaderMgr.peekNextChar();
> if (nextCh == chOpenAngle)
> {
> // Ok, it could be the xml decl, a comment, the doc type
> line,
> // or the start of the root element.
> if (checkXMLDecl(true))
> {
> // There shall be at lease --ONE-- space in between
> // the tag ' //
> // If we are not at line 1, col 6, then the decl was not
> // the first text, so its invalid.
> const XMLReader* curReader =
> fReaderMgr.getCurrentReader();
> if ((curReader->getLineNumber() != 1)
> || (curReader->getColumnNumber() != 7))
> {
> emitError(XMLErrs::XMLDeclMustBeFirst);
> }
> scanXMLDecl(Decl_XML);
> }
> else if (fReaderMgr.skippedString(XMLUni::fgPIString))
> {
> scanPI();
> }
> else if (fReaderMgr.skippedString(XMLUni::fgCommentString))
> {
> scanComment();
> }
> else if (fReaderMgr.skippedString(XMLUni::fgDocTypeString))
> {
> if (sawDocTypeDecl) {
> emitError(XMLErrs::DuplicateDocTypeDecl);
> }
> scanDocTypeDecl();
> sawDocTypeDecl = true;
> // if reusing grammar, this has been validated already in
> first scan
> // skip for performance
> if (fValidate && fGrammar && !fGrammar->getValidated()) {
> // validate the DTD scan so far
> fValidator->preContentValidation(fUseCachedGrammar,
> true);
> }
> }
> else
> {
> // Assume its the start of the root element
> return;
> }
> }
> else if (fReaderMgr.getCurrentReader()->isWhitespace(nextCh))
> {
> // If we have a document handler then gather up the
> // whitespace and call back. Otherwise just skip over spaces.
> if (fDocHandler)
> {
> fReaderMgr.getSpaces(bbCData.getBuffer());
> fDocHandler->ignorableWhitespace
>
