[jira] [Commented] (XERCESC-2188) Use-after-free on external DTD scan
[ https://issues.apache.org/jira/browse/XERCESC-2188?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17793670#comment-17793670 ] Boris Kolpackov commented on XERCESC-2188: -- A new PR with the fix: [https://github.com/apache/xerces-c/pull/54] Please review/test. > Use-after-free on external DTD scan > --- > > Key: XERCESC-2188 > URL: https://issues.apache.org/jira/browse/XERCESC-2188 > Project: Xerces-C++ > Issue Type: Bug > Components: Validating Parser (DTD) >Affects Versions: 3.0.0, 3.0.1, 3.0.2, 3.1.0, 3.1.1, 3.1.2, 3.2.0, 3.1.3, > 3.1.4, 3.2.1, 3.2.2 >Reporter: Scott Cantor >Priority: Major > Attachments: Apache-496067-disclosure-report.pdf > > > This is a record of an unfixed bug reported in 2018 in the DTD scanner, per > the attached PDF, corresponding to CVE-2018-1311. -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: c-dev-unsubscr...@xerces.apache.org For additional commands, e-mail: c-dev-h...@xerces.apache.org
[jira] [Commented] (XERCESC-2204) Remove message loader
[ https://issues.apache.org/jira/browse/XERCESC-2204?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17136595#comment-17136595 ] Boris Kolpackov commented on XERCESC-2204: -- I think it's pretty clear iconv is redundant but it would be bad to loose the ability to build an external dependency-free version of Xerces-C++. Perhaps we should have a thread on c-dev to discussing and agree on the plan for 4.0.0 where we can also consider removing other redundant components, switching to a later C++11 standard, etc? Roger, if you could maybe send the list all the major changes you have in mind, this will get the ball rolling? > Remove message loader > - > > Key: XERCESC-2204 > URL: https://issues.apache.org/jira/browse/XERCESC-2204 > Project: Xerces-C++ > Issue Type: Bug > Components: Miscellaneous >Affects Versions: 3.3.0 >Reporter: Roger Leigh >Assignee: Roger Leigh >Priority: Major > Fix For: 3.3.0 > > > We support several different message loaders (inmemory, icu, iconv). > However... we don't have any translations to actually warrant all this > complexity, and likely never will. We have the basic en_US and that's it. > So this code is essentially unused, and I don't see much prospect of it being > used in the future given that there have been zero translations written in > the last two decades. > In order to reduce the size of the test matrix and reduce the maintenance > burden, I'd like to ask if this is something we could safely drop? > See also XALANC-808 which is the same issue for Xalan-C. -- 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-2204) Remove message loader
[ https://issues.apache.org/jira/browse/XERCESC-2204?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17133959#comment-17133959 ] Boris Kolpackov commented on XERCESC-2204: -- I am not sure about this. While we do not provide translations ourselves, I believe at least with ICU they can be loaded dynamically. In other words, there could be applications out there relying on that functionality (or, admittedly less realistically, there could be application that will want this functionality in the future – internationalization is often an afterthought). Secondly, I believe such a change would require a new major release (since it won't be source-compatible) and probably a vote. More generally, I've seen a few other bug reports from you (e.g., requiring std::mutex) that I believe would require 4.0.0. So I am wondering what's the overall goal here? Are you signing up to modernize Xerces-C++ ;)? > Remove message loader > - > > Key: XERCESC-2204 > URL: https://issues.apache.org/jira/browse/XERCESC-2204 > Project: Xerces-C++ > Issue Type: Bug > Components: Miscellaneous >Affects Versions: 3.3.0 >Reporter: Roger Leigh >Assignee: Roger Leigh >Priority: Major > Fix For: 3.3.0 > > > We support several different message loaders (inmemory, icu, iconv). > However... we don't have any translations to actually warrant all this > complexity, and likely never will. We have the basic en_US and that's it. > So this code is essentially unused, and I don't see much prospect of it being > used in the future given that there have been zero translations written in > the last two decades. > In order to reduce the size of the test matrix and reduce the maintenance > burden, I'd like to ask if this is something we could safely drop? > See also XALANC-808 which is the same issue for Xalan-C. -- 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-1971) Cannot build on Mac OS X 10.7
[ https://issues.apache.org/jira/browse/XERCESC-1971?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13084825#comment-13084825 ] Boris Kolpackov commented on XERCESC-1971: -- Nathaniel, Xerces-C++ 2.8.0 is no longer maintained/supported. There will be no new releases in 2-series. Have you tried to build Xerces-C++ 3.1.1? Cannot build on Mac OS X 10.7 - Key: XERCESC-1971 URL: https://issues.apache.org/jira/browse/XERCESC-1971 Project: Xerces-C++ Issue Type: Bug Components: Build Affects Versions: 2.8.0 Environment: Mac OSX 10.7 (Lion). Must be built in 64-bit mode to be binary-compatible with standard Lion builds. Reporter: Nathaniel Tagg This has been seen before, for example: http://web.archiveorange.com/archive/v/3yUylsC2yFLq8CqyP0Ml The code will not build, failing in several places. I do not require Mac OSX specific tools; I'd be very happy with just POSIX-compliant libraries, if such a build option were possible. Although one can download a 32-bit binary, it will not compile against standard 64-bit binaries in other code. I'm compiling a large number of other libraries against XercesC, and cannot modify the build systems to build on 32-bit mode. -- 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-1959) serializeGrammars does not work between 32 and 64 bit systems
[ https://issues.apache.org/jira/browse/XERCESC-1959?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13002969#comment-13002969 ] Boris Kolpackov commented on XERCESC-1959: -- Daniel, I agree the current implementation is not ideal so if you would like to come up with a patch, then that would be very welcome. David, regarding backwards compatibility, there is a format version number stored with the binary representation. Now, the problem is that the version itself is stored in a non-portable manner. Luckily it is always 32-bit (unsigned int) so we can write 0x there for the new format which will make sure that any previous version (regardless of the endianness) will not compare equal. serializeGrammars does not work between 32 and 64 bit systems - Key: XERCESC-1959 URL: https://issues.apache.org/jira/browse/XERCESC-1959 Project: Xerces-C++ Issue Type: Bug Components: Validating Parser (XML Schema) Affects Versions: 3.1.1 Environment: Win Vista 32 bit + VS 2010 express, Xerces-C 3.1.1 binary Ubuntu 10.10 64 bit, Xerces-C 3.1 installed Reporter: Daniel Turcanu Serialization of schema grammar does not work between Windows 32 and Linux 64 bit. Serializing on one machine (with serializeGrammars) and deserializing on the other (with deserializeGrammars) fails ungracefully. Serializing and deserializing on the same machine works fine. -- 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] Updated: (XERCESC-1951) Missing Libs.private in the xerces-c pkg-config file
[ https://issues.apache.org/jira/browse/XERCESC-1951?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Boris Kolpackov updated XERCESC-1951: - Fix Version/s: (was: 3.1.1) Thanks for the patch. Missing Libs.private in the xerces-c pkg-config file Key: XERCESC-1951 URL: https://issues.apache.org/jira/browse/XERCESC-1951 Project: Xerces-C++ Issue Type: Bug Components: Build Affects Versions: 3.1.1, 3.1.2, 3.2.0, 4.0.0 Environment: MinGW cross compiling Reporter: Volker Grabsch Fix For: 3.1.2, 3.2.0, 4.0.0 Attachments: xerces-fix-pkgconfig.patch When compiling Xerces statically with libCURL support, the command pkg-config xerces-c --static --libs does not output the CURL lib and its dependencies. This finally leads to linker errors. The attached patch fixed this issue. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: c-dev-unsubscr...@xerces.apache.org For additional commands, e-mail: c-dev-h...@xerces.apache.org
[jira] Created: (XERCESC-1950) Build-in UCS4 transcoder does not respect endianess
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 Fix For: 3.1.2, 3.2.0 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. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: c-dev-unsubscr...@xerces.apache.org For additional commands, e-mail: c-dev-h...@xerces.apache.org
[jira] Updated: (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 ] Boris Kolpackov updated XERCESC-1950: - Attachment: test.xml 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 Fix For: 3.1.2, 3.2.0 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. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: c-dev-unsubscr...@xerces.apache.org For additional commands, e-mail: c-dev-h...@xerces.apache.org
[jira] Updated: (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
]
Boris Kolpackov updated XERCESC-1947:
-
Fix Version/s: 3.2.0
3.1.2
Ben, the reason I am interested in whether this affects parsing/serialization
is because if it does then we have a critical issue and a bug-fix release is
probably needed. If it only affects TranscodeToStr, which is only used in a few
net accessors, then this is not critical (it is highly unlikely a URI will
contain a three-byte UTF-8 sequence) and can wait until the normal release
cycle. I think we both agree this only affects TranscodeToStr. Scheduling this
bug for 3.1.2/3.2.0.
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
Priority: Critical
Fix For: 3.1.2, 3.2.0
Attachments: 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.
-
You can reply to this email to add a comment to the issue online.
-
To unsubscribe, e-mail: c-dev-unsubscr...@xerces.apache.org
For additional commands, e-mail: c-dev-h...@xerces.apache.org
[jira] Commented: (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:comment-tabpanelfocusedCommentId=12920195#action_12920195
]
Boris Kolpackov commented on XERCESC-1947:
--
Ben, is this only a problem in TranscodeToStr or can you also get this by
parsing/serializing XML? It is my understanding that this only affects
TranscodeToStr.
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
Priority: Critical
Attachments: 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.
-
You can reply to this email to add a comment to the issue online.
-
To unsubscribe, e-mail: c-dev-unsubscr...@xerces.apache.org
For additional commands, e-mail: c-dev-h...@xerces.apache.org
[jira] Updated: (XERCESC-1936) ICUTransService and IconvGNUransService CAN NOT deal with huge file.
[ https://issues.apache.org/jira/browse/XERCESC-1936?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Boris Kolpackov updated XERCESC-1936: - Fix Version/s: 3.1.2 3.2.0 4.0.0 Yes, I just tried your test with ICU and I get the error. Scheduling this bug for the next release. ICUTransService and IconvGNUransService CAN NOT deal with huge file. Key: XERCESC-1936 URL: https://issues.apache.org/jira/browse/XERCESC-1936 Project: Xerces-C++ Issue Type: Bug Components: Utilities Affects Versions: 2.8.0, 3.1.1 Environment: RHEL-5.5 glibc-2.5-49.el5_5.2 libicu-3.6-5.11.4 Reporter: kirby zhou Fix For: 3.1.2, 3.2.0, 4.0.0 If a huge file passed to XMLReader, it will call TransService mulitple times, and splite the file content into several fragments. Unfortunately, the fragment will contain incomplete multi-byte characters. But neither ICUTransService nor IconvGNUransService deal with it. ICUTransService did not deal with U_TRUNCATED_CHAR_FOUND, and IconvGNUransService did not deal with EINVAL. Both 2.8.0 and 3.1.1 have the same bug. For example, make 2 XML like that: ]# ( echo '?xml version=1.0 encoding=GBK ?'; echo 'data'; for ((i=0;i2;++i)); do echo -n '中文汉字A'; done ; echo; echo '/data' ) ~/small.xml ]# ( echo '?xml version=1.0 encoding=GBK ?'; echo 'data'; for ((i=0;i10;++i)); do echo -n '中文汉字A'; done ; echo; echo '/data' ) ~/big.xml # the small.xml and big.xml are analogical. ]# samples/SAXPrint -x=gbk ~/small.xml ?xml version=1.0 encoding=gbk? data 中文汉字A中文汉字A /data # with icu ]# samples/SAXPrint -x=gbk ~/big.xml ?xml version=1.0 encoding=gbk? data Fatal Error at file /root/big.xml, line 3, char 16377 Message: char 0x6C49 is not representable in 'gbk' encoding # with iconvgnu ]# samples/SAXPrint -x=gbk ~/big.xml ]# samples/SAXPrint -x=gbk ~/big.xml ?xml version=1.0 encoding=gbk? data Fatal Error at file /root/big.xml, line 3, char 16377 Message: invalid multi-byte sequence -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: c-dev-unsubscr...@xerces.apache.org For additional commands, e-mail: c-dev-h...@xerces.apache.org
[jira] Commented: (XERCESC-1451) Valgrind reports mismatched new/delete[] usage
[ https://issues.apache.org/jira/browse/XERCESC-1451?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12901970#action_12901970 ] Boris Kolpackov commented on XERCESC-1451: -- Daniel, Have you tried the latest release (3.1.1)? 2.8.0 is no longer supported so even if there is a bug, it won't be fixed in 2.x.y release series. Valgrind reports mismatched new/delete[] usage -- Key: XERCESC-1451 URL: https://issues.apache.org/jira/browse/XERCESC-1451 Project: Xerces-C++ Issue Type: Bug Affects Versions: 2.5.0, 2.6.0 Environment: Red Hat 9 (Shrike 2.4.20-6smp), Dell Precision 530 Valgrind 2.4.0 g++ 3.2.2 Reporter: Glenn Miyake Valgrind reports a mismatch new/delete[] MemoryManagerImpl::allocate(unsigned) appears to allocate using just new(size). This memory is then incorrectly freed using array delete (delete []) in XMLString::release. Simply changing the release method to call delete does not work since it appears that release is also used to free memory allocated with new []. Partial valgrind output follows: ==21267== Mismatched free() / delete / delete [] ==21267==at 0x1B903D5D: operator delete[](void*) (vg_replace_malloc.c:161) ==21267==by 0x1BB0A9EC: xercesc_2_6::XMLString::release(unsigned short**) (in /home/gmiyake/dev/xerces-c-src_2_6_0/lib/libxerces-c.so.26.0) ==21267==by 0x836BC59: altova::CDoc::convertXmlDocToString(altova::CNode) (Doc.cpp:451) ==21267==by 0x836E059: altova::CNode::convertXmlDocToString() (Node.cpp:469) ==21267== Address 0x1BE20C18 is 0 bytes inside a block of size 3912 alloc'd ==21267==at 0x1B9036A6: operator new(unsigned) (vg_replace_malloc.c:132) ==21267==by 0x1BA7C51B: xercesc_2_6::MemoryManagerImpl::allocate(unsigned) (in /home/gmiyake/dev/xerces-c-src_2_6_0/lib/libxerces-c.so.26.0) ==21267==by 0x1BA49F0A: xercesc_2_6::DOMWriterImpl::writeToString(xercesc_2_6::DOMNode const) (in /home/gmiyake/dev/xerces-c-src_2_6_0/lib/libxerces-c.so.26.0) ==21267==by 0x836BC23: altova::CDoc::convertXmlDocToString(altova::CNode) (Doc.cpp:440) ==21267==by 0x836E059: altova::CNode::convertXmlDocToString() (Node.cpp:469) -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: c-dev-unsubscr...@xerces.apache.org For additional commands, e-mail: c-dev-h...@xerces.apache.org
[jira] Updated: (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
]
Boris Kolpackov updated XERCESC-1940:
-
Fix Version/s: 3.1.2
3.2.0
Thanks for the report, Anil. I am scheduling this for 3.1.2 and 3.2.0. Though
the patch doesn't look portable (dynamic allocation of an array).
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 = types:statusSet xmlns:types:statusSet=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.
-
You can reply to this email to add a comment to the issue online.
-
To unsubscribe, e-mail: c-dev-unsubscr...@xerces.apache.org
For additional commands, e-mail: c-dev-h...@xerces.apache.org
[jira] Updated: (XERCESC-1936) ICUTransService and IconvGNUransService CAN NOT deal with huge file.
[ https://issues.apache.org/jira/browse/XERCESC-1936?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Boris Kolpackov updated XERCESC-1936: - Hi, Can you attach the sample files to the bug report? The content that you have pasted in the description is all garbled. Also, would you be able to come up with a patch for this issue? ICUTransService and IconvGNUransService CAN NOT deal with huge file. Key: XERCESC-1936 URL: https://issues.apache.org/jira/browse/XERCESC-1936 Project: Xerces-C++ Issue Type: Bug Components: Utilities Affects Versions: 2.8.0, 3.1.1 Environment: RHEL-5.5 glibc-2.5-49.el5_5.2 libicu-3.6-5.11.4 Reporter: kirby zhou If a huge file passed to XMLReader, it will call TransService mulitple times, and splite the file content into several fragments. Unfortunately, the fragment will contain incomplete multi-byte characters. But neither ICUTransService nor IconvGNUransService deal with it. ICUTransService did not deal with U_TRUNCATED_CHAR_FOUND, and IconvGNUransService did not deal with EINVAL. Both 2.8.0 and 3.1.1 have the same bug. For example, make 2 XML like that: ]# ( echo '?xml version=1.0 encoding=GBK ?'; echo 'data'; for ((i=0;i2;++i)); do echo -n '中文汉字A'; done ; echo; echo '/data' ) ~/small.xml ]# ( echo '?xml version=1.0 encoding=GBK ?'; echo 'data'; for ((i=0;i10;++i)); do echo -n '中文汉字A'; done ; echo; echo '/data' ) ~/big.xml # the small.xml and big.xml are analogical. ]# samples/SAXPrint -x=gbk ~/small.xml ?xml version=1.0 encoding=gbk? data 中文汉字A中文汉字A /data # with icu ]# samples/SAXPrint -x=gbk ~/big.xml ?xml version=1.0 encoding=gbk? data Fatal Error at file /root/big.xml, line 3, char 16377 Message: char 0x6C49 is not representable in 'gbk' encoding # with iconvgnu ]# samples/SAXPrint -x=gbk ~/big.xml ]# samples/SAXPrint -x=gbk ~/big.xml ?xml version=1.0 encoding=gbk? data Fatal Error at file /root/big.xml, line 3, char 16377 Message: invalid multi-byte sequence -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: c-dev-unsubscr...@xerces.apache.org For additional commands, e-mail: c-dev-h...@xerces.apache.org
[jira] Created: (XERCESC-1931) Add support for Windows-style UNC URIs
Add support for Windows-style UNC URIs -- Key: XERCESC-1931 URL: https://issues.apache.org/jira/browse/XERCESC-1931 Project: Xerces-C++ Issue Type: Improvement Components: Utilities Affects Versions: 3.1.1 Reporter: Boris Kolpackov Fix For: 3.1.2, 3.2.0 There are three ways to represent Windows network share paths in URI that are in use today: file://host/path file:host/path file:/host/path Xerces-C++ only supports the later two. The first encoding is the Microsoft recommended[1] and Windows API functions construct URI this way. We should probably add support for the first format as well. [1] http://blogs.msdn.com/b/ie/archive/2006/12/06/file-uris-in-windows.aspx -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: c-dev-unsubscr...@xerces.apache.org For additional commands, e-mail: c-dev-h...@xerces.apache.org
[jira] Closed: (XERCESC-1930) CRLF is replaced by space
[ https://issues.apache.org/jira/browse/XERCESC-1930?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Boris Kolpackov closed XERCESC-1930. Resolution: Invalid CRLF is replaced by space -- Key: XERCESC-1930 URL: https://issues.apache.org/jira/browse/XERCESC-1930 Project: Xerces-C++ Issue Type: Bug Affects Versions: 2.2.0 Reporter: Harpreet Hi, Our code creates a xml where description tag contains text in the format abcdCRLFefgh where CR stands for carriage return and LF stands for line feed. Now when we pass the xml to xerces, the CRLF combo is converted to space which is unexpected. Is this issue already reported? I searched over the net and in JIRA as well but could not find any such reported issues. Is there any workaround available for this. Thanks Harpreet -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: c-dev-unsubscr...@xerces.apache.org For additional commands, e-mail: c-dev-h...@xerces.apache.org
[jira] Updated: (XERCESC-1925) Wrong temporary token type causes regex construction to fail
[ https://issues.apache.org/jira/browse/XERCESC-1925?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Boris Kolpackov updated XERCESC-1925: - Fix Version/s: 3.1.2 3.2.0 Scheduling for 3.1.2, 3.2.0. Wrong temporary token type causes regex construction to fail Key: XERCESC-1925 URL: https://issues.apache.org/jira/browse/XERCESC-1925 Project: Xerces-C++ Issue Type: Bug Components: Utilities Reporter: John Keeping Fix For: 3.1.2, 3.2.0 Attachments: xerces-range-token-merge.patch When checking for token overlap in a regular expression a temporary range token is constructed and merged with another range token. This temporary token has type Token::T_RANGE so the merge fails if the actual token is of type Token::T_NRANGE. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: c-dev-unsubscr...@xerces.apache.org For additional commands, e-mail: c-dev-h...@xerces.apache.org
[jira] Updated: (XERCESC-1926) IGXMLScanner can fail to properly set its XSModel.
[ https://issues.apache.org/jira/browse/XERCESC-1926?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Boris Kolpackov updated XERCESC-1926: - Fix Version/s: 3.1.2 3.2.0 Scheduling for 3.1.2, 3.2.0. IGXMLScanner can fail to properly set its XSModel. -- Key: XERCESC-1926 URL: https://issues.apache.org/jira/browse/XERCESC-1926 Project: Xerces-C++ Issue Type: Bug Components: Validating Parser (XML Schema) Reporter: John Keeping Fix For: 3.1.2, 3.2.0 Attachments: xerces-model-update.patch If an IGXMLScanner is used for a document with no schema and then reset to scan a document with a schema the model is not set correctly. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: c-dev-unsubscr...@xerces.apache.org For additional commands, e-mail: c-dev-h...@xerces.apache.org
[jira] Closed: (XERCESC-1922) MacOSUnicodeConverter.cpp: ISO C++ forbids comparison between pointer of type 'void *' and pointer-to-function
[
https://issues.apache.org/jira/browse/XERCESC-1922?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Boris Kolpackov closed XERCESC-1922.
Fix Version/s: 3.1.2
3.2.0
(was: 3.1.0)
Resolution: Fixed
Fix is in SVN, thanks.
MacOSUnicodeConverter.cpp: ISO C++ forbids comparison between pointer of type
'void *' and pointer-to-function
--
Key: XERCESC-1922
URL: https://issues.apache.org/jira/browse/XERCESC-1922
Project: Xerces-C++
Issue Type: Improvement
Components: Build
Environment: Mac OS X 10.6.3, g++ 4.2.1, xerces 3.1
Reporter: isidoro ghezzi
Priority: Minor
Fix For: 3.1.2, 3.2.0
Original Estimate: 1h
Remaining Estimate: 1h
Compiling with $ g++ --version
i686-apple-darwin10-g++-4.2.1 (GCC) 4.2.1 (Apple Inc. build 5646) (dot 1)
having -Wall -Wextra -Wconversion -ansi -pedantic flags the result is:
xercesc/util/Transcoders/MacOSUnicodeConverter/MacOSUnicodeConverter.cpp: In
static member function 'static bool
xercesc_3_1::MacOSUnicodeConverter::IsMacOSUnicodeConverterSupported()':
xercesc/util/Transcoders/MacOSUnicodeConverter/MacOSUnicodeConverter.cpp:461:
error: ISO C++ forbids comparison between pointer of type 'void *' and
pointer-to-function
xercesc/util/Transcoders/MacOSUnicodeConverter/MacOSUnicodeConverter.cpp:462:
error: ISO C++ forbids comparison between pointer of type 'void *' and
pointer-to-function
to avoid that, i suggest to change:
[code]
bool
MacOSUnicodeConverter::IsMacOSUnicodeConverterSupported(void)
{
return UpgradeScriptInfoToTextEncoding != (void*)NULL
CreateTextToUnicodeInfoByEncoding != (void*)NULL
;
}
[/code]
to:
[code]
bool
MacOSUnicodeConverter::IsMacOSUnicodeConverterSupported(void)
{
return (0L != UpgradeScriptInfoToTextEncoding)
(0L != CreateTextToUnicodeInfoByEncoding)
;
}
[/code]
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
-
To unsubscribe, e-mail: c-dev-unsubscr...@xerces.apache.org
For additional commands, e-mail: c-dev-h...@xerces.apache.org
[jira] Closed: (XERCESC-1923) removing extras semicolon
[ https://issues.apache.org/jira/browse/XERCESC-1923?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Boris Kolpackov closed XERCESC-1923. Fix Version/s: 3.1.2 3.2.0 Resolution: Fixed The fix is in SVN, thanks! removing extras semicolon - Key: XERCESC-1923 URL: https://issues.apache.org/jira/browse/XERCESC-1923 Project: Xerces-C++ Issue Type: Test Components: Samples/Tests Affects Versions: 3.1.0 Environment: MacOS 10.3.6, xerces 3.1, gcc 4.2 Reporter: isidoro ghezzi Fix For: 3.1.2, 3.2.0 Original Estimate: 1h Remaining Estimate: 1h Compiling with $ g++ --version i686-apple-darwin10-g++-4.2.1 (GCC) 4.2.1 (Apple Inc. build 5646) (dot 1) having -Wall -Wextra -Wconversion -ansi -pedantic flags the result is: $ make check ... Compiling src/DOM/DOMMemTest/DOMMemTest.cpp src/DOM/DOMMemTest/DOMMemTest.cpp:50: error: extra ';' src/DOM/DOMMemTest/DOMMemTest.cpp:1489: error: extra ';' Compiling src/DOM/Normalizer/Normalizer.cpp src/DOM/Normalizer/Normalizer.cpp:203: error: extra ';' Compiling src/DOM/RangeTest/RangeTest.cpp src/DOM/RangeTest/RangeTest.cpp:55: error: extra ';' src/DOM/RangeTest/RangeTest.cpp:966: error: extra ';' Compiling src/DOM/Traversal/Traversal.cpp src/DOM/Traversal/Traversal.cpp:55: error: extra ';' src/DOM/Traversal/Traversal.cpp:557: error: extra ';' Compiling src/EncodingTest/EncodingTest.cpp src/EncodingTest/EncodingTest.cpp:82: error: extra ';' src/EncodingTest/EncodingTest.cpp:96: error: extra ';' src/EncodingTest/EncodingTest.cpp:111: error: extra ';' src/EncodingTest/EncodingTest.cpp:172: error: extra ';' src/EncodingTest/EncodingTest.cpp:443: error: extra ';' solved simply removing extra ; at above lines. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: c-dev-unsubscr...@xerces.apache.org For additional commands, e-mail: c-dev-h...@xerces.apache.org
[jira] Closed: (XERCESC-1924) Cannot open include file: 'inttypes.h': No such file or directory
[ https://issues.apache.org/jira/browse/XERCESC-1924?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Boris Kolpackov closed XERCESC-1924. Resolution: Invalid Please don't ask for help by creating bug report. Rather, post your question to the c-users mailing list: http://xerces.apache.org/xerces-c/mailing-lists.html Cannot open include file: 'inttypes.h': No such file or directory - Key: XERCESC-1924 URL: https://issues.apache.org/jira/browse/XERCESC-1924 Project: Xerces-C++ Issue Type: Bug Components: Build Affects Versions: 3.1.0 Environment: Cygwin 1.7.5 running on Vista using Visual C++ 2008 Express Edition Reporter: R Manger I am trying to install GDML add-on to Geant4, but I get an error when Xerces_autoconf_config.hpp calls for 'inttypes.hh.' Here is an excerpt of the compilation process: Compiling G4GDMLParser.cc ... G4GDMLParser.cc c:/xerces/include\xercesc/util/Xerces_autoconf_config.hpp(88) : fatal error C1083: Cannot open include file: 'inttypes.h': No such file or directory make[2] *** [c:/Geant4/geant4_9_3/tmp/WIN32-VC/G4gdml/G4GDMLParser.o] Error 2 make[1]: *** [objs] Error 2 I know that Visual Studio is set up to communicate with cygwin properly because I have built many other cpp toolkits in this environment. What may be the problem? Thanks -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: c-dev-unsubscr...@xerces.apache.org For additional commands, e-mail: c-dev-h...@xerces.apache.org
[jira] Closed: (XERCESC-1921) Buffer overflow in XMLString::replaceTokens()
[ https://issues.apache.org/jira/browse/XERCESC-1921?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Boris Kolpackov closed XERCESC-1921. Resolution: Invalid Scott, the documentation for replaceTokens specifies that the buffer should be maxChars + 1 long to accommodate for the null terminator. While this interface is not ideal, this function is internal so I am not sure whether it makes sense to change it. I have audited all the places it is called from and they all make sure to allocate extra character in the buffer. Please reopen this issue if you see an actual buffer overrun. Buffer overflow in XMLString::replaceTokens() - Key: XERCESC-1921 URL: https://issues.apache.org/jira/browse/XERCESC-1921 Project: Xerces-C++ Issue Type: Bug Components: Utilities Environment: Probably any C++ Environment Reporter: Scott Colcord The function XMLString::replaceTokens() does not take its terminating NULL into account when comparing with the maxChars limit passed by the caller. Consequently, when passed a too-large string, it will overwrite one XMLCh after the buffer. It should be changed to test (curOutInd+1 maxChars), and increment curOutInd when setting the null. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: c-dev-unsubscr...@xerces.apache.org For additional commands, e-mail: c-dev-h...@xerces.apache.org
[jira] Closed: (XERCESC-1920) UnixHTTPURLInputStream core-dumps
[ https://issues.apache.org/jira/browse/XERCESC-1920?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Boris Kolpackov closed XERCESC-1920. Assignee: Boris Kolpackov Fix Version/s: 3.1.1 3.2.0 Resolution: Fixed Fix is in SVN and will be included in the upcoming 3.1.1 release. Thanks for the report! UnixHTTPURLInputStream core-dumps - Key: XERCESC-1920 URL: https://issues.apache.org/jira/browse/XERCESC-1920 Project: Xerces-C++ Issue Type: Bug Components: SAX/SAX2 Affects Versions: 3.0.1 Environment: Solaris 32 bit Reporter: Kristian Ivarsson Assignee: Boris Kolpackov Fix For: 3.1.1, 3.2.0 Using SAX2XMLReader or SAXParser to parse following XML (note the tripple slashes) makes the application to core dump and a SEGV occurs in UnixHTTPURLInputStream::UnixHTTPURLInputStream() where function gethostbyname() is called ... const char * const xml = ?xml version='1.0' encoding='ISO-8859-1' standalone='no'? !DOCTYPE root SYSTEM 'http:///server.org/dtd.dtd' root/; ... What happens is that the first (and only) argument to gethostbyname() is 0 (zero/null) and some inner machanism of gethostbyname() cannot handle that I'm not sure what class/mechanism in XercesC is to blame though ? It could be XMLURL::XMLURL() that doesn't throw because of an invalid URL It could be XMLURL::getHost() that returns 0 instead of an empty XMLCh-sequence It could be XMLString::transcode() that doesn't complain when transcoding a null-XMLCh-sequence It could be ArrayJanoitor::ArrayJanoitor() that doesn't complain about that an unnecessary assignment has ben given to it It could be UnixHTTPURLInputStream::UnixHTTPURLInputStream() that tries to operate on a null-char-array It could be Solaris::gethostbyname() that doesn't have proper error-handling of input parameters (cannot be solved in this project though) I haven't tried it with any of the DOMParsers, but I would guess that the behaviour would be similar if the same underlaying mechanisms are (re)used -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: c-dev-unsubscr...@xerces.apache.org For additional commands, e-mail: c-dev-h...@xerces.apache.org
[jira] Closed: (XERCESC-1919) Access violation in AbstractDOMParser::docComment()
[
https://issues.apache.org/jira/browse/XERCESC-1919?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Boris Kolpackov closed XERCESC-1919.
Assignee: Boris Kolpackov
Fix Version/s: 3.1.1
3.2.0
Resolution: Fixed
The fix is in SVN and will be in the shortly-to-be-released 3.1.1. Thanks for
reporting this and for the test case!
Access violation in AbstractDOMParser::docComment()
---
Key: XERCESC-1919
URL: https://issues.apache.org/jira/browse/XERCESC-1919
Project: Xerces-C++
Issue Type: Bug
Components: Non-Validating Parser
Affects Versions: 3.1.0
Environment: Windows 7
Visual C++ 2008
Static manually built version of Xerces 3.1.0
Reporter: Dmitriy V'jukov
Assignee: Boris Kolpackov
Fix For: 3.1.1, 3.2.0
Attachments: crash.xml
I parse an XML document with the following code:
XercesDOMParser parser;
parser.setCreateEntityReferenceNodes(false);
parser.setLoadExternalDTD(false);
parser.setLoadSchema(false);
parser.setSkipDTDValidation(true);
parser.setExitOnFirstFatalError(false);
MemBufInputSource source ((XMLByte const*)decoded.begin(),
decoded.size(), L);
parser.parse(source);
Parser crashes in:
void AbstractDOMParser::docComment(const XMLCh* const comment)
{
if (fCreateCommentNodes) {
DOMComment *dcom = fDocument-createComment(comment);
castToParentImpl (fCurrentParent)-appendChildFast (dcom); // -
fCurrentParent == 0
fCurrentNode = dcom;
}
}
with fCurrentParent == 0.
Current position of parser is line 233, column 17, i.e. straight after !--
Scripts --
Here is the XML document:
[attached as 'crash.xml']
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
https://issues.apache.org/jira/secure/Administrators.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] Updated: (XERCESC-1910) The RegularExpression 'matches' function no longer returns the start and end position of a match
[
https://issues.apache.org/jira/browse/XERCESC-1910?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Boris Kolpackov updated XERCESC-1910:
-
Fix Version/s: 3.1.0
(was: 3.2.0)
(was: 3.1.1)
The RegularExpression 'matches' function no longer returns the start and end
position of a match
Key: XERCESC-1910
URL: https://issues.apache.org/jira/browse/XERCESC-1910
Project: Xerces-C++
Issue Type: Bug
Components: Utilities
Affects Versions: 3.0.1
Environment: Windows
Reporter: Steve Roberts
Fix For: 3.1.0
We have recently upgraded from version 2.2.0 to version 3.0.1. Between these
versions a change was made to the RegularExpression::matchUnion function, so
that it now uses a local version of the context structure. The result of this
is that the 'fMatch' member of the context can be changed from its original
instance. Therefore, back in the RegularExpression::matches function, just
before it returns, it sets the start and end position of the match:
context.fMatch-setStartPos(0, (int)matchStart);
context.fMatch-setEndPos(0, matchEnd);
However, the 'fMatch' object no longer matches the one that was passed
through to function (due to what happened in 'matchUnion') and therefore
these values don't get returned to the calling function.
Therefore, I think that in the 'matches' function is should actually be
setting the start and end position of the 'pMatch' property that is passed
into the function, rather than the 'context.fMatch'.
The code we are using to call the regular expression is this:
XERCES_CPP_NAMESPACE::RegularExpression re(expression.c_str());
if( re.matches( text, match ) )
{ ...
where expression = ([\-\(]?\d{1,3}([,
]\d{3})+\.\d+[\)]?|[\-\(]?\d+\.\d+[\)]?).*
and text = 13.13
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
https://issues.apache.org/jira/secure/Administrators.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-1910) The RegularExpression 'matches' function no longer returns the start and end position of a match
[
https://issues.apache.org/jira/browse/XERCESC-1910?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Boris Kolpackov closed XERCESC-1910.
Assuming this is fixed since 3.1.0.
The RegularExpression 'matches' function no longer returns the start and end
position of a match
Key: XERCESC-1910
URL: https://issues.apache.org/jira/browse/XERCESC-1910
Project: Xerces-C++
Issue Type: Bug
Components: Utilities
Affects Versions: 3.0.1
Environment: Windows
Reporter: Steve Roberts
Fix For: 3.1.0
We have recently upgraded from version 2.2.0 to version 3.0.1. Between these
versions a change was made to the RegularExpression::matchUnion function, so
that it now uses a local version of the context structure. The result of this
is that the 'fMatch' member of the context can be changed from its original
instance. Therefore, back in the RegularExpression::matches function, just
before it returns, it sets the start and end position of the match:
context.fMatch-setStartPos(0, (int)matchStart);
context.fMatch-setEndPos(0, matchEnd);
However, the 'fMatch' object no longer matches the one that was passed
through to function (due to what happened in 'matchUnion') and therefore
these values don't get returned to the calling function.
Therefore, I think that in the 'matches' function is should actually be
setting the start and end position of the 'pMatch' property that is passed
into the function, rather than the 'context.fMatch'.
The code we are using to call the regular expression is this:
XERCES_CPP_NAMESPACE::RegularExpression re(expression.c_str());
if( re.matches( text, match ) )
{ ...
where expression = ([\-\(]?\d{1,3}([,
]\d{3})+\.\d+[\)]?|[\-\(]?\d+\.\d+[\)]?).*
and text = 13.13
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
https://issues.apache.org/jira/secure/Administrators.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] Updated: (XERCESC-1914) SEnumVal does not produce correct output
[ https://issues.apache.org/jira/browse/XERCESC-1914?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Boris Kolpackov updated XERCESC-1914: - Fix Version/s: 3.1.1 3.2.0 Need to check what's going on here. SEnumVal does not produce correct output Key: XERCESC-1914 URL: https://issues.apache.org/jira/browse/XERCESC-1914 Project: Xerces-C++ Issue Type: Bug Components: Samples/Tests Affects Versions: 3.1.0 Environment: Windows Reporter: David Burrell Fix For: 3.1.1, 3.2.0 SEnumVal does not produce correct output. Our application relies on the ability to enumerate the grammar. The last release that worked correctly was 2.3.0. We cannot upgrade to any later version until we find a solution to this problem. The main problem is that the content model appears to be incorrect. This can be seen by comparing formatted content models produced by SEnumVal. Here is partial output from SEnumVal, comparing 2.3.0 with 3.1.0... xerces-c 2.3.0: (showing correct output) Name: category Model Type: Children Create Reason:Declared ContentType: OneOrMore Content Model:(severity)+ ComplexType: TypeName: ,C2 ContentType:OneOrMore Attributes: Name: name Type: CDATA Default Type: #REQUIRED Base Datatype: string Name: categoryCode Type: CDATA Default Type: #REQUIRED Base Datatype: string Enumeration: 0 1 2 3.1.0: ( incorrect - content model should be '(severity)+' ) Name: category Model Type: Children Create Reason:Declared ContentType: ModelGroupSequence Content Model:(severity,) ComplexType: TypeName: ,__AnonC2 ContentType:ModelGroupSequence Attributes: Name: categoryCode Type: CDATA Default Type: #REQUIRED Base Datatype: string Enumeration: 0 1 2 Name: name Type: CDATA Default Type: #REQUIRED Base Datatype: string -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://issues.apache.org/jira/secure/Administrators.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] Updated: (XERCESC-1785) Build and test on all supported platforms
[ https://issues.apache.org/jira/browse/XERCESC-1785?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Boris Kolpackov updated XERCESC-1785: - Fix Version/s: 3.2.0 (was: 3.1.0) Build and test on all supported platforms - Key: XERCESC-1785 URL: https://issues.apache.org/jira/browse/XERCESC-1785 Project: Xerces-C++ Issue Type: Task Components: Build Reporter: Boris Kolpackov Priority: Blocker Fix For: 3.2.0 We need to make sure that building, testing and installation work on all platforms that we have committed to support. See the following Wiki page for the status: http://wiki.apache.org/xerces/XercescBuildStatus -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://issues.apache.org/jira/secure/Administrators.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] Updated: (XERCESC-1907) PDB file name for static 64-bit debug builds in VC8 and VC9 project files are not library specific
[ https://issues.apache.org/jira/browse/XERCESC-1907?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Boris Kolpackov updated XERCESC-1907: - Fix Version/s: 3.1.1 3.2.0 Scheduling for 3.1.1 PDB file name for static 64-bit debug builds in VC8 and VC9 project files are not library specific -- Key: XERCESC-1907 URL: https://issues.apache.org/jira/browse/XERCESC-1907 Project: Xerces-C++ Issue Type: Bug Components: Build Affects Versions: 3.1.0 Environment: Windows Reporter: Boris Kolpackov Priority: Minor Fix For: 3.1.1, 3.2.0 The PDB file for static 64-bit debug builds in VC8 and VC9 project files are still names xerceslib_vc80.pdb. We have fixed this for 32-bit builds but not for 64-bit, for some reason. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://issues.apache.org/jira/secure/Administrators.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-1912) Conflicting includes cpuid.h and intrin.h (both define __cpuid)
[ https://issues.apache.org/jira/browse/XERCESC-1912?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Boris Kolpackov closed XERCESC-1912. Assignee: Boris Kolpackov Resolution: Fixed Fix is in SVN. Conflicting includes cpuid.h and intrin.h (both define __cpuid) --- Key: XERCESC-1912 URL: https://issues.apache.org/jira/browse/XERCESC-1912 Project: Xerces-C++ Issue Type: Bug Components: Build Affects Versions: 3.1.0 Environment: GCC 4.4 (mingw) with mingw-w64 environment (64-bit, cross-compiling under Debian GNU/Linux) Reporter: Tommi Vainikainen Assignee: Boris Kolpackov Priority: Minor Fix For: 3.1.1, 3.2.0 GCC (since 4.3 AFAIK) contains cpuid.h which defines _get_cpuid(...) and __cpuid(level, a, b, c, d). intrin.h is Windows-API which defines __cpuid(int CPUInfo[4], int InfoType) Definitions of __cpuid are clearly not compatible. However when cross-compiling with GCC-mingw for Windows, configure script detects existence of both cpuid.h and intrin.h and includes both in PlatformUtils.cpp Following trivial patch workarounds this problem. diff -ur xerces-c-3.1.0/src/xercesc/util/PlatformUtils.cpp xerces-c-3.1.0.patched/src/xercesc/util/PlatformUtils.cpp --- xerces-c-3.1.0/src/xercesc/util/PlatformUtils.cpp 2009-08-28 16:21:24.0 +0300 +++ xerces-c-3.1.0.patched/src/xercesc/util/PlatformUtils.cpp 2010-02-15 11:16:33.0 +0200 @@ -37,7 +37,7 @@ #if HAVE_SYS_TIMEB_H #include sys/timeb.h #endif -#if HAVE_CPUID_H +#if HAVE_CPUID_H !XERCES_HAVE_INTRIN_H # include cpuid.h #endif -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://issues.apache.org/jira/secure/Administrators.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-1911) spelling fixes for xerces
[ https://issues.apache.org/jira/browse/XERCESC-1911?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Boris Kolpackov closed XERCESC-1911. Assignee: Boris Kolpackov Resolution: Fixed Changes are in SVN. Note also that there were a couple of wrong/incomplete fixes in the provided patch. spelling fixes for xerces - Key: XERCESC-1911 URL: https://issues.apache.org/jira/browse/XERCESC-1911 Project: Xerces-C++ Issue Type: Bug Reporter: timeless Assignee: Boris Kolpackov Priority: Trivial Fix For: 3.1.1, 3.2.0 Attachments: 12456044 I was running a spelling fix process against a Symbian repository and discovered that a portion of the changes was to Xerces, so I'm trying to deliver the spelling fixes here. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://issues.apache.org/jira/secure/Administrators.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-1907) PDB file name for static 64-bit debug builds in VC8 and VC9 project files are not library specific
[ https://issues.apache.org/jira/browse/XERCESC-1907?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Boris Kolpackov closed XERCESC-1907. Assignee: Boris Kolpackov Resolution: Fixed Fix is in SVN. PDB file name for static 64-bit debug builds in VC8 and VC9 project files are not library specific -- Key: XERCESC-1907 URL: https://issues.apache.org/jira/browse/XERCESC-1907 Project: Xerces-C++ Issue Type: Bug Components: Build Affects Versions: 3.1.0 Environment: Windows Reporter: Boris Kolpackov Assignee: Boris Kolpackov Priority: Minor Fix For: 3.1.1, 3.2.0 The PDB file for static 64-bit debug builds in VC8 and VC9 project files are still names xerceslib_vc80.pdb. We have fixed this for 32-bit builds but not for 64-bit, for some reason. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://issues.apache.org/jira/secure/Administrators.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-1918) XInclude broken with multiple level includes
[ https://issues.apache.org/jira/browse/XERCESC-1918?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Boris Kolpackov closed XERCESC-1918. Assignee: Boris Kolpackov Resolution: Fixed I have re-implemented the patch and committed it. Also fixed a few bugs and memory leaks in XInclude code while at it. XInclude broken with multiple level includes Key: XERCESC-1918 URL: https://issues.apache.org/jira/browse/XERCESC-1918 Project: Xerces-C++ Issue Type: Bug Components: Non-Validating Parser Affects Versions: 3.0.0 Environment: linux, windows Reporter: keith mcneill Assignee: Boris Kolpackov Fix For: 3.1.1, 3.2.0 Attachments: xerces-c-xinclude.diff, xinclude-bottom.xml, xinclude-middle.xml, xinclude-top.xml If you use xinclude on multiple levels ( 2) with relative path names. XInclude will break with an error something like no scheme. I tracked this down to a problem in XIncludeUtils::doDOMNodeXInclude. When an includeDoc was found it created a DocumentFragment to hang the new copied nodes off of. At the end of processing it would paste the DocumentFragment on to the document. The problem was that DocumentFragment lost the absolute path in its getBaseURI(). This absolute path also contained the scheme. This diff fixes XInclude by not using a DocumentFragment. We just use insertBefore() to insert the new nodes in the destination document in order. This way the getBaseURI() is never lost. I've also included a fix to XIncludeLocation.prependPath(). PrependPath used to slam a new path on the beginning of the current path without checking to see if the current path already had a scheme. For example you could end up with paths like: file:///new/parent/file:///old/child. Now it will produce file:///new/parent/old/child. XIncludeLocation probably needs to get smarter about dealing with schemes URI's in general. I've included a diff an example files that can be run with the XInclude sample. Note that with these fixes the xerces c++ xinclude behaves more like the java xinclude support. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://issues.apache.org/jira/secure/Administrators.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-1918) XInclude broken with multiple level includes
[ https://issues.apache.org/jira/browse/XERCESC-1918?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12852089#action_12852089 ] Boris Kolpackov commented on XERCESC-1918: -- Keith, thanks for the patch. I would like to commit it, however, the project's charter[1] requires me to get the answers to the following questions from you before I can do this: a) Name and employer b) Are you the author of the code being contributed? c) Do you have the right to grant the copyright and patent licenses for the contribution that are set forth in the ASF v.2.0 license (http://www.apache.org/licenses/LICENSE-2.0)? d) Does your employer have any rights to code that you have written, for example, through your contract for employment? If so, has your employer given you permission to contribute the code on its behalf or waived its rights in the code? e) Are you aware of any third-party licenses or other restrictions (such as related patents or trademarks) that could apply to your contribution? If so, what are they? If you can provide the answers as a comment for this issue, that would be great. [1] http://xerces.apache.org/xerces-c/charter.html XInclude broken with multiple level includes Key: XERCESC-1918 URL: https://issues.apache.org/jira/browse/XERCESC-1918 Project: Xerces-C++ Issue Type: Bug Components: Non-Validating Parser Affects Versions: 3.0.0 Environment: linux, windows Reporter: keith mcneill Attachments: xerces-c-xinclude.diff, xinclude-bottom.xml, xinclude-middle.xml, xinclude-top.xml If you use xinclude on multiple levels ( 2) with relative path names. XInclude will break with an error something like no scheme. I tracked this down to a problem in XIncludeUtils::doDOMNodeXInclude. When an includeDoc was found it created a DocumentFragment to hang the new copied nodes off of. At the end of processing it would paste the DocumentFragment on to the document. The problem was that DocumentFragment lost the absolute path in its getBaseURI(). This absolute path also contained the scheme. This diff fixes XInclude by not using a DocumentFragment. We just use insertBefore() to insert the new nodes in the destination document in order. This way the getBaseURI() is never lost. I've also included a fix to XIncludeLocation.prependPath(). PrependPath used to slam a new path on the beginning of the current path without checking to see if the current path already had a scheme. For example you could end up with paths like: file:///new/parent/file:///old/child. Now it will produce file:///new/parent/old/child. XIncludeLocation probably needs to get smarter about dealing with schemes URI's in general. I've included a diff an example files that can be run with the XInclude sample. Note that with these fixes the xerces c++ xinclude behaves more like the java xinclude support. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: c-dev-unsubscr...@xerces.apache.org For additional commands, e-mail: c-dev-h...@xerces.apache.org
[jira] Updated: (XERCESC-1917) GCCDefs str[n]icmp prototype and symbol exposure
[
https://issues.apache.org/jira/browse/XERCESC-1917?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Boris Kolpackov updated XERCESC-1917:
-
Priority: Minor (was: Major)
Issue Type: Improvement (was: Bug)
FYI, there are no plans to release any more versions in the 2-series. In the
3-series we use a similar workaround but in a cross-platform way, so this patch
is not easily applicable. Also, what is the problem with having these symbols
visible in the Xerces-C++ library?
GCCDefs str[n]icmp prototype and symbol exposure
Key: XERCESC-1917
URL: https://issues.apache.org/jira/browse/XERCESC-1917
Project: Xerces-C++
Issue Type: Improvement
Components: Build
Affects Versions: 2.8.0
Environment: linux x86_64 gcc
Reporter: George Gensure
Priority: Minor
The stricmp and strnicmp prototypes provided as a workaround for those
functions missing in gcc/glibc installations are defined in the global scope
and without extern C qualifiers. As a result, these are the *only*
non-xerces_2_8 namespaced functions exposed by the shared library on linux.
I recognize that the compiler workarounds are included prior to the xercesc
namespace definition, and as a compromise I'd be happy to see the definitions
have their prototypes changed to be within an extern C block, as well as
__attribute__((visibility(hidden))) applied to their definitions. The
following diff applies cleanly to the 2.8 release and corrects my problem:
--- src/xercesc/util/Compilers/GCCDefs.hpp
+++ src/xercesc/util/Compilers/GCCDefs.hpp
@@ -130,8 +130,10 @@
#if !defined(__CYGWIN__) !defined(__MINGW32__)
+extern C {
int stricmp(const char* const str1, const char* const str2);
int strnicmp(const char* const str1, const char* const str2, const unsigned
int count);
+}
#endif // ! __CYGWIN__
--- src/xercesc/util/Compilers/GCCDefs.cpp
+++ src/xercesc/util/Compilers/GCCDefs.cpp
@@ -33,11 +33,13 @@
#if !defined(__CYGWIN__) !defined(__MINGW32__)
+__attribute__((visibility(hidden)))
int stricmp(const char* const str1, const char* const str2)
{
return strcasecmp(str1, str2);
}
+__attribute__((visibility(hidden)))
int strnicmp(const char* const str1, const char* const str2, const unsigned
int count)
{
if (count == 0)
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
-
To unsubscribe, e-mail: c-dev-unsubscr...@xerces.apache.org
For additional commands, e-mail: c-dev-h...@xerces.apache.org
[jira] Closed: (XERCESC-1915) Segmentation fault in getPooledString
[ https://issues.apache.org/jira/browse/XERCESC-1915?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Boris Kolpackov closed XERCESC-1915. Resolution: Invalid This is a problem in XL C++ optimizer as explained in one of the comments for XERCESC-1904. The workaround is to add -qalias=noansi. Segmentation fault in getPooledString - Key: XERCESC-1915 URL: https://issues.apache.org/jira/browse/XERCESC-1915 Project: Xerces-C++ Issue Type: Bug Components: DOM Affects Versions: 2.7.0 Environment: AIX 6.1, powerpc, IBM XL C/C++ for AIX, V10.1 Reporter: Olov Brötell Priority: Blocker Segmentation fault in getPooledString after call to 'createSPE'. - ... // This string hasn't been seen before. Add it to the pool. *pspe = spe = createSPE(in, fDoc); return spe-fString; } - Reproducible in my environment *unless* built with debugging symbols (-d). Steps to reproduce: - build xerces-c_2_7_0 on AIX 6.1 with IBM XL C/C++ for AIX, V10.1 (32 or 64 bit) - build sample programs - execute for example CreateDOMDocument to get segfault $dbx -d 1 -C core Type 'help' for help. [Object file is not specified. Using CreateDOMDocument as an object file] warning: The core file is not a fullcore. Some info may not be available. [using memory image in core] reading symbolic information ... Segmentation fault in getPooledString__Q2_11xercesc_2_713DOMStringPoolFPCUs at 0xd50d8e24 0xd50d8e24 (getPooledString__Q2_11xercesc_2_713DOMStringPoolFPCUs+0xa4) 907f stw r3,0x0(r31) (dbx) where getPooledString__Q2_11xercesc_2_713DOMStringPoolFPCUs() at 0xd50d8e24 DOMDocumentImpl.getPooledString(const unsigned short*)() at 0xd4e88d70 DOMElementImpl.DOMElementImpl(xercesc_2_7::DOMDocument*,const unsigned short*)() at 0xd50e8fa8 DOMElementNSImpl.DOMElementNSImpl(xercesc_2_7::DOMDocument*,const unsigned short*,const unsigned short*)() at 0xd50e77a4 DOMDocumentImpl.createElementNS(const unsigned short*,const unsigned short*)() at 0xd4e7aec4 DOMDocumentImpl.DOMDocumentImpl(const unsigned short*,const unsigned short*,xercesc_2_7::DOMDocumentType*,xercesc_2_7::MemoryManager *)() at 0xd4e7acf0 DOMImplementationImpl.createDocument(const unsigned short*,const unsigned short*,xercesc_2_7::DOMDocumentType*,xercesc_2_7::MemoryMa nager*)() at 0xd4e908c4 unnamed block in main(argC = 1, = /\362)^P), line 140 in CreateDOMDocument.cpp unnamed block in main(argC = 1, = /\362)^P), line 140 in CreateDOMDocument.cpp main(argC = 1, = /\362)^P), line 140 in CreateDOMDocument.cpp -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: c-dev-unsubscr...@xerces.apache.org For additional commands, e-mail: c-dev-h...@xerces.apache.org
[jira] Updated: (XERCESC-1913) Change to importNode to copy prefixes breaks when xmlns= is present
[ https://issues.apache.org/jira/browse/XERCESC-1913?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Boris Kolpackov updated XERCESC-1913: - Fix Version/s: 3.2.0 3.1.1 Change to importNode to copy prefixes breaks when xmlns= is present - Key: XERCESC-1913 URL: https://issues.apache.org/jira/browse/XERCESC-1913 Project: Xerces-C++ Issue Type: Bug Components: DOM Affects Versions: 3.1.0 Environment: Affects all platforms Reporter: Scott Cantor Fix For: 3.1.1, 3.2.0 A change to importNode was made to copy over prefixes of nodes with non-empty namespaces, using setPrefix. This causes setPrefix to throw a DOMException if called on the default namespace declaration node (xmlns=) because it checks for that explicitly. The revised fix should check for that case in one of the two spots, probably in setPrefix by ignoring the issue when the prefix supplied is NULL. Mailing list thread here: http://marc.info/?t=12662079471r=1w=2 -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: c-dev-unsubscr...@xerces.apache.org For additional commands, e-mail: c-dev-h...@xerces.apache.org
[jira] Closed: (XERCESC-1913) Change to importNode to copy prefixes breaks when xmlns= is present
[ https://issues.apache.org/jira/browse/XERCESC-1913?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Boris Kolpackov closed XERCESC-1913. Resolution: Fixed Assignee: Boris Kolpackov Fix is in the trunk and in the 3.1.1 branch. Change to importNode to copy prefixes breaks when xmlns= is present - Key: XERCESC-1913 URL: https://issues.apache.org/jira/browse/XERCESC-1913 Project: Xerces-C++ Issue Type: Bug Components: DOM Affects Versions: 3.1.0 Environment: Affects all platforms Reporter: Scott Cantor Assignee: Boris Kolpackov Fix For: 3.1.1, 3.2.0 A change to importNode was made to copy over prefixes of nodes with non-empty namespaces, using setPrefix. This causes setPrefix to throw a DOMException if called on the default namespace declaration node (xmlns=) because it checks for that explicitly. The revised fix should check for that case in one of the two spots, probably in setPrefix by ignoring the issue when the prefix supplied is NULL. Mailing list thread here: http://marc.info/?t=12662079471r=1w=2 -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: c-dev-unsubscr...@xerces.apache.org For additional commands, e-mail: c-dev-h...@xerces.apache.org
[jira] Updated: (XERCESC-1911) spelling fixes for xerces
[ https://issues.apache.org/jira/browse/XERCESC-1911?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Boris Kolpackov updated XERCESC-1911: - Fix Version/s: 3.2.0 3.1.1 Scheduling for 3.1.1 and 3.2.0. Thanks for the patch! spelling fixes for xerces - Key: XERCESC-1911 URL: https://issues.apache.org/jira/browse/XERCESC-1911 Project: Xerces-C++ Issue Type: Bug Reporter: timeless Priority: Trivial Fix For: 3.1.1, 3.2.0 Attachments: 12456044 I was running a spelling fix process against a Symbian repository and discovered that a portion of the changes was to Xerces, so I'm trying to deliver the spelling fixes here. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: c-dev-unsubscr...@xerces.apache.org For additional commands, e-mail: c-dev-h...@xerces.apache.org
[jira] Updated: (XERCESC-1912) Conflicting includes cpuid.h and intrin.h (both define __cpuid)
[ https://issues.apache.org/jira/browse/XERCESC-1912?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Boris Kolpackov updated XERCESC-1912: - Fix Version/s: 3.2.0 3.1.1 Scheduling for 3.1.1 and 3.2.0. Thanks for the patch! Conflicting includes cpuid.h and intrin.h (both define __cpuid) --- Key: XERCESC-1912 URL: https://issues.apache.org/jira/browse/XERCESC-1912 Project: Xerces-C++ Issue Type: Bug Components: Build Affects Versions: 3.1.0 Environment: GCC 4.4 (mingw) with mingw-w64 environment (64-bit, cross-compiling under Debian GNU/Linux) Reporter: Tommi Vainikainen Priority: Minor Fix For: 3.1.1, 3.2.0 GCC (since 4.3 AFAIK) contains cpuid.h which defines _get_cpuid(...) and __cpuid(level, a, b, c, d). intrin.h is Windows-API which defines __cpuid(int CPUInfo[4], int InfoType) Definitions of __cpuid are clearly not compatible. However when cross-compiling with GCC-mingw for Windows, configure script detects existence of both cpuid.h and intrin.h and includes both in PlatformUtils.cpp Following trivial patch workarounds this problem. diff -ur xerces-c-3.1.0/src/xercesc/util/PlatformUtils.cpp xerces-c-3.1.0.patched/src/xercesc/util/PlatformUtils.cpp --- xerces-c-3.1.0/src/xercesc/util/PlatformUtils.cpp 2009-08-28 16:21:24.0 +0300 +++ xerces-c-3.1.0.patched/src/xercesc/util/PlatformUtils.cpp 2010-02-15 11:16:33.0 +0200 @@ -37,7 +37,7 @@ #if HAVE_SYS_TIMEB_H #include sys/timeb.h #endif -#if HAVE_CPUID_H +#if HAVE_CPUID_H !XERCES_HAVE_INTRIN_H # include cpuid.h #endif -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: c-dev-unsubscr...@xerces.apache.org For additional commands, e-mail: c-dev-h...@xerces.apache.org
[jira] Commented: (XERCESC-1910) The RegularExpression 'matches' function no longer returns the start and end position of a match
[
https://issues.apache.org/jira/browse/XERCESC-1910?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12832466#action_12832466
]
Boris Kolpackov commented on XERCESC-1910:
--
Steve, do I understand you correctly in that you are saying that certain
functionality (that you used to rely on) has been removed between the two
version as opposed to that there is a bug that affects the current version?
The RegularExpression 'matches' function no longer returns the start and end
position of a match
Key: XERCESC-1910
URL: https://issues.apache.org/jira/browse/XERCESC-1910
Project: Xerces-C++
Issue Type: Bug
Components: Utilities
Affects Versions: 3.0.1
Environment: Windows
Reporter: Steve Roberts
We have recently upgraded from version 2.2.0 to version 3.0.1. Between these
versions a change was made to the RegularExpression::matchUnion function, so
that it now uses a local version of the context structure. The result of this
is that the 'fMatch' member of the context can be changed from its original
instance. Therefore, back in the RegularExpression::matches function, just
before it returns, it sets the start and end position of the match:
context.fMatch-setStartPos(0, (int)matchStart);
context.fMatch-setEndPos(0, matchEnd);
However, the 'fMatch' object no longer matches the one that was passed
through to function (due to what happened in 'matchUnion') and therefore
these values don't get returned to the calling function.
Therefore, I think that in the 'matches' function is should actually be
setting the start and end position of the 'pMatch' property that is passed
into the function, rather than the 'context.fMatch'.
The code we are using to call the regular expression is this:
XERCES_CPP_NAMESPACE::RegularExpression re(expression.c_str());
if( re.matches( text, match ) )
{ ...
where expression = ([\-\(]?\d{1,3}([,
]\d{3})+\.\d+[\)]?|[\-\(]?\d+\.\d+[\)]?).*
and text = 13.13
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
-
To unsubscribe, e-mail: c-dev-unsubscr...@xerces.apache.org
For additional commands, e-mail: c-dev-h...@xerces.apache.org
[jira] Closed: (XERCESC-1908) Xerces-c SAX application crashed on Solaris 10 x64
[ https://issues.apache.org/jira/browse/XERCESC-1908?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Boris Kolpackov closed XERCESC-1908. Resolution: Invalid I am assuming this is a toolchain problem and closing this issue. If there is new information pointing to Xerces-C++, please reopen it. Xerces-c SAX application crashed on Solaris 10 x64 -- Key: XERCESC-1908 URL: https://issues.apache.org/jira/browse/XERCESC-1908 Project: Xerces-C++ Issue Type: Bug Components: SAX/SAX2 Affects Versions: 2.7.0, 2.8.0, 3.0.0, 3.0.1 Environment: $uname -a SunOS xsol-qa1 5.10 Generic_137138-09 i86pc i386 i86pc $CC -V CC: Sun C++ 5.7 2005/01/07 Reporter: Bill Fu Attachments: config.tar.gz, sample test result.jpg, testsax_64so.tar.gz This issue just happens on Solaris 10 x64. There is no problem on other platforms, such as Solaris 10 x86 (32-bit), AIX (both 32 and 64), HP-UX (both PA-RISC and IA64), Linux x86 etc. I wrote a xerces-c sax application on Solaris 10 x64. The class MXmlHandler was the xml handler what was inherited from DefaultHandeler. The following is the compiler and linker flags. Compiler flags: -mt -xarch=amd64 -g -I/usr/app/xercesc/2.8/include Linker flags: -mt -xarch=amd64 -L/usr/app/xercesc/2.8/lib -lxerces-c At the begining of the method void startElement( const XMLCh* consturi, const XMLCh* constlocalname, const XMLCh* constqname, const Attributes attributes); the value of the parameter qname was wrong. For example the qname should be a string like schemaName, but it was a recognised string. This is the behavior in RELEASE libraries. In the DEBUG mode, the application crashed in xerces-c libraries. The following is traceback. =[1] xercesc_2_8::XMLAttr::getValue(this = 0x18), line 486 in XMLAttr.hpp [2] xercesc_2_8::VecAttrListImpl::getValue(this = 0x4cc3e8, index = 1U), line 86 in VecAttrListImpl.cpp [3] 0xfd7ffeab6546(0x0, 0x0, 0x0, 0x0, 0x0, 0x0), at 0xfd7ffeab6545 [4] xercesc_2_8::SAXParser::startElement(this = 0x4cc3a8, elemDecl = CLASS, elemURLId = 1U, elemPrefix = 0xfd7ffe1bb3b0, attrList = CLASS, attrCount = 2U, isEmpty = false, isRoot = true), line 971 in SAXParser.cpp [5] xercesc_2_8::IGXMLScanner::scanStartTag(this = 0x4cd6b8, gotData = true), line 2101 in IGXMLScanner.cpp [6] xercesc_2_8::IGXMLScanner::scanContent(this = 0x4cd6b8), line 899 in IGXMLScanner.cpp [7] xercesc_2_8::IGXMLScanner::scanDocument(this = 0x4cd6b8, src = CLASS), line 215 in IGXMLScanner.cpp [8] xercesc_2_8::XMLScanner::scanDocument(this = 0x4cd6b8, systemId = 0x4d4530), line 460 in XMLScanner.cpp [9] xercesc_2_8::XMLScanner::scanDocument(this = 0x4cd6b8, systemId = 0x4c7f68 ../dats/adr3xml.dat), line 468 in XMLScanner.cpp [10] xercesc_2_8::SAXParser::parse(this = 0x4cc3a8, systemId = 0x4c7f68 ../dats/adr3xml.dat), line 587 in SAXParser.cpp -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: c-dev-unsubscr...@xerces.apache.org For additional commands, e-mail: c-dev-h...@xerces.apache.org
[jira] Commented: (XERCESC-1908) Xerces-c SAX application crashed on Solaris 10 x64
[ https://issues.apache.org/jira/browse/XERCESC-1908?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12829590#action_12829590 ] Boris Kolpackov commented on XERCESC-1908: -- Bill, I tried your test case on Solaris 10 x86-64 with Sun CC 5.10 (I don't have access to 5.7 at the moment) and Xerces-C++ 3.1.0 (I used a pre-built library from the website) . Both test cases (pic and non-pic) print the expected result. So I think this is either a compiler issue or there is something special about your setup. Can you download the latest version of Sun CC (can be installed side-by-side with older versions) and see if you still get the same problem? Xerces-c SAX application crashed on Solaris 10 x64 -- Key: XERCESC-1908 URL: https://issues.apache.org/jira/browse/XERCESC-1908 Project: Xerces-C++ Issue Type: Bug Components: SAX/SAX2 Affects Versions: 2.7.0, 2.8.0, 3.0.0, 3.0.1 Environment: $uname -a SunOS xsol-qa1 5.10 Generic_137138-09 i86pc i386 i86pc $CC -V CC: Sun C++ 5.7 2005/01/07 Reporter: Bill Fu Attachments: config.tar.gz, sample test result.jpg, testsax_64so.tar.gz This issue just happens on Solaris 10 x64. There is no problem on other platforms, such as Solaris 10 x86 (32-bit), AIX (both 32 and 64), HP-UX (both PA-RISC and IA64), Linux x86 etc. I wrote a xerces-c sax application on Solaris 10 x64. The class MXmlHandler was the xml handler what was inherited from DefaultHandeler. The following is the compiler and linker flags. Compiler flags: -mt -xarch=amd64 -g -I/usr/app/xercesc/2.8/include Linker flags: -mt -xarch=amd64 -L/usr/app/xercesc/2.8/lib -lxerces-c At the begining of the method void startElement( const XMLCh* consturi, const XMLCh* constlocalname, const XMLCh* constqname, const Attributes attributes); the value of the parameter qname was wrong. For example the qname should be a string like schemaName, but it was a recognised string. This is the behavior in RELEASE libraries. In the DEBUG mode, the application crashed in xerces-c libraries. The following is traceback. =[1] xercesc_2_8::XMLAttr::getValue(this = 0x18), line 486 in XMLAttr.hpp [2] xercesc_2_8::VecAttrListImpl::getValue(this = 0x4cc3e8, index = 1U), line 86 in VecAttrListImpl.cpp [3] 0xfd7ffeab6546(0x0, 0x0, 0x0, 0x0, 0x0, 0x0), at 0xfd7ffeab6545 [4] xercesc_2_8::SAXParser::startElement(this = 0x4cc3a8, elemDecl = CLASS, elemURLId = 1U, elemPrefix = 0xfd7ffe1bb3b0, attrList = CLASS, attrCount = 2U, isEmpty = false, isRoot = true), line 971 in SAXParser.cpp [5] xercesc_2_8::IGXMLScanner::scanStartTag(this = 0x4cd6b8, gotData = true), line 2101 in IGXMLScanner.cpp [6] xercesc_2_8::IGXMLScanner::scanContent(this = 0x4cd6b8), line 899 in IGXMLScanner.cpp [7] xercesc_2_8::IGXMLScanner::scanDocument(this = 0x4cd6b8, src = CLASS), line 215 in IGXMLScanner.cpp [8] xercesc_2_8::XMLScanner::scanDocument(this = 0x4cd6b8, systemId = 0x4d4530), line 460 in XMLScanner.cpp [9] xercesc_2_8::XMLScanner::scanDocument(this = 0x4cd6b8, systemId = 0x4c7f68 ../dats/adr3xml.dat), line 468 in XMLScanner.cpp [10] xercesc_2_8::SAXParser::parse(this = 0x4cc3a8, systemId = 0x4c7f68 ../dats/adr3xml.dat), line 587 in SAXParser.cpp -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: c-dev-unsubscr...@xerces.apache.org For additional commands, e-mail: c-dev-h...@xerces.apache.org
[jira] Commented: (XERCESC-1908) Xerces-c SAX application crashed on Solaris 10 x64
[ https://issues.apache.org/jira/browse/XERCESC-1908?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12828532#action_12828532 ] Boris Kolpackov commented on XERCESC-1908: -- Bill, can you attach a test case (XML file and C++ test driver, preferably for the latest 3.1.0 release) that reproduces this problem? Xerces-c SAX application crashed on Solaris 10 x64 -- Key: XERCESC-1908 URL: https://issues.apache.org/jira/browse/XERCESC-1908 Project: Xerces-C++ Issue Type: Bug Components: SAX/SAX2 Affects Versions: 2.7.0, 2.8.0, 3.0.0, 3.0.1 Environment: $uname -a SunOS xsol-qa1 5.10 Generic_137138-09 i86pc i386 i86pc $CC -V CC: Sun C++ 5.7 2005/01/07 Reporter: Bill Fu This issue just happens on Solaris 10 x64. There is no problem on other platforms, such as Solaris 10 x86 (32-bit), AIX (both 32 and 64), HP-UX (both PA-RISC and IA64), Linux x86 etc. I wrote a xerces-c sax application on Solaris 10 x64. The class MXmlHandler was the xml handler what was inherited from DefaultHandeler. The following is the compiler and linker flags. Compiler flags: -mt -xarch=amd64 -g -I/usr/app/xercesc/2.8/include Linker flags: -mt -xarch=amd64 -L/usr/app/xercesc/2.8/lib -lxerces-c At the begining of the method void startElement( const XMLCh* consturi, const XMLCh* constlocalname, const XMLCh* constqname, const Attributes attributes); the value of the parameter qname was wrong. For example the qname should be a string like schemaName, but it was a recognised string. This is the behavior in RELEASE libraries. In the DEBUG mode, the application crashed in xerces-c libraries. The following is traceback. =[1] xercesc_2_8::XMLAttr::getValue(this = 0x18), line 486 in XMLAttr.hpp [2] xercesc_2_8::VecAttrListImpl::getValue(this = 0x4cc3e8, index = 1U), line 86 in VecAttrListImpl.cpp [3] 0xfd7ffeab6546(0x0, 0x0, 0x0, 0x0, 0x0, 0x0), at 0xfd7ffeab6545 [4] xercesc_2_8::SAXParser::startElement(this = 0x4cc3a8, elemDecl = CLASS, elemURLId = 1U, elemPrefix = 0xfd7ffe1bb3b0, attrList = CLASS, attrCount = 2U, isEmpty = false, isRoot = true), line 971 in SAXParser.cpp [5] xercesc_2_8::IGXMLScanner::scanStartTag(this = 0x4cd6b8, gotData = true), line 2101 in IGXMLScanner.cpp [6] xercesc_2_8::IGXMLScanner::scanContent(this = 0x4cd6b8), line 899 in IGXMLScanner.cpp [7] xercesc_2_8::IGXMLScanner::scanDocument(this = 0x4cd6b8, src = CLASS), line 215 in IGXMLScanner.cpp [8] xercesc_2_8::XMLScanner::scanDocument(this = 0x4cd6b8, systemId = 0x4d4530), line 460 in XMLScanner.cpp [9] xercesc_2_8::XMLScanner::scanDocument(this = 0x4cd6b8, systemId = 0x4c7f68 ../dats/adr3xml.dat), line 468 in XMLScanner.cpp [10] xercesc_2_8::SAXParser::parse(this = 0x4cc3a8, systemId = 0x4c7f68 ../dats/adr3xml.dat), line 587 in SAXParser.cpp -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: c-dev-unsubscr...@xerces.apache.org For additional commands, e-mail: c-dev-h...@xerces.apache.org
[jira] Closed: (XERCESC-1909) Need information on Exception Handling mechanism used in Log4Net project
[ https://issues.apache.org/jira/browse/XERCESC-1909?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Boris Kolpackov closed XERCESC-1909. Resolution: Invalid Please ask questions on the mailing list instead of filing a bug report: http://xerces.apache.org/xerces-c/mailing-lists.html Need information on Exception Handling mechanism used in Log4Net project - Key: XERCESC-1909 URL: https://issues.apache.org/jira/browse/XERCESC-1909 Project: Xerces-C++ Issue Type: Task Affects Versions: 1.6.0 Environment: XP Reporter: Rajat Raina Fix For: 1.6.0 I need some information as we are working on a common Exception handling framework for all our code. Can you please let me know if Xerces-C++ dll defines any Exception filters through the usage of Microsoft's SetUnhandledExceptionFilter? I need this information for my common exception handling framework designing. Please let me know! Thanks! -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: c-dev-unsubscr...@xerces.apache.org For additional commands, e-mail: c-dev-h...@xerces.apache.org
[jira] Created: (XERCESC-1907) PDB file name for static 64-bit debug builds in VC8 and VC9 project files are not library specific
PDB file name for static 64-bit debug builds in VC8 and VC9 project files are not library specific -- Key: XERCESC-1907 URL: https://issues.apache.org/jira/browse/XERCESC-1907 Project: Xerces-C++ Issue Type: Bug Components: Build Affects Versions: 3.1.0 Environment: Windows Reporter: Boris Kolpackov Priority: Minor The PDB file for static 64-bit debug builds in VC8 and VC9 project files are still names xerceslib_vc80.pdb. We have fixed this for 32-bit builds but not for 64-bit, for some reason. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: c-dev-unsubscr...@xerces.apache.org For additional commands, e-mail: c-dev-h...@xerces.apache.org
[jira] Closed: (XERCESC-1904) Cannot build shared library from xerces-c 3.0.1 on AIX6.1 with xlC V10.1
[ https://issues.apache.org/jira/browse/XERCESC-1904?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Boris Kolpackov closed XERCESC-1904. Resolution: Fixed Fix Version/s: 3.1.0 Assuming fixed in the just-released 3.1.0. Cannot build shared library from xerces-c 3.0.1 on AIX6.1 with xlC V10.1 Key: XERCESC-1904 URL: https://issues.apache.org/jira/browse/XERCESC-1904 Project: Xerces-C++ Issue Type: Bug Components: Build Affects Versions: 3.0.1 Environment: OS : AIX 6.1 TL3 SP1 Compiler: IBM XL C/C++ Enterprise Edition for AIX, V10.1 Reporter: Gauthier Helin Priority: Blocker Fix For: 3.1.0 Attachments: config.log, config.log_3.1.0 Hello, I cannot build the xerces 3.0.1 shared library on AIX 6.1 with xlC 10.1. It always produce the static library even if I specify --enable-shared=yes. I tried may different ./configure and gmake options without any success. here is some output of the ./configure which shows that it thinks that the linker does not support shared libs : checking if xlc_r supports -c -o file.o... yes checking whether the xlc_r linker (/usr/bin/ld) supports shared libraries... no checking dynamic linker characteristics... no checking how to hardcode library paths into programs... unsupported checking whether stripping libraries is possible... no checking if libtool supports shared libraries... no checking whether to build shared libraries... no checking whether to build static libraries... yes configure: creating libtool appending configuration tag CXX to libtool checking whether the xlC_r linker (/usr/bin/ld) supports shared libraries... no checking for xlC_r option to produce PIC... checking if xlC_r static flag works... yes checking if xlC_r supports -c -o file.o... yes checking whether the xlC_r linker (/usr/bin/ld) supports shared libraries... no checking dynamic linker characteristics... no (cached) (cached) checking how to hardcode library paths into programs... unsupported appending configuration tag F77 to libtool checking whether xlc_r and cc understand -c and -o together... yes the command line used was : ./configure --prefix=$PREFIX CXX=xlC_r CC=xlc_r --enable-shared=yes gmake libxerces_c_la_LDFLAGS=-qmkshrobj This was working fine on AIX 5.3 with xlC 7 Thanks a lot for any help. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: c-dev-unsubscr...@xerces.apache.org For additional commands, e-mail: c-dev-h...@xerces.apache.org
[jira] Created: (XERCESC-1906) Double checked locking using in RangeTokenMap::getRange
Double checked locking using in RangeTokenMap::getRange --- Key: XERCESC-1906 URL: https://issues.apache.org/jira/browse/XERCESC-1906 Project: Xerces-C++ Issue Type: Bug Components: Utilities Affects Versions: 3.1.0 Reporter: Boris Kolpackov This pattern is invalid on modern CPUs. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: c-dev-unsubscr...@xerces.apache.org For additional commands, e-mail: c-dev-h...@xerces.apache.org
[jira] Commented: (XERCESC-1904) Cannot build shared library from xerces-c 3.0.1 on AIX6.1 with xlC V10.1
[ https://issues.apache.org/jira/browse/XERCESC-1904?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12802346#action_12802346 ] Boris Kolpackov commented on XERCESC-1904: -- To fix 3.0.1 you will need to install a fairly recent versions of autotools (automake, autoconf, and libtool) and run the reconf script in the root directory of the Xerces-C++ distribution (you can do it on a machine other than your AIX box). Regarding optimization, I am not sure what is the default debug/optimize setting for XLC in autotools. I know for g++ it is -g -O2. But you can always override this on the configure command line: ./configure CFLAGS=-O2 CXXFLAGS=-O2 I tend to think that the core dump with optimization enabled is a bug in XLC. Cannot build shared library from xerces-c 3.0.1 on AIX6.1 with xlC V10.1 Key: XERCESC-1904 URL: https://issues.apache.org/jira/browse/XERCESC-1904 Project: Xerces-C++ Issue Type: Bug Components: Build Affects Versions: 3.0.1 Environment: OS : AIX 6.1 TL3 SP1 Compiler: IBM XL C/C++ Enterprise Edition for AIX, V10.1 Reporter: Gauthier Helin Priority: Blocker Attachments: config.log, config.log_3.1.0 Hello, I cannot build the xerces 3.0.1 shared library on AIX 6.1 with xlC 10.1. It always produce the static library even if I specify --enable-shared=yes. I tried may different ./configure and gmake options without any success. here is some output of the ./configure which shows that it thinks that the linker does not support shared libs : checking if xlc_r supports -c -o file.o... yes checking whether the xlc_r linker (/usr/bin/ld) supports shared libraries... no checking dynamic linker characteristics... no checking how to hardcode library paths into programs... unsupported checking whether stripping libraries is possible... no checking if libtool supports shared libraries... no checking whether to build shared libraries... no checking whether to build static libraries... yes configure: creating libtool appending configuration tag CXX to libtool checking whether the xlC_r linker (/usr/bin/ld) supports shared libraries... no checking for xlC_r option to produce PIC... checking if xlC_r static flag works... yes checking if xlC_r supports -c -o file.o... yes checking whether the xlC_r linker (/usr/bin/ld) supports shared libraries... no checking dynamic linker characteristics... no (cached) (cached) checking how to hardcode library paths into programs... unsupported appending configuration tag F77 to libtool checking whether xlc_r and cc understand -c and -o together... yes the command line used was : ./configure --prefix=$PREFIX CXX=xlC_r CC=xlc_r --enable-shared=yes gmake libxerces_c_la_LDFLAGS=-qmkshrobj This was working fine on AIX 5.3 with xlC 7 Thanks a lot for any help. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: c-dev-unsubscr...@xerces.apache.org For additional commands, e-mail: c-dev-h...@xerces.apache.org
[jira] Commented: (XERCESC-1904) Cannot build shared library from xerces-c 3.0.1 on AIX6.1 with xlC V10.1
[ https://issues.apache.org/jira/browse/XERCESC-1904?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12801828#action_12801828 ] Boris Kolpackov commented on XERCESC-1904: -- Gauthier, can you also ry to build 3.1.0.rc1 which you can download from here: http://people.apache.org/builds/xerces/c/ It uses newer versions of autotools which may help. Cannot build shared library from xerces-c 3.0.1 on AIX6.1 with xlC V10.1 Key: XERCESC-1904 URL: https://issues.apache.org/jira/browse/XERCESC-1904 Project: Xerces-C++ Issue Type: Bug Components: Build Affects Versions: 3.0.1 Environment: OS : AIX 6.1 TL3 SP1 Compiler: IBM XL C/C++ Enterprise Edition for AIX, V10.1 Reporter: Gauthier Helin Priority: Blocker Attachments: config.log Hello, I cannot build the xerces 3.0.1 shared library on AIX 6.1 with xlC 10.1. It always produce the static library even if I specify --enable-shared=yes. I tried may different ./configure and gmake options without any success. here is some output of the ./configure which shows that it thinks that the linker does not support shared libs : checking if xlc_r supports -c -o file.o... yes checking whether the xlc_r linker (/usr/bin/ld) supports shared libraries... no checking dynamic linker characteristics... no checking how to hardcode library paths into programs... unsupported checking whether stripping libraries is possible... no checking if libtool supports shared libraries... no checking whether to build shared libraries... no checking whether to build static libraries... yes configure: creating libtool appending configuration tag CXX to libtool checking whether the xlC_r linker (/usr/bin/ld) supports shared libraries... no checking for xlC_r option to produce PIC... checking if xlC_r static flag works... yes checking if xlC_r supports -c -o file.o... yes checking whether the xlC_r linker (/usr/bin/ld) supports shared libraries... no checking dynamic linker characteristics... no (cached) (cached) checking how to hardcode library paths into programs... unsupported appending configuration tag F77 to libtool checking whether xlc_r and cc understand -c and -o together... yes the command line used was : ./configure --prefix=$PREFIX CXX=xlC_r CC=xlc_r --enable-shared=yes gmake libxerces_c_la_LDFLAGS=-qmkshrobj This was working fine on AIX 5.3 with xlC 7 Thanks a lot for any help. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: c-dev-unsubscr...@xerces.apache.org For additional commands, e-mail: c-dev-h...@xerces.apache.org
[jira] Commented: (XERCESC-1903) xerces-c-3.1.0-rc1: possible API change?
[ https://issues.apache.org/jira/browse/XERCESC-1903?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12795119#action_12795119 ] Boris Kolpackov commented on XERCESC-1903: -- We can also ask the XQilla folks to release 2.2.3 or some such to resolve this once 3.1.0 is out. xerces-c-3.1.0-rc1: possible API change? Key: XERCESC-1903 URL: https://issues.apache.org/jira/browse/XERCESC-1903 Project: Xerces-C++ Issue Type: Bug Affects Versions: 3.1.0 Environment: debian Reporter: Jay Berkenbilt A debian user reports trouble compiling xqilla 2.2.2 (http://xqilla.sourceforge.net) with xerces-c 3.1.0 rc1 but says that it does compile with 3.0.1. We exchanged a few messages, but neither one of us is sure whether the code in question is using an internal interface that is not supposed to be part of the public API or whether this is an unintentional API incompatibility. I'm including the text of our latest email exchange here so you can make a judgment call on this before the final 3.1.0 is released. == I was compiling XQilla library version 2.2.2 from http://xqilla.sourceforge.net against Xerces-C in Debian, when I noticed that the xqilla library cannot be compiled against libxerces-c-dev 3.1.0~rc1, but it can compiled against version 3.0.1 still in testing. So it seems that version 3.1 breaks API compatibility. Are you and/or upstream developers aware of this? Is this actually a bug that I should report against libxerces-c-dev or not? I'm not aware of any expected API changes between 3.0.1 and 3.1.0, but I haven't checked with upstream. I believe the intention is not to introduce API compatibilities though. Please go ahead and file a bug against the debian package. Obviously any specific details you can provide would be helpful. I will then forward it to upstream. Thanks for bringing this to my attention! Hi, I looked now the error messages a bit more to see what was changed, and noticed that those API breaks are in a class definition in the subdir internal. Thus I now wonder if it counts as API break that would in the interest of the developers. Here is the compiler error I got: src/schema/SchemaValidatorFilter.cpp: In member function 'virtual unsigned int SchemaValidatorFilter::resolveQName(const XMLCh*, xercesc_3_1::XMLBuffer, short int, int)': src/schema/SchemaValidatorFilter.cpp:713: error: no matching function for call to 'xercesc_3_1::ElemStack::mapPrefixToURI(const XMLCh [], xercesc_3_1::ElemStack::MapModes, bool)' /usr/include/xercesc/internal/ElemStack.hpp:190: note: candidates are: unsigned int xercesc_3_1::ElemStack::mapPrefixToURI(const XMLCh*, bool) const src/schema/SchemaValidatorFilter.cpp:729: error: no matching function for call to 'xercesc_3_1::ElemStack::mapPrefixToURI(XMLCh*, xercesc_3_1::ElemStack::MapModes, bool)' /usr/include/xercesc/internal/ElemStack.hpp:190: note: candidates are: unsigned int xercesc_3_1::ElemStack::mapPrefixToURI(const XMLCh*, bool) const -- Tommi Vainikainen -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: c-dev-unsubscr...@xerces.apache.org For additional commands, e-mail: c-dev-h...@xerces.apache.org
[jira] Created: (XERCESC-1902) Stray newline if pretty-printing without xml declaration
Stray newline if pretty-printing without xml declaration Key: XERCESC-1902 URL: https://issues.apache.org/jira/browse/XERCESC-1902 Project: Xerces-C++ Issue Type: Bug Components: DOM Affects Versions: 3.1.0 Reporter: Boris Kolpackov Priority: Minor If we disable writing xml declaration and enable pretty printing, we get a stray newline at the beginning of the document: ' root ... /root ' -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: c-dev-unsubscr...@xerces.apache.org For additional commands, e-mail: c-dev-h...@xerces.apache.org
[jira] Commented: (XERCESC-1901) memory address leak when running many threads which will parsing xml files
[ https://issues.apache.org/jira/browse/XERCESC-1901?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12790307#action_12790307 ] Boris Kolpackov commented on XERCESC-1901: -- I ran your test under valgrind. While there are a number of leaks in it (e.g., you don't free ACE task), none of them are Xerces-C++ related (output below). Can you run valgrind and see what you get? All thread exit ==19096== ==19096== ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 9 from 1) ==19096== malloc/free: in use at exit: 19,381 bytes in 24 blocks. ==19096== malloc/free: 30,730 allocs, 30,706 frees, 50,514,225 bytes allocated. ==19096== For counts of detected errors, rerun with: -v ==19096== searching for pointers to 24 not-freed blocks. ==19096== checked 677,216 bytes. ==19096== ==19096== 8 bytes in 1 blocks are still reachable in loss record 1 of 15 ==19096==at 0x4C232DC: operator new(unsigned long) (vg_replace_malloc.c:230) ==19096==by 0x54DB6B6: ACE_TSSACE_Service_Config::TSS_Resources::make_TSS_TYPE() const (TSS_T.cpp:60) ==19096==by 0x54DB4D6: ACE_TSSACE_Service_Config::TSS_Resources::ts_get() const (TSS_T.cpp:219) ==19096==by 0x54DB1DA: ACE_TSSACE_Service_Config::TSS_Resources::operator ACE_Service_Config::TSS_Resources*() const (TSS_T.cpp:53) ==19096==by 0x54DA333: ACE_Service_Config::current_i(ACE_Service_Gestalt*) (Service_Config.cpp:378) ==19096==by 0x54DA196: ACE_Service_Config::current() (Service_Config.cpp:354) ==19096==by 0x54DA35C: ACE_Service_Config::static_svcs() (Service_Config.cpp:394) ==19096==by 0x5542060: ACE_Object_Manager_Preallocations::ACE_Object_Manager_Preallocations() (Object_Manager.cpp:134) ==19096==by 0x55428B2: ACE_Object_Manager::init() (Object_Manager.cpp:257) ==19096==by 0x5542C33: ACE_Object_Manager::ACE_Object_Manager() (Object_Manager.cpp:313) ==19096==by 0x5542E90: ACE_Object_Manager::instance() (Object_Manager.cpp:333) ==19096==by 0x5543D97: ACE_Object_Manager_Manager::ACE_Object_Manager_Manager() (Object_Manager.cpp:758) ==19096== ==19096== ==19096== 64 bytes in 1 blocks are still reachable in loss record 2 of 15 ==19096==at 0x4C232DC: operator new(unsigned long) (vg_replace_malloc.c:230) ==19096==by 0x54DA286: ACE_Service_Config::current_i(ACE_Service_Gestalt*) (Service_Config.cpp:375) ==19096==by 0x54DA196: ACE_Service_Config::current() (Service_Config.cpp:354) ==19096==by 0x54DA35C: ACE_Service_Config::static_svcs() (Service_Config.cpp:394) ==19096==by 0x5542060: ACE_Object_Manager_Preallocations::ACE_Object_Manager_Preallocations() (Object_Manager.cpp:134) ==19096==by 0x55428B2: ACE_Object_Manager::init() (Object_Manager.cpp:257) ==19096==by 0x5542C33: ACE_Object_Manager::ACE_Object_Manager() (Object_Manager.cpp:313) ==19096==by 0x5542E90: ACE_Object_Manager::instance() (Object_Manager.cpp:333) ==19096==by 0x5543D97: ACE_Object_Manager_Manager::ACE_Object_Manager_Manager() (Object_Manager.cpp:758) ==19096==by 0x5543FC4: __static_initialization_and_destruction_0(int, int) (Object_Manager.cpp:774) ==19096==by 0x554400C: global constructors keyed to _ZN18ACE_Object_Manager9instance_E (Object_Manager.cpp:855) ==19096==by 0x5596A45: (within /home/boris/work/ace/ACE-5.5.2/ace/libACE.so.5.5.2) ==19096== ==19096== ==19096== 72 bytes in 1 blocks are still reachable in loss record 3 of 15 ==19096==at 0x4C232DC: operator new(unsigned long) (vg_replace_malloc.c:230) ==19096==by 0x54E2803: ACE_Service_Repository::instance(unsigned long) (Service_Repository.cpp:63) ==19096==by 0x54DCC99: ACE_Service_Gestalt::ACE_Service_Gestalt(unsigned long, bool, bool) (Service_Gestalt.cpp:243) ==19096==by 0x54DA4AE: ACE_Service_Config::ACE_Service_Config(int, unsigned long, int) (Service_Config.cpp:447) ==19096==by 0x54DB40F: ACE_SingletonACE_Service_Config, ACE_Thread_Mutex::ACE_Singleton() (Singleton.inl:14) ==19096==by 0x54DAF9D: ACE_SingletonACE_Service_Config, ACE_Thread_Mutex::instance() (Singleton.cpp:77) ==19096==by 0x54DA084: ACE_Service_Config::global() (Service_Config.cpp:284) ==19096==by 0x54DA18E: ACE_Service_Config::current() (Service_Config.cpp:354) ==19096==by 0x54DA35C: ACE_Service_Config::static_svcs() (Service_Config.cpp:394) ==19096==by 0x5542060: ACE_Object_Manager_Preallocations::ACE_Object_Manager_Preallocations() (Object_Manager.cpp:134) ==19096==by 0x55428B2: ACE_Object_Manager::init() (Object_Manager.cpp:257) ==19096==by 0x5542C33: ACE_Object_Manager::ACE_Object_Manager() (Object_Manager.cpp:313) ==19096== ==19096== ==19096== 80 bytes in 1 blocks are still reachable in loss record 4 of 15 ==19096==at 0x4C232DC: operator new(unsigned long) (vg_replace_malloc.c:230) ==19096==by 0x54DAF90: ACE_SingletonACE_Service_Config, ACE_Thread_Mutex::instance() (Singleton.cpp:77) ==19096==by 0x54DA084:
[jira] Closed: (XERCESC-1900) Compile xerces.dll using /MT to remove the dependency on msvcr90.dll
[ https://issues.apache.org/jira/browse/XERCESC-1900?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Boris Kolpackov closed XERCESC-1900. Resolution: Invalid Closing this issue. Compile xerces.dll using /MT to remove the dependency on msvcr90.dll Key: XERCESC-1900 URL: https://issues.apache.org/jira/browse/XERCESC-1900 Project: Xerces-C++ Issue Type: Improvement Components: Build Affects Versions: 3.0.1 Environment: Windows OS. Reporter: David Wendt Priority: Trivial The xerces-c_3_0.dll requires msvc90.dll to be installed. We have found that some of our customers do not have the msvcr90.dll installed on their machines. Changing the compile flag from /MD to /MT for the Release configuration will remove the dependency (compiles all needed C-runtime code into the xerces DLL itself). The result is a 90KB bigger DLL which is only about 6% increase in size. I can provide the modified .vcproj. Another option is to create a separate Release configuration with this compile option too. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: c-dev-unsubscr...@xerces.apache.org For additional commands, e-mail: c-dev-h...@xerces.apache.org
[jira] Updated: (XERCESC-1881) xsd sequence validation reporting errors too late
[
https://issues.apache.org/jira/browse/XERCESC-1881?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Boris Kolpackov updated XERCESC-1881:
-
Fix Version/s: (was: 3.1.0)
4.0.0
3.2.0
Rescheduling to 3.2.0/4.0.0.
xsd sequence validation reporting errors too late
-
Key: XERCESC-1881
URL: https://issues.apache.org/jira/browse/XERCESC-1881
Project: Xerces-C++
Issue Type: Bug
Components: Validating Parser (XML Schema)
Affects Versions: 3.0.1
Environment: Windows Visaa 32, Xerces 3.0.1
Reporter: Brian Hoyt
Fix For: 3.2.0, 4.0.0
Validation using the following xsd and xml results in two different results
between XercesJ and XercesC++.
For java I get the error reporting the sequence error right after the
processing of element url because name
cannot appear after url. But for C++ the error is not reported until the
last element within person has been
processed. This obviously isn't correct because by that time it is too late.
The way Java is reporting it seems to
be correct so that I can stop processing the xml file.
?xml version=1.0 encoding=UTF-8?
xs:schema xmlns:xs='http://www.w3.org/2001/XMLSchema'
xs:element name=person
xs:complexType
xs:sequence
xs:element name=name type='xs:string' minOccurs='0'
maxOccurs='1'/
xs:element name=email type='xs:string' minOccurs='0'
maxOccurs='unbounded'/
xs:element name=urltype='xs:string' minOccurs='0'
maxOccurs='unbounded'/
xs:element name=link type='xs:string' minOccurs='0'
maxOccurs='1'/
/xs:sequence
/xs:complexType
/xs:element
/xs:schema
?xml version=1.0 encoding=UTF-8?
person xmlns:xsi=http://www.w3.org/2001/XMLSchema-instance;
xsi:noNamespaceSchemaLocation='foo.xsd'
urlwww.foo.com/url
nameBoss/name
emailch...@foo.com/email
link/
/person
The output from running the XercesJ 2.9.1 Writer sample on the above xsd/xml
is:
person xsi:noNamespaceSchemaLocation=foo.xsd
urlwww.foo.com/url
[Error] foo.xml:5:11: cvc-complex-type.2.4.a: Invalid content was found
star
ting with element 'name'. One of '{url, link}' is expected.
nameBoss/name
emailch...@foo.com/email
link/link
/person
The output from running the XercesC++ 3.0.1
?xml version=1.0 encoding=LATIN1?
person xsi:noNamespaceSchemaLocation=foo.xsd
urlwww.foo.com/url
nameBoss/name
emailch...@foo.com/email
link/link
Error at file C:\xerces-3_0_1\bin/foo.xml, line 8, char 10
Message: element 'name' is not allowed for content model
'((name,email,url),li
nk)'
/person
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
-
To unsubscribe, e-mail: c-dev-unsubscr...@xerces.apache.org
For additional commands, e-mail: c-dev-h...@xerces.apache.org
[jira] Closed: (XERCESC-1659) Order sensitivity in schemaLocation and noNamespaceSchemaLocation
[ https://issues.apache.org/jira/browse/XERCESC-1659?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Boris Kolpackov closed XERCESC-1659. Resolution: Fixed The fix is in SVN. All test cases now pass with multi-import support enabled. Order sensitivity in schemaLocation and noNamespaceSchemaLocation - Key: XERCESC-1659 URL: https://issues.apache.org/jira/browse/XERCESC-1659 Project: Xerces-C++ Issue Type: Bug Components: Validating Parser (XML Schema) Affects Versions: 3.1.0 Environment: all Reporter: Boris Kolpackov Assignee: Boris Kolpackov Fix For: 3.1.0 Attachments: test-case-1.tar.gz, test-case-2.tar.gz I am attaching two test cases (each consists of 3 schemas plus an XML instance). If you try to run domprint on the first test case, you will get the following error: $ domprint -v=always -n -s -f test-users.xml Error at file test-users.xml, line 6, column 78 Message: Unknown element 'b:UserDatabase' If you change the order of the schemaLocation and noNamespaceSchemaLocation attributes in test-users.xml then the error disappears. The second test case is a slight modification of the first test case with the only difference being the schemas with targetNamespace are now do not have a namespace, and the schema that used to be without a namespace (derived-user-config.xsd) now is in a namespace. If you run domprint on this test case, you will get the following error: $ domprint -v=always -n -s -f test-users.xml Error at file test-users.xml, line 6, column 55 Message: Unknown element 'UserDatabase' This seems to prove that for Xerces-C++, for some reason, it is important that the schema that declares the root element is mentioned in the first *Location attribute (nor matter whether schemaLocation or noNamespaceSchemaLocation). Now comes the surprise: if we reverse the order of the two attributes in the second test case, domprint terminates with segmentation fault. Examination of the core points to the IGXMLScanner.cpp, line 2288: elemDecl = fGrammar-getElemDecl( uriId, nameRawBuf, qnameRawBuf, currentScope ); -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: c-dev-unsubscr...@xerces.apache.org For additional commands, e-mail: c-dev-h...@xerces.apache.org
[jira] Updated: (XERCESC-1754) Invalid restriction error on valid schema
[ https://issues.apache.org/jira/browse/XERCESC-1754?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Boris Kolpackov updated XERCESC-1754: - Affects Version/s: (was: 2.8.0) 3.1.0 The problem still present in the 3.1.0 codebase. Invalid restriction error on valid schema - Key: XERCESC-1754 URL: https://issues.apache.org/jira/browse/XERCESC-1754 Project: Xerces-C++ Issue Type: Bug Components: Validating Parser (XML Schema) Affects Versions: 3.1.0 Environment: any Reporter: Boris Kolpackov Attachments: test.xsd In the attached schema, maxOccurs=1 in the sequence compositor causes Xerces-C++ to report this schema as invalid. Changing it to 2 gets rid of the error. The same problem exist in minOccurs=0 to minOccurs=1 restriction. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: c-dev-unsubscr...@xerces.apache.org For additional commands, e-mail: c-dev-h...@xerces.apache.org
[jira] Updated: (XERCESC-1544) xsd:redefine recently broken
[ https://issues.apache.org/jira/browse/XERCESC-1544?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Boris Kolpackov updated XERCESC-1544: - Affects Version/s: (was: 2.7.0) 3.1.0 Still present in the 3.1.0 codebase. xsd:redefine recently broken Key: XERCESC-1544 URL: https://issues.apache.org/jira/browse/XERCESC-1544 Project: Xerces-C++ Issue Type: Bug Components: Validating Parser (XML Schema) Affects Versions: 3.1.0 Environment: MacOS X, g++ build Reporter: Jerry Carter Attachments: redefine1.xsd, redefine2.xsd, redefine3.xml, redefine3.xsd The W3C schema for VoiceXML is quite complex and makes a good test of Xerces. Previous versions worked well, but 2.7.0 has some problems. In addition the regexp issues (bug 1512), xsd:redefine is also broken. This has worked in previous versions (up through 2.6.0, I believe). The main VXML schema http://www.w3.org/TR/voicexml21/vxml.xsd eventually includes http://www.w3.org/TR/voicexml21/vxml-synthesis-extension.xsd. There, on line 28 is the problem statement: xsd:redefine schemaLocation=vxml-synthesis-restriction.xsd This generates two classes of error messages. 1: Message: Could not find a declaration in the schema to be redefined corresponding to '...' 2: Message: Global complexType:'...' declared more than once or also declared as simpleType -- To reproduce, run the following lines through SAX2Print: ?xml version=1.0 encoding=UTF-8? vxml version=2.1 xmlns=http://www.w3.org/2001/vxml; xmlns:xsi=http://www.w3.org/2001/XMLSchema-instance; xsi:schemaLocation=http://www.w3.org/2001/vxml http://www.w3.org/TR/voicexml21/vxml.xsd; form block exit/ /block /form /vxml xerces-c-src_2_7_0/bin: ./SAX2Print -v=always schema_issue.xml ?xml version=1.0 encoding=LATIN1? Error at file http://www.w3.org/TR/voicexml21/vxml-synthesis-restriction.xsd, line 30, char 53 Message: Could not find a declaration in the schema to be redefined corresponding to 'say-as' Error at file http://www.w3.org/TR/voicexml21/vxml-synthesis-restriction.xsd, line 43, char 52 Message: Could not find a declaration in the schema to be redefined corresponding to 'audio' Error at file http://www.w3.org/TR/voicexml21/vxml-synthesis-restriction.xsd, line 55, char 38 Message: Could not find a declaration in the schema to be redefined corresponding to 'mark' Error at file http://www.w3.org/TR/voicexml21/vxml-synthesis-extension.xsd, line 30, char 53 Message: Global complexType:'say-as' declared more than once or also declared as simpleType Error at file http://www.w3.org/TR/voicexml21/vxml-synthesis-extension.xsd, line 43, char 52 Message: Global complexType:'audio' declared more than once or also declared as simpleType Error at file http://www.w3.org/TR/voicexml21/vxml-synthesis-extension.xsd, line 55, char 38 Message: Global complexType:'mark' declared more than once or also declared as simpleType vxml version=2.1 xsi:schemaLocation=http://www.w3.org/2001/vxml http://www.w3.org/TR/voicexml21/vxml.xsd; form scope=dialog block exit/exit /block /form -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: c-dev-unsubscr...@xerces.apache.org For additional commands, e-mail: c-dev-h...@xerces.apache.org
[jira] Closed: (XERCESC-1627) Schema validator sensitive to the order of xsd:import and xsd:include elements.
[ https://issues.apache.org/jira/browse/XERCESC-1627?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Boris Kolpackov closed XERCESC-1627. Resolution: Fixed Fix Version/s: 3.1.0 With the multiple import enabled, I get the same output with the original schema and with the swapped include/import. There are some other schema and validation errors but I am assuming the original bug is fixed. Schema validator sensitive to the order of xsd:import and xsd:include elements. --- Key: XERCESC-1627 URL: https://issues.apache.org/jira/browse/XERCESC-1627 Project: Xerces-C++ Issue Type: Bug Components: Validating Parser (XML Schema) Affects Versions: 2.5.0, 2.6.0, 2.7.0 Environment: Windows XP SR2 Reporter: Peter Aberline Priority: Minor Fix For: 3.1.0 Attachments: schema_validator_bug.zip Xerces validating schema parser appears to be intolerant of the order of xsd:import and xsd:include elements. This can be demonstrated with the the DOMCount program: DOMCount -s -n -v=always CSW_caps.xml This causes validation errors by the schema validator unable to resolve types included in owsGetCapabilities. Swapping the order of the xsd:include to after the xsd:import (lines 22-25 of CSW-discovery.xsd) solves the validation error. The fragment of XMLSchema.xsd shown below suggests to me that import and include elements can be in any order? http://www.w3.org/2001/XMLSchema.xsd: xs:element name=schema id=schema xs:annotation xs:documentation source=http://www.w3.org/TR/xmlschema-1/#element-schema/ /xs:annotation xs:complexType xs:complexContent xs:extension base=xs:openAttrs xs:sequence xs:choice minOccurs=0 maxOccurs=unbounded xs:element ref=xs:include/ xs:element ref=xs:import/ xs:element ref=xs:redefine/ xs:element ref=xs:annotation/ /xs:choice xs:sequence minOccurs=0 maxOccurs=unbounded xs:group ref=xs:schemaTop/ xs:element ref=xs:annotation minOccurs=0 maxOccurs=unbounded/ /xs:sequence ... ... /xs:sequence /xs:extension /xs:complexContent /xs:complexType /xs:element -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: c-dev-unsubscr...@xerces.apache.org For additional commands, e-mail: c-dev-h...@xerces.apache.org
[jira] Updated: (XERCESC-1703) Bad error description reported by xerces
[
https://issues.apache.org/jira/browse/XERCESC-1703?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Boris Kolpackov updated XERCESC-1703:
-
Priority: Major (was: Minor)
Affects Version/s: (was: 2.6.0)
3.1.0
Fix Version/s: 3.1.0
Issue Type: Bug (was: Improvement)
Bug is still present in the 3.1.0 codebase. Would be nice to fix for 3.1.0.
Bad error description reported by xerces
Key: XERCESC-1703
URL: https://issues.apache.org/jira/browse/XERCESC-1703
Project: Xerces-C++
Issue Type: Bug
Components: Validating Parser (XML Schema)
Affects Versions: 3.1.0
Environment: all platforms
Reporter: Anton Nikolaevsky
Fix For: 3.1.0
xml:
date/
xsd:
xsd:schema xmlns:xsd=http://www.w3.org/2001/XMLSchema;
xsd:element name=date type=xsd:dateTime/
/xsd:schema
Observed: error Datatype error: Type:SchemaDateTimeException, Message:buffer
not initialized
yet!.
Expected error message: something like '' is not a valid value for the type
{http://www.w3.org/2001/XMLSchema}dateTime;
An exception is thrown at XMLDateTime.hpp[411] from
XMLDateTime::assertBuffer() invoked by XMLDateTime::initParser().
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
-
To unsubscribe, e-mail: c-dev-unsubscr...@xerces.apache.org
For additional commands, e-mail: c-dev-h...@xerces.apache.org
[jira] Updated: (XERCESC-1884) Anytype prevent identity constraint application
[ https://issues.apache.org/jira/browse/XERCESC-1884?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Boris Kolpackov updated XERCESC-1884: - Priority: Major (was: Minor) Affects Version/s: (was: 2.7.0) 3.1.0 The problem is still present in the 3.1.0 codebase. Anytype prevent identity constraint application --- Key: XERCESC-1884 URL: https://issues.apache.org/jira/browse/XERCESC-1884 Project: Xerces-C++ Issue Type: Bug Components: Validating Parser (XML Schema) Affects Versions: 3.1.0 Environment: Linux 2.6.5-7.244-smp x86_64 GNU/Linux Reporter: Thomas Carcaud Attachments: anytype_prevent_id_constraint.xml, anytype_prevent_id_constraint.xsd ID declaration is not found when it is enclosed in two levels of anytype elements. In this example : ?xml version=1.0 encoding=utf-8? xs:schema xmlns:xs=http://www.w3.org/2001/XMLSchema; elementFormDefault=qualified xs:element name=bigBadWolf xs:complexType xs:sequence maxOccurs=unbounded xs:element name=eat xs:complexType xs:attribute name=ref type=xs:IDREF/ /xs:complexType /xs:element /xs:sequence /xs:complexType /xs:element xs:element name=littlePig xs:complexType xs:attribute name=id type=xs:ID/ /xs:complexType /xs:element xs:element name=world xs:complexType xs:all xs:element name=strawHouse/ xs:element name=stickHouse/ xs:element name=brickHouse/ xs:element ref=bigBadWolf/ /xs:all /xs:complexType /xs:element /xs:schema ?xml version=1.0 encoding=UTF-8? world xmlns:xsi=http://www.w3.org/2001/XMLSchema-instance; xsi:noNamespaceSchemaLocation=anytype_prevent_id_constraint.xsd strawHouse littlePig id=first/ /strawHouse stickHouse littlePig id=second/ /stickHouse brickHouse thickWall littlePig id=third/ /thickWall /brickHouse bigBadWolf eat ref=first/ eat ref=second/ eat ref=third/ /bigBadWolf /world Validation fails with error ID attribute 'third' was referenced but never declared. Same kind of problem can be reproduced with unique/key and keyref and it also prevent duplicate id detection. From my investigations in IGXMLScanner , at the brickHouse level, modelType == SchemaElementDecl::Any will set laxThisOne to true. Then at the thickWall level, laxThisOne set fValidate to false. And this disable the call to fICHandler-activateIdentityConstraint. My text editor using XercesJ 2.9.1 does not suffer from this bug. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: c-dev-unsubscr...@xerces.apache.org For additional commands, e-mail: c-dev-h...@xerces.apache.org
[jira] Updated: (XERCESC-1866) Crash with regular expression
[
https://issues.apache.org/jira/browse/XERCESC-1866?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Boris Kolpackov updated XERCESC-1866:
-
Fix Version/s: (was: 3.1.0)
4.0.0
3.2.0
I have committed the attached patch for 3.1.0. I am leaving this bug open and
rescheduling it for 3.2.0/4.0.0 since this seems to be a temporary fix.
Crash with regular expression
-
Key: XERCESC-1866
URL: https://issues.apache.org/jira/browse/XERCESC-1866
Project: Xerces-C++
Issue Type: Bug
Components: Utilities
Environment: Windows XP, Visual Studio 2005
Reporter: Alexander Hartmann
Assignee: David Bertoni
Fix For: 3.2.0, 4.0.0
Attachments: XERCESC-1866.patch
when I run the following test code my application crashes on the second
regEx.matches call:
{
XMLBuffer optionsBuf;
optionsBuf.append('i');
optionsBuf.append('H');
RegularExpression regEx(L^\\W*Excel\\W*$, optionsBuf.getRawBuffer());
regEx.matches(Excel);
}
{
XMLBuffer optionsBuf;
optionsBuf.append('i');
optionsBuf.append('H');
RegularExpression regEx(L^\\W*Excel\\W*$, optionsBuf.getRawBuffer());
regEx.matches(Excel);
}
some details I found during debugging:
- there is an instance of RangeToken where I have no idea where this is
created. I've set a breakpoint in the constructor but the debugger does not
stop.
- when RangeToken::getCaseInsensitiveToken is called a new RangeToken is
created and stored in fCaseIToken
- when parsing is finished the newly created RangeToken is deleted (through
~RegularExpression - ~TokenFactory), but the original RangeToken (where I
don't know where it is created) still exists and references the deleted
RangeToken in fCaseIToken
- the next time RangeToken::getCaseInsensitiveToken is called the invalid
reference fCaseIToken is returned and this leads to a crash when it is
accessed.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
-
To unsubscribe, e-mail: c-dev-unsubscr...@xerces.apache.org
For additional commands, e-mail: c-dev-h...@xerces.apache.org
[jira] Closed: (XERCESC-1747) Schema validation fails on cpe schema
[ https://issues.apache.org/jira/browse/XERCESC-1747?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Boris Kolpackov closed XERCESC-1747. Resolution: Fixed Fix Version/s: 3.1.0 The fix is in SVN. Schema validation fails on cpe schema - Key: XERCESC-1747 URL: https://issues.apache.org/jira/browse/XERCESC-1747 Project: Xerces-C++ Issue Type: Bug Components: Validating Parser (XML Schema) Affects Versions: 2.7.0 Environment: windows, linux, osx, solaris Reporter: Paul Whitehurst Fix For: 3.1.0 Attachments: cpe-1.0.xsd, cpetest.xml Xerces C fails to validate against the CPE schema (http://cpe.mitre.org/) with an invalid URI error. Using the PParse test application I get the following error: Error at file C:\dev\test\schema\cpetest.xml, line 4, char 60 Message: Datatype error: Type:InvalidDatatypeValueException, Message:Value 'cpe://microsoft.windows:vista' is NOT a valid URI . -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: c-dev-unsubscr...@xerces.apache.org For additional commands, e-mail: c-dev-h...@xerces.apache.org
[jira] Closed: (XERCESC-1748) parsing registry based authorities in URI fails
[ https://issues.apache.org/jira/browse/XERCESC-1748?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Boris Kolpackov closed XERCESC-1748. Resolution: Fixed The fix is in SVN. parsing registry based authorities in URI fails --- Key: XERCESC-1748 URL: https://issues.apache.org/jira/browse/XERCESC-1748 Project: Xerces-C++ Issue Type: Bug Components: Validating Parser (XML Schema) Affects Versions: 3.0.1 Environment: Linux Reporter: G. Kramer Assignee: Boris Kolpackov Priority: Blocker Fix For: 3.1.0 Attachments: anyURITest.xml, anyURITest.xsd, xercesc-1748patch.txt validating documents against schema containing registry based authorities in anyURI typed attributes fails with: Message: Datatype error: Type:InvalidDatatypeValueException, Message:Value '...' is NOT a valid URI -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: c-dev-unsubscr...@xerces.apache.org For additional commands, e-mail: c-dev-h...@xerces.apache.org
[jira] Updated: (XERCESC-1854) Serialization does not detect invalid XML characters
[ https://issues.apache.org/jira/browse/XERCESC-1854?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Boris Kolpackov updated XERCESC-1854: - Fix Version/s: (was: 3.1.0) 4.0.0 3.2.0 Rescheduling for 3.2.0/4.0.0. Serialization does not detect invalid XML characters Key: XERCESC-1854 URL: https://issues.apache.org/jira/browse/XERCESC-1854 Project: Xerces-C++ Issue Type: Bug Components: DOM Affects Versions: 3.0.1 Reporter: Boris Kolpackov Fix For: 3.2.0, 4.0.0 Attachments: test.cxx The attached test case serializes an invalid XML 1.0 document that contains a character with value 0x04. See http://www.w3.org/TR/REC-xml/#NT-Char for the list of valid characters in an XML 1.0 document. I've done some digging and it seems that XMLFormatter should check for this. In fast, there is already code for XML 1.1 that checks for these control characters since they need to be escaped in 1.1. It looks like we need to check for invalid characters when in the 1.0 mode. There is the XMLChar1_0::isXMLChar() function which can presumably be used. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: c-dev-unsubscr...@xerces.apache.org For additional commands, e-mail: c-dev-h...@xerces.apache.org
[jira] Closed: (XERCESC-1826) XMLURL::makeNewStream() fails to decode file:/// URLs containing the (properly escaped) % character
[ https://issues.apache.org/jira/browse/XERCESC-1826?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Boris Kolpackov closed XERCESC-1826. Resolution: Fixed The fix is in SVN. XMLURL::makeNewStream() fails to decode file:/// URLs containing the (properly escaped) % character --- Key: XERCESC-1826 URL: https://issues.apache.org/jira/browse/XERCESC-1826 Project: Xerces-C++ Issue Type: Bug Components: Utilities Affects Versions: 2.5.0, 2.6.0, 2.7.0, 2.8.0, 3.0.0, 2.9.0, 3.1.0 Environment: Windows XP Prof. German, MS Visual Studio 2003 Reporter: Matteo Ceruti Assignee: Boris Kolpackov Fix For: 3.1.0 I truly believe that XMLURL::makeNewStream() (see src/xercesc/util/XMLURL.cpp) does not correctly handle file:///-URLs containing the escape-sequence %25 (that is the '%'-character itself). Consider you have a win32 filepath like C:\Documents\myfile_%_.xml . Its URL would be file:///C:/Documents/myfile_%25_.xml, right? But this URL is rejected by raising a MalformedURLException. makeNewStream() decodes the URL by searching and replacing the escape-sequences one by one. When it sucessfully replaced %25 by the '%'-character it continunes it's search for the next escape-sequence. The problem is, that it starts at the very position, where the last escape-sequence began. Therefore it suddenly finds a %-character again, because it had just been put there. This happens at least with xerces-c 2.5 and it seems that the current (revision=670359) http://svn.apache.org/viewvc/xerces/c/trunk/src/xercesc/util/XMLURL.cpp still has this problem. So probably other releases may have the same issue. I think the line percentIndex = XMLString::indexOf(realPath, chPercent, percentIndex, fMemoryManager); should be replaced by percentIndex = XMLString::indexOf(realPath, chPercent, percentIndex + 1, fMemoryManager); This works for me. Please correct me, if I'm wrong. Thank you in advance. Best regards, Matteo -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: c-dev-unsubscr...@xerces.apache.org For additional commands, e-mail: c-dev-h...@xerces.apache.org
[jira] Closed: (XERCESC-1703) Bad error description reported by xerces
[
https://issues.apache.org/jira/browse/XERCESC-1703?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Boris Kolpackov closed XERCESC-1703.
Resolution: Fixed
Assignee: Boris Kolpackov
The fix is in SVN.
Bad error description reported by xerces
Key: XERCESC-1703
URL: https://issues.apache.org/jira/browse/XERCESC-1703
Project: Xerces-C++
Issue Type: Bug
Components: Validating Parser (XML Schema)
Affects Versions: 3.1.0
Environment: all platforms
Reporter: Anton Nikolaevsky
Assignee: Boris Kolpackov
Fix For: 3.1.0
xml:
date/
xsd:
xsd:schema xmlns:xsd=http://www.w3.org/2001/XMLSchema;
xsd:element name=date type=xsd:dateTime/
/xsd:schema
Observed: error Datatype error: Type:SchemaDateTimeException, Message:buffer
not initialized
yet!.
Expected error message: something like '' is not a valid value for the type
{http://www.w3.org/2001/XMLSchema}dateTime;
An exception is thrown at XMLDateTime.hpp[411] from
XMLDateTime::assertBuffer() invoked by XMLDateTime::initParser().
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
-
To unsubscribe, e-mail: c-dev-unsubscr...@xerces.apache.org
For additional commands, e-mail: c-dev-h...@xerces.apache.org
[jira] Closed: (XERCESC-1263) Abstract type not handled correctly by cached grammar
[ https://issues.apache.org/jira/browse/XERCESC-1263?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Boris Kolpackov closed XERCESC-1263. Resolution: Fixed Assignee: Boris Kolpackov The fix is in SVN. Abstract type not handled correctly by cached grammar - Key: XERCESC-1263 URL: https://issues.apache.org/jira/browse/XERCESC-1263 Project: Xerces-C++ Issue Type: Bug Components: Validating Parser (XML Schema) Affects Versions: 3.1.0 Reporter: Matthew Berry Assignee: Boris Kolpackov Fix For: 3.1.0 Details: I have managed to narrow the problem I am having to a simple test case. In the schema, I have an abstract type defined and am using xsi:type with a concrete type in the data file. If I have a xsi:schemaLocation attribute in my data file, then the test Xml file passes the validation. (I have used DOMCount to verify this) If I remove xsi:schemaLocation and instead from my source code call loadGrammar() and setFeature(XMLUni::fgXercesUseCachedGrammarInParse, true), I am getting the following error messages: Message: Element paramInstance is declared with a type that is abstract. Use xsi:type to specify a non-abstract type Message: Attribute 'name' is not declared for element 'paramInstance' Schema: --- xsd:schema targetNamespace=http://www.temp.org; xmlns:tmp=http://www.temp.org; xmlns:xsd=http://www.w3.org/2001/XMLSchema; !-- Define a 'paramInstance' element NOTE: We use an abstract base to allow for extension -- xsd:complexType name=ParamInstanceType abstract=true / xsd:element name=paramInstance type=ParamInstanceType / !-- Specifying a concrete type -- xsd:complexType name=ConcreteParamInstance xsd:complexContent xsd:extension base=tmp:ParamInstanceType xsd:attribute name=name type=xsd:string use=required / /xsd:extension /xsd:complexContent /xsd:complexType /xsd:schema Test data file: --- paramInstance xmlns=http://www.temp.org; xmlns:xsi=http://www.w3.org/2001/XMLSchema-instance; xsi:type=ConcreteParamInstance name=param1 / -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: c-dev-unsubscr...@xerces.apache.org For additional commands, e-mail: c-dev-h...@xerces.apache.org
[jira] Closed: (XERCESC-1898) LocalFileFormatTarget dtor may throw an exception
[ https://issues.apache.org/jira/browse/XERCESC-1898?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Boris Kolpackov closed XERCESC-1898. Resolution: Fixed The fix is in SVN. LocalFileFormatTarget dtor may throw an exception - Key: XERCESC-1898 URL: https://issues.apache.org/jira/browse/XERCESC-1898 Project: Xerces-C++ Issue Type: Bug Components: Miscellaneous Affects Versions: 3.0.0, 3.0.1 Reporter: peter Assignee: Boris Kolpackov Fix For: 3.1.0 The destructor of LocalFileFormatTarget is calling flushBuffer() which in turn may throw exceptions. Throwing exceptions in dtor however is dangerous since it may lead to program termination if the exception is thrown during stack unwind. Example: DOMLSSerializer::writeToURI() is causing imediate program termination if there is no space left on disk. The reason is an exception thrown in DOMLSSerializer::write(). During stack unwind the dtor of LocalFileFormatTarget is called throwing another exception which is illegal and leads to program termination. Example stacktrace from real world application: msvcr90d.dll!__NMSG_WRITE() + 0x75 Bytes msvcr90d.dll!_abort() + 0x2d Bytes msvcr90d.dll!terminate() + 0x6e Bytes msvcr90d.dll!___FrameUnwindFilter() + 0x40 Bytes msvcr90d.dll!___FrameUnwindToState() + 0x106 Bytes msvcr90d.d...@_eh4_callfilterfunc@8() + 0x12 Bytes ntdll.dll!executehandl...@20() + 0x26 Bytes ntdll.dll!executehand...@20() + 0x24 Bytes ntdll.dll!_kiuserexceptiondispatc...@8() + 0xf Bytes kernel32.dll!_raiseexcept...@16() + 0x59 Bytes msvcr90d.dll!__cxxthrowexcept...@8() + 0x52 Bytes xerces-c_3_0D.dll!xercesc_3_0::WindowsFileMgr::fileWrite(void * f=0x0900, unsigned long byteCount=1022, const unsigned char * buffer=0x115e5d18, xercesc_3_0::MemoryManager * const manager=0x0498f758) Zeile 314C++ xerces-c_3_0D.dll!xercesc_3_0::XMLPlatformUtils::writeBufferToFile(void * const theFile=0x0900, unsigned long toWrite=1022, const unsigned char * const toFlush=0x115e5d18, xercesc_3_0::MemoryManager * const memmgr=0x0498f758) Zeile 608C++ xerces-c_3_0D.dll!xercesc_3_0::LocalFileFormatTarget::flushBuffer() Zeile 120 + 0x21 BytesC++ xerces-c_3_0D.dll!xercesc_3_0::LocalFileFormatTarget::~LocalFileFormatTarget() Zeile 83C++ xerces-c_3_0D.dll!xercesc_3_0::LocalFileFormatTarget::`vector deleting destructor'() + 0x4d BytesC++ xerces-c_3_0D.dll!xercesc_3_0::Janitorxercesc_3_0::XMLFormatTarget::reset(xercesc_3_0::XMLFormatTarget * p=0x) Zeile 90 + 0x22 BytesC++ xerces-c_3_0D.dll!xercesc_3_0::Janitorxercesc_3_0::XMLFormatTarget::~Janitorxercesc_3_0::XMLFormatTarget() Zeile 44C++ msvcr90d.dll!__callsettingfr...@12() + 0x26 Bytes msvcr90d.dll!___FrameUnwindToState() + 0xf4 Bytes msvcr90d.dll!___InternalCxxFrameHandler() + 0x7f Bytes msvcr90d.dll!___CxxFrameHandler3() + 0x2c Bytes ntdll.dll!executehandl...@20() + 0x26 Bytes ntdll.dll!executehand...@20() + 0x24 Bytes msvcr90d.dll!_UnwindNestedFrames() + 0x2f Bytes msvcr90d.dll!___FrameUnwindToState() + 0x1cf Bytes msvcr90d.dll!___InternalCxxFrameHandler() + 0x48a Bytes msvcr90d.dll!___InternalCxxFrameHandler() + 0x147 Bytes msvcr90d.dll!___CxxFrameHandler3() + 0x2c Bytes ntdll.dll!executehandl...@20() + 0x26 Bytes ntdll.dll!executehand...@20() + 0x24 Bytes ntdll.dll!_kiuserexceptiondispatc...@8() + 0xf Bytes kernel32.dll!_raiseexcept...@16() + 0x59 Bytes msvcr90d.dll!__cxxthrowexcept...@8() + 0x52 Bytes xerces-c_3_0D.dll!xercesc_3_0::WindowsFileMgr::fileWrite(void * f=0x0900, unsigned long byteCount=1022, const unsigned char * buffer=0x115e5d18, xercesc_3_0::MemoryManager * const manager=0x0498f758) Zeile 314C++ xerces-c_3_0D.dll!xercesc_3_0::XMLPlatformUtils::writeBufferToFile(void * const theFile=0x0900, unsigned long toWrite=1022, const unsigned char * const toFlush=0x115e5d18, xercesc_3_0::MemoryManager * const memmgr=0x0498f758) Zeile 608C++ xerces-c_3_0D.dll!xercesc_3_0::LocalFileFormatTarget::flushBuffer() Zeile 120 + 0x21 BytesC++ xerces-c_3_0D.dll!xercesc_3_0::LocalFileFormatTarget::flush() Zeile 92 C++ xerces-c_3_0D.dll!xercesc_3_0::DOMLSSerializerImpl::write(const xercesc_3_0::DOMNode * nodeToWrite=0x11776040, xercesc_3_0::DOMLSOutput * const destination=0x1909f76c) Zeile 542C++ xerces-c_3_0D.dll!xercesc_3_0::DOMLSSerializerImpl::writeToURI(const xercesc_3_0::DOMNode * nodeToWrite=0x11776040, const
[jira] Closed: (XERCESC-1337) DOMMemTest fails with Segmentation violation(xserces1.7 + ICU transcode + windows2000)
[ https://issues.apache.org/jira/browse/XERCESC-1337?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Boris Kolpackov closed XERCESC-1337. Resolution: Fixed Fix Version/s: 3.0.1 Assuming fixed in the latest release. DOMMemTest fails with Segmentation violation(xserces1.7 + ICU transcode + windows2000) Key: XERCESC-1337 URL: https://issues.apache.org/jira/browse/XERCESC-1337 Project: Xerces-C++ Issue Type: Bug Components: Utilities Affects Versions: 1.7.0 Environment: windows2000 + xseces 1.7 Reporter: Leon Zhang Priority: Critical Fix For: 3.0.1 Attachments: DOMMemTest.cpp When I run DOMMemTest testcase after build xerces with ICU trascode option, DOMMemTest always fails with Segmentation violation. I am not sure this is a DOMString bug or ICUTransService.cpp bug. But it seesm that this is not a DOMString bug, since after build serces with WIN32 transcode. It seems that xseces 2.5 have the same bug, so other guys have to build xerces with WIN32 transcode. I need your help. (You some products are embeded in xerces). Thanks a lot! -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: c-dev-unsubscr...@xerces.apache.org For additional commands, e-mail: c-dev-h...@xerces.apache.org
[jira] Closed: (XERCESC-1205) primary document entity could not be opened - on Win98
[
https://issues.apache.org/jira/browse/XERCESC-1205?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Boris Kolpackov closed XERCESC-1205.
Resolution: Fixed
Fix Version/s: 3.0.1
Win98 is no longer supported.
primary document entity could not be opened - on Win98
--
Key: XERCESC-1205
URL: https://issues.apache.org/jira/browse/XERCESC-1205
Project: Xerces-C++
Issue Type: Bug
Components: Utilities
Affects Versions: 2.1.0, 2.4.0, 2.5.0
Environment: Together with Xalan. I have had the bug on Win98 (1st
and 2nd edition). Reading the code I think Win95 and WinME may have the same
problem.
Reporter: Florian Nowotny
Fix For: 3.0.1
When I use an unc path as the input parameter of the constructor of Xalan's
XSLTInputSource( const char* )
on Win98 systems Xerces raises the error:
The primary document entitiy could not be opened.
Id=\\server\shared\..path-to-xml-file
I traced through Xerces' code an found that
- the constructor of Xerces' InputSource( const XMLCh* const SystemId,
MemoryManager*) is called internally and the systemId is
file:/server/shared/...
- later in Win32PlatformUtils.cpp the Windows API method CreateFileA is
called and tmpName is //server/shared/...
BUT: CreateFileA can't open an UNC-Path with forward slashes on both
Win98-PCs that I have tested (Win98 1st and 2nd Edition).
It's unfriendly that the error message reports the file-to-open-path with
back slashes?
I fixed the problem by patching
xerces/src/xercesc/util/Platforms/Win32/Win32PlatformUtils.cpp (Xerces
version 2.5.0) in method
openFile(const XMLCh* const fileName, MemoryManager* const manager).
Here is my code beginning with line 326:
else
{
//
// We are Win 95 / 98. Take the Unicode file name back to (char *)
//so that we can open it.
//
char* tmpName = XMLString::transcode(nameToOpen, manager);
//
// Bugfix:
// I'm replacing all forward slashes with backward slashes
//
int len = strlen(tmpName);
for ( int i = 0; i len; ++i )
{
if ( tmpName[i] == '/' )
tmpName[i] = '\\';
}
retVal = ::CreateFileA
(
tmpName
, GENERIC_READ
, FILE_SHARE_READ
, 0
, OPEN_EXISTING
, FILE_FLAG_SEQUENTIAL_SCAN
, 0
);
manager-deallocate(tmpName);//delete [] tmpName;
}
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
-
To unsubscribe, e-mail: c-dev-unsubscr...@xerces.apache.org
For additional commands, e-mail: c-dev-h...@xerces.apache.org
[jira] Closed: (XERCESC-1127) ABW: Array bounds write xercesc_2_4::HashBase::HashBase #Nvariant 1() [XMLString.hpp:1612]
[ https://issues.apache.org/jira/browse/XERCESC-1127?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Boris Kolpackov closed XERCESC-1127. Resolution: Fixed Fix Version/s: 3.0.1 Assignee: (was: Xerces-C Developers Mailing List) The latest releases has been checked extensively with valgrind so I assume this has been fixed. ABW: Array bounds write xercesc_2_4::HashBase::HashBase #Nvariant 1() [XMLString.hpp:1612] -- Key: XERCESC-1127 URL: https://issues.apache.org/jira/browse/XERCESC-1127 Project: Xerces-C++ Issue Type: Bug Components: Utilities Affects Versions: 2.4.0 Environment: Operating System: Solaris Platform: Other Reporter: Greg Franks Fix For: 3.0.1 Attachments: bugzilla This error is popping up during object allocation. It may be that the xerces memory allocation is confusing purify, in which case, this is a non problem. The stack trace is attached. ABWArray bounds write CORRUPTING An ABW message indicates that your program is about to write a value to before the beginning or after the end of an allo- cated block. Common causes include: o making an array too small (e.g. failing to account for the terminating NULL in a string); o forgetting to multiply by sizeof(type) when allocating for an array of objects; o using an array index too large or negative; o failing to NULL terminate a string; or o being off-by-one in copying elements up or down an array. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: c-dev-unsubscr...@xerces.apache.org For additional commands, e-mail: c-dev-h...@xerces.apache.org
[jira] Closed: (XERCESC-1105) transcode function on AIX returns incorrect value
[
https://issues.apache.org/jira/browse/XERCESC-1105?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Boris Kolpackov closed XERCESC-1105.
Resolution: Invalid
Assignee: (was: Xerces-C Developers Mailing List)
No reply from the reporter. Assuming invalid.
transcode function on AIX returns incorrect value
-
Key: XERCESC-1105
URL: https://issues.apache.org/jira/browse/XERCESC-1105
Project: Xerces-C++
Issue Type: Bug
Components: Utilities
Affects Versions: 2.2.0
Environment: Operating System: AIX
Platform: Other
Reporter: Karen Bradshaw
XMLString::transcode always returns 1 regardless of the provided buffer size.
// const char * str;
// XMLCh * buffer;
// size_t buffer_size;
if(XMLString::transcode(str, buffer, buffer_size - 4))
{
return buffer;
}
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
-
To unsubscribe, e-mail: c-dev-unsubscr...@xerces.apache.org
For additional commands, e-mail: c-dev-h...@xerces.apache.org
[jira] Closed: (XERCESC-777) XMLPlatformUtils::Initialize() fails to execute any code when called from an shared object
[
https://issues.apache.org/jira/browse/XERCESC-777?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Boris Kolpackov closed XERCESC-777.
---
Resolution: Invalid
Assignee: (was: Xerces-C Developers Mailing List)
I am pretty sure this is a compiler issue.
XMLPlatformUtils::Initialize() fails to execute any code when called from an
shared object
--
Key: XERCESC-777
URL: https://issues.apache.org/jira/browse/XERCESC-777
Project: Xerces-C++
Issue Type: Bug
Components: Utilities
Affects Versions: 2.1.0
Environment: Operating System: Solaris
Platform: Sun
Reporter: mstorrs
I have compiled Xerces2.1 (stable) on Solaris 2.8 using g++ 2.95.3. The
samples execute properly. I am linking the xerces.so to another shared
object
I am creating. This shared object is loaded by an application at run time,
when I call XMLPlatformUtils::Initialize() from the shared object the code
executes the call, but never actually performs any code within that function
-
I know this because I have editted the Initialize() function and outputed a
debug statement to a file (this works successfully during execution of one of
the samples). After Initialize returns, the code continues and then once the
code tries to execute getDOMImplementation(), the shared object core dumps,
because the global mutex lock is null, since the new XMLMutex statement is
never executed within Initialize(). I placed debug statements in this Xerces
code as well, and know that the function executes, and crashes once the code
tries to lock to set the cleanupfunction.
Is there any reason that Initialize wouldn't execute the code?? I have
attached the shared object code as well as the Makefile. I also tried with
c++, and that failed the exact same way.
Here is the shared object code:
extern C unsigned int OBLIX_DLLEXPORT Crap(const char *eventName, ObPPPData
*data)
{
int iStatus = STATUS_PPP_OK;// Return code
AbstractDOMParser::ValSchemes valScheme = AbstractDOMParser::Val_Auto;
bool doNamespaces = false;
bool doSchema = false;
bool schemaFullChecking = false;
bool errorOccurred = false;
try
{
FILE *fp = fopen(/opt/netpoint/custom/xerces.txt, w);
fprintf(fp, Before Initialize\n);
fclose(fp);
XMLPlatformUtils::Initialize();
fp = fopen(/opt/netpoint/custom/xerces.txt, a);
fprintf(fp, After Initialize\n);
fclose(fp);
}
catch (const XMLException toCatch)
{
data-SetResultString(NonInternalUser: XML Exception occured);
return STATUS_PPP_ABORT;
}
catch (...)
{
data-SetResultString(S Happens);
return STATUS_PPP_ABORT;
}
try
{
// Instantiate the DOM parser.
static const XMLCh gLS[] = { chLatin_L, chLatin_S, chNull };
DOMImplementation *impl =
DOMImplementationRegistry::getDOMImplementation(gLS);
DOMBuilder*parser = ((DOMImplementationLS*)impl)-
createDOMBuilder(DOMImplementationLS:
:MODE_SYNCHRONOUS, 0);
parser-setFeature(XMLUni::fgDOMNamespaces, doNamespaces);
parser-setFeature(XMLUni::fgXercesSchema, doSchema);
parser-setFeature(XMLUni::fgXercesSchemaFullChecking,
schemaFullChecking);
if (valScheme == AbstractDOMParser::Val_Auto)
{
parser-setFeature(XMLUni::fgDOMValidateIfSchema, true);
}
else if (valScheme == AbstractDOMParser::Val_Never)
{
parser-setFeature(XMLUni::fgDOMValidation, false);
}
else if (valScheme == AbstractDOMParser::Val_Always)
{
parser-setFeature(XMLUni::fgDOMValidation, true);
etc.
Makefile
--
CC = g++
SHARED_LIB_EXT = so
CFLAGS = -c -DSOLARIS -D_REENTRANT -fpic -Wall -g -O2 -I.
-I/usr/local/include -
I/opt/netpoint/identity
/oblix/include/ppp -I/opt/netpoint/custom/xerces-c-src2_1_0/include -
I/opt/netpoint/custom/ldap/include
LOADFLAG = -DSOLARIS -fpic -mt -shared -L/usr/lib -L/usr/local/lib -
L/opt/netpoint/custom/ldap/lib -L/o
pt/netpoint/custom/xerces-c-src2_1_0/lib -lxerces-c -lldap50 -lpthread
all : fed.$(SHARED_LIB_EXT)
fed.$(SHARED_LIB_EXT) : common.o FedHandler.o InternalUser.o
NonInternalUser.o
IntUserToServices.o test
.o
$(CC) $(LOADFLAG) -o $@ common.o FedHandler.o InternalUser.o
NonInternalUser.o IntUserToServices.o
test.o
common.o : common.cpp
$(CC) $(CFLAGS) common.cpp -o $@
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Closed: (XERCESC-501) Xerces hangs in ThrowXML
[
https://issues.apache.org/jira/browse/XERCESC-501?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Boris Kolpackov closed XERCESC-501.
---
Resolution: Invalid
Assignee: (was: Xerces-C Developers Mailing List)
Can you try to reproduce this problem with the latest release? If it is still
there, can you reopen this bug and provide a test case?
Xerces hangs in ThrowXML
Key: XERCESC-501
URL: https://issues.apache.org/jira/browse/XERCESC-501
Project: Xerces-C++
Issue Type: Bug
Components: Utilities
Affects Versions: 1.7.0
Environment: Operating System: Windows NT/2K
Platform: PC
Reporter: Mikael Widenfalk
I have several threads (CWinThread) that use Xerces. Sooner or later one
specific thread gets stuck in ThrowXML. The exact point varies depending on
what
I send in systemID. This is one example:
void XMLURL::setURL(const XMLCh* constbaseURL
, const XMLCh* constrelativeURL)
{
cleanup();
// Parse our URL string
parse(relativeURL);
//
// If its relative and the base is non-null and non-empty, then
// parse the base URL string and conglomerate them.
//
if (isRelative() baseURL)
{
if (*baseURL)
{
XMLURL basePart(baseURL);
if (!conglomerateWithBase(basePart, false))
{
cleanup();
ThrowXML(MalformedURLException,
XMLExcepts::URL_RelativeBaseURL);
}
}
}
}
[ baseURL = Client relativeURL = Information-1-0.dtd ]
The calltree proceeds with:
msvcrtd!__cxxthrowexcept...@8
KERNEL32!77e989d1()
so there are no more clues there I guess. The CPU is at 0% and it appears as
though everything is stuck in some mutex.
I've made a (large) test program that spawns 50 threads and parses 50 DTD'd
XML
documents in each and it also occasionally gets stucks.
Brief facts of the case are:
* Single thread single point of initialization.
* Uses SAX.
* New parser, etc. for each document read.
* Uses MemBufInputSource.
* Uses MS VS6 sp5.
Sorry if this provides little clue as to what goes on. Please contact me for
more specfic information, if needed.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
-
To unsubscribe, e-mail: c-dev-unsubscr...@xerces.apache.org
For additional commands, e-mail: c-dev-h...@xerces.apache.org
[jira] Closed: (XERCESC-481) pthread_mutex_lock is slow on solaris
[
https://issues.apache.org/jira/browse/XERCESC-481?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Boris Kolpackov closed XERCESC-481.
---
Resolution: Invalid
Assignee: (was: Xerces-C Developers Mailing List)
I believe this has been addressed in Solaris.
pthread_mutex_lock is slow on solaris
-
Key: XERCESC-481
URL: https://issues.apache.org/jira/browse/XERCESC-481
Project: Xerces-C++
Issue Type: Bug
Components: Utilities
Affects Versions: 1.7.0
Environment: Operating System: Solaris
Platform: Sun
Reporter: Case Larsen
Since this is used a lot in the string pool, it impacts performance. here is
a fix which we use and it works.
// this returns old value, so we need to add or subtract value to get true
value
inline int ink_atomic_increment(void *mem, int value)
{
volatile int * memp = (int *)mem;
for (;;) {
int current = *memp;
int new_value = current+value;
asm(cas %2,%3,%0 : =r (new_value) : 0 (new_value), m (*memp),
r (current));
if (new_value == current) return current;
}
}
int XMLPlatformUtils::atomicIncrement(int location)
{
return ink_atomic_increment(location,1) + 1;
}
int XMLPlatformUtils::atomicDecrement(int location)
{
return ink_atomic_increment(location,-1) - 1;
}
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
-
To unsubscribe, e-mail: c-dev-unsubscr...@xerces.apache.org
For additional commands, e-mail: c-dev-h...@xerces.apache.org
[jira] Closed: (XERCESC-1455) Template ValueVectorOf does not call destructors for removing objects. A memory leak could result from this.
[
https://issues.apache.org/jira/browse/XERCESC-1455?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Boris Kolpackov closed XERCESC-1455.
Resolution: Fixed
Fix Version/s: 3.0.1
I see that there is now the callDestructor flag in ValueVectorOf. So I assume
this has been fixed (in an ugly way).
Template ValueVectorOf does not call destructors for removing objects. A
memory leak could result from this.
Key: XERCESC-1455
URL: https://issues.apache.org/jira/browse/XERCESC-1455
Project: Xerces-C++
Issue Type: Bug
Components: Utilities
Affects Versions: 2.3.0
Environment: Solaris
Reporter: Alex Akula
Assignee: David Bertoni
Fix For: 3.0.1
Attachments: patch.txt
When objects get removed from ValueVectorOf object type container no
destructors are called for the objects. Amemory leak could result from this.
This could be fixed by changing the code:
template class TElem void ValueVectorOfTElem::
removeElementAt(const unsigned int removeAt)
{
if (removeAt = fCurCount)
ThrowXML(ArrayIndexOutOfBoundsException, XMLExcepts::Vector_BadIndex);
fElemList[removeAt] = 0; // akula -- this is the fix for classes in
which assign operator is overloaded appropriate way.
if (removeAt == fCurCount-1)
{
fCurCount--;
return;
}
// Copy down every element above remove point
for (unsigned int index = removeAt; index fCurCount-1; index++)
fElemList[index] = fElemList[index+1];
// And bump down count
fCurCount--;
}
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
-
To unsubscribe, e-mail: c-dev-unsubscr...@xerces.apache.org
For additional commands, e-mail: c-dev-h...@xerces.apache.org
[jira] Closed: (XERCESC-1656) Project uses deprecated Mac OS X functions and data types.
[ https://issues.apache.org/jira/browse/XERCESC-1656?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Boris Kolpackov closed XERCESC-1656. Resolution: Fixed Fix Version/s: 3.0.1 Assuming this is fixed in the 3-series. Project uses deprecated Mac OS X functions and data types. -- Key: XERCESC-1656 URL: https://issues.apache.org/jira/browse/XERCESC-1656 Project: Xerces-C++ Issue Type: Bug Components: Utilities Affects Versions: 2.7.0 Environment: Mac OS X 10.4 with Xcode 2.4.1 Reporter: Kevin Hoyt Assignee: James Berry Fix For: 3.0.1 All functions that take an FSSpec are depricated. These functions need to be replaced with FSRef based functions so Xerces can still be used once these functions become obsolete. Also, I vote for removing support for Classic (Mac OS 9). If anyone really needs this, they can use an older release. And, I'd say the same thing about supporting CodeWarrior. These are the files that need to be updated. MacOSPLatformUtils.cpp MacOSPlatformUtils.hpp MacOSUnicodeConverter.cpp Is anyone working on updating the Mac specific code for Xerces??? -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: c-dev-unsubscr...@xerces.apache.org For additional commands, e-mail: c-dev-h...@xerces.apache.org
[jira] Updated: (XERCESC-1866) Crash with regular expression
[
https://issues.apache.org/jira/browse/XERCESC-1866?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Boris Kolpackov updated XERCESC-1866:
-
Fix Version/s: 3.1.0
Would be really nice to fix this for 3.1.0.
Crash with regular expression
-
Key: XERCESC-1866
URL: https://issues.apache.org/jira/browse/XERCESC-1866
Project: Xerces-C++
Issue Type: Bug
Components: Utilities
Environment: Windows XP, Visual Studio 2005
Reporter: Alexander Hartmann
Assignee: David Bertoni
Fix For: 3.1.0
Attachments: XERCESC-1866.patch
when I run the following test code my application crashes on the second
regEx.matches call:
{
XMLBuffer optionsBuf;
optionsBuf.append('i');
optionsBuf.append('H');
RegularExpression regEx(L^\\W*Excel\\W*$, optionsBuf.getRawBuffer());
regEx.matches(Excel);
}
{
XMLBuffer optionsBuf;
optionsBuf.append('i');
optionsBuf.append('H');
RegularExpression regEx(L^\\W*Excel\\W*$, optionsBuf.getRawBuffer());
regEx.matches(Excel);
}
some details I found during debugging:
- there is an instance of RangeToken where I have no idea where this is
created. I've set a breakpoint in the constructor but the debugger does not
stop.
- when RangeToken::getCaseInsensitiveToken is called a new RangeToken is
created and stored in fCaseIToken
- when parsing is finished the newly created RangeToken is deleted (through
~RegularExpression - ~TokenFactory), but the original RangeToken (where I
don't know where it is created) still exists and references the deleted
RangeToken in fCaseIToken
- the next time RangeToken::getCaseInsensitiveToken is called the invalid
reference fCaseIToken is returned and this leads to a crash when it is
accessed.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
-
To unsubscribe, e-mail: c-dev-unsubscr...@xerces.apache.org
For additional commands, e-mail: c-dev-h...@xerces.apache.org
[jira] Updated: (XERCESC-1826) XMLURL::makeNewStream() fails to decode file:/// URLs containing the (properly escaped) % character
[ https://issues.apache.org/jira/browse/XERCESC-1826?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Boris Kolpackov updated XERCESC-1826: - Fix Version/s: 3.1.0 Assignee: Boris Kolpackov XMLURL::makeNewStream() fails to decode file:/// URLs containing the (properly escaped) % character --- Key: XERCESC-1826 URL: https://issues.apache.org/jira/browse/XERCESC-1826 Project: Xerces-C++ Issue Type: Bug Components: Utilities Affects Versions: 2.5.0, 2.6.0, 2.7.0, 2.8.0, 3.0.0, 2.9.0, 3.1.0 Environment: Windows XP Prof. German, MS Visual Studio 2003 Reporter: Matteo Ceruti Assignee: Boris Kolpackov Fix For: 3.1.0 I truly believe that XMLURL::makeNewStream() (see src/xercesc/util/XMLURL.cpp) does not correctly handle file:///-URLs containing the escape-sequence %25 (that is the '%'-character itself). Consider you have a win32 filepath like C:\Documents\myfile_%_.xml . Its URL would be file:///C:/Documents/myfile_%25_.xml, right? But this URL is rejected by raising a MalformedURLException. makeNewStream() decodes the URL by searching and replacing the escape-sequences one by one. When it sucessfully replaced %25 by the '%'-character it continunes it's search for the next escape-sequence. The problem is, that it starts at the very position, where the last escape-sequence began. Therefore it suddenly finds a %-character again, because it had just been put there. This happens at least with xerces-c 2.5 and it seems that the current (revision=670359) http://svn.apache.org/viewvc/xerces/c/trunk/src/xercesc/util/XMLURL.cpp still has this problem. So probably other releases may have the same issue. I think the line percentIndex = XMLString::indexOf(realPath, chPercent, percentIndex, fMemoryManager); should be replaced by percentIndex = XMLString::indexOf(realPath, chPercent, percentIndex + 1, fMemoryManager); This works for me. Please correct me, if I'm wrong. Thank you in advance. Best regards, Matteo -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: c-dev-unsubscr...@xerces.apache.org For additional commands, e-mail: c-dev-h...@xerces.apache.org
[jira] Updated: (XERCESC-1599) DTD grammar caching of failed grammer causes segmentation fault
[ https://issues.apache.org/jira/browse/XERCESC-1599?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Boris Kolpackov updated XERCESC-1599: - Affects Version/s: (was: 2.7.0) 3.0.1 I tried the attached test with 3.0.1. IGXMLScanner works without any problem, including under valgrind. DGXMLScanner on the other hand does cause some memory access/free errors. So it seems this has been fixed in the former but not the latter. DTD grammar caching of failed grammer causes segmentation fault --- Key: XERCESC-1599 URL: https://issues.apache.org/jira/browse/XERCESC-1599 Project: Xerces-C++ Issue Type: Bug Components: Validating Parser (DTD) Affects Versions: 3.0.1 Environment: All. Reporter: Michael Fuller Priority: Critical Attachments: test-12907.tar Problem: If you enable grammar caching and: * DTD validate a valid document * DTD validate an invalid document * DTD validate an valid document a segmentation fault, etc. occurs inside Xerces. Apparent cause: When parsing a document in DTD mode, the parser always creates a temporary grammar called [dtd]. If the parser successully parses the document, it puts the parsed DTD in [dtd] and then renames [dtd] to the real name of the DTD. However, if the parse does not succeed, the parser (erroneously?) just leaves [dtd] in the grammer cache. This means that [dtd] exists in the grammar cache when a new document is parsed later that uses a novel DTD, then the presence of [dtd] in the grammar cache will eventually cause a memory leak and double free, ultimately causing a crash (see attached dbx or gdb output). This affects users of the DGXMLScanner and the IGXMLScanner. A fix for the problem is to make sure that before [dtd] is placed in the grammar cache any existing [dtd] is removed. The attached test case failed under both Solaris and Linux. Under Solaris, depending on where the files were located, environment, etc. it would sometimes crash, and sometimes not. However, even when it did not crash, it was still double freeing, etc; this can be seen by running bcheck test-12907 (output attached). Under linux, it always seems to crash with: *** glibc detected *** free(): invalid pointer: 0x0050ed18 *** However, even if the erroneous code does not trigger a crash, valgrind should show the problem. We have developed a kludgy workaround, but I do not think that it is a good fix. See the attached diffs against 2.7.0. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: c-dev-unsubscr...@xerces.apache.org For additional commands, e-mail: c-dev-h...@xerces.apache.org
[jira] Closed: (XERCESC-372) Xerces-C++/1.7 parser can not handle % sign correctly
[ https://issues.apache.org/jira/browse/XERCESC-372?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Boris Kolpackov closed XERCESC-372. --- Resolution: Fixed Fix Version/s: 3.0.1 Assignee: (was: Xerces-C Developers Mailing List) Assuming fixed in the latest release. Xerces-C++/1.7 parser can not handle % sign correctly - Key: XERCESC-372 URL: https://issues.apache.org/jira/browse/XERCESC-372 Project: Xerces-C++ Issue Type: Bug Components: Validating Parser (DTD) Affects Versions: 1.7.0 Environment: Operating System: HP-UX Platform: HP Reporter: Yufan Zhang Fix For: 3.0.1 Your Xerces-C++/1.7 parser can not handle % sign correctly. If a #PCDATA element contains a value of %, this % will go away. But for %%, sometimes we get %, sometime get %% in the chars value of the documentHandler interface function ::characters(const XMLCh* chars, const unsigned int lenght). Do you know why? or we can not simply send %, in stead, we need to convert % to other string. If so, what string we need to convert to. If not, is there any special setting we forgot to do? Thanks, Yufan -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: c-dev-unsubscr...@xerces.apache.org For additional commands, e-mail: c-dev-h...@xerces.apache.org
[jira] Closed: (XERCESC-1630) Unclear error description when validation by schema
[ https://issues.apache.org/jira/browse/XERCESC-1630?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Boris Kolpackov closed XERCESC-1630. Resolution: Won't Fix I don't think anyone will ever try to do this. The code base is already complex enough. Unclear error description when validation by schema --- Key: XERCESC-1630 URL: https://issues.apache.org/jira/browse/XERCESC-1630 Project: Xerces-C++ Issue Type: Improvement Components: Validating Parser (DTD) Affects Versions: 2.4.0 Environment: Solaris Reporter: woods wang When using the Xerces to validate the xml by schema, for example, the content model is '((msisdn,imsi),region)', as you know, the msisdn and imsi is mandatory parameters, if the xml is missing the msisdn element, Xerces will report the error Message: Element 'imsi' is not valid for content model:'((msisdn,imsi),region)'!! I understand that the 'msisdn' is the first expected mandatory parameter, but xerces get the 'imsi' as the first parameter, so it complain the 'imsi' is not valid. But could it be possible to change the error description to make it more clear? like msisdn is missing something like that... thanks, //woods -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: c-dev-unsubscr...@xerces.apache.org For additional commands, e-mail: c-dev-h...@xerces.apache.org
[jira] Commented: (XERCESC-1859) DOMLSResourceResolver resolveResource() called for every instance of a DTD.
[ https://issues.apache.org/jira/browse/XERCESC-1859?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12779320#action_12779320 ] Boris Kolpackov commented on XERCESC-1859: -- Confirmed. The problem could be that DTDs don't have a key that can be used to ignore duplicate schemas like the target namespace is used in XML Schema caching. One way to address this would be to extend the fgXercesLoadSchema property to also apply to DTDs. DOMLSResourceResolver resolveResource() called for every instance of a DTD. --- Key: XERCESC-1859 URL: https://issues.apache.org/jira/browse/XERCESC-1859 Project: Xerces-C++ Issue Type: Bug Components: Validating Parser (DTD) Affects Versions: 3.0.1 Environment: x86 build Reporter: Ben Griffin Attachments: 12421546.zip By overriding DOMLSResourceResolver, it can be identified that every time a DTD based document is being validated, the DTD cache is being ignored, and DOMLSInput* DOMLSResourceResolver::resolveResource() is being called to locate the relevant resource. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: c-dev-unsubscr...@xerces.apache.org For additional commands, e-mail: c-dev-h...@xerces.apache.org
[jira] Closed: (XERCESC-1202) GeneralAttributeCheck initialize fails
[ https://issues.apache.org/jira/browse/XERCESC-1202?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Boris Kolpackov closed XERCESC-1202. Resolution: Fixed Fix Version/s: 3.0.1 Assuming fixed in 3.0.1. GeneralAttributeCheck initialize fails -- Key: XERCESC-1202 URL: https://issues.apache.org/jira/browse/XERCESC-1202 Project: Xerces-C++ Issue Type: Bug Components: Validating Parser (XML Schema) Affects Versions: 2.3.0 Environment: Sun Solaris 8 Reporter: Michael Kopp Priority: Critical Fix For: 3.0.1 We are parsing the same xml in multiple threads, which contains a schema. Very frequently, at least once for every tinderbox build, we get the following core dump: =[1] xercesc_2_3::ValueHashTableOfunsigned short::findBucketElem(this = (nil), key = 0x8ec3a4, hashVal = 4265683276U), line 252 in ValueHashTableOf.c [2] xercesc_2_3::ValueHashTableOfunsigned short::get(this = (nil), key = 0x8ec3a4), line 199 in ValueHashTableOf.c dbx: warning: unexpected RTTI for type xercesc_2_3::XSDLocator [3] xercesc_2_3::GeneralAttributeCheck::getFacetId(this = 0xfc500c24, facetName = 0x8ec3a4), line 298 in GeneralAttributeCheck.hpp [4] xercesc_2_3::TraverseSchema::traverseByRestriction(this = 0xfc500b58, rootElem = 0x8ec008, contentElem = 0x8ec118, typeName = 0x453198, qualifiedName = 0x47b758, finalSet = 0), line 2981 in TraverseSchema.cpp [5] xercesc_2_3::TraverseSchema::traverseSimpleTypeDecl(this = 0xfc500b58, childElem = 0x8ec008, topLevel = false, baseRefContext = 0), line 1082 in TraverseSchema.cpp [6] xercesc_2_3::TraverseSchema::traverseAttributeDecl(this = 0xfc500b58, elem = 0x8ebdd8, typeInfo = 0x33eee0, topLevel = false), line 2053 in TraverseSchema.cpp [7] xercesc_2_3::TraverseSchema::processAttributes(this = 0xfc500b58, elem = 0x8eac50, attElem = 0x8ebdd8, baseRawName = (nil), baseLocalPart = (nil), baseURI = (nil), typeInfo = 0x33eee0, isBaseAnyType = false), line 6108 in TraverseSchema.cpp [8] xercesc_2_3::TraverseSchema::processComplexContent(this = 0xfc500b58, ctElem = 0x8eac50, typeName = 0x8ead70, childElem = 0x8eae40, typeInfo = 0x33eee0, baseRawName = (nil), baseLocalPart = (nil), baseURI = (nil), isMixed = false, isBaseAnyType = false), line 5906 in TraverseSchema.cpp [9] xercesc_2_3::TraverseSchema::traverseComplexTypeDecl(this = 0xfc500b58, elem = 0x8eac50, topLevel = true, recursingTypeName = (nil)), line 1269 in TraverseSchema.cpp [10] xercesc_2_3::TraverseSchema::processChildren(this = 0xfc500b58, root = 0x8ea5a8), line 4283 in TraverseSchema.cpp [11] xercesc_2_3::TraverseSchema::doTraverseSchema(this = 0xfc500b58, schemaRoot = 0x8ea5a8), line 276 in TraverseSchema.cpp [12] xercesc_2_3::TraverseSchema::TraverseSchema(this = 0xfc500b58, schemaRoot = 0x8ea5a8, uriStringPool = 0x43d0f0, schemaGrammar = 0x8cfe10, grammarResolver = 0x8844b8, xmlScanner = 0x21a458, schemaURL = 0x2126c0, entityHandler = (nil), errorReporter = 0x3ff874, manager = 0xd50b8), line 253 in TraverseSchema.cpp [13] xercesc_2_3::IGXMLScanner::resolveSchemaGrammar(this = 0x21a458, loc = 0x812458, uri = 0x213ad8), line 1421 in IGXMLScanner2.cpp [14] xercesc_2_3::IGXMLScanner::parseSchemaLocation(this = 0x21a458, schemaLocationStr = 0x262a58), line 1285 in IGXMLScanner2.cpp [15] xercesc_2_3::IGXMLScanner::scanRawAttrListforNameSpaces(this = 0x21a458, theRawAttrList = 0x7dbd30, attCount = 4), line 1247 in IGXMLScanner2.cpp [16] xercesc_2_3::IGXMLScanner::scanStartTagNS(this = 0x21a458, gotData = true), line 2034 in IGXMLScanner.cpp [17] xercesc_2_3::IGXMLScanner::scanContent(this = 0x21a458, extEntity = false), line 849 in IGXMLScanner.cpp [18] xercesc_2_3::IGXMLScanner::scanDocument(this = 0x21a458, src = CLASS), line 209 in IGXMLScanner.cpp [19] xercesc_2_3::XMLScanner::scanDocument(this = 0x21a458, systemId = 0x25b9b8), line 419 in XMLScanner.cpp [20] xercesc_2_3::XMLScanner::scanDocument(this = 0x21a458, systemId = 0x817d58 /view/auto_build_MessageMapper_Development-dcacpl1-2004-04-25.2135_view/dcaclearcase/vobs/eQuality/eBridge/../../eBridge/FormatDefinitions/swift/SwiftDataDictionary.xml), line 427 in XMLScanner.cpp [21] xercesc_2_3::SAX2XMLReaderImpl::parse(this = 0x3ff868, systemId = 0x817d58 /view/auto_build_MessageMapper_Development-dcacpl1-2004-04-25.2135_view/dcaclearcase/vobs/eQuality/eBridge/../../eBridge/FormatDefinitions/swift/SwiftDataDictionary.xml), line 637 in SAX2XMLReaderImpl.cpp [22] ftisoft::vendor::swift::Field::GetDictionary(toFill = CLASS, def_dir = CLASS), line 156 in DataDictionary.cpp ... I looked into it and found that the initialize of GeneralAttributeCheck::mapElements seems to fail. Although the mutex
[jira] Updated: (XERCESC-1748) parsing registry based authorities in URI fails
[ https://issues.apache.org/jira/browse/XERCESC-1748?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Boris Kolpackov updated XERCESC-1748: - Affects Version/s: (was: 2.7.0) 3.0.1 Fix Version/s: 3.1.0 Assignee: Boris Kolpackov parsing registry based authorities in URI fails --- Key: XERCESC-1748 URL: https://issues.apache.org/jira/browse/XERCESC-1748 Project: Xerces-C++ Issue Type: Bug Components: Validating Parser (XML Schema) Affects Versions: 3.0.1 Environment: Linux Reporter: G. Kramer Assignee: Boris Kolpackov Priority: Blocker Fix For: 3.1.0 Attachments: anyURITest.xml, anyURITest.xsd, xercesc-1748patch.txt validating documents against schema containing registry based authorities in anyURI typed attributes fails with: Message: Datatype error: Type:InvalidDatatypeValueException, Message:Value '...' is NOT a valid URI -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: c-dev-unsubscr...@xerces.apache.org For additional commands, e-mail: c-dev-h...@xerces.apache.org
[jira] Updated: (XERCESC-1659) Order sensitivity in schemaLocation and noNamespaceSchemaLocation
[ https://issues.apache.org/jira/browse/XERCESC-1659?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Boris Kolpackov updated XERCESC-1659: - Affects Version/s: (was: 2.7.0) 3.1.0 Fix Version/s: 3.1.0 Assignee: Boris Kolpackov Confirmed the problems are still present, even with multi-import enabled. Order sensitivity in schemaLocation and noNamespaceSchemaLocation - Key: XERCESC-1659 URL: https://issues.apache.org/jira/browse/XERCESC-1659 Project: Xerces-C++ Issue Type: Bug Components: Validating Parser (XML Schema) Affects Versions: 3.1.0 Environment: all Reporter: Boris Kolpackov Assignee: Boris Kolpackov Fix For: 3.1.0 Attachments: test-case-1.tar.gz, test-case-2.tar.gz I am attaching two test cases (each consists of 3 schemas plus an XML instance). If you try to run domprint on the first test case, you will get the following error: $ domprint -v=always -n -s -f test-users.xml Error at file test-users.xml, line 6, column 78 Message: Unknown element 'b:UserDatabase' If you change the order of the schemaLocation and noNamespaceSchemaLocation attributes in test-users.xml then the error disappears. The second test case is a slight modification of the first test case with the only difference being the schemas with targetNamespace are now do not have a namespace, and the schema that used to be without a namespace (derived-user-config.xsd) now is in a namespace. If you run domprint on this test case, you will get the following error: $ domprint -v=always -n -s -f test-users.xml Error at file test-users.xml, line 6, column 55 Message: Unknown element 'UserDatabase' This seems to prove that for Xerces-C++, for some reason, it is important that the schema that declares the root element is mentioned in the first *Location attribute (nor matter whether schemaLocation or noNamespaceSchemaLocation). Now comes the surprise: if we reverse the order of the two attributes in the second test case, domprint terminates with segmentation fault. Examination of the core points to the IGXMLScanner.cpp, line 2288: elemDecl = fGrammar-getElemDecl( uriId, nameRawBuf, qnameRawBuf, currentScope ); -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: c-dev-unsubscr...@xerces.apache.org For additional commands, e-mail: c-dev-h...@xerces.apache.org
[jira] Updated: (XERCESC-1263) Abstract type not handled correctly by cached grammar
[ https://issues.apache.org/jira/browse/XERCESC-1263?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Boris Kolpackov updated XERCESC-1263: - Affects Version/s: (was: 2.5.0) (was: 2.3.0) 3.1.0 Fix Version/s: 3.1.0 The bug is still present in 3.1.0. Abstract type not handled correctly by cached grammar - Key: XERCESC-1263 URL: https://issues.apache.org/jira/browse/XERCESC-1263 Project: Xerces-C++ Issue Type: Bug Components: Validating Parser (XML Schema) Affects Versions: 3.1.0 Reporter: Matthew Berry Fix For: 3.1.0 Details: I have managed to narrow the problem I am having to a simple test case. In the schema, I have an abstract type defined and am using xsi:type with a concrete type in the data file. If I have a xsi:schemaLocation attribute in my data file, then the test Xml file passes the validation. (I have used DOMCount to verify this) If I remove xsi:schemaLocation and instead from my source code call loadGrammar() and setFeature(XMLUni::fgXercesUseCachedGrammarInParse, true), I am getting the following error messages: Message: Element paramInstance is declared with a type that is abstract. Use xsi:type to specify a non-abstract type Message: Attribute 'name' is not declared for element 'paramInstance' Schema: --- xsd:schema targetNamespace=http://www.temp.org; xmlns:tmp=http://www.temp.org; xmlns:xsd=http://www.w3.org/2001/XMLSchema; !-- Define a 'paramInstance' element NOTE: We use an abstract base to allow for extension -- xsd:complexType name=ParamInstanceType abstract=true / xsd:element name=paramInstance type=ParamInstanceType / !-- Specifying a concrete type -- xsd:complexType name=ConcreteParamInstance xsd:complexContent xsd:extension base=tmp:ParamInstanceType xsd:attribute name=name type=xsd:string use=required / /xsd:extension /xsd:complexContent /xsd:complexType /xsd:schema Test data file: --- paramInstance xmlns=http://www.temp.org; xmlns:xsi=http://www.w3.org/2001/XMLSchema-instance; xsi:type=ConcreteParamInstance name=param1 / -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: c-dev-unsubscr...@xerces.apache.org For additional commands, e-mail: c-dev-h...@xerces.apache.org
[jira] Updated: (XERCESC-1232) Access violation when validating against invalid schema
[ https://issues.apache.org/jira/browse/XERCESC-1232?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Boris Kolpackov updated XERCESC-1232: - Affects Version/s: (was: 2.5.0) 3.1.0 Segfault is still there in the 3.1.0 codebase. Access violation when validating against invalid schema --- Key: XERCESC-1232 URL: https://issues.apache.org/jira/browse/XERCESC-1232 Project: Xerces-C++ Issue Type: Bug Components: Validating Parser (XML Schema) Affects Versions: 3.1.0 Environment: Windows XP - VC++ 6.0 SP5 Reporter: Alberto Massari Attachments: Feb2.xml, t1.xsd, x1.xsd, xsi.xsd I received an invalid schema, where a schema with no target namespace imported a second schema (with a target namespace) that, in turn, imported a third schema having no target namespace. When an instance of XML is validated against this schema, an access violation occurs when trying to use the fGrammar for the top level XML element, as it had already been deleted. This happens because TraverseSchema::preprocessImport is testing for a duplicate grammar being imported only if the grammar has a namespace; if a grammar with no namespace is imported, it is parsed again and placed in the grammar resolver. But the grammar resolver will delete the Grammar object previously associated with that key, and when that Grammar object will be restored at the end of the processing of the xs:import statement, it will be an invalid pointer. To reproduce the access violation, run DOMPrint -n -s feb2.xml on the attached files. Alberto -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: c-dev-unsubscr...@xerces.apache.org For additional commands, e-mail: c-dev-h...@xerces.apache.org
[jira] Closed: (XERCESC-1174) Error message doesnt contain all usefull informations if the schema-parsing isnt successfull
[
https://issues.apache.org/jira/browse/XERCESC-1174?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Boris Kolpackov closed XERCESC-1174.
Resolution: Invalid
Assignee: (was: Xerces-C Developers Mailing List)
No clear problem description provided.
Error message doesnt contain all usefull informations if the schema-parsing
isnt successfull
Key: XERCESC-1174
URL: https://issues.apache.org/jira/browse/XERCESC-1174
Project: Xerces-C++
Issue Type: Bug
Components: Validating Parser (XML Schema)
Affects Versions: 2.4.0
Environment: Operating System: Windows XP
Platform: PC
Reporter: Kai-Uwe Schmidt
Under M$ VC++ 6.0
The Information can be delivered to the user by modifying the resource String
table ID 16430 like this:
Datatype error: Type:{0}, Attribute: {2}, Message:{1}.
and upgrading:
emitError (XMLValid::DatatypeError, idve.getType(), idve.getMessage(),attDef-
getFullName());
in SchemaValidator::validateAttrValue.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
-
To unsubscribe, e-mail: c-dev-unsubscr...@xerces.apache.org
For additional commands, e-mail: c-dev-h...@xerces.apache.org
[jira] Closed: (XERCESC-1187) Xerces SAX2 parser can not skip xs:any if xsi:nil is used in xml
[ https://issues.apache.org/jira/browse/XERCESC-1187?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Boris Kolpackov closed XERCESC-1187. Resolution: Fixed Fix Version/s: 3.1.0 Assignee: (was: Xerces-C Developers Mailing List) Works in 3.1.0. Xerces SAX2 parser can not skip xs:any if xsi:nil is used in xml Key: XERCESC-1187 URL: https://issues.apache.org/jira/browse/XERCESC-1187 Project: Xerces-C++ Issue Type: Bug Components: Validating Parser (XML Schema) Affects Versions: 2.4.0 Environment: Operating System: Solaris Platform: Sun Reporter: Andy Ding Fix For: 3.1.0 We're using Xerces-C++ version 2.4.0. Now we found an error about xerces SAX2 parser can not skip xs:any type if xsi:nil=true is used in xml. As you can see, in following note.xml, the element school should be validated by another schema file defining this element, not by the schema file defining xs:any. The schema example: ?xml version=1.0? xs:schema xmlns:xs=http://www.w3.org/2001/XMLSchema; xmlns=http://www.w3schools.com; elementFormDefault=qualified targetNamespace=http://www.w3schools.com; xs:element name=note xs:complexType xs:sequence xs:element name=to type=xs:string/ xs:element name=from type=xs:string/ xs:any namespace=##any processContents=skip maxOccurs=unbounded/ /xs:sequence /xs:complexType /xs:element /xs:schema The xml example: ?xml version=1.0? note xmlns=http://www.w3schools.com; xmlns:xsi=http://www.w3.org/2001/XMLSchema-instance; xsi:schemaLocation=http://www.w3schools.com note.xsd toTove/to fromJani/from school student xsi:nil=true/ /school /note The error message: Error at file 1, line 15, char 8 Message: Element note with attribute xsi:nil=true must be empty -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: c-dev-unsubscr...@xerces.apache.org For additional commands, e-mail: c-dev-h...@xerces.apache.org
[jira] Closed: (XERCESC-991) When calling getContentModel() on element it throws exception for empty elements
[
https://issues.apache.org/jira/browse/XERCESC-991?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Boris Kolpackov closed XERCESC-991.
---
Resolution: Invalid
Assignee: (was: Xerces-C Developers Mailing List)
Please provide a test case if you believe this is still a problem.
When calling getContentModel() on element it throws exception for empty
elements
Key: XERCESC-991
URL: https://issues.apache.org/jira/browse/XERCESC-991
Project: Xerces-C++
Issue Type: Bug
Components: Validating Parser (XML Schema)
Affects Versions: 2.2.0
Environment: Operating System: Other
Platform: Other
Reporter: Hima Mukkamala
When getContentModel() is called on elem where
SchemaELementDecl* elem for an empty element declaration,
it throws an exception. Isn't it the right
approach to return null similar to SchemaElementDecl::Simple
typed elements.
Fix would be to add this code in ComplexTypeInfo::makeContentModel
// code
else if (fContentType == SchemaElementDecl::Empty) {
// just return nothing
}
in this function.
-thanks
hima
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
-
To unsubscribe, e-mail: c-dev-unsubscr...@xerces.apache.org
For additional commands, e-mail: c-dev-h...@xerces.apache.org
[jira] Updated: (XERCESC-391) Make Error/Message Extension Of The XMLValidator Possible
[ https://issues.apache.org/jira/browse/XERCESC-391?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Boris Kolpackov updated XERCESC-391: Priority: Minor (was: Major) Assignee: (was: Xerces-C Developers Mailing List) Issue Type: New Feature (was: Bug) Make Error/Message Extension Of The XMLValidator Possible - Key: XERCESC-391 URL: https://issues.apache.org/jira/browse/XERCESC-391 Project: Xerces-C++ Issue Type: New Feature Components: Validating Parser (XML Schema) Affects Versions: 1.7.0 Environment: Operating System: Linux Platform: PC Reporter: Reid Spencer Priority: Minor Attachments: XMLValidator.cpp, XMLValidator.hpp, XMLValidityCodes.hpp The 1.7.0 xercesc/framework/XMLValidator class uses a message numbering and loading schema that does not lend itself to extension of the class. In my case, I am attempting to provide further semantic validation of a document by extending the class xercesc/validators/schema/SchemaValidator. To make XMLValidator a little more friendly to those wishing to extend it, I have made four new virtual functions in the XMLValidator interface. All four have default implementations and no code changes to any other classes were required. The new virtual functions are: getClassLoader, isWarning, isError, and isFatal. These four functions permit a subclass to determine which class loader gets loaded to generate the error message and to also decide which error codes are warnings, errors, or fatal. Previously, these capabilities were statically coded into XMLValidator and XMLValid. One other change is that XMLValid::Codes is now an unsigned integer rather than an enumeration. This change is needed in order to make it possible for subclasses to have their own range of error codes. XMLValidator reserves error numbers 0- for its own use. Subclasses can pick any other range for their error numbers. The change to implement this consists of only three files: xercesc/framework/XMLValidator.hpp xercesc/framework/XMLValidator.cpp xercesc/framework/XMLValidityCodes.hpp All three files are provided as attachments and have been tested in the following environment (i.e. all Sample Test programs work): Platform: PC (2 x 1GHz Pentium III ) Operating System: Linux 7.1 + updates (kernel = 2.4.9-31smp) Compiler: GCC 3.0.3 It would be great if these changes could be made to stick in future releases. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: c-dev-unsubscr...@xerces.apache.org For additional commands, e-mail: c-dev-h...@xerces.apache.org
[jira] Updated: (XERCESC-1668) Good schema rejected - simpleContent/complexContent
[ https://issues.apache.org/jira/browse/XERCESC-1668?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Boris Kolpackov updated XERCESC-1668: - Affects Version/s: (was: 2.7.0) 3.1.0 Good schema rejected - simpleContent/complexContent --- Key: XERCESC-1668 URL: https://issues.apache.org/jira/browse/XERCESC-1668 Project: Xerces-C++ Issue Type: Bug Components: Validating Parser (XML Schema) Affects Versions: 3.1.0 Reporter: Jochen Schwarze Attachments: test.xml, test.xsd The attached schema does not validate the attached instance: file:///.../test.xsd:12,36: The type 'xs:anyType' specified as the base in the simpleContent element must not have complexContent Both schema and instance validate in Xerces-J 2.9 (with schema-full-checking), with MSXML 4.0 and 6.0, Saxon-SA 8.8, XSV 2.10-1 and with Alphaworks' SchemaQualityChecker. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: c-dev-unsubscr...@xerces.apache.org For additional commands, e-mail: c-dev-h...@xerces.apache.org
[jira] Commented: (XERCESC-1668) Good schema rejected - simpleContent/complexContent
[ https://issues.apache.org/jira/browse/XERCESC-1668?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12779345#action_12779345 ] Boris Kolpackov commented on XERCESC-1668: -- Still present in the 3.1.0 codebase. Good schema rejected - simpleContent/complexContent --- Key: XERCESC-1668 URL: https://issues.apache.org/jira/browse/XERCESC-1668 Project: Xerces-C++ Issue Type: Bug Components: Validating Parser (XML Schema) Affects Versions: 3.1.0 Reporter: Jochen Schwarze Attachments: test.xml, test.xsd The attached schema does not validate the attached instance: file:///.../test.xsd:12,36: The type 'xs:anyType' specified as the base in the simpleContent element must not have complexContent Both schema and instance validate in Xerces-J 2.9 (with schema-full-checking), with MSXML 4.0 and 6.0, Saxon-SA 8.8, XSV 2.10-1 and with Alphaworks' SchemaQualityChecker. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: c-dev-unsubscr...@xerces.apache.org For additional commands, e-mail: c-dev-h...@xerces.apache.org
[jira] Closed: (XERCESC-1576) lax wildcard is handled as strict wildcard in some cases
[ https://issues.apache.org/jira/browse/XERCESC-1576?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Boris Kolpackov closed XERCESC-1576. Resolution: Invalid Please provide a test case (schema and xml files) that reproduces this problem. lax wildcard is handled as strict wildcard in some cases Key: XERCESC-1576 URL: https://issues.apache.org/jira/browse/XERCESC-1576 Project: Xerces-C++ Issue Type: Bug Components: Validating Parser (XML Schema) Affects Versions: 2.6.0 Environment: Windows VC++ Reporter: Akihiko Tozawa This bug is similar to XERCESJ-128. When reading for example, xs:any processContents=lax namespace=a b c d/, this lax is ignored and treated as strict. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: c-dev-unsubscr...@xerces.apache.org For additional commands, e-mail: c-dev-h...@xerces.apache.org
[jira] Closed: (XERCESC-1587) The default values for attributes in schema are not resolved using DOMBuilder
[ https://issues.apache.org/jira/browse/XERCESC-1587?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Boris Kolpackov closed XERCESC-1587. Resolution: Invalid Works for me. The default values for attributes in schema are not resolved using DOMBuilder - Key: XERCESC-1587 URL: https://issues.apache.org/jira/browse/XERCESC-1587 Project: Xerces-C++ Issue Type: Bug Components: Validating Parser (XML Schema) Affects Versions: 2.6.0 Reporter: Vit Ondruch I was used to use the XSD schema with default attribute values as: xs:attribute name=MaxSequenceLength type=xs:unsignedLong form=unqualified default=1 / A lot of my XML files does not contained the attributes with specified default value at all. When i used the XercesDOMParser, everything worked as expected and when i try to retrieve the value of such attribute, the default value was returned, but that does not apply for DOMBuilder unfortunatelly. The attribute is simply not found, which is wrong. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: c-dev-unsubscr...@xerces.apache.org For additional commands, e-mail: c-dev-h...@xerces.apache.org
[jira] Closed: (XERCESC-1601) SAX2 Parser throws an uncaught xercesc_2_7::XMLValid::Codes exception when setValidationConstraintFatal is on with enclosing xml tags
[
https://issues.apache.org/jira/browse/XERCESC-1601?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Boris Kolpackov closed XERCESC-1601.
Resolution: Invalid
Does not appear to be a problem with Xerces-C++.
SAX2 Parser throws an uncaught xercesc_2_7::XMLValid::Codes exception when
setValidationConstraintFatal is on with enclosing xml tags
-
Key: XERCESC-1601
URL: https://issues.apache.org/jira/browse/XERCESC-1601
Project: Xerces-C++
Issue Type: Bug
Components: Validating Parser (XML Schema)
Affects Versions: 2.7.0
Environment: Xerces 2.7 recompiled locally
Win2K, WinXP, Win2k3
Microsoft Visual Sutudio 7.1 in either debug or release builds
Reporter: Michel Courtine
I implemented a xerces SAX2 parser by following IBM's recommandations in
Make the most of Xerces-C++ found at:
http://www-128.ibm.com/developerworks/xml/library/x-xercc/
This parser works fine with large and complex files and performs a very good
validation. No complains at all.
Untill we started to use DOM generated files by a Java app that outputs this
kind of xml data:
Directory xmlns=http://www.rd.bbc.co.uk/dtv/wp4/System42;
xmlns:xsi=http://www.w3.org/2001/XMLSchema-instance; version=1
xsi:schemaLocation=http://www.rd.bbc.co.uk/dtv/wp4/System42
../schema/system42.xsd
ModuleEntry version=1 type=CODE name=LIBCORE
/ModuleEntry
ModuleEntry version=1 type=CODE name=LIBPATH
/ModuleEntry
ModuleEntry version=1 type=OPENTV_RESOURCE name=SYS_ENV
/ModuleEntry
ModuleEntry version=1 type=OPENTV_RESOURCE name=SERVICE
/ModuleEntry
ServiceInfo version=1 name=singleStreamVideo
/ServiceInfo
/Directory
When we send the following xml, with self-contained tags (one-liners)
instead of empty-enclosing tags, no exceptions are thrown and the validation
parsing are performed correctly.
Directory xmlns=http://www.rd.bbc.co.uk/dtv/wp4/System42;
xmlns:xsi=http://www.w3.org/2001/XMLSchema-instance; version=1
xsi:schemaLocation=http://www.rd.bbc.co.uk/dtv/wp4/System42
../schema/system42.xsd
ModuleEntry version=1 type=CODE name=LIBCORE /
ModuleEntry version=1 type=CODE name=LIBPATH /
ModuleEntry version=1 type=OPENTV_RESOURCE name=SYS_ENV /
ModuleEntry version=1 type=OPENTV_RESOURCE name=SERVICE /
ServiceInfo version=1 name=singleStreamVideo /
/Directory
An other interesting point for you is that when we turn
setValidationConstraintFatal to false or the validation off, the parsing is
performed correctly too.
This definately means to me that the validation considers the xml file as
invalid although both forms are supposed to be valid from an xsd point of
view.
(XMLSpy validates both versions against our xsd).
On top of that, probably because because we set setValidationConstraintFatal
to true, the exception is caught internally and fails silently preventing us
from catching it.
Here is the xsd definition of a ModuleEntry:
xs:element name=ModuleEntry
xs:annotation
xs:documentationModule entry
declaration/xs:documentation
/xs:annotation
xs:complexType
xs:attribute name=name type=xs:string
use=required/
xs:attribute name=type use=required
xs:simpleType
xs:restriction base=xs:string
xs:enumeration
value=DIRECTORY/
xs:enumeration
value=ENVIRONMENT/
xs:enumeration
value=STREAMEVENTS/
xs:enumeration
value=OPENTV_RESOURCE/
xs:enumeration
value=SYS42_RESOURCE/
xs:enumeration
value=PROPRIETARY_RESOURCE/
xs:enumeration value=CODE/
xs:enumeration value=RAW/
xs:enumeration
value=VERSIONED_RAW/
/xs:restriction
/xs:simpleType
/xs:attribute
xs:attribute name=version type=xs:unsignedInt
use=required/
/xs:complexType
/xs:element
Here are the features we set in the compilers
bool CParseMgr::parse(const char* sFilename, const char *sXsdPath)
{
CXercesInitialiser InitXerces;
m_sFilename = sFilename;
SAX2XMLReader* parser = XMLReaderFactory::createXMLReader();
[jira] Updated: (XERCESC-1715) xereces-c allows a restricted type to have mixed content, where the content type of the base is not.
[ https://issues.apache.org/jira/browse/XERCESC-1715?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Boris Kolpackov updated XERCESC-1715: - Affects Version/s: (was: 2.7.0) 3.1.0 Still present in the 3.1.0 codebase. Xerces-J 2.9.1 appears to have the same problem. xereces-c allows a restricted type to have mixed content, where the content type of the base is not. - Key: XERCESC-1715 URL: https://issues.apache.org/jira/browse/XERCESC-1715 Project: Xerces-C++ Issue Type: Bug Components: Validating Parser (XML Schema) Affects Versions: 3.1.0 Reporter: Christian Will Hi there, xereces-c allows a restricted type to have mixed content, where the content type of the base is not. sample: ?xml version=1.0? xsd:schema xmlns:xsd=http://www.w3.org/2001/XMLSchema; xsd:complexType name=A xsd:choice minOccurs=0 maxOccurs=4 xsd:group ref=x/ xsd:group ref=y/ /xsd:choice /xsd:complexType xsd:group name=x xsd:sequence xsd:element name=x1/ xsd:element name=x2/ /xsd:sequence /xsd:group xsd:group name=y xsd:choice xsd:element name=y1/ xsd:element name=y2/ /xsd:choice /xsd:group xsd:group name=G xsd:choice xsd:group ref=x/ xsd:group ref=y/ /xsd:choice /xsd:group xsd:element name=elem xsd:complexType mixed=true xsd:complexContent xsd:restriction base=A xsd:group ref=G minOccurs=0 maxOccurs=0/ /xsd:restriction /xsd:complexContent /xsd:complexType /xsd:element /xsd:schema Regards, Christian Will -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: c-dev-unsubscr...@xerces.apache.org For additional commands, e-mail: c-dev-h...@xerces.apache.org
[jira] Closed: (XERCESC-1721) Unexpected error info is reported for the group referrence(and Order indicators all is used in the group definition)
[ https://issues.apache.org/jira/browse/XERCESC-1721?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Boris Kolpackov closed XERCESC-1721. Resolution: Invalid The all compositor cannot be inside the sequence compositor. If you remove the sequence tags in the referencing type, the schema becomes valid. Unexpected error info is reported for the group referrence(and Order indicators all is used in the group definition) -- Key: XERCESC-1721 URL: https://issues.apache.org/jira/browse/XERCESC-1721 Project: Xerces-C++ Issue Type: Bug Components: Validating Parser (XML Schema) Affects Versions: 2.7.0 Environment: Windows XP Reporter: Bill Yan When a group is defined with Order indicators all, and this group is refered in a complexType definition, the schema file looks like this: xsd:schema xmlns:xsd=http://www.w3.org/2001/XMLSchema; xsd:element name=comment type=xsd:string/ xsd:group name=schemaTop3 xsd:all xsd:element ref=comment/ /xsd:all /xsd:group xsd:complexType name=PurchaseOrderType xsd:sequence xsd:group ref=schemaTop3 minOccurs=0 maxOccurs=0/ /xsd:sequence /xsd:complexType /xsd:schema when I use XercesDOMParser::loadGrammar() to check the validity of this schema file, the following error info is reported: A group whose content is 'all' must only appear as the content type of a complex type definition. - Line 11, Col 61. I tried to change xsd:all to xsd:sequence or xsd:choice, no error is reported. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: c-dev-unsubscr...@xerces.apache.org For additional commands, e-mail: c-dev-h...@xerces.apache.org
