[jira] Created: (XERCESC-1467) Socket 's' in the 'BinHTTPURLInputStream' constructor is never closed when an exception occurs.
Socket 's' in the 'BinHTTPURLInputStream' constructor is never closed when an exception occurs. --- Key: XERCESC-1467 URL: http://issues.apache.org/jira/browse/XERCESC-1467 Project: Xerces-C++ Type: Bug Components: Utilities Versions: 2.5.0 Reporter: Rogério Corrêa When an exception occurs in the constructor of the class BinHTTPURLInputStream, the socket opened in the call to 'socket' is never closed. I´m calling closesocket before every throw, but considering a socket object maybe better. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Created: (XERCESC-1521) Error in regexpr matching
Error in regexpr matching - Key: XERCESC-1521 URL: http://issues.apache.org/jira/browse/XERCESC-1521 Project: Xerces-C++ Type: Bug Components: Validating Parser (Schema) (Xerces 1.5 or up only) Versions: 2.7.0 Environment: Windows XP Professional SP2, MS Visual C++ 6.0, A newly downloaded binary distribution of Xerces-C 2.7.0 Reporter: Kasper Døring Hi I use the followin type definition: to match decimal values using the e-notation (the regexpr is not perfet I know). When I try to validate the value '1.e23' (for instance) the validation fails even though it is clearly valid. The problem disapears when I move to a Linux (Debian) platform and run the exact code. I'll gladly email some code and example XML-files Best regards Kasper Døring -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Created: (XERCESC-1562) XercesLib.mcp.xml is broken on CodeWarrior 9
XercesLib.mcp.xml is broken on CodeWarrior 9
Key: XERCESC-1562
URL: http://issues.apache.org/jira/browse/XERCESC-1562
Project: Xerces-C++
Type: Bug
Components: Build
Versions: 2.7.0
Environment: CodeWarrior 9.5 / OSX 10.4.0 / XCode 2.1 (for the Universal 10.4
SDK)
{OS X Volume} point to the Mac OS 10.4 Universal SDK root rather than / (this
is to allow replicable builds regardless of which subversion of MacOS X is
running)
Reporter: François Robert
Priority: Minor
Searching JIRA did not seem to return any existing bug report for this issue,
so here it is :
Compiling Xerces C++ 2.7.0 with CodeWarrior 9.5 is not possible out ot the box.
If you attempt to build Mach-O Framework Release (or Debug) target, you get 22
build errors, 18 of which are "identifier 'restrict' redeclared", 2 are headers
files "XObjectComparator.hpp" not found and 2 are "XTemplateComparator.hpp" not
found.
I got rid of the "identifier redeclared" by adding to the target settings the
following :
Language Settings / C/C++ Settings / Enable C99 Extensions : checked (was
unchecked)
Looking at the VC7.1project, it appears that those files are not even referred
to, so I got rid of the other 4 errors by eliminating altogether the files from
the /Xerces/internal group where they are located.
With those two modifications, the CW project compiles but does not link. You
get 8 undefined symbol errors regarding :
XMLInitializer, identityConstraintHandler; XSValue and XSAXMLScanner
Looking again at VC7.1project, I noted that the following 8 files are included
:
/internal/SAXMLScanner.cpp & .hpp
/framework/psvi/XSValue.cpp & .hpp
/validators/schema/identity/IdentityConstraintHandler.cpp & .hpp
/util/XMLInitializer.cpp & .hpp
So I added them in the corresponding groups in CW9 project and that was
sufficient to link.
FYI, there are other files not referenced in the CW9 but found in VC7 project,
apart from stuff irrelevant to CW like compiler or platform dependent files :
/internal/BinMemOutputStream.cpp & hpp
/parsers/SAX2XMLFilterImpl.cpp &.hpp
There are also quite a few .hpp and .c files in various folders (harmless ???)
not referenced either.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see:
http://www.atlassian.com/software/jira
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Commented: (XERCESC-1562) XercesLib.mcp.xml is broken on CodeWarrior 9
[
http://issues.apache.org/jira/browse/XERCESC-1562?page=comments#action_12365738
]
François Robert commented on XERCESC-1562:
--
The link issue is the same as issue XERCESC-1306.
https://issues.apache.org:443/jira/browse/XERCESC-1306
> XercesLib.mcp.xml is broken on CodeWarrior 9
>
>
> Key: XERCESC-1562
> URL: http://issues.apache.org/jira/browse/XERCESC-1562
> Project: Xerces-C++
> Type: Bug
> Components: Build
> Versions: 2.7.0
> Environment: CodeWarrior 9.5 / OSX 10.4.0 / XCode 2.1 (for the Universal
> 10.4 SDK)
> {OS X Volume} point to the Mac OS 10.4 Universal SDK root rather than / (this
> is to allow replicable builds regardless of which subversion of MacOS X is
> running)
> Reporter: François Robert
> Priority: Minor
>
> Searching JIRA did not seem to return any existing bug report for this issue,
> so here it is :
> Compiling Xerces C++ 2.7.0 with CodeWarrior 9.5 is not possible out ot the
> box.
> If you attempt to build Mach-O Framework Release (or Debug) target, you get
> 22 build errors, 18 of which are "identifier 'restrict' redeclared", 2 are
> headers files "XObjectComparator.hpp" not found and 2 are
> "XTemplateComparator.hpp" not found.
> I got rid of the "identifier redeclared" by adding to the target settings the
> following :
> Language Settings / C/C++ Settings / Enable C99 Extensions : checked (was
> unchecked)
> Looking at the VC7.1project, it appears that those files are not even
> referred to, so I got rid of the other 4 errors by eliminating altogether the
> files from the /Xerces/internal group where they are located.
> With those two modifications, the CW project compiles but does not link. You
> get 8 undefined symbol errors regarding :
> XMLInitializer, identityConstraintHandler; XSValue and XSAXMLScanner
> Looking again at VC7.1project, I noted that the following 8 files are
> included :
> /internal/SAXMLScanner.cpp & .hpp
> /framework/psvi/XSValue.cpp & .hpp
> /validators/schema/identity/IdentityConstraintHandler.cpp & .hpp
> /util/XMLInitializer.cpp & .hpp
> So I added them in the corresponding groups in CW9 project and that was
> sufficient to link.
> FYI, there are other files not referenced in the CW9 but found in VC7
> project, apart from stuff irrelevant to CW like compiler or platform
> dependent files :
> /internal/BinMemOutputStream.cpp & hpp
> /parsers/SAX2XMLFilterImpl.cpp &.hpp
> There are also quite a few .hpp and .c files in various folders (harmless
> ???) not referenced either.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see:
http://www.atlassian.com/software/jira
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Commented: (XERCESC-1306) link errors upgrading from 2.3.0 to 2.6.0 [MacOS 9.2, CodeWarrior 8.3]
[ http://issues.apache.org/jira/browse/XERCESC-1306?page=comments#action_12365746 ] François Robert commented on XERCESC-1306: -- Got the same for 2.7.0 (plus other stuff), reported in XERCESC-1562 The "half dozen files" I needed added to the project are itemized in the above mentionned issue. > link errors upgrading from 2.3.0 to 2.6.0 [MacOS 9.2, CodeWarrior 8.3] > -- > > Key: XERCESC-1306 > URL: http://issues.apache.org/jira/browse/XERCESC-1306 > Project: Xerces-C++ > Type: Bug > Components: Build > Versions: 2.6.0 > Environment: MacOS 9.2, CodeWarrior 8.3 > Reporter: Adam Heinz > Assignee: James Berry > > I built 2.6.0 without any trouble. I then tried to link my project against > the new lib, but received the errors below. My project links against 2.3.0 > without any difficulty. > Link Error : undefined: > 'xercesc_2_6::IdentityConstraintHandler::IdentityConstraintHandler(xercesc_2_6::XMLScanner*,xercesc_2_6::MemoryManager*)' > (code) > Referenced from 'xercesc_2_6::SGXMLScanner::commonInit()' in > Xerces.Classic.Dbg.Lib > Referenced from 'xercesc_2_6::IGXMLScanner::commonInit()' in > Xerces.Classic.Dbg.Lib > Link Error : undefined: 'xercesc_2_6::IdentityConstraintHandler::reset()' > (code) > Referenced from 'xercesc_2_6::SGXMLScanner::scanReset(const > xercesc_2_6::InputSource&)' in Xerces.Classic.Dbg.Lib > Referenced from 'xercesc_2_6::IGXMLScanner::scanReset(const > xercesc_2_6::InputSource&)' in Xerces.Classic.Dbg.Lib > Link Error : undefined: > 'xercesc_2_6::IdentityConstraintHandler::activateIdentityConstraint(xercesc_2_6::SchemaElementDecl*,int,unsigned > int,const unsigned short*,const > xercesc_2_6::RefVectorOf&,unsigned int)' (code) > Referenced from 'xercesc_2_6::SGXMLScanner::scanStartTag(bool&)' in > Xerces.Classic.Dbg.Lib > Referenced from 'xercesc_2_6::IGXMLScanner::scanStartTagNS(bool&)' in > Xerces.Classic.Dbg.Lib > Link Error : undefined: 'xercesc_2_6::XSValue::getActualValue(const > unsigned > short*,xercesc_2_6::XSValue::DataType,xercesc_2_6::XSValue::Status&,xercesc_2_6::XSValue::XMLVersion,bool,xercesc_2_6::MemoryManager*)' > (code) > Referenced from 'xercesc_2_6::PSVIItem::getActualValue() const' in > Xerces.Classic.Dbg.Lib > Link Error : undefined: 'xercesc_2_6::XSValue::getDataType(const unsigned > short*)' (code) > Referenced from 'xercesc_2_6::PSVIItem::getActualValue() const' in > Xerces.Classic.Dbg.Lib > Link Error : undefined: > 'xercesc_2_6::XSAXMLScanner::XSAXMLScanner(xercesc_2_6::GrammarResolver*,xercesc_2_6::XMLStringPool*,xercesc_2_6::SchemaGrammar*,xercesc_2_6::MemoryManager*)' > (code) > Referenced from 'xercesc_2_6::TraverseSchema::validateAnnotations()' in > Xerces.Classic.Dbg.Lib > Link Error : undefined: > 'xercesc_2_6::IdentityConstraintHandler::deactivateContext(xercesc_2_6::SchemaElementDecl*,const > unsigned short*)' (code) > Referenced from 'xercesc_2_6::SGXMLScanner::scanEndTag(bool&)' in > Xerces.Classic.Dbg.Lib > Referenced from 'xercesc_2_6::SGXMLScanner::scanStartTag(bool&)' in > Xerces.Classic.Dbg.Lib > Referenced from 'xercesc_2_6::IGXMLScanner::scanStartTagNS(bool&)' in > Xerces.Classic.Dbg.Lib > Referenced from 'xercesc_2_6::IGXMLScanner::scanEndTag(bool&)' in > Xerces.Classic.Dbg.Lib -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Created: (XERCESC-1593) critical Warning on compiling XercesC 2.7.0
critical Warning on compiling XercesC 2.7.0 --- Key: XERCESC-1593 URL: http://issues.apache.org/jira/browse/XERCESC-1593 Project: Xerces-C++ Type: Bug Components: Build Versions: 2.7.0 Environment: MSVC 2003 (7.1) Set Warning Level to 4 Reporter: Lukas Grützmacher I've compiled XercesC 2.7.0 from sources with MSVC2003. I've changed the project settings to use always warning level 4. Thereby I found a lot of warnings. IMHO some of them are critical: xerces-c-src_2_7_0\src\xercesc\validators\schema\traverseschema.cpp(6490) : warning C4701: local variable 'defAttType' may be used without having been initialized xerces-c-src_2_7_0\src\xercesc\util\regx\token.cpp(259) : warning C4701: local variable 'ret2' may be used without having been initialized xerces-c-src_2_7_0\src\xercesc\util\regx\RegularExpression.cpp(184) : warning C4244: 'argument' : conversion from 'XMLInt32' to 'const XMLCh', possible loss of data xerces-c-src_2_7_0\src\xercesc\util\platforms\win32\win32platformutils.cpp(795) : warning C4701: local variable 'retVal' may be used without having been initialized xerces-c-src_2_7_0\tests\xserializertest\xserializertest.cpp(537) : warning C4701: local variable 'duration' may be used without having been initialized Many others are not critical but sould be fixed, too. Here are some examples: DFAContentModel.cpp ..\..\..\..\..\src\xercesc\validators\common\CMNode.hpp(129) : warning C4245: 'initializing' : conversion from 'int' to 'unsigned int', signed/unsigned mismatch xerces-c-src_2_7_0\src\xercesc\internal\XSAXMLScanner.cpp(310) : warning C4245: 'argument' : conversion from '' to 'unsigned int', signed/unsigned mismatch xerces-c-src_2_7_0\src\xercesc\framework\psvi\XSValue.cpp(1721) : warning C4189: 'strLen' : local variable is initialized but not referenced xerces-c-src_2_7_0\src\xercesc\dom\deprecated\DOM_RangeException.cpp(36) : warning C4244: 'argument' : conversion from 'xercesc_2_7::DOM_RangeException::RangeExceptionCode' to 'short', possible loss of data -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Commented: (XERCESC-1593) critical Warning on compiling XercesC 2.7.0
[ http://issues.apache.org/jira/browse/XERCESC-1593?page=comments#action_12379078 ] Lukas Grützmacher commented on XERCESC-1593: It may be safe in special case. But do you want to analyze each time all warnings? My recommendation is to make the code always warning free. What is the problem to initialize all these variables? > critical Warning on compiling XercesC 2.7.0 > --- > > Key: XERCESC-1593 > URL: http://issues.apache.org/jira/browse/XERCESC-1593 > Project: Xerces-C++ > Type: Bug > Components: Build > Versions: 2.7.0 > Environment: MSVC 2003 (7.1) > Set Warning Level to 4 > Reporter: Lukas Grützmacher > > I've compiled XercesC 2.7.0 from sources with MSVC2003. > I've changed the project settings to use always warning level 4. > Thereby I found a lot of warnings. IMHO some of them are critical: > xerces-c-src_2_7_0\src\xercesc\validators\schema\traverseschema.cpp(6490) : > warning C4701: local variable 'defAttType' may be used without having been > initialized > xerces-c-src_2_7_0\src\xercesc\util\regx\token.cpp(259) : warning C4701: > local variable 'ret2' may be used without having been initialized > xerces-c-src_2_7_0\src\xercesc\util\regx\RegularExpression.cpp(184) : warning > C4244: 'argument' : conversion from 'XMLInt32' to 'const XMLCh', possible > loss of data > xerces-c-src_2_7_0\src\xercesc\util\platforms\win32\win32platformutils.cpp(795) > : warning C4701: local variable 'retVal' may be used without having been > initialized > xerces-c-src_2_7_0\tests\xserializertest\xserializertest.cpp(537) : warning > C4701: local variable 'duration' may be used without having been initialized > Many others are not critical but sould be fixed, too. Here are some examples: > DFAContentModel.cpp > ..\..\..\..\..\src\xercesc\validators\common\CMNode.hpp(129) : warning C4245: > 'initializing' : conversion from 'int' to 'unsigned int', signed/unsigned > mismatch > xerces-c-src_2_7_0\src\xercesc\internal\XSAXMLScanner.cpp(310) : warning > C4245: 'argument' : conversion from '' to 'unsigned int', signed/unsigned > mismatch > xerces-c-src_2_7_0\src\xercesc\framework\psvi\XSValue.cpp(1721) : warning > C4189: 'strLen' : local variable is initialized but not referenced > xerces-c-src_2_7_0\src\xercesc\dom\deprecated\DOM_RangeException.cpp(36) : > warning C4244: 'argument' : conversion from > 'xercesc_2_7::DOM_RangeException::RangeExceptionCode' to 'short', possible > loss of data -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Commented: (XERCESC-1593) critical Warning on compiling XercesC 2.7.0
[
http://issues.apache.org/jira/browse/XERCESC-1593?page=comments#action_12383179
]
Lukas Grützmacher commented on XERCESC-1593:
I've checked again now the code at traverseschema.cpp:6490. Now I agree that
the code looks safe now. But it is really hard to understand.
I know there are many compilers in the world. But I think MSVC is one of the
major compilers for the Windows platform ("your" binary release is also build
by MSVC, isn't it?). So why not take advantages from this compiler. Yes, it has
not found out that the code is currently safe. But I was also not able to see
this first time ;)
I want to explain my target "always warning free". In the past I've made the
experiance that compiling in warning level 4 can really find problems in the
code, e.g. unititialized values which really occur. So we (my company) has
decided to enforce level 4. Then it is easier to fix all warnings instead of
reviewing all warnings each time of recompile.
Further: Now you have checked that the warning at traverseschema.cpp:6490 is
not critical and you keep this state in your mind. Later on somebody changes
the code around so that is not safe anymore. But you may not check anymore this
warning and you may really run into problems.
For the problem of initial values I want to give an example:
change
XMLAttDef::DefAttTypes defAttType; (traverseschema.cpp:6449)
to
XMLAttDef::DefAttTypes defAttType = XMLAttDef::DefAttTypes_Unknown;
In the case the value is really not overwritten and so used with
DefAttTypes_Unknown it is better to check against DefAttTypes_Unknown instead
of checking all other expected values. If it is really always overwritten so
this "costs" are only "DWORD PTR _defAttType$27151[ebp], -1".
> critical Warning on compiling XercesC 2.7.0
> ---
>
> Key: XERCESC-1593
> URL: http://issues.apache.org/jira/browse/XERCESC-1593
> Project: Xerces-C++
> Type: Bug
> Components: Build
> Versions: 2.7.0
> Environment: MSVC 2003 (7.1)
> Set Warning Level to 4
> Reporter: Lukas Grützmacher
>
> I've compiled XercesC 2.7.0 from sources with MSVC2003.
> I've changed the project settings to use always warning level 4.
> Thereby I found a lot of warnings. IMHO some of them are critical:
> xerces-c-src_2_7_0\src\xercesc\validators\schema\traverseschema.cpp(6490) :
> warning C4701: local variable 'defAttType' may be used without having been
> initialized
> xerces-c-src_2_7_0\src\xercesc\util\regx\token.cpp(259) : warning C4701:
> local variable 'ret2' may be used without having been initialized
> xerces-c-src_2_7_0\src\xercesc\util\regx\RegularExpression.cpp(184) : warning
> C4244: 'argument' : conversion from 'XMLInt32' to 'const XMLCh', possible
> loss of data
> xerces-c-src_2_7_0\src\xercesc\util\platforms\win32\win32platformutils.cpp(795)
> : warning C4701: local variable 'retVal' may be used without having been
> initialized
> xerces-c-src_2_7_0\tests\xserializertest\xserializertest.cpp(537) : warning
> C4701: local variable 'duration' may be used without having been initialized
> Many others are not critical but sould be fixed, too. Here are some examples:
> DFAContentModel.cpp
> ..\..\..\..\..\src\xercesc\validators\common\CMNode.hpp(129) : warning C4245:
> 'initializing' : conversion from 'int' to 'unsigned int', signed/unsigned
> mismatch
> xerces-c-src_2_7_0\src\xercesc\internal\XSAXMLScanner.cpp(310) : warning
> C4245: 'argument' : conversion from '' to 'unsigned int', signed/unsigned
> mismatch
> xerces-c-src_2_7_0\src\xercesc\framework\psvi\XSValue.cpp(1721) : warning
> C4189: 'strLen' : local variable is initialized but not referenced
> xerces-c-src_2_7_0\src\xercesc\dom\deprecated\DOM_RangeException.cpp(36) :
> warning C4244: 'argument' : conversion from
> 'xercesc_2_7::DOM_RangeException::RangeExceptionCode' to 'short', possible
> loss of data
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see:
http://www.atlassian.com/software/jira
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Created: (XERCESC-1647) Parsing of a 40MB xml string leads to use 500MB RAM memory
Parsing of a 40MB xml string leads to use 500MB RAM memory -- Key: XERCESC-1647 URL: http://issues.apache.org/jira/browse/XERCESC-1647 Project: Xerces-C++ Issue Type: Improvement Components: DOM Affects Versions: 2.7.0 Environment: Windows 2000/Windows XP; Visual C++6 Reporter: Cédric Dutoit When I parse a 40MB xml string using a dombuilder and a membufinputsource/wrapper4inputsource, the parser is taking 500MB of RAM. The normal behaviour would be to use around 40MB of RAM only. Here is an extract of the source code I'm using : string xml(...); DOMBuilder* parser = ((XML_NQ DOMImplementationLS*)impl)->createDOMBuilder(XML_NQ DOMImplementationLS::MODE_SYNCHRONOUS, 0); parser->setFeature(XML_NQ XMLUni::fgDOMNamespaces, false); parser->setFeature(XML_NQ XMLUni::fgXercesSchema, false); parser->setFeature(XML_NQ XMLUni::fgXercesSchemaFullChecking, false); MemBufInputSource source(reinterpret_cast(xml.c_str()), xml.size(), "InputSource"); Wrapper4InputSource wis(&source, false); doc = parser->parse(wis); Or perhaps there is another way of parsing xml string using DOM ? I'd like to have mode_asynchronous, but I've seen that this is not yet supported by Xerces-c, unfortunately... Cédric D. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Created: (XERCESC-1767) Output of XMLString::transcode not freed?
Output of XMLString::transcode not freed?
-
Key: XERCESC-1767
URL: https://issues.apache.org/jira/browse/XERCESC-1767
Project: Xerces-C++
Issue Type: Bug
Components: Documentation
Environment: The Xerces-C++ webpage
Reporter: Mateusz Czapliński
Priority: Trivial
In the example code snippet at
http://xerces.apache.org/xerces-c/program-sax.html
there's a fragment as follows:
void MySAXHandler::fatalError(const SAXParseException& exception)
{
char* message = XMLString::transcode(exception.getMessage());
cout << "Fatal Error: " << message
<< " at line: " << exception.getLineNumber()
<< endl;
}
This seems to contradict the claim in XMLString.hpp that the caller of
XMLString::transcode() is responsible for freeing the memory.
If there's some reason why this is OK there, it should be clearly stated.
Especially as this is a basic hello-world-like example lots of people will
presumably start with - and now it might be understood as "Oh, that's not
really so important to free this memory, you know."
--
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: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Created: (XERCESC-1768) xerces-c++ 2.8.0 fails to build when choosing IconvGNU as message loader on 64bit architecture
xerces-c++ 2.8.0 fails to build when choosing IconvGNU as message loader on 64bit architecture -- Key: XERCESC-1768 URL: https://issues.apache.org/jira/browse/XERCESC-1768 Project: Xerces-C++ Issue Type: Bug Affects Versions: 2.8.0 Environment: Gentoo Linux 2007.0 amd64 Reporter: Tiziano Müller [...] MsgCatalogLoader.cpp: In constructor 'xercesc_2_8::MsgCatalogLoader::MsgCatalogLoader(const XMLCh*)': MsgCatalogLoader.cpp:103: error: cast from 'void*' to 'int' loses precision MsgCatalogLoader.cpp:104: error: cast from 'void*' to 'int' loses precision make[2]: *** [MsgCatalogLoader.o] Error 1 make[1]: *** [messageloaders] Error 2 make: *** [Util] Error 2 make: *** Waiting for unfinished jobs (C++) XSObject.o (C++) XSParticle.o (C++) XSSimpleTypeDefinition.o (C++) XSTypeDefinition.o (C++) XSValue.o (C++) XSWildcard.o (CP) /var/tmp/paludis/dev-libs/xerces-c-2.8.0/work/xerces-c-src_2_8_0/include/xercesc/framework/psvi I'd guess that this is also the reason for bug XERCESC-1586 -- 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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Commented: (XERCESC-1768) xerces-c++ 2.8.0 fails to build when choosing IconvGNU as message loader on 64bit architecture
[ https://issues.apache.org/jira/browse/XERCESC-1768?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12553459 ] Tiziano Müller commented on XERCESC-1768: - Hmm, maybe not. Replacing (int) by a (long) solved the issue and seems more portable... > xerces-c++ 2.8.0 fails to build when choosing IconvGNU as message loader on > 64bit architecture > -- > > Key: XERCESC-1768 > URL: https://issues.apache.org/jira/browse/XERCESC-1768 > Project: Xerces-C++ > Issue Type: Bug >Affects Versions: 2.8.0 > Environment: Gentoo Linux 2007.0 amd64 >Reporter: Tiziano Müller > > [...] > MsgCatalogLoader.cpp: In constructor > 'xercesc_2_8::MsgCatalogLoader::MsgCatalogLoader(const XMLCh*)': > MsgCatalogLoader.cpp:103: error: cast from 'void*' to 'int' loses precision > MsgCatalogLoader.cpp:104: error: cast from 'void*' to 'int' loses precision > make[2]: *** [MsgCatalogLoader.o] Error 1 > make[1]: *** [messageloaders] Error 2 > make: *** [Util] Error 2 > make: *** Waiting for unfinished jobs > (C++) XSObject.o > (C++) XSParticle.o > (C++) XSSimpleTypeDefinition.o > (C++) XSTypeDefinition.o > (C++) XSValue.o > (C++) XSWildcard.o > (CP) > /var/tmp/paludis/dev-libs/xerces-c-2.8.0/work/xerces-c-src_2_8_0/include/xercesc/framework/psvi > I'd guess that this is also the reason for bug XERCESC-1586 -- 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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Created: (XERCESC-1769) xerces-c++ 2.8.0 ICU message loader broken due to deprecated API usage and various other problems
xerces-c++ 2.8.0 ICU message loader broken due to deprecated API usage and various other problems - Key: XERCESC-1769 URL: https://issues.apache.org/jira/browse/XERCESC-1769 Project: Xerces-C++ Issue Type: Bug Affects Versions: 2.8.0 Environment: Gentoo Linux 2007.0 AMD64, ICU 3.6 and 3.8 Reporter: Tiziano Müller a) the .res-file can't be used as a fallback if the memory-blob can't be loaded, but it should be the .dat-file (as far as I understood it) b) loading the messages using a full file-path is deprecated (according to http://www.icu-project.org/apiref/icu4c/ures_8h.html#c4d72fc9f7cc63a05f646cabee4be167) and it really doesn't work c) When using "make install" to install the library, the library libXercesMessages.so.28.0 doesn't get installed which leads to a unresolved symbol error when linking against libxerces-c.so.28.0 d) When trying to run a test or a sample linked against xerces-c++ built with ICU message loader support, xerces-c++ panics with the error "Cannot load message domain", whether or not libXercesMessages and the .res/.dat-file in /usr/msg are available or not. The patch I'm going to attach fixes this. -- 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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Updated: (XERCESC-1769) xerces-c++ 2.8.0 ICU message loader broken due to deprecated API usage and various other problems
[ https://issues.apache.org/jira/browse/XERCESC-1769?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tiziano Müller updated XERCESC-1769: Attachment: xerces-c-2.8.0-icu_ressource_fix.patch As written above: the attached patch makes it possible to use ICU as a message loader. > xerces-c++ 2.8.0 ICU message loader broken due to deprecated API usage and > various other problems > - > > Key: XERCESC-1769 > URL: https://issues.apache.org/jira/browse/XERCESC-1769 > Project: Xerces-C++ > Issue Type: Bug >Affects Versions: 2.8.0 > Environment: Gentoo Linux 2007.0 AMD64, ICU 3.6 and 3.8 >Reporter: Tiziano Müller > Attachments: xerces-c-2.8.0-icu_ressource_fix.patch > > > a) the .res-file can't be used as a fallback if the memory-blob can't be > loaded, but it should be the .dat-file (as far as I understood it) > b) loading the messages using a full file-path is deprecated (according to > http://www.icu-project.org/apiref/icu4c/ures_8h.html#c4d72fc9f7cc63a05f646cabee4be167) > and it really doesn't work > c) When using "make install" to install the library, the library > libXercesMessages.so.28.0 doesn't get installed which leads to a unresolved > symbol error when linking against libxerces-c.so.28.0 > d) When trying to run a test or a sample linked against xerces-c++ built with > ICU message loader support, xerces-c++ panics with the error "Cannot load > message domain", whether or not libXercesMessages and the .res/.dat-file in > /usr/msg are available or not. The patch I'm going to attach fixes this. -- 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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Commented: (XERCESC-1769) xerces-c++ 2.8.0 ICU message loader broken due to deprecated API usage and various other problems
[ https://issues.apache.org/jira/browse/XERCESC-1769?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12574480#action_12574480 ] Tiziano Müller commented on XERCESC-1769: - Thats correct. I corrected those issues in our ebuilds (packages). Sorry that I didn't answer your first question, but I was quite busy at that time. > xerces-c++ 2.8.0 ICU message loader broken due to deprecated API usage and > various other problems > - > > Key: XERCESC-1769 > URL: https://issues.apache.org/jira/browse/XERCESC-1769 > Project: Xerces-C++ > Issue Type: Bug >Affects Versions: 2.8.0 > Environment: Gentoo Linux 2007.0 AMD64, ICU 3.6 and 3.8 >Reporter: Tiziano Müller > Fix For: 3.0.0, 2.9.0 > > Attachments: xerces-c-2.8.0-icu_ressource_fix.patch > > > a) the .res-file can't be used as a fallback if the memory-blob can't be > loaded, but it should be the .dat-file (as far as I understood it) > b) loading the messages using a full file-path is deprecated (according to > http://www.icu-project.org/apiref/icu4c/ures_8h.html#c4d72fc9f7cc63a05f646cabee4be167) > and it really doesn't work > c) When using "make install" to install the library, the library > libXercesMessages.so.28.0 doesn't get installed which leads to a unresolved > symbol error when linking against libxerces-c.so.28.0 > d) When trying to run a test or a sample linked against xerces-c++ built with > ICU message loader support, xerces-c++ panics with the error "Cannot load > message domain", whether or not libXercesMessages and the .res/.dat-file in > /usr/msg are available or not. The patch I'm going to attach fixes this. -- 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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Created: (XERCESC-1809) seg fault on 64bit
seg fault on 64bit
--
Key: XERCESC-1809
URL: https://issues.apache.org/jira/browse/XERCESC-1809
Project: Xerces-C++
Issue Type: Bug
Affects Versions: 2.8.0
Environment: Gentoo-Linux (emerge --version -> Portage 2.1.4.4
(default-linux/amd64/2007.0, gcc-4.1.2, glibc-2.6.1-r0, 2.6.21-gentoo-r4
x86_64))
Reporter: Guido Jäkel
I try to advance the Gentoo ebuild for dbxml to 2.4.13. For that, Xerces-C
2.8.0 and XQuilla is a prerequesite. The Gentoo ebuild for Xerces-C have been
tweeked to include the patches for XQilla this days. Now i'm able to build
dbxml on 32bit and 64bit. On 32bit it seems to work from the first tests, but
on 64bit even a simple "dbxml -v" dies with an segmentation fault.
With gdb, i got the following stack trace:
{code}
#0 0x2abcb1fe6c2c in ?? () from /lib/libc.so.6
#1 0x2abcb14f5de0 in xercesc_2_8::XMLString::parseInt () from
/usr/lib/libxerces-c.so.28
#2 0x2abcb13b3bbd in xercesc_2_8::AbstractStringValidator::assignFacet ()
from /usr/lib/libxerces-c.so.28
#3 0x2abcb13b411d in xercesc_2_8::AbstractStringValidator::init () from
/usr/lib/libxerces-c.so.28
#4 0x2abcb144cfe0 in
xercesc_2_8::ListDatatypeValidator::ListDatatypeValidator () from
/usr/lib/libxerces-c.so.28
#5 0x2abcb141837e in
xercesc_2_8::DatatypeValidatorFactory::createDatatypeValidator () from
/usr/lib/libxerces-c.so.28
#6 0x2abcb14198f9 in
xercesc_2_8::DatatypeValidatorFactory::expandRegistryToFullSchemaSet ()
from /usr/lib/libxerces-c.so.28
#7 0x2abcb097e733 in XQillaPlatformUtils::initialize () from
/usr/lib/libxqilla.so.4
#8 0x2abcb00d9fff in DbXml::Globals::initializeXmlPlatform () from
/usr/lib/libdbxml-2.4.so
#9 0x2abcb00da53f in DbXml::Globals::initialize () from
/usr/lib/libdbxml-2.4.so
#10 0x2abcb00df043 in DbXml::Manager::Manager () from
/usr/lib/libdbxml-2.4.so
#11 0x2abcb00d8fca in DbXml::XmlManager::XmlManager () from
/usr/lib/libdbxml-2.4.so
#12 0x0040c259 in ?? ()
#13 0x2abcb1fd0b74 in __libc_start_main () from /lib/libc.so.6
#14 0x0040ba39 in ?? ()
#15 0x7ad47148 in ?? ()
#16 0x in ?? ()
{code}
>From that, i *guess* that it break's HERE, because this looks like a libc-call
>to me.
.../xerces-c-src/src/xercesc/util/XMLString.cpp:
{code}
int XMLString::parseInt(const XMLCh* const toConvert
, MemoryManager* const manager)
{
// If no string, or empty string, then it is a failure
if ((!toConvert) || (!*toConvert))
ThrowXMLwithMemMgr(NumberFormatException, XMLExcepts::XMLNUM_null_ptr,
manager);
XMLCh* trimmedStr = XMLString::replicate(toConvert, manager);
ArrayJanitor jan1(trimmedStr, manager);
XMLString::trim(trimmedStr);
unsigned int trimmedStrLen = XMLString::stringLen(trimmedStr);
if ( !trimmedStrLen )
ThrowXMLwithMemMgr(NumberFormatException, XMLExcepts::XMLNUM_null_ptr,
manager);
//the errno set by previous run is NOT automatically cleared
errno = 0;
char *nptr = XMLString::transcode(trimmedStr, manager);
ArrayJanitor jan2(nptr, manager);
char *endptr;
long retVal = strtol(nptr, &endptr, 10); <-[HERE]
// check if all chars are valid char
if ( (endptr - nptr) != (int) trimmedStrLen)
ThrowXMLwithMemMgr(NumberFormatException,
XMLExcepts::XMLNUM_Inv_chars, manager);
// check if overflow/underflow occurs
if (errno == ERANGE)
ThrowXMLwithMemMgr(NumberFormatException,
XMLExcepts::Str_ConvertOverflow, manager);
//
// REVISIT: conversion of (long) to (int)
// may truncate value on IA64
return (int) retVal;
}
{code}
May please anybody give me a hint how to get it running on 64bit? Feel free to
ask for further information you'll need,
thank you
Guido
--
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: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Updated: (XERCESC-1809) seg fault on 64bit
[
https://issues.apache.org/jira/browse/XERCESC-1809?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Guido Jäkel updated XERCESC-1809:
-
Description:
I try to advance the Gentoo ebuild for dbxml to 2.4.13. For that, Xerces-C
2.8.0 and XQuilla is a prerequesite. The Gentoo ebuild for Xerces-C have been
tweeked to include the patches for XQilla this days. Now i'm able to build
dbxml on 32bit and 64bit. On 32bit it seems to work from the first tests, but
on 64bit even a simple "dbxml -v" dies with an segmentation fault.
With gdb, i got the following stack trace:
#0 0x2abcb1fe6c2c in ?? () from /lib/libc.so.6
#1 0x2abcb14f5de0 in xercesc_2_8::XMLString::parseInt () from
/usr/lib/libxerces-c.so.28
#2 0x2abcb13b3bbd in xercesc_2_8::AbstractStringValidator::assignFacet ()
from /usr/lib/libxerces-c.so.28
#3 0x2abcb13b411d in xercesc_2_8::AbstractStringValidator::init () from
/usr/lib/libxerces-c.so.28
#4 0x2abcb144cfe0 in
xercesc_2_8::ListDatatypeValidator::ListDatatypeValidator () from
/usr/lib/libxerces-c.so.28
#5 0x2abcb141837e in
xercesc_2_8::DatatypeValidatorFactory::createDatatypeValidator () from
/usr/lib/libxerces-c.so.28
#6 0x2abcb14198f9 in
xercesc_2_8::DatatypeValidatorFactory::expandRegistryToFullSchemaSet ()
from /usr/lib/libxerces-c.so.28
#7 0x2abcb097e733 in XQillaPlatformUtils::initialize () from
/usr/lib/libxqilla.so.4
#8 0x2abcb00d9fff in DbXml::Globals::initializeXmlPlatform () from
/usr/lib/libdbxml-2.4.so
#9 0x2abcb00da53f in DbXml::Globals::initialize () from
/usr/lib/libdbxml-2.4.so
#10 0x2abcb00df043 in DbXml::Manager::Manager () from
/usr/lib/libdbxml-2.4.so
#11 0x2abcb00d8fca in DbXml::XmlManager::XmlManager () from
/usr/lib/libdbxml-2.4.so
#12 0x0040c259 in ?? ()
#13 0x2abcb1fd0b74 in __libc_start_main () from /lib/libc.so.6
#14 0x0040ba39 in ?? ()
#15 0x7ad47148 in ?? ()
#16 0x in ?? ()
>From that, i *guess* that it break's HERE, because this looks like a libc-call
>to me.
.../xerces-c-src/src/xercesc/util/XMLString.cpp:
int XMLString::parseInt(const XMLCh* const toConvert
, MemoryManager* const manager)
{
// If no string, or empty string, then it is a failure
if ((!toConvert) || (!*toConvert))
ThrowXMLwithMemMgr(NumberFormatException, XMLExcepts::XMLNUM_null_ptr,
manager);
XMLCh* trimmedStr = XMLString::replicate(toConvert, manager);
ArrayJanitor jan1(trimmedStr, manager);
XMLString::trim(trimmedStr);
unsigned int trimmedStrLen = XMLString::stringLen(trimmedStr);
if ( !trimmedStrLen )
ThrowXMLwithMemMgr(NumberFormatException, XMLExcepts::XMLNUM_null_ptr,
manager);
//the errno set by previous run is NOT automatically cleared
errno = 0;
char *nptr = XMLString::transcode(trimmedStr, manager);
ArrayJanitor jan2(nptr, manager);
char *endptr;
long retVal = strtol(nptr, &endptr, 10); <-[HERE]
// check if all chars are valid char
if ( (endptr - nptr) != (int) trimmedStrLen)
ThrowXMLwithMemMgr(NumberFormatException,
XMLExcepts::XMLNUM_Inv_chars, manager);
// check if overflow/underflow occurs
if (errno == ERANGE)
ThrowXMLwithMemMgr(NumberFormatException,
XMLExcepts::Str_ConvertOverflow, manager);
//
// REVISIT: conversion of (long) to (int)
// may truncate value on IA64
return (int) retVal;
}
May please anybody give me a hint how to get it running on 64bit? Feel free to
ask for further information you'll need,
thank you
Guido
was:
I try to advance the Gentoo ebuild for dbxml to 2.4.13. For that, Xerces-C
2.8.0 and XQuilla is a prerequesite. The Gentoo ebuild for Xerces-C have been
tweeked to include the patches for XQilla this days. Now i'm able to build
dbxml on 32bit and 64bit. On 32bit it seems to work from the first tests, but
on 64bit even a simple "dbxml -v" dies with an segmentation fault.
With gdb, i got the following stack trace:
{code}
#0 0x2abcb1fe6c2c in ?? () from /lib/libc.so.6
#1 0x2abcb14f5de0 in xercesc_2_8::XMLString::parseInt () from
/usr/lib/libxerces-c.so.28
#2 0x2abcb13b3bbd in xercesc_2_8::AbstractStringValidator::assignFacet ()
from /usr/lib/libxerces-c.so.28
#3 0x2abcb13b411d in xercesc_2_8::AbstractStringValidator::init () from
/usr/lib/libxerces-c.so.28
#4 0x2abcb144cfe0 in
xercesc_2_8::ListDatatypeValidator::ListDatatypeValidator () from
/usr/lib/libxerces-c.so.28
#5 0x2abcb141837e in
xercesc_2_8::DatatypeValidatorFactory::createDatatypeValidator () from
/usr/lib/libxerces-c.so.28
#6 0x2abcb14198f9 in
xercesc_2_8::DatatypeValidatorFactory::expandRegistryToFullSchemaSet ()
from /usr/lib/libxerces-c.so.28
#7 0x2abcb097e733 in XQillaPlatformUtils::initialize (
[jira] Commented: (XERCESC-1809) seg fault on 64bit
[
https://issues.apache.org/jira/browse/XERCESC-1809?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12604502#action_12604502
]
Guido Jäkel commented on XERCESC-1809:
--
Dear Boris,
... and the other will point me here, because it crashes in Xerces! Following
your sugesstion, i have let build the Xerces test programms.
All from the test suite fails with an similar error. Here's the console
printout of the first of the tested programs. Even StdInParse will fail with
the same. This will fority that my problem with dbxml is cored here in Xerces-C.
And yes, this is the right path to the file - you'll see it from the following
run through strace. May this help to find any hints to me?
thank you
Guido
-
[EMAIL PROTECTED]
/var/tmp/portage/dev-libs/xerces-c-2.8.0/work/xerces-c-src_2_8_0/scripts #
SAX2Count ../samples/data/personal.xml
Fatal Error at file , line 0, char 0
Message: An exception occurred! Type:RuntimeException, Message: The primary
document entity could not be opened.
Id=/var/tmp/portage/dev-libs/xerces-c-2.8.0/work/xerces-c-src_2_8_0/samples/data/personal.xml
[EMAIL PROTECTED]
/var/tmp/portage/dev-libs/xerces-c-2.8.0/work/xerces-c-src_2_8_0/scripts #
strace SAX2Count ../samples/data/personal.xml
execve("/var/tmp/portage/dev-libs/xerces-c-2.8.0/work/xerces-c-src_2_8_0//bin/SAX2Count",
["SAX2Count", "../samples/data/personal.xml"...], [/* 37 vars */]) = 0
brk(0) = 0x60a000
mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) =
0x2afadfd48000
uname({sys="Linux", node="leo2", ...}) = 0
access("/etc/ld.so.preload", R_OK) = -1 ENOENT (No such file or directory)
open("/etc/ld.so.cache", O_RDONLY) = 3
fstat(3, {st_mode=S_IFREG|0644, st_size=24304, ...}) = 0
mmap(NULL, 24304, PROT_READ, MAP_PRIVATE, 3, 0) = 0x2afadfd49000
close(3)= 0
open("/usr/lib/libxerces-c.so.28", O_RDONLY) = 3
read(3,
"\177ELF\2\1\1\0\0\0\0\0\0\0\0\0\3\0>\0\1\0\0\0\340\207\30\0\0\0\0\0"..., 832)
= 832
fstat(3, {st_mode=S_IFREG|0755, st_size=4189264, ...}) = 0
mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) =
0x2afadfd4f000
mmap(NULL, 6287960, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_DENYWRITE, 3, 0) =
0x2afadff49000
mprotect(0x2afae0304000, 2093056, PROT_NONE) = 0
mmap(0x2afae0503000, 282624, PROT_READ|PROT_WRITE,
MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3, 0x3ba000) = 0x2afae0503000
mmap(0x2afae0548000, 600, PROT_READ|PROT_WRITE,
MAP_PRIVATE|MAP_FIXED|MAP_ANONYMOUS, -1, 0) = 0x2afae0548000
close(3)= 0
open("/lib/libpthread.so.0", O_RDONLY) = 3
read(3, "\177ELF\2\1\1\0\0\0\0\0\0\0\0\0\3\0>\0\1\0\0\0\260W\0\0\0\0\0\0"...,
832) = 832
fstat(3, {st_mode=S_IFREG|0755, st_size=131577, ...}) = 0
mmap(NULL, 2204528, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_DENYWRITE, 3, 0) =
0x2afae0549000
mprotect(0x2afae055e000, 2097152, PROT_NONE) = 0
mmap(0x2afae075e000, 8192, PROT_READ|PROT_WRITE,
MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3, 0x15000) = 0x2afae075e000
mmap(0x2afae076, 13168, PROT_READ|PROT_WRITE,
MAP_PRIVATE|MAP_FIXED|MAP_ANONYMOUS, -1, 0) = 0x2afae076
close(3)= 0
open("/usr/lib/gcc/x86_64-pc-linux-gnu/4.1.2/libstdc++.so.6", O_RDONLY) = 3
read(3, "\177ELF\2\1\1\0\0\0\0\0\0\0\0\0\3\0>[EMAIL PROTECTED]"..., 832) = 832
fstat(3, {st_mode=S_IFREG|0755, st_size=985888, ...}) = 0
mmap(NULL, 3157792, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_DENYWRITE, 3, 0) =
0x2afae0764000
mprotect(0x2afae084c000, 2097152, PROT_NONE) = 0
mmap(0x2afae0a4c000, 36864, PROT_READ|PROT_WRITE,
MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3, 0xe8000) = 0x2afae0a4c000
mmap(0x2afae0a55000, 73504, PROT_READ|PROT_WRITE,
MAP_PRIVATE|MAP_FIXED|MAP_ANONYMOUS, -1, 0) = 0x2afae0a55000
close(3)= 0
open("/lib/libm.so.6", O_RDONLY)= 3
read(3, "\177ELF\2\1\1\0\0\0\0\0\0\0\0\0\3\0>\0\1\0\0\0\0?\0\0\0\0\0\0"...,
832) = 832
fstat(3, {st_mode=S_IFREG|0755, st_size=526472, ...}) = 0
mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) =
0x2afae0a67000
mmap(NULL, 2621672, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_DENYWRITE, 3, 0) =
0x2afae0a68000
mprotect(0x2afae0ae8000, 2093056, PROT_NONE) = 0
mmap(0x2afae0ce7000, 8192, PROT_READ|PROT_WRITE,
MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3, 0x7f000) = 0x2afae0ce7000
close(3)= 0
open("/lib/libgcc_s.so.1", O_RDONLY)= 3
read(3, "\177ELF\2\1\1\0\0\0\0\0\0\0\0\0\3\0>\0\1\0\0\0\360\37\0\0\0\0\0\0"...,
832) = 832
fstat(3, {st_mode=S_IFREG|0644, st_size=55400, ...}) = 0
mmap(NULL, 2151240, PROT_READ|PROT_EXE
[jira] Commented: (XERCESC-1809) seg fault on 64bit
[
https://issues.apache.org/jira/browse/XERCESC-1809?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12606276#action_12606276
]
Guido Jäkel commented on XERCESC-1809:
--
Dear Boris,
Yes, it was compiled with iconv support. This is easy switchable in the Gentoo
ebuild via a USE-flag "iconv". I let build Xerces-C++ without it. And now, the
dbxml cli starts working !!!
What did i lost with the iconv: Just language support for error messages? And
which is the bugtracker to approach with the issue, now? In former times, there
was a seperate libiconv, but now it seems to be a part of libc, right?
Thank you a lot, so far.
Guido
---
[EMAIL PROTECTED] /var/tmp/portage # dbxml
dbxml> quit
[EMAIL PROTECTED] /var/tmp/portage # strace dbxml
execve("/usr/bin/dbxml", ["dbxml"], [/* 35 vars */]) = 0
brk(0) = 0x651000
mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) =
0x2ad4024c8000
uname({sys="Linux", node="leo2", ...}) = 0
access("/etc/ld.so.preload", R_OK) = -1 ENOENT (No such file or directory)
open("/usr/lib/tls/x86_64/libdbxml-2.4.so", O_RDONLY) = -1 ENOENT (No such file
or directory)
stat("/usr/lib/tls/x86_64", 0x7fffa85f8eb0) = -1 ENOENT (No such file or
directory)
open("/usr/lib/tls/libdbxml-2.4.so", O_RDONLY) = -1 ENOENT (No such file or
directory)
stat("/usr/lib/tls", 0x7fffa85f8eb0)= -1 ENOENT (No such file or directory)
open("/usr/lib/x86_64/libdbxml-2.4.so", O_RDONLY) = -1 ENOENT (No such file or
directory)
stat("/usr/lib/x86_64", 0x7fffa85f8eb0) = -1 ENOENT (No such file or directory)
open("/usr/lib/libdbxml-2.4.so", O_RDONLY) = 3
read(3, "\177ELF\2\1\1\0\0\0\0\0\0\0\0\0\3\0>\0\1\0\0\0p\277\16\0\0\0\0\0"...,
832) = 832
fstat(3, {st_mode=S_IFREG|0755, st_size=2914080, ...}) = 0
mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) =
0x2ad4024c9000
mmap(NULL, 5010512, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_DENYWRITE, 3, 0) =
0x2ad4026c9000
mprotect(0x2ad402978000, 2097152, PROT_NONE) = 0
mmap(0x2ad402b78000, 98304, PROT_READ|PROT_WRITE,
MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3, 0x2af000) = 0x2ad402b78000
mmap(0x2ad402b9, 1104, PROT_READ|PROT_WRITE,
MAP_PRIVATE|MAP_FIXED|MAP_ANONYMOUS, -1, 0) = 0x2ad402b9
close(3)= 0
open("/usr/lib/libdb_cxx-4.6.so", O_RDONLY) = 3
read(3, "\177ELF\2\1\1\0\0\0\0\0\0\0\0\0\3\0>\0\1\0\0\0\20K\3\0\0\0\0\0"...,
832) = 832
fstat(3, {st_mode=S_IFREG|0755, st_size=1384472, ...}) = 0
mmap(NULL, 3480608, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_DENYWRITE, 3, 0) =
0x2ad402b91000
mprotect(0x2ad402cdd000, 2093056, PROT_NONE) = 0
mmap(0x2ad402edc000, 28672, PROT_READ|PROT_WRITE,
MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3, 0x14b000) = 0x2ad402edc000
close(3)= 0
open("/usr/lib/libxqilla.so.4", O_RDONLY) = 3
read(3, "\177ELF\2\1\1\0\0\0\0\0\0\0\0\0\3\0>\0\1\0\0\0\220h\30\0\0\0\0\0"...,
832) = 832
fstat(3, {st_mode=S_IFREG|0755, st_size=4521696, ...}) = 0
mmap(NULL, 6620728, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_DENYWRITE, 3, 0) =
0x2ad402ee3000
mprotect(0x2ad4032cb000, 2097152, PROT_NONE) = 0
mmap(0x2ad4034cb000, 425984, PROT_READ|PROT_WRITE,
MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3, 0x3e8000) = 0x2ad4034cb000
mmap(0x2ad403533000, 1592, PROT_READ|PROT_WRITE,
MAP_PRIVATE|MAP_FIXED|MAP_ANONYMOUS, -1, 0) = 0x2ad403533000
close(3)= 0
open("/usr/lib/libnsl.so.1", O_RDONLY) = -1 ENOENT (No such file or directory)
open("/etc/ld.so.cache", O_RDONLY) = 3
fstat(3, {st_mode=S_IFREG|0644, st_size=24304, ...}) = 0
mmap(NULL, 24304, PROT_READ, MAP_PRIVATE, 3, 0) = 0x2ad403534000
close(3)= 0
open("/lib/libnsl.so.1", O_RDONLY) = 3
read(3, "\177ELF\2\1\1\0\0\0\0\0\0\0\0\0\3\0>[EMAIL PROTECTED]"..., 832) = 832
fstat(3, {st_mode=S_IFREG|0755, st_size=84800, ...}) = 0
mmap(NULL, 2190032, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_DENYWRITE, 3, 0) =
0x2ad40353a000
mprotect(0x2ad40354e000, 2093056, PROT_NONE) = 0
mmap(0x2ad40374d000, 8192, PROT_READ|PROT_WRITE,
MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3, 0x13000) = 0x2ad40374d000
mmap(0x2ad40374f000, 6864, PROT_READ|PROT_WRITE,
MAP_PRIVATE|MAP_FIXED|MAP_ANONYMOUS, -1, 0) = 0x2ad40374f000
close(3)= 0
open("/usr/lib/libpthread.so.0", O_RDONLY) = -1 ENOENT (No such file or
directory)
open("/lib/libpthread.so.0", O_RDONLY) = 3
read(3, "\177ELF\2\1\1\0\0\0\0\0\0\0\0\0\3\0>\0\1\0\0\0\260W\0\0\0\0\0\0"...,
832) = 832
fstat(3, {st_mode=S_IFREG|0755, st_size=131577, ...}) = 0
mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_AN
[jira] Commented: (XERCESC-1809) seg fault on 64bit
[
https://issues.apache.org/jira/browse/XERCESC-1809?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12606277#action_12606277
]
Guido Jäkel commented on XERCESC-1809:
--
Dear Boris,
for completeness, i let build the Xerces-C samples, too. As expected, now they
are roughly running.
To compare with the above, here the current strace of SAX2Count.
Guido
[EMAIL PROTECTED]
/var/tmp/portage/dev-libs/xerces-c-2.8.0/work/xerces-c-src_2_8_0/samples/data #
../../bin/SAX2Count personal.xml
personal.xml: 1 ms (37 elems, 12 attrs, 134 spaces, 134 chars)
[EMAIL PROTECTED]
/var/tmp/portage/dev-libs/xerces-c-2.8.0/work/xerces-c-src_2_8_0/samples/data #
strace ../../bin/SAX2Count personal.xml
execve("../../bin/SAX2Count", ["../../bin/SAX2Count", "personal.xml"], [/* 36
vars */]) = 0
brk(0) = 0x60a000
mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) =
0x2ad4e203f000
uname({sys="Linux", node="leo2", ...}) = 0
access("/etc/ld.so.preload", R_OK) = -1 ENOENT (No such file or directory)
open("/etc/ld.so.cache", O_RDONLY) = 3
fstat(3, {st_mode=S_IFREG|0644, st_size=24304, ...}) = 0
mmap(NULL, 24304, PROT_READ, MAP_PRIVATE, 3, 0) = 0x2ad4e204
close(3)= 0
open("/usr/lib/libxerces-c.so.28", O_RDONLY) = 3
read(3, "\177ELF\2\1\1\0\0\0\0\0\0\0\0\0\3\0>\0\1\0\0\0`t\30\0\0\0\0\0"...,
832) = 832
fstat(3, {st_mode=S_IFREG|0755, st_size=4389840, ...}) = 0
mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) =
0x2ad4e2046000
mmap(NULL, 6488504, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_DENYWRITE, 3, 0) =
0x2ad4e224
mprotect(0x2ad4e262c000, 2093056, PROT_NONE) = 0
mmap(0x2ad4e282b000, 282624, PROT_READ|PROT_WRITE,
MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3, 0x3eb000) = 0x2ad4e282b000
mmap(0x2ad4e287, 440, PROT_READ|PROT_WRITE,
MAP_PRIVATE|MAP_FIXED|MAP_ANONYMOUS, -1, 0) = 0x2ad4e287
close(3)= 0
open("/lib/libpthread.so.0", O_RDONLY) = 3
read(3, "\177ELF\2\1\1\0\0\0\0\0\0\0\0\0\3\0>\0\1\0\0\0\260W\0\0\0\0\0\0"...,
832) = 832
fstat(3, {st_mode=S_IFREG|0755, st_size=131577, ...}) = 0
mmap(NULL, 2204528, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_DENYWRITE, 3, 0) =
0x2ad4e2871000
mprotect(0x2ad4e2886000, 2097152, PROT_NONE) = 0
mmap(0x2ad4e2a86000, 8192, PROT_READ|PROT_WRITE,
MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3, 0x15000) = 0x2ad4e2a86000
mmap(0x2ad4e2a88000, 13168, PROT_READ|PROT_WRITE,
MAP_PRIVATE|MAP_FIXED|MAP_ANONYMOUS, -1, 0) = 0x2ad4e2a88000
close(3)= 0
open("/usr/lib/gcc/x86_64-pc-linux-gnu/4.1.2/libstdc++.so.6", O_RDONLY) = 3
read(3, "\177ELF\2\1\1\0\0\0\0\0\0\0\0\0\3\0>[EMAIL PROTECTED]"..., 832) = 832
fstat(3, {st_mode=S_IFREG|0755, st_size=985888, ...}) = 0
mmap(NULL, 3157792, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_DENYWRITE, 3, 0) =
0x2ad4e2a8c000
mprotect(0x2ad4e2b74000, 2097152, PROT_NONE) = 0
mmap(0x2ad4e2d74000, 36864, PROT_READ|PROT_WRITE,
MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3, 0xe8000) = 0x2ad4e2d74000
mmap(0x2ad4e2d7d000, 73504, PROT_READ|PROT_WRITE,
MAP_PRIVATE|MAP_FIXED|MAP_ANONYMOUS, -1, 0) = 0x2ad4e2d7d000
close(3)= 0
open("/lib/libm.so.6", O_RDONLY)= 3
read(3, "\177ELF\2\1\1\0\0\0\0\0\0\0\0\0\3\0>\0\1\0\0\0\0?\0\0\0\0\0\0"...,
832) = 832
fstat(3, {st_mode=S_IFREG|0755, st_size=526472, ...}) = 0
mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) =
0x2ad4e2d8f000
mmap(NULL, 2621672, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_DENYWRITE, 3, 0) =
0x2ad4e2d9
mprotect(0x2ad4e2e1, 2093056, PROT_NONE) = 0
mmap(0x2ad4e300f000, 8192, PROT_READ|PROT_WRITE,
MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3, 0x7f000) = 0x2ad4e300f000
close(3)= 0
open("/lib/libgcc_s.so.1", O_RDONLY)= 3
read(3, "\177ELF\2\1\1\0\0\0\0\0\0\0\0\0\3\0>\0\1\0\0\0\360\37\0\0\0\0\0\0"...,
832) = 832
fstat(3, {st_mode=S_IFREG|0644, st_size=55400, ...}) = 0
mmap(NULL, 2151240, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_DENYWRITE, 3, 0) =
0x2ad4e3011000
mprotect(0x2ad4e301e000, 2093056, PROT_NONE) = 0
mmap(0x2ad4e321d000, 8192, PROT_READ|PROT_WRITE,
MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3, 0xc000) = 0x2ad4e321d000
close(3)= 0
open("/lib/libc.so.6", O_RDONLY)= 3
read(3,
"\177ELF\2\1\1\0\0\0\0\0\0\0\0\0\3\0>\0\1\0\0\0\220\334\1\0\0\0\0\0"..., 832) =
832
fstat(3, {st_mode=S_IFREG|0755, st_size=1293456, ...}) = 0
mmap(NULL, 3399928, PROT_READ|PROT_EXEC, MAP_P
[jira] Created: (XERCESC-1849) Xerces-C and GSL: conflicting Macro "DLL_EXPORT" on Windows
Xerces-C and GSL: conflicting Macro "DLL_EXPORT" on Windows --- Key: XERCESC-1849 URL: https://issues.apache.org/jira/browse/XERCESC-1849 Project: Xerces-C++ Issue Type: Bug Components: Build Affects Versions: 3.0.1 Environment: Visual Studio 2008, Vista x64 (testing system) - this bug should affect all MSVC builds Reporter: -- When using XERCES 3.0 and GSL (here 1.8 - but 1.11 still has the same issue) a MACRO conflict will occur, when using Xerces' DLL in a project which at the same time uses GSL dlls. The conflicting Macro is "DLL_EXPORT". In gsl-1.8\include\gsl\gsl_types.h you will find: #ifdef WIN32 # ifdef GSL_DLL #ifdef DLL_EXPORT # define GSL_VAR extern __declspec(dllexport) # define GSL_EXPORT __declspec(dllexport) #else # define GSL_VAR extern __declspec(dllimport) # define GSL_EXPORT __declspec(dllimport) #endif # else #define GSL_VAR extern #define GSL_EXPORT # endif #else # define GSL_VAR extern # define GSL_EXPORT #endif In XERCES' xerces-c-3.0.0\src\xercesc\util\Xerces_autoconf_config.msvc.hpp #ifdef XERCES_STATIC_LIBRARY #define XERCES_PLATFORM_EXPORT #define XERCES_PLATFORM_IMPORT #else #define XERCES_PLATFORM_EXPORT __declspec(dllexport) #define XERCES_PLATFORM_IMPORT __declspec(dllimport) #ifndef OPENMS_XERCESDLL #define DLL_EXPORT #endif #endif and xerces-c-3.0.0\src\xercesc\util\XercesDefs.hpp #if defined(DLL_EXPORT) #if defined(XERCES_BUILDING_LIBRARY) #define XMLUTIL_EXPORT XERCES_PLATFORM_EXPORT #define XMLPARSER_EXPORT XERCES_PLATFORM_EXPORT #define SAX_EXPORT XERCES_PLATFORM_EXPORT #define SAX2_EXPORT XERCES_PLATFORM_EXPORT #define CDOM_EXPORT XERCES_PLATFORM_EXPORT #define PARSERS_EXPORT XERCES_PLATFORM_EXPORT #define VALIDATORS_EXPORT XERCES_PLATFORM_EXPORT #define XINCLUDE_EXPORT XERCES_PLATFORM_EXPORT #else #define XMLUTIL_EXPORT XERCES_PLATFORM_IMPORT #define XMLPARSER_EXPORT XERCES_PLATFORM_IMPORT #define SAX_EXPORT XERCES_PLATFORM_IMPORT #define SAX2_EXPORT XERCES_PLATFORM_IMPORT #define CDOM_EXPORT XERCES_PLATFORM_IMPORT #define PARSERS_EXPORT XERCES_PLATFORM_IMPORT #define VALIDATORS_EXPORT XERCES_PLATFORM_IMPORT #define XINCLUDE_EXPORT XERCES_PLATFORM_IMPORT #endif #if defined(XERCES_BUILDING_DEPRECATED_LIBRARY) #define DEPRECATED_DOM_EXPORT XERCES_PLATFORM_EXPORT #else #define DEPRECATED_DOM_EXPORT XERCES_PLATFORM_IMPORT #endif #else #define XMLUTIL_EXPORT #define XMLPARSER_EXPORT #define SAX_EXPORT #define SAX2_EXPORT #define CDOM_EXPORT #define DEPRECATED_DOM_EXPORT #define PARSERS_EXPORT #define VALIDATORS_EXPORT #define XINCLUDE_EXPORT #endif -- This leads to GSL defining #define GSL_VAR extern __declspec(dllexport) when it should be defining # define GSL_VAR extern __declspec(dllimport) and thus linking the third party app that uses XERCES and GSL will fail due to wrong symbol names for GSL functions. Why doesnt XERCES use something like XERCES_DLL which external projects need to define if they are using XERCES headers? DLL_EXPORT is quite a confusing name (especially when its also used for importing). Workaround (2 patches): --- src\xercesc\util\Xerces_autoconf_config.msvc.hppDo Jul 24 19:24:46 2008 +++ src\xercesc\util\Xerces_autoconf_config.msvc.hppDo Jan 22 14:09:09 2009 @@ -100,8 +100,10 @@ #else #define XERCES_PLATFORM_EXPORT __declspec(dllexport) #define XERCES_PLATFORM_IMPORT __declspec(dllimport) +#ifndef XERCES_DLL #define DLL_EXPORT #endif +#endif #define XERCES_MFC_SUPPORT PATCH #2 --- src\xercesc\util\XercesDefs.hpp Do Jan 22 19:13:55 2009 +++ src\xercesc\util\XercesDefs.hpp Do Jan 22 19:13:22 2009 @@ -133,7 +133,7 @@ // The DLL_EXPORT flag should be defined on the command line during the build of a DLL // configure conspires to make this happen. -#if defined(DLL_EXPORT) +#if ((defined(DLL_EXPORT)) || (defined(XERCES_DLL))) #if defined(XERCES_BUILDING_LIBRARY) #define XMLUTIL_EXPORT XERCES_PLATFORM_EXPORT #define XMLPARSER_EXPORT XERCES_PLATFORM_EXPORT This should do the trick. -- 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-1609) Ported Xerces-C++ to Windows Mobile
[ https://issues.apache.org/jira/browse/XERCESC-1609?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12803207#action_12803207 ] Mert Büyüktuncay commented on XERCESC-1609: --- Hello, I too am trying to use xerces on windows mobile 5.0. But unfortunately I could neither have successfully built the current version nor found a nightly one. >From your posts it seems like there is a sln file in the nightly >distributions(and hopefully vs project files) which is not available in normal releases. Can give a link to the mentioned codes or possibly guide me in the right direction for this issue. If possible I would also like to get the codes you compiled. Regards Mert > Ported Xerces-C++ to Windows Mobile > --- > > Key: XERCESC-1609 > URL: https://issues.apache.org/jira/browse/XERCESC-1609 > Project: Xerces-C++ > Issue Type: New Feature > Components: Build >Affects Versions: Nightly build (please specify the date) > Environment: Build Environment: > Visual Studio 2005 Professional Edition. > Windows Mobile 5.0 SDK for Pocket PC. > Test Environment: > Emulator > Dell Axim X51v >Reporter: jin adachi > Attachments: wince_project.diff, wince_src.diff > > > I ported Xerces-C++ 3.0 to Windows Mobile 5.0 for Pocket PC. > - Created Windows Mobile 5.0 Pocket PC SDK (ARMV4I) Projects. > - Ported XercesLib. > - Ported some samples. (changed entry point, string) > Restrictions > - Doesn't work xml4com. -- 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] Issue Comment Edited: (XERCESC-1609) Ported Xerces-C++ to Windows Mobile
[ https://issues.apache.org/jira/browse/XERCESC-1609?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12803207#action_12803207 ] Mert Büyüktuncay edited comment on XERCESC-1609 at 1/21/10 11:50 AM: - Hello, I too am trying to use xerces on windows mobile 5.0. But unfortunately I could neither have successfully built the current version nor found a nightly one. >From your posts it seems like there is a sln file in the nightly >distributions(and hopefully vs project files) which is not available in normal releases. Can you give a link to the mentioned codes or possibly guide me in the right direction for this issue. If possible I would also like to get the codes you compiled. Regards Mert Thanks Edit: Sorry this was a false alarm I just found the svn repository. Projects and sln were all there from the beginning. Though Xerces does not seem to be compiling for windows mobile 5 out of the box. I don't have the same nightly build so I guess I should do this manually taking the patches as reference. was (Author: nazilli): Hello, I too am trying to use xerces on windows mobile 5.0. But unfortunately I could neither have successfully built the current version nor found a nightly one. >From your posts it seems like there is a sln file in the nightly >distributions(and hopefully vs project files) which is not available in normal releases. Can give a link to the mentioned codes or possibly guide me in the right direction for this issue. If possible I would also like to get the codes you compiled. Regards Mert > Ported Xerces-C++ to Windows Mobile > --- > > Key: XERCESC-1609 > URL: https://issues.apache.org/jira/browse/XERCESC-1609 > Project: Xerces-C++ > Issue Type: New Feature > Components: Build >Affects Versions: Nightly build (please specify the date) > Environment: Build Environment: > Visual Studio 2005 Professional Edition. > Windows Mobile 5.0 SDK for Pocket PC. > Test Environment: > Emulator > Dell Axim X51v >Reporter: jin adachi > Attachments: wince_project.diff, wince_src.diff > > > I ported Xerces-C++ 3.0 to Windows Mobile 5.0 for Pocket PC. > - Created Windows Mobile 5.0 Pocket PC SDK (ARMV4I) Projects. > - Ported XercesLib. > - Ported some samples. (changed entry point, string) > Restrictions > - Doesn't work xml4com. -- 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-1915) Segmentation fault in getPooledString
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] Reopened: (XERCESC-1915) Segmentation fault in getPooledString
[ https://issues.apache.org/jira/browse/XERCESC-1915?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Olov Brötell reopened XERCESC-1915: --- The specified flag, -qalias=noansi, does not help in my case, unfortunately. --- export TRANSCODER="NATIVE" export MESSAGELOADER="INMEM" export NETACCESSOR="FileOnly" export THREADS="pthread" export BITSTOBUILD="32" export CC="xlc" export CXX="xlC" export CXXFLAGS=" -qalias=noansi -w -O2 -DNDEBUG -DPROJ_XMLPARSER -DPROJ_XMLUTIL -DPROJ_PARSERS -DPROJ_SAX4C -DPROJ_SAX2 -DPROJ_DOM -DPROJ_DEPRECATED_DOM -DPROJ_VALIDATORS -DXML_USE_NATIVE_TRANSCODER -DXML_USE_INMEM_MESSAGELOADER -DXML_USE_PTHREADS " export CFLAGS=" -qalias=noansi -w -O2 -DNDEBUG -DPROJ_XMLPARSER -DPROJ_XMLUTIL -DPROJ_PARSERS -DPROJ_SAX4C -DPROJ_SAX2 -DPROJ_DOM -D PROJ_DEPRECATED_DOM -DPROJ_VALIDATORS -DXML_USE_NATIVE_TRANSCODER -DXML_USE_INMEM_MESSAGELOADER -DXML_USE_PTHREADS " export LDFLAGS=" " export LIBS=" " > 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] Commented: (XERCESC-1915) Segmentation fault in getPooledString
[ https://issues.apache.org/jira/browse/XERCESC-1915?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12839772#action_12839772 ] Olov Brötell commented on XERCESC-1915: --- Built with command: runConfigure -paix -cxlc -xxlC -minmem -nfileonly -tnative -z -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] Commented: (XERCESC-1915) Segmentation fault in getPooledString
[ https://issues.apache.org/jira/browse/XERCESC-1915?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12840087#action_12840087 ] Olov Brötell commented on XERCESC-1915: --- To avoid a segfault i have to turn off optimization with -O0. > 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] Closed: (XERCESC-1915) Segmentation fault in getPooledString
[ https://issues.apache.org/jira/browse/XERCESC-1915?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Olov Brötell closed XERCESC-1915. - Resolution: Invalid As has been pointed out this is probably a bug in the XLC 10 optimizer. "Workaround" is to turn off optimization. http://issues.apache.org/jira/browse/XERCESC-1904?focusedCommentId=12802346&page=com.atlassian.jira.plugin.system.issuetabpanels%3Acomment-tabpanel#action_12802346 > 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] [Created] (XERCESC-2004) bit operation error in DOMNodeImpl::reverseTreeOrderBitPattern
朱亚东 created XERCESC-2004:
Summary: bit operation error in
DOMNodeImpl::reverseTreeOrderBitPattern
Key: XERCESC-2004
URL: https://issues.apache.org/jira/browse/XERCESC-2004
Project: Xerces-C++
Issue Type: Bug
Components: DOM
Affects Versions: 3.1.1
Environment: any
Reporter: 朱亚东
code like below:
short DOMNodeImpl::reverseTreeOrderBitPattern(short pattern) const {
if(pattern & DOMNode::DOCUMENT_POSITION_PRECEDING) {
pattern &= !DOMNode::DOCUMENT_POSITION_PRECEDING;
pattern |= DOMNode::DOCUMENT_POSITION_FOLLOWING;
}
I think it should be:
short DOMNodeImpl::reverseTreeOrderBitPattern(short pattern) const {
if(pattern & DOMNode::DOCUMENT_POSITION_PRECEDING) {
pattern &= ~DOMNode::DOCUMENT_POSITION_PRECEDING;
pattern |= DOMNode::DOCUMENT_POSITION_FOLLOWING;
}
because !DOMNode::DOCUMENT_POSITION_PRECEDING always be 0.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
-
To unsubscribe, e-mail: c-dev-unsubscr...@xerces.apache.org
For additional commands, e-mail: c-dev-h...@xerces.apache.org
[jira] [Created] (XERCESC-2031) Janitor::~Janitor() throws in unwind
Jimmie Högklint created XERCESC-2031: Summary: Janitor::~Janitor() throws in unwind Key: XERCESC-2031 URL: https://issues.apache.org/jira/browse/XERCESC-2031 Project: Xerces-C++ Issue Type: Bug Components: Utilities Affects Versions: 3.1.1 Environment: Solaris 10, x86 Reporter: Jimmie Högklint If PosixFileMgr::fileClose() receives an invalid file handler or if its unable to close a file handler it will throw an exception. If this is done in an unwind of, for example, Janitor noone is around to catch that exception before the process is terminated. (Leaving a destructor with a throw during unwind is rewarded with termination of the process) This happens when variable "streamJanitor" goes out of scope in ReaderMgr::createReader(...) Callstack looks like this: [6] std::terminate(0xfeafd2e3, 0xfe7eb940, 0xfc5c5ce8, 0xfe7eb940, 0x0, 0xfe7eb940), at 0xfe7d471f [7] __Cimpl::ex_terminate(0xfedf9290, 0xfee69fd0, 0x2, 0xfe7ec658, 0xfe7ec4a0, 0x0), at 0xfe7d4b82 [8] _ex_throw_body(0xfe7ec658, 0xfeafd2e3, 0xfc5c5d60, 0xfe7d546e), at 0xfe7d5561 [9] __Crun::ex_throw(0xfe7ec6a4, 0xfed84ab8, 0xfeb04488, 0xfed82da2), at 0xfe7d54ca [10] xercesc_3_1::PosixFileMgr::fileClose(this = 0x8f69a18, f = 0xfe3f2d00, manager = 0x8f69618) (optimized), at 0xfed82e40 (line ~81) in "PosixFileMgr.cpp" [11] xercesc_3_1::XMLPlatformUtils::closeFile(theFile = 0xfe3f2d00, memmgr = 0x8f69618) (optimized), at 0xfeb021b9 (line ~578) in "PlatformUtils.cpp" [12] xercesc_3_1::BinFileInputStream::~BinFileInputStream(this = 0x91df400) (optimized), at 0xfeafd2de (line ~64) in "BinFileInputStream.cpp" [13] __SLIP.DELETER__A(this = 0x91df400, delete = 1) (optimized), at 0xfeafd53e (line ~61) in "BinFileInputStream.cpp" [14] xercesc_3_1::Janitor::reset(this = 0xfc5c5e84, p = (nil)) (optimized), at 0xfec16fd6 (line ~90) in "Janitor.c" [15] xercesc_3_1::Janitor::~Janitor(this = 0xfc5c5e84) (optimized), at 0xfec166f8 (line ~43) in "Janitor.c" [16] xercesc_3_1::ReaderMgr::createReader(this = 0x930a604, src = CLASS, _ARG3 = true, refFrom = RefFrom_NonLiteral, type = Type_General, source = Source_External, calcSrcOfs = false, lowWaterMark = 100U) (optimized), at 0xfec12ee4 (line ~440) in "ReaderMgr.cpp" [17] xercesc_3_1::IGXMLScanner::scanReset(this = 0x930a578, src = CLASS) (optimized), at 0xfec08e7c (line ~1275) in "IGXMLScanner2.cpp" [18] xercesc_3_1::IGXMLScanner::scanDocument(this = 0x930a578, src = CLASS) (optimized), at 0xfebfb52e (line ~198) in "IGXMLScanner.cpp" [19] xercesc_3_1::AbstractDOMParser::parse(this = 0xfc5c6018, source = CLASS) (optimized), at 0xfec67c34 (line ~545) in "AbstractDOMParser.cpp" [20] xercesc_3_1::IGXMLScanner::resolveSchemaGrammar(this = 0x9283f68, loc = 0x93c4b3c, uri = 0x93c5020, ignoreLoadSchema = true) (optimized), at 0xfec0a8d0 (line ~1859) in "IGXMLScanner2.cpp" [21] xercesc_3_1::IGXMLScanner::parseSchemaLocation(this = 0x9283f68, schemaLocationStr = 0x9627e10, ignoreLoadSchema = true) (optimized), at 0xfec0a0b4 (line ~1727) in "IGXMLScanner2.cpp" [22] xercesc_3_1::IGXMLScanner::scanStartTagNS(this = 0x9283f68, gotData = true) (optimized), at 0xfebff71a (line ~2205) in "IGXMLScanner.cpp" [23] xercesc_3_1::IGXMLScanner::scanContent(this = 0x9283f68) (optimized), at 0xfebfcb7b (line ~890) in "IGXMLScanner.cpp" [24] xercesc_3_1::IGXMLScanner::scanDocument(this = 0x9283f68, src = CLASS) (optimized), at 0xfebfb571 (line ~217) in "IGXMLScanner.cpp" [25] xercesc_3_1::AbstractDOMParser::parse(this = 0x92e6e50, source = CLASS) (optimized), at 0xfec67c34 (line ~545) in "AbstractDOMParser.cpp" [26] xercesc_3_1::DOMLSParserImpl::parse(this = 0x92e6e50, source = 0xfc5c6718) (optimized), at 0xfec714ce (line ~754) in "DOMLSParserImpl.cpp" This applies to WindowsFileMgr as well. If additional information is needed I'm happy to provide it. -- This message was sent by Atlassian JIRA (v6.2#6252) - To unsubscribe, e-mail: c-dev-unsubscr...@xerces.apache.org For additional commands, e-mail: c-dev-h...@xerces.apache.org
[jira] [Commented] (XERCESC-2031) Janitor::~Janitor() throws in unwind
[ https://issues.apache.org/jira/browse/XERCESC-2031?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14007163#comment-14007163 ] Jimmie Högklint commented on XERCESC-2031: -- Whoa, that was fast! I applied the patch on top of xercesc 3.1.1 and it works fine. Thanks > Janitor::~Janitor() throws in unwind > > > Key: XERCESC-2031 > URL: https://issues.apache.org/jira/browse/XERCESC-2031 > Project: Xerces-C++ > Issue Type: Bug > Components: Utilities >Affects Versions: 3.1.1 > Environment: Solaris 10, x86 >Reporter: Jimmie Högklint >Assignee: Alberto Massari > Fix For: 3.2.0 > > > If PosixFileMgr::fileClose() receives an invalid file handler or if its > unable to close a file handler it will throw an exception. If this is done in > an unwind of, for example, Janitor noone is around to catch > that exception before the process is terminated. (Leaving a destructor with a > throw during unwind is rewarded with termination of the process) > This happens when variable "streamJanitor" goes out of scope in > ReaderMgr::createReader(...) > Callstack looks like this: > [6] std::terminate(0xfeafd2e3, 0xfe7eb940, 0xfc5c5ce8, 0xfe7eb940, 0x0, > 0xfe7eb940), at 0xfe7d471f > [7] __Cimpl::ex_terminate(0xfedf9290, 0xfee69fd0, 0x2, 0xfe7ec658, > 0xfe7ec4a0, 0x0), at 0xfe7d4b82 > [8] _ex_throw_body(0xfe7ec658, 0xfeafd2e3, 0xfc5c5d60, 0xfe7d546e), at > 0xfe7d5561 > [9] __Crun::ex_throw(0xfe7ec6a4, 0xfed84ab8, 0xfeb04488, 0xfed82da2), at > 0xfe7d54ca > [10] xercesc_3_1::PosixFileMgr::fileClose(this = 0x8f69a18, f = 0xfe3f2d00, > manager = 0x8f69618) (optimized), at 0xfed82e40 (line ~81) in > "PosixFileMgr.cpp" > [11] xercesc_3_1::XMLPlatformUtils::closeFile(theFile = 0xfe3f2d00, memmgr = > 0x8f69618) (optimized), at 0xfeb021b9 (line ~578) in "PlatformUtils.cpp" > [12] xercesc_3_1::BinFileInputStream::~BinFileInputStream(this = 0x91df400) > (optimized), at 0xfeafd2de (line ~64) in "BinFileInputStream.cpp" > [13] __SLIP.DELETER__A(this = 0x91df400, delete = 1) (optimized), at > 0xfeafd53e (line ~61) in "BinFileInputStream.cpp" > [14] xercesc_3_1::Janitor::reset(this = > 0xfc5c5e84, p = (nil)) (optimized), at 0xfec16fd6 (line ~90) in "Janitor.c" > [15] xercesc_3_1::Janitor::~Janitor(this = > 0xfc5c5e84) (optimized), at 0xfec166f8 (line ~43) in "Janitor.c" > [16] xercesc_3_1::ReaderMgr::createReader(this = 0x930a604, src = CLASS, > _ARG3 = true, refFrom = RefFrom_NonLiteral, type = Type_General, source = > Source_External, calcSrcOfs = false, lowWaterMark = 100U) (optimized), at > 0xfec12ee4 (line ~440) in "ReaderMgr.cpp" > [17] xercesc_3_1::IGXMLScanner::scanReset(this = 0x930a578, src = CLASS) > (optimized), at 0xfec08e7c (line ~1275) in "IGXMLScanner2.cpp" > [18] xercesc_3_1::IGXMLScanner::scanDocument(this = 0x930a578, src = CLASS) > (optimized), at 0xfebfb52e (line ~198) in "IGXMLScanner.cpp" > [19] xercesc_3_1::AbstractDOMParser::parse(this = 0xfc5c6018, source = CLASS) > (optimized), at 0xfec67c34 (line ~545) in "AbstractDOMParser.cpp" > [20] xercesc_3_1::IGXMLScanner::resolveSchemaGrammar(this = 0x9283f68, loc = > 0x93c4b3c, uri = 0x93c5020, ignoreLoadSchema = true) (optimized), at > 0xfec0a8d0 (line ~1859) in "IGXMLScanner2.cpp" > [21] xercesc_3_1::IGXMLScanner::parseSchemaLocation(this = 0x9283f68, > schemaLocationStr = 0x9627e10, ignoreLoadSchema = true) (optimized), at > 0xfec0a0b4 (line ~1727) in "IGXMLScanner2.cpp" > [22] xercesc_3_1::IGXMLScanner::scanStartTagNS(this = 0x9283f68, gotData = > true) (optimized), at 0xfebff71a (line ~2205) in "IGXMLScanner.cpp" > [23] xercesc_3_1::IGXMLScanner::scanContent(this = 0x9283f68) (optimized), at > 0xfebfcb7b (line ~890) in "IGXMLScanner.cpp" > [24] xercesc_3_1::IGXMLScanner::scanDocument(this = 0x9283f68, src = CLASS) > (optimized), at 0xfebfb571 (line ~217) in "IGXMLScanner.cpp" > [25] xercesc_3_1::AbstractDOMParser::parse(this = 0x92e6e50, source = CLASS) > (optimized), at 0xfec67c34 (line ~545) in "AbstractDOMParser.cpp" > [26] xercesc_3_1::DOMLSParserImpl::parse(this = 0x92e6e50, source = > 0xfc5c6718) (optimized), at 0xfec714ce (line ~754) in "DOMLSParserImpl.cpp" > This applies to WindowsFileMgr as well. > If additional information is needed I'm happy to provide it. -- This message was sent by Atlassian JIRA (v6.2#6252) - To unsubscribe, e-mail: c-dev-unsubscr...@xerces.apache.org For additional commands, e-mail: c-dev-h...@xerces.apache.org
[jira] [Created] (XERCESC-2036) XSTypeDefinition::getNamespace() is missing a const qualifier
Erik Sjölund created XERCESC-2036: - Summary: XSTypeDefinition::getNamespace() is missing a const qualifier Key: XERCESC-2036 URL: https://issues.apache.org/jira/browse/XERCESC-2036 Project: Xerces-C++ Issue Type: Bug Components: Validating Parser (XML Schema) Affects Versions: 3.1.1 Reporter: Erik Sjölund Priority: Minor The function XSTypeDefinition::getNamespace() should have a const qualifier, just like XSTypeDefinition::getName() has. $ cd xerces-c-3.1.1/src/xercesc/framework/psvi/ $ grep "XMLCh\* getName" XSTypeDefinition.hpp virtual const XMLCh* getName() const = 0; virtual const XMLCh* getNamespace() = 0; -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: c-dev-unsubscr...@xerces.apache.org For additional commands, e-mail: c-dev-h...@xerces.apache.org
[jira] [Created] (XERCESC-2040) space before & does not collapse
Darko Škerl created XERCESC-2040: Summary: space before & does not collapse Key: XERCESC-2040 URL: https://issues.apache.org/jira/browse/XERCESC-2040 Project: Xerces-C++ Issue Type: Bug Components: Validating Parser (XML Schema) Affects Versions: 2.7.0, 2.8.0 Environment: Windows, AIX Reporter: Darko Škerl I have an XSD with typed definition as: I have an XML with the following tag: & Note there is a space before & FreeText is of type CustomText. The parser should remove the initial space and leave only & but instead I get the following error: Message: Datatype error: Type:InvalidDatatypeValueException, Message:Value ' <' does not match regular expression facet '\S+.*'. Does anyone know what could be the problem? Is there a workaround for that bug? Does Xerces 3.1 solve that problem? Regards -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: c-dev-unsubscr...@xerces.apache.org For additional commands, e-mail: c-dev-h...@xerces.apache.org
[jira] [Updated] (XERCESC-2050) wrong use of delete keyword in DTest.cpp
[ https://issues.apache.org/jira/browse/XERCESC-2050?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Hanno Böck updated XERCESC-2050: Attachment: xerces-c-fix-alloc-dealloc.diff Patch to fix issue > wrong use of delete keyword in DTest.cpp > > > Key: XERCESC-2050 > URL: https://issues.apache.org/jira/browse/XERCESC-2050 > Project: Xerces-C++ > Issue Type: Bug > Components: Samples/Tests >Affects Versions: 3.1.2 >Reporter: Hanno Böck >Priority: Minor > Attachments: xerces-c-fix-alloc-dealloc.diff > > > In the file DTest.cpp there is a wrong use of the delete keyword. The > variable hugeString is allocated with: > char* hugeString=new char[HUGE_STRING+1]; > It gets deallocated with: > delete hugeString; > When allocating a variable with "new type[size]" one has to deallocate with > "delete [] variable". These kinds of errors can be seen when compiling with > address sanitizer. I'll attach a patch. -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: c-dev-unsubscr...@xerces.apache.org For additional commands, e-mail: c-dev-h...@xerces.apache.org
[jira] [Created] (XERCESC-2050) wrong use of delete keyword in DTest.cpp
Hanno Böck created XERCESC-2050: --- Summary: wrong use of delete keyword in DTest.cpp Key: XERCESC-2050 URL: https://issues.apache.org/jira/browse/XERCESC-2050 Project: Xerces-C++ Issue Type: Bug Components: Samples/Tests Affects Versions: 3.1.2 Reporter: Hanno Böck Priority: Minor Attachments: xerces-c-fix-alloc-dealloc.diff In the file DTest.cpp there is a wrong use of the delete keyword. The variable hugeString is allocated with: char* hugeString=new char[HUGE_STRING+1]; It gets deallocated with: delete hugeString; When allocating a variable with "new type[size]" one has to deallocate with "delete [] variable". These kinds of errors can be seen when compiling with address sanitizer. I'll attach a patch. -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: c-dev-unsubscr...@xerces.apache.org For additional commands, e-mail: c-dev-h...@xerces.apache.org
[jira] [Created] (XERCESC-2051) Overlapping memcpy call
Hanno Böck created XERCESC-2051: --- Summary: Overlapping memcpy call Key: XERCESC-2051 URL: https://issues.apache.org/jira/browse/XERCESC-2051 Project: Xerces-C++ Issue Type: Bug Affects Versions: 3.1.2 Reporter: Hanno Böck Priority: Minor Attachments: xerces-c-overlapping-memcpy.diff When running the test suite with address sanitizer enabled it will report an overlapping memcpy call: < = < ==8236==ERROR: AddressSanitizer: memcpy-param-overlap: memory ranges [0x006678c0,0x006678ca) and [0x006678c2, 0x006678cc) overlap < #0 0x7f1025853f24 (/usr/lib/gcc/x86_64-pc-linux-gnu/4.9.2/libasan.so.1+0x2ff24) < #1 0x7f1024df4bf8 in xercesc_3_1::XMLString::moveChars(unsigned short*, unsigned short const*, unsigned long) xercesc/util/XMLString.hpp:1446 < #2 0x7f1024e627eb in xercesc_3_1::XMLString::collapseWS(unsigned short*, xercesc_3_1::MemoryManager*) xercesc/util/XMLString.cpp:1813 < #3 0x44a098 in DOMTest::testUtilFunctions() src/DOM/DOMTest/DTest.cpp:5752 < #4 0x412865 in main src/DOM/DOMTest/DTest.cpp:984 < #5 0x7f10209b5f9f in __libc_start_main (/lib64/libc.so.6+0x1ff9f) < #6 0x405848 (/tmp/xerces-c-3.1.2/tests/.libs/DOMTest+0x405848) < < 0x006678c0 is located 0 bytes inside of global variable 'tempStr' from 'src/DOM/DOMTest/DTest.cpp' (0x6678c0) of size 8000 < 0x006678c2 is located 2 bytes inside of global variable 'tempStr' from 'src/DOM/DOMTest/DTest.cpp' (0x6678c0) of size 8000 < SUMMARY: AddressSanitizer: memcpy-param-overlap ??:0 ?? < ==8236==ABORTING memcpy calls to overlapping memory areas are not allowed. memmove can be used in such instances. (I'll attach a patch that changes that, but I'd ask for it to be reviewed by someone familiar with the code and check whether the overlapping copying is really intended.) -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: c-dev-unsubscr...@xerces.apache.org For additional commands, e-mail: c-dev-h...@xerces.apache.org
[jira] [Updated] (XERCESC-2051) Overlapping memcpy call
[ https://issues.apache.org/jira/browse/XERCESC-2051?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Hanno Böck updated XERCESC-2051: Attachment: xerces-c-overlapping-memcpy.diff Proposed patch > Overlapping memcpy call > --- > > Key: XERCESC-2051 > URL: https://issues.apache.org/jira/browse/XERCESC-2051 > Project: Xerces-C++ > Issue Type: Bug >Affects Versions: 3.1.2 >Reporter: Hanno Böck >Priority: Minor > Attachments: xerces-c-overlapping-memcpy.diff > > > When running the test suite with address sanitizer enabled it will report an > overlapping memcpy call: > < = > < ==8236==ERROR: AddressSanitizer: memcpy-param-overlap: memory ranges > [0x006678c0,0x006678ca) and [0x006678c2, 0x006678cc) overlap > < #0 0x7f1025853f24 > (/usr/lib/gcc/x86_64-pc-linux-gnu/4.9.2/libasan.so.1+0x2ff24) > < #1 0x7f1024df4bf8 in xercesc_3_1::XMLString::moveChars(unsigned short*, > unsigned short const*, unsigned long) xercesc/util/XMLString.hpp:1446 > < #2 0x7f1024e627eb in xercesc_3_1::XMLString::collapseWS(unsigned > short*, xercesc_3_1::MemoryManager*) xercesc/util/XMLString.cpp:1813 > < #3 0x44a098 in DOMTest::testUtilFunctions() > src/DOM/DOMTest/DTest.cpp:5752 > < #4 0x412865 in main src/DOM/DOMTest/DTest.cpp:984 > < #5 0x7f10209b5f9f in __libc_start_main (/lib64/libc.so.6+0x1ff9f) > < #6 0x405848 (/tmp/xerces-c-3.1.2/tests/.libs/DOMTest+0x405848) > < > < 0x006678c0 is located 0 bytes inside of global variable 'tempStr' from > 'src/DOM/DOMTest/DTest.cpp' (0x6678c0) of size 8000 > < 0x006678c2 is located 2 bytes inside of global variable 'tempStr' from > 'src/DOM/DOMTest/DTest.cpp' (0x6678c0) of size 8000 > < SUMMARY: AddressSanitizer: memcpy-param-overlap ??:0 ?? > < ==8236==ABORTING > memcpy calls to overlapping memory areas are not allowed. memmove can be used > in such instances. (I'll attach a patch that changes that, but I'd ask for it > to be reviewed by someone familiar with the code and check whether the > overlapping copying is really intended.) -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: c-dev-unsubscr...@xerces.apache.org For additional commands, e-mail: c-dev-h...@xerces.apache.org
[jira] [Created] (XERCESC-2053) typo in the documentation: "InputSource resolveEntity" -> "InputSource* resolveEntity"
Erik Sjölund created XERCESC-2053: - Summary: typo in the documentation: "InputSource resolveEntity" -> "InputSource* resolveEntity" Key: XERCESC-2053 URL: https://issues.apache.org/jira/browse/XERCESC-2053 Project: Xerces-C++ Issue Type: Bug Components: Documentation Reporter: Erik Sjölund Priority: Trivial The code examples in the documentation does not match the EntityResolver interface. There is a missing "*". I attach the output from the command "svn diff" from a fresh svn checkout with the typos corrected. -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: c-dev-unsubscr...@xerces.apache.org For additional commands, e-mail: c-dev-h...@xerces.apache.org
[jira] [Updated] (XERCESC-2053) typo in the documentation: "InputSource resolveEntity" -> "InputSource* resolveEntity"
[ https://issues.apache.org/jira/browse/XERCESC-2053?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Erik Sjölund updated XERCESC-2053: -- Attachment: svn-diff.txt A diff with the typos corrected. > typo in the documentation: "InputSource resolveEntity" -> "InputSource* > resolveEntity" > -- > > Key: XERCESC-2053 > URL: https://issues.apache.org/jira/browse/XERCESC-2053 > Project: Xerces-C++ > Issue Type: Bug > Components: Documentation >Reporter: Erik Sjölund >Priority: Trivial > Attachments: svn-diff.txt > > > The code examples in the documentation does not match the EntityResolver > interface. There is a missing "*". I attach the output from the command "svn > diff" from a fresh svn checkout with the typos corrected. -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: c-dev-unsubscr...@xerces.apache.org For additional commands, e-mail: c-dev-h...@xerces.apache.org
[jira] [Created] (XERCESC-2106) Refactoring of CoreDocumentImpl
João Paulo Lemes Machado created XERCESC-2106: - Summary: Refactoring of CoreDocumentImpl Key: XERCESC-2106 URL: https://issues.apache.org/jira/browse/XERCESC-2106 Project: Xerces-C++ Issue Type: Improvement Components: DOM Reporter: João Paulo Lemes Machado Hello everyone. I was analyzing the modularization of some classes, and I identified that the class CoreDocumentImpl has an opportunity for cohesion improvement. The class SAXParser was in the same situation and the problem was solved as follows: The AbstractSAXParser class was created, and several get() and set() methods that were used only to configure the class parameters were moved from SAXParser to AbstractSAXParser. The new class was then accessed through an instance variable in SAXParser. This strategy has cleaned and improved SAXParser cohesion. With this in mind, I would recommend creating a new class: CoreDocumentImplConfig , and moving the following methods: setXmlVersion setVersion getNodeName getXmlStandalone getStrictErrorChecking setStrictErrorChecking getElementsByTagName getNodeListCache getNodeNumber setUserData getStandalone getAsync getTextContent setEncoding getUserData getDoctype getMutationEvents getOwnerDocument getVersion getDocumentURI getIdentifiers getElementById getEncoding setAttrNode getXmlVersion setInputEncoding getNodeType getErrorChecking setDocumentURI getXmlEncoding getBaseURI setStandalone setXmlEncoding getDocumentElement getInputEncoding getIdentifier setAsync getElementsByTagNameNS setXmlStandalone setMutationEvents getImplementation getDomConfig setTextContent getUserDataRecord setUserDataTable setErrorChecking getFeature from the CoreDocumentImpl. Those parameters accessed by an instance variable in the CoreDocumentImpl. Moreover, the orthogonality is the design would be enhanced. What do you think about that? -- This message was sent by Atlassian JIRA (v6.4.14#64029) - To unsubscribe, e-mail: c-dev-unsubscr...@xerces.apache.org For additional commands, e-mail: c-dev-h...@xerces.apache.org
[jira] [Commented] (XERCESC-2106) Refactoring of CoreDocumentImpl
[ https://issues.apache.org/jira/browse/XERCESC-2106?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16092890#comment-16092890 ] João Paulo Lemes Machado commented on XERCESC-2106: --- Thanks for the reply Scott. In my work I'm trying to identify opportunities for code improvements and ways to make it simpler for maintenance activities. I identified some few others opportunities, could you point me to someone who could evaluate them? Even if they are not implemented these practices can be adopted for future implementations. > Refactoring of CoreDocumentImpl > --- > > Key: XERCESC-2106 > URL: https://issues.apache.org/jira/browse/XERCESC-2106 > Project: Xerces-C++ > Issue Type: Improvement > Components: DOM >Reporter: João Paulo Lemes Machado > > Hello everyone. > I was analyzing the modularization of some classes, and I identified that the > class CoreDocumentImpl has an opportunity for cohesion improvement. > The class SAXParser was in the same situation and the problem was solved as > follows: The AbstractSAXParser class was created, and several get() and set() > methods that were used only to configure the class parameters were moved from > SAXParser to AbstractSAXParser. > The new class was then accessed through an instance variable in SAXParser. > This strategy has cleaned and improved SAXParser cohesion. > With this in mind, I would recommend creating a new class: > CoreDocumentImplConfig , and moving the following methods: > setXmlVersion > setVersion > getNodeName > getXmlStandalone > getStrictErrorChecking > setStrictErrorChecking > getElementsByTagName > getNodeListCache > getNodeNumber > setUserData > getStandalone > getAsync > getTextContent > setEncoding > getUserData > getDoctype > getMutationEvents > getOwnerDocument > getVersion > getDocumentURI > getIdentifiers > getElementById > getEncoding > setAttrNode > getXmlVersion > setInputEncoding > getNodeType > getErrorChecking > setDocumentURI > getXmlEncoding > getBaseURI > setStandalone > setXmlEncoding > getDocumentElement > getInputEncoding > getIdentifier > setAsync > getElementsByTagNameNS > setXmlStandalone > setMutationEvents > getImplementation > getDomConfig > setTextContent > getUserDataRecord > setUserDataTable > setErrorChecking > getFeature > from the CoreDocumentImpl. > Those parameters accessed by an instance variable in the CoreDocumentImpl. > Moreover, the orthogonality is the design would be enhanced. > What do you think about that? -- This message was sent by Atlassian JIRA (v6.4.14#64029) - To unsubscribe, e-mail: c-dev-unsubscr...@xerces.apache.org For additional commands, e-mail: c-dev-h...@xerces.apache.org
[jira] [Commented] (XERCESC-1532) PSVI: I/F doesn't provide length of hexBinary data
[ https://issues.apache.org/jira/browse/XERCESC-1532?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16131875#comment-16131875 ] Yannick Müller commented on XERCESC-1532: - Same applies to base64Binary values. > PSVI: I/F doesn't provide length of hexBinary data > -- > > Key: XERCESC-1532 > URL: https://issues.apache.org/jira/browse/XERCESC-1532 > Project: Xerces-C++ > Issue Type: Bug > Components: Validating Parser (XML Schema) >Affects Versions: 2.7.0 >Reporter: Steve Magnani > > When PSVIItem::getActualValue() is called for a hexBinary attribute, > XSValue::getActValStrings() produces a binary bytestream equivalent of the > hexBinary string. It also appends a zero byte at the end of the bytestream. > While clients are able to access the bytestream (via > XSValue::fData.fValue.f_byteVal), there does not seem to be any way for > clients to tell how many bytes are in the stream without replicating some of > the logic used by XSValue::getActValStrings(). Checking for a zero byte is > not reliable, because zero bytes are valid in hexBinary values. > Suggest making XSValue::fData.fValue.f_byteVal a struct that includes the > length of the byte stream, as well as a pointer to it. -- This message was sent by Atlassian JIRA (v6.4.14#64029) - To unsubscribe, e-mail: c-dev-unsubscr...@xerces.apache.org For additional commands, e-mail: c-dev-h...@xerces.apache.org
[jira] [Created] (XERCESC-2122) CMake: wrong substitutions in pkg-config file
Ferenc Wágner created XERCESC-2122:
--
Summary: CMake: wrong substitutions in pkg-config file
Key: XERCESC-2122
URL: https://issues.apache.org/jira/browse/XERCESC-2122
Project: Xerces-C++
Issue Type: Bug
Components: Build
Affects Versions: 3.2.0
Environment: Debian GNU/Linux unstable
Reporter: Ferenc Wágner
Here's a diff between the {{xerces-c.pc}} files created by CMake and Autotools:
{code}
--- ../xerces-c.pc.cmake2017-10-06 11:33:55.580393801 +
+++ xerces-c.pc 2017-10-06 11:34:28.129103784 +
@@ -1,11 +1,11 @@
prefix=/usr/local
-exec_prefix=/usr/local
-libdir=/usr/local/lib
-includedir=/usr/local/include
+exec_prefix=${prefix}
+libdir=${exec_prefix}/lib
+includedir=${prefix}/include
Name: Xerces-C++
Description: Validating XML parser library for C++
-Version:
-Libs: -L/usr/local/lib -lxerces-c
-Libs.private:
-Cflags: -I/usr/local/include
+Version: 3.2.0
+Libs: -L${libdir} -lxerces-c
+Libs.private: -lcurl
+Cflags: -I${includedir}
{code}
In my opinion the CMake version has the following problems:
* variables are expanded ({{prefix}} and {{includedir}}),
* the version string is missing,
* static linking options ({{-lcurl}}) are missing (after {{Libs.private}}).
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
-
To unsubscribe, e-mail: c-dev-unsubscr...@xerces.apache.org
For additional commands, e-mail: c-dev-h...@xerces.apache.org
[jira] [Created] (XERCESC-2175) Source and destination overlap in memcpy
João M. S. Silva created XERCESC-2175: - Summary: Source and destination overlap in memcpy Key: XERCESC-2175 URL: https://issues.apache.org/jira/browse/XERCESC-2175 Project: Xerces-C++ Issue Type: Bug Components: Validating Parser (XML Schema) Affects Versions: 3.2.2 Reporter: João M. S. Silva I get this Valgrind error: ==5331== Source and destination overlap in memcpy(0x38f870c0, 0x38f870c2, 70) ==5331== at 0x442F0C8: memcpy@@GLIBC_2.14 (vg_replace_strmem.c:1033) ==5331== by 0x4999F77: xercesc_3_1::XMLString::collapseWS(unsigned short*, xercesc_3_1::MemoryManager*) (in /usr/lib64/libxerces-c-3.1.so) ==5331== by 0x4AA78A4: xercesc_3_1::TraverseSchema::getElementAttValue(xercesc_3_1::DOMElement const*, unsigned short const*, xercesc_3_1::DatatypeValidator::ValidatorType) (in /usr/lib64/libxerces-c-3.1.so) ==5331== by 0x4ABCC76: xercesc_3_1::TraverseSchema::traverseElementDecl(xercesc_3_1::DOMElement const*, bool) (in /usr/lib64/libxerces-c-3.1.so) ==5331== by 0x4AB819E: xercesc_3_1::TraverseSchema::traverseChoiceSequence(xercesc_3_1::DOMElement const*, int, bool&) (in /usr/lib64/libxerces-c-3.1.so) ==5331== by 0x4AB8C55: xercesc_3_1::TraverseSchema::processComplexContent(xercesc_3_1::DOMElement const*, unsigned short const*, xercesc_3_1::DOMElement const*, xercesc_3_1::ComplexTypeInfo*, unsigned short const*, bool, bool) (in /usr/lib64/libxerces-c-3.1.so) ==5331== by 0x4AB9F39: xercesc_3_1::TraverseSchema::traverseComplexTypeDecl(xercesc_3_1::DOMElement const*, bool, unsigned short const*) (in /usr/lib64/libxerces-c-3.1.so) ==5331== by 0x4AC02C1: xercesc_3_1::TraverseSchema::processChildren(xercesc_3_1::DOMElement const*) (in /usr/lib64/libxerces-c-3.1.so) ==5331== by 0x4AC0F60: xercesc_3_1::TraverseSchema::traverseInclude(xercesc_3_1::DOMElement const*) (in /usr/lib64/libxerces-c-3.1.so) ==5331== by 0x4ABFD6B: xercesc_3_1::TraverseSchema::processChildren(xercesc_3_1::DOMElement const*) (in /usr/lib64/libxerces-c-3.1.so) ==5331== by 0x4AC0A55: xercesc_3_1::TraverseSchema::doTraverseSchema(xercesc_3_1::DOMElement const*) (in /usr/lib64/libxerces-c-3.1.so) ==5331== by 0x4AC3FB1: xercesc_3_1::TraverseSchema::TraverseSchema(xercesc_3_1::DOMElement*, xercesc_3_1::XMLStringPool*, xercesc_3_1::SchemaGrammar*, xercesc_3_1::GrammarResolver*, xercesc_3_1::RefHash2KeysTableOf*, xercesc_3_1::RefHash2KeysTableOf*, xercesc_3_1::XMLScanner*, unsigned short const*, xercesc_3_1::XMLEntityHandler*, xercesc_3_1::XMLErrorReporter*, xercesc_3_1::MemoryManager*, bool) (in /usr/lib64/libxerces-c-3.1.so) -- This message was sent by Atlassian Jira (v8.3.2#803003) - To unsubscribe, e-mail: c-dev-unsubscr...@xerces.apache.org For additional commands, e-mail: c-dev-h...@xerces.apache.org
[jira] [Commented] (XERCESC-2175) Source and destination overlap in memcpy
[ https://issues.apache.org/jira/browse/XERCESC-2175?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16991939#comment-16991939 ] João M. S. Silva commented on XERCESC-2175: --- I think we must close the ticket then, as I can't provide one. > Source and destination overlap in memcpy > > > Key: XERCESC-2175 > URL: https://issues.apache.org/jira/browse/XERCESC-2175 > Project: Xerces-C++ > Issue Type: Bug > Components: Validating Parser (XML Schema) >Affects Versions: 3.2.2 >Reporter: João M. S. Silva >Priority: Major > > I get this Valgrind error: > ==5331== Source and destination overlap in memcpy(0x38f870c0, 0x38f870c2, 70) > ==5331== at 0x442F0C8: memcpy@@GLIBC_2.14 (vg_replace_strmem.c:1033) > ==5331== by 0x4999F77: xercesc_3_1::XMLString::collapseWS(unsigned short*, > xercesc_3_1::MemoryManager*) (in /usr/lib64/libxerces-c-3.1.so) > ==5331== by 0x4AA78A4: > xercesc_3_1::TraverseSchema::getElementAttValue(xercesc_3_1::DOMElement > const*, unsigned short const*, xercesc_3_1::DatatypeValidator::ValidatorType) > (in /usr/lib64/libxerces-c-3.1.so) > ==5331== by 0x4ABCC76: > xercesc_3_1::TraverseSchema::traverseElementDecl(xercesc_3_1::DOMElement > const*, bool) (in /usr/lib64/libxerces-c-3.1.so) > ==5331== by 0x4AB819E: > xercesc_3_1::TraverseSchema::traverseChoiceSequence(xercesc_3_1::DOMElement > const*, int, bool&) (in /usr/lib64/libxerces-c-3.1.so) > ==5331== by 0x4AB8C55: > xercesc_3_1::TraverseSchema::processComplexContent(xercesc_3_1::DOMElement > const*, unsigned short const*, xercesc_3_1::DOMElement const*, > xercesc_3_1::ComplexTypeInfo*, unsigned short const*, bool, bool) (in > /usr/lib64/libxerces-c-3.1.so) > ==5331== by 0x4AB9F39: > xercesc_3_1::TraverseSchema::traverseComplexTypeDecl(xercesc_3_1::DOMElement > const*, bool, unsigned short const*) (in /usr/lib64/libxerces-c-3.1.so) > ==5331== by 0x4AC02C1: > xercesc_3_1::TraverseSchema::processChildren(xercesc_3_1::DOMElement const*) > (in /usr/lib64/libxerces-c-3.1.so) > ==5331== by 0x4AC0F60: > xercesc_3_1::TraverseSchema::traverseInclude(xercesc_3_1::DOMElement const*) > (in /usr/lib64/libxerces-c-3.1.so) > ==5331== by 0x4ABFD6B: > xercesc_3_1::TraverseSchema::processChildren(xercesc_3_1::DOMElement const*) > (in /usr/lib64/libxerces-c-3.1.so) > ==5331== by 0x4AC0A55: > xercesc_3_1::TraverseSchema::doTraverseSchema(xercesc_3_1::DOMElement const*) > (in /usr/lib64/libxerces-c-3.1.so) > ==5331== by 0x4AC3FB1: > xercesc_3_1::TraverseSchema::TraverseSchema(xercesc_3_1::DOMElement*, > xercesc_3_1::XMLStringPool*, xercesc_3_1::SchemaGrammar*, > xercesc_3_1::GrammarResolver*, > xercesc_3_1::RefHash2KeysTableOf xercesc_3_1::StringHasher>*, > xercesc_3_1::RefHash2KeysTableOf xercesc_3_1::StringHasher>*, xercesc_3_1::XMLScanner*, unsigned short const*, > xercesc_3_1::XMLEntityHandler*, xercesc_3_1::XMLErrorReporter*, > xercesc_3_1::MemoryManager*, bool) (in /usr/lib64/libxerces-c-3.1.so) -- 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-2175) Source and destination overlap in memcpy
[ https://issues.apache.org/jira/browse/XERCESC-2175?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16992016#comment-16992016 ] João M. S. Silva commented on XERCESC-2175: --- The problem is that I don't remember how I obtained that. I remember thinking that this should be reported, that it was to some extent irrespective of the testcase and that the stack trace would be enough. Apparently I was wrong. I'll try to see if i remember how I got this. > Source and destination overlap in memcpy > > > Key: XERCESC-2175 > URL: https://issues.apache.org/jira/browse/XERCESC-2175 > Project: Xerces-C++ > Issue Type: Bug > Components: Validating Parser (XML Schema) >Affects Versions: 3.2.0, 3.2.1, 3.2.2 >Reporter: João M. S. Silva >Priority: Major > Fix For: 3.2.3 > > > I get this Valgrind error: > ==5331== Source and destination overlap in memcpy(0x38f870c0, 0x38f870c2, 70) > ==5331== at 0x442F0C8: memcpy@@GLIBC_2.14 (vg_replace_strmem.c:1033) > ==5331== by 0x4999F77: xercesc_3_1::XMLString::collapseWS(unsigned short*, > xercesc_3_1::MemoryManager*) (in /usr/lib64/libxerces-c-3.1.so) > ==5331== by 0x4AA78A4: > xercesc_3_1::TraverseSchema::getElementAttValue(xercesc_3_1::DOMElement > const*, unsigned short const*, xercesc_3_1::DatatypeValidator::ValidatorType) > (in /usr/lib64/libxerces-c-3.1.so) > ==5331== by 0x4ABCC76: > xercesc_3_1::TraverseSchema::traverseElementDecl(xercesc_3_1::DOMElement > const*, bool) (in /usr/lib64/libxerces-c-3.1.so) > ==5331== by 0x4AB819E: > xercesc_3_1::TraverseSchema::traverseChoiceSequence(xercesc_3_1::DOMElement > const*, int, bool&) (in /usr/lib64/libxerces-c-3.1.so) > ==5331== by 0x4AB8C55: > xercesc_3_1::TraverseSchema::processComplexContent(xercesc_3_1::DOMElement > const*, unsigned short const*, xercesc_3_1::DOMElement const*, > xercesc_3_1::ComplexTypeInfo*, unsigned short const*, bool, bool) (in > /usr/lib64/libxerces-c-3.1.so) > ==5331== by 0x4AB9F39: > xercesc_3_1::TraverseSchema::traverseComplexTypeDecl(xercesc_3_1::DOMElement > const*, bool, unsigned short const*) (in /usr/lib64/libxerces-c-3.1.so) > ==5331== by 0x4AC02C1: > xercesc_3_1::TraverseSchema::processChildren(xercesc_3_1::DOMElement const*) > (in /usr/lib64/libxerces-c-3.1.so) > ==5331== by 0x4AC0F60: > xercesc_3_1::TraverseSchema::traverseInclude(xercesc_3_1::DOMElement const*) > (in /usr/lib64/libxerces-c-3.1.so) > ==5331== by 0x4ABFD6B: > xercesc_3_1::TraverseSchema::processChildren(xercesc_3_1::DOMElement const*) > (in /usr/lib64/libxerces-c-3.1.so) > ==5331== by 0x4AC0A55: > xercesc_3_1::TraverseSchema::doTraverseSchema(xercesc_3_1::DOMElement const*) > (in /usr/lib64/libxerces-c-3.1.so) > ==5331== by 0x4AC3FB1: > xercesc_3_1::TraverseSchema::TraverseSchema(xercesc_3_1::DOMElement*, > xercesc_3_1::XMLStringPool*, xercesc_3_1::SchemaGrammar*, > xercesc_3_1::GrammarResolver*, > xercesc_3_1::RefHash2KeysTableOf xercesc_3_1::StringHasher>*, > xercesc_3_1::RefHash2KeysTableOf xercesc_3_1::StringHasher>*, xercesc_3_1::XMLScanner*, unsigned short const*, > xercesc_3_1::XMLEntityHandler*, xercesc_3_1::XMLErrorReporter*, > xercesc_3_1::MemoryManager*, bool) (in /usr/lib64/libxerces-c-3.1.so) -- 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-2175) Source and destination overlap in memcpy
[ https://issues.apache.org/jira/browse/XERCESC-2175?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16992518#comment-16992518 ] João M. S. Silva commented on XERCESC-2175: --- I made some experiments that could have led to this Valgrind report but could not reproduce it. > Source and destination overlap in memcpy > > > Key: XERCESC-2175 > URL: https://issues.apache.org/jira/browse/XERCESC-2175 > Project: Xerces-C++ > Issue Type: Bug > Components: Validating Parser (XML Schema) >Affects Versions: 3.2.0, 3.2.1, 3.2.2 >Reporter: João M. S. Silva >Priority: Major > Fix For: 3.2.3 > > > I get this Valgrind error: > ==5331== Source and destination overlap in memcpy(0x38f870c0, 0x38f870c2, 70) > ==5331== at 0x442F0C8: memcpy@@GLIBC_2.14 (vg_replace_strmem.c:1033) > ==5331== by 0x4999F77: xercesc_3_1::XMLString::collapseWS(unsigned short*, > xercesc_3_1::MemoryManager*) (in /usr/lib64/libxerces-c-3.1.so) > ==5331== by 0x4AA78A4: > xercesc_3_1::TraverseSchema::getElementAttValue(xercesc_3_1::DOMElement > const*, unsigned short const*, xercesc_3_1::DatatypeValidator::ValidatorType) > (in /usr/lib64/libxerces-c-3.1.so) > ==5331== by 0x4ABCC76: > xercesc_3_1::TraverseSchema::traverseElementDecl(xercesc_3_1::DOMElement > const*, bool) (in /usr/lib64/libxerces-c-3.1.so) > ==5331== by 0x4AB819E: > xercesc_3_1::TraverseSchema::traverseChoiceSequence(xercesc_3_1::DOMElement > const*, int, bool&) (in /usr/lib64/libxerces-c-3.1.so) > ==5331== by 0x4AB8C55: > xercesc_3_1::TraverseSchema::processComplexContent(xercesc_3_1::DOMElement > const*, unsigned short const*, xercesc_3_1::DOMElement const*, > xercesc_3_1::ComplexTypeInfo*, unsigned short const*, bool, bool) (in > /usr/lib64/libxerces-c-3.1.so) > ==5331== by 0x4AB9F39: > xercesc_3_1::TraverseSchema::traverseComplexTypeDecl(xercesc_3_1::DOMElement > const*, bool, unsigned short const*) (in /usr/lib64/libxerces-c-3.1.so) > ==5331== by 0x4AC02C1: > xercesc_3_1::TraverseSchema::processChildren(xercesc_3_1::DOMElement const*) > (in /usr/lib64/libxerces-c-3.1.so) > ==5331== by 0x4AC0F60: > xercesc_3_1::TraverseSchema::traverseInclude(xercesc_3_1::DOMElement const*) > (in /usr/lib64/libxerces-c-3.1.so) > ==5331== by 0x4ABFD6B: > xercesc_3_1::TraverseSchema::processChildren(xercesc_3_1::DOMElement const*) > (in /usr/lib64/libxerces-c-3.1.so) > ==5331== by 0x4AC0A55: > xercesc_3_1::TraverseSchema::doTraverseSchema(xercesc_3_1::DOMElement const*) > (in /usr/lib64/libxerces-c-3.1.so) > ==5331== by 0x4AC3FB1: > xercesc_3_1::TraverseSchema::TraverseSchema(xercesc_3_1::DOMElement*, > xercesc_3_1::XMLStringPool*, xercesc_3_1::SchemaGrammar*, > xercesc_3_1::GrammarResolver*, > xercesc_3_1::RefHash2KeysTableOf xercesc_3_1::StringHasher>*, > xercesc_3_1::RefHash2KeysTableOf xercesc_3_1::StringHasher>*, xercesc_3_1::XMLScanner*, unsigned short const*, > xercesc_3_1::XMLEntityHandler*, xercesc_3_1::XMLErrorReporter*, > xercesc_3_1::MemoryManager*, bool) (in /usr/lib64/libxerces-c-3.1.so) -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: c-dev-unsubscr...@xerces.apache.org For additional commands, e-mail: c-dev-h...@xerces.apache.org
[jira] [Created] (XERCESC-2248) cmake: use enumerations for possible values, so that cmake-gui offers a drop-down selection
Дилян Палаузов created XERCESC-2248: --- Summary: cmake: use enumerations for possible values, so that cmake-gui offers a drop-down selection Key: XERCESC-2248 URL: https://issues.apache.org/jira/browse/XERCESC-2248 Project: Xerces-C++ Issue Type: Improvement Reporter: Дилян Палаузов -- 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] [Updated] (XERCESC-2248) cmake: use enumerations for possible values, so that cmake-gui offers a drop-down selection
[
https://issues.apache.org/jira/browse/XERCESC-2248?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Дилян Палаузов updated XERCESC-2248:
Attachment: f5106371c52674a8fc0fe8ddfac92e62c85402c7.patch.txt
Component/s: Build
Flags: Patch
Affects Version/s: 3.2.5
4.0.0
Description:
The current change allows the cmake-gui (like {_}ccmake{_}) to offer the user a
fixed enumeration of possible values, so that the user can select one from a
drop-down menu. In case of _ccmake_ the possible values are toggled by pressing
enter and it is not anymore possible for the user to enter text as value.
I have very basic knowledge about {_}cmake{_}, so there might be a different
way to achieve the same result. If a different way is preferred, please go
forward with it, without asking me to adopt it.
Patch is attached.
Priority: Trivial (was: Major)
> cmake: use enumerations for possible values, so that cmake-gui offers a
> drop-down selection
> ---
>
> Key: XERCESC-2248
> URL: https://issues.apache.org/jira/browse/XERCESC-2248
> Project: Xerces-C++
> Issue Type: Improvement
> Components: Build
>Affects Versions: 3.2.5, 4.0.0
>Reporter: Дилян Палаузов
>Priority: Trivial
> Attachments: f5106371c52674a8fc0fe8ddfac92e62c85402c7.patch.txt
>
>
> The current change allows the cmake-gui (like {_}ccmake{_}) to offer the user
> a fixed enumeration of possible values, so that the user can select one from
> a drop-down menu. In case of _ccmake_ the possible values are toggled by
> pressing enter and it is not anymore possible for the user to enter text as
> value.
> I have very basic knowledge about {_}cmake{_}, so there might be a different
> way to achieve the same result. If a different way is preferred, please go
> forward with it, without asking me to adopt it.
> Patch is attached.
--
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-1390) Regular expressions with unions do not work properly with replacing and tokenizing.
[ http://issues.apache.org/jira/browse/XERCESC-1390?page=comments#action_63591 ] cargilld commented on XERCESC-1390: --- Hi Dave, I reviewed the patch and found some tests to exercise your change and it seems to work fine. Please go ahead and commit your patch. David > Regular expressions with unions do not work properly with replacing and > tokenizing. > --- > > Key: XERCESC-1390 > URL: http://issues.apache.org/jira/browse/XERCESC-1390 > Project: Xerces-C++ > Type: Bug > Components: Utilities > Versions: 2.6.0 > Reporter: David Bertoni > Assignee: David Bertoni > Priority: Critical > Attachments: patch.txt > > Consider the following regular expression: > "(ab) | (a)" > with the following input string: > "abracadabra" > If you use an instance the RegularExpression class to replace any matching > substrings with the empty string, the result should be the following string: > "rcdr" > Instead, just the last "a" in the string is replaced: > "abracadabr" > If you use the same RegularExpression instance to tokenize the expression, > the result should be the following set of strings: > "" > "r" > "c" > "d" > "r" > "" > Instead, the result is > "abracadabr" > "" > I will attach a proposed patch, but I don't know this code well, so it would > be great if someone could review it. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Commented: (XERCESC-1368) Catch-all handler are problematic on Windows
[ http://issues.apache.org/jira/browse/XERCESC-1368?page=comments#action_63592 ] cargilld commented on XERCESC-1368: --- Hi Dave, I reviewed your patch and it looks fine, feel free to commit the patch. David > Catch-all handler are problematic on Windows > > > Key: XERCESC-1368 > URL: http://issues.apache.org/jira/browse/XERCESC-1368 > Project: Xerces-C++ > Type: Bug > Components: Miscellaneous > Versions: 2.6.0 > Environment: Windows XP with Visual Studio .NET 2003 > Reporter: David Bertoni > Assignee: David Bertoni > Attachments: patch.txt > > Exception handlers of the form "catch(...)" are causing problems in our > product code on Windows, because they are catching hardware exceptions, such > as access violations. > There is an article in the MSDN Knowledge Base that describes how this has > changed between Visual Studio 6, and Visual Studio .NET: > http://msdn.microsoft.com/library/default.asp?url=/library/en-us/vclang/html/_core_exception_handling.3a_.default_synchronous_exception_model.asp > However, my experience with Xerces-C using Visual Studio .NET 2003 is that > hardware exceptions (asynchronous exceptions, in the Microsoft parlance) are > still being caught in Xerces-C in catch-all handlers. This is problematic > because it interferes with normal diagnosis of hardware faults, and can lead > to code being executed in Xerces-C when the system is in an unknown state. > It is also a makes it difficult to write code that will behave the same on > other platforms. > Looking into the code reveals multiple places where a catch-all handler > resets some object (or some other similar behavior), then rethrows the same > exception. I'd like to propose that we try to eliminate as many of these > catch handlers as possible by replaces these actions with stack objects that > perform these actions automatically whether or not an exception is thrown > (auto_ptr-like behavior). This will also have the benefit of simplifying the > code. From a "philosophical" perspective, I also think its better for code > to catch the exceptions it's concerned with, and avoid catch-all handlers > except when absolutely necessary. > I will attach a proposed patch for a class that does this sort of thing, and > some modified code that uses this class. I would also like to see if anyone > else has observed this behavior in their Windows applications. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Resolved: (XERCESC-1404) Error message contains a substitution parameter that is not supplied
[ http://issues.apache.org/jira/browse/XERCESC-1404?page=all ] cargilld resolved XERCESC-1404: --- Resolution: Fixed Hi Dave, I fixed this, going with option 2. I had some other message updates to do so addressed this at the same time. David > Error message contains a substitution parameter that is not supplied > > > Key: XERCESC-1404 > URL: http://issues.apache.org/jira/browse/XERCESC-1404 > Project: Xerces-C++ > Type: Bug > Components: Miscellaneous > Versions: 2.6.0 > Reporter: David Bertoni > Assignee: David Bertoni > Priority: Minor > > The error message for XMLExcepts::HshTbl_NoSuchKeyExists has a substitution > parameter, but the code never supplies it. We should either: > 1. supplied the parameter > 2. remove it > I'm suggesting we opt for 2, since the value of the key is not terribly > useful to the end user, and this exception is not very common. > Opinions? -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Commented: (XERCESC-1413) Build fails on PowerPC IBM AIX 4.3.3.0
[ http://issues.apache.org/jira/browse/XERCESC-1413?page=comments#action_63796 ] cargilld commented on XERCESC-1413: --- Hi Kai, What version of xlC are you using? I build on AIX regularly and haven't encountered these problems. For the first error I don't see anything wrong with: void operator delete(void* p, MemoryManager* memMgr); For the second error, it is a bug: ArrayJanitor& operator=(const ArrayJanitor& copy); should be: ArrayJanitor& operator=(const ArrayJanitor& copy); I will fix this later. David > Build fails on PowerPC IBM AIX 4.3.3.0 > -- > > Key: XERCESC-1413 > URL: http://issues.apache.org/jira/browse/XERCESC-1413 > Project: Xerces-C++ > Type: Bug > Components: Utilities > Versions: 2.6.0 > Environment: PowerPC IBM AIX 4.3.3.0, > Reporter: Kai Hackemesser > > This is the output from 'make' I got: > xlC_r -qnotempinc -D_THREAD_SAFE -qnamemangling=ansi -c > -I/home/edm/mpadm22/xerces-c-src_2_6_0/src/xercesc/include -w -O2 > -DPROJ_XMLPARSER -DPROJ_XMLUTIL -DPROJ_PARSERS -DPROJ_SAX4C -DPROJ_SAX2 > -DPROJ_DOM -DPROJ_DEPRECATED_DOM -DPROJ_VALIDATORS > -DXML_USE_NATIVE_TRANSCODER -DXML_USE_INMEM_MESSAGELOADER -DXML_USE_PTHREADS > -DXML_USE_NETACCESSOR_SOCKET -o > /home/edm/mpadm22/xerces-c-src_2_6_0/src/xercesc/obj/AIX/Base64.o Base64.cpp > "/home/edm/mpadm22/xerces-c-src_2_6_0/src/xercesc/include/xercesc/util/XMemory.hpp", > line 98.10: 1540-141: (S) Argument 2 for "operator delete" must be of type > "unsigned long". > "/home/edm/mpadm22/xerces-c-src_2_6_0/src/xercesc/include/xercesc/util/Janitor.hpp", > line 146.17: 1540-090: (S) Syntax error - expected "<" and found "&". > make[1]: *** [Base64.o] Error 1 > make[1]: Leaving directory > `/home/edm/mpadm22/xerces-c-src_2_6_0/src/xercesc/util' > make: *** [Util] Error 2 > How to solve? > Regards, > Kai -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Commented: (XERCESC-1413) Build fails on PowerPC IBM AIX 4.3.3.0
[ http://issues.apache.org/jira/browse/XERCESC-1413?page=comments#action_63808 ] cargilld commented on XERCESC-1413: --- Hi Kai, xlC V5 and below are out of support (as is AIX 4.3.3). I suspect the problem you are encountering is a compiler limitiation. Can you upgrade to xlC V6 or V7? David > Build fails on PowerPC IBM AIX 4.3.3.0 > -- > > Key: XERCESC-1413 > URL: http://issues.apache.org/jira/browse/XERCESC-1413 > Project: Xerces-C++ > Type: Bug > Components: Utilities > Versions: 2.6.0 > Environment: PowerPC IBM AIX 4.3.3.0, > Reporter: Kai Hackemesser > > This is the output from 'make' I got: > xlC_r -qnotempinc -D_THREAD_SAFE -qnamemangling=ansi -c > -I/home/edm/mpadm22/xerces-c-src_2_6_0/src/xercesc/include -w -O2 > -DPROJ_XMLPARSER -DPROJ_XMLUTIL -DPROJ_PARSERS -DPROJ_SAX4C -DPROJ_SAX2 > -DPROJ_DOM -DPROJ_DEPRECATED_DOM -DPROJ_VALIDATORS > -DXML_USE_NATIVE_TRANSCODER -DXML_USE_INMEM_MESSAGELOADER -DXML_USE_PTHREADS > -DXML_USE_NETACCESSOR_SOCKET -o > /home/edm/mpadm22/xerces-c-src_2_6_0/src/xercesc/obj/AIX/Base64.o Base64.cpp > "/home/edm/mpadm22/xerces-c-src_2_6_0/src/xercesc/include/xercesc/util/XMemory.hpp", > line 98.10: 1540-141: (S) Argument 2 for "operator delete" must be of type > "unsigned long". > "/home/edm/mpadm22/xerces-c-src_2_6_0/src/xercesc/include/xercesc/util/Janitor.hpp", > line 146.17: 1540-090: (S) Syntax error - expected "<" and found "&". > make[1]: *** [Base64.o] Error 1 > make[1]: Leaving directory > `/home/edm/mpadm22/xerces-c-src_2_6_0/src/xercesc/util' > make: *** [Util] Error 2 > How to solve? > Regards, > Kai -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Resolved: (XERCESC-1414) DOMException instead of call to ErrorHandler
[ http://issues.apache.org/jira/browse/XERCESC-1414?page=all ] cargilld resolved XERCESC-1414: --- Resolution: Fixed Hi, I made a fix recently that will catch this error. You will now get: Fatal Error at file d:\bugs\1414.xsd, line 8, char 8 Message: Element qname beginning with 'xsd:' invalid This is fixed in the latest source. David > DOMException instead of call to ErrorHandler > > > Key: XERCESC-1414 > URL: http://issues.apache.org/jira/browse/XERCESC-1414 > Project: Xerces-C++ > Type: Bug > Components: Validating Parser (Schema) (Xerces 1.5 or up only) > Versions: 2.6.0 > Environment: x86_64-pc-linux-gnu > Reporter: Boris Kolpackov > > Consider the following XML Schema > > http://www.w3.org/2001/XMLSchema"; > xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"; > xsi:schemaLocation="http://www.w3.org/2001/XMLSchema > XMLSchema.xsd" > xmlns:test="http://www.example.org/test"; > targetNamespace="http://www.example.org/test";> > > > > Note '::' in element declaration. When I feed this file to loadGrammar() > I get DOMException with error code 14 and message that reads: > "An attempt is made to create or change an object in a way which is incorrect > with regard to namespaces" > Should this error be rather dealt with via ErrorHandler (with file, position, > etc.)? That's the impression I got from reading comments in DOMException.hpp. > thanks, > -boris -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Assigned: (XERCESC-1115) Base64Binary validation failed when length is zero
[ http://issues.apache.org/jira/browse/XERCESC-1115?page=all ]
cargilld reassigned XERCESC-1115:
-
Assign To: cargilld (was: Xerces-C Developers Mailing List)
> Base64Binary validation failed when length is zero
> --
>
> Key: XERCESC-1115
> URL: http://issues.apache.org/jira/browse/XERCESC-1115
> Project: Xerces-C++
> Type: Bug
> Components: Validating Parser (Schema) (Xerces 1.5 or up only)
> Versions: 2.3.0
> Environment: Operating System: Other
> Platform: Other
> Reporter: Loic BAUDRY
> Assignee: cargilld
>
> If a base64binary element have no data, the validation failed with the
> following
> message :
> "Datatype error: Type:InvalidDatatypeValueException, Message:Value '' is not
> encoded in Base64 ."
> To reproduce, create an XD with
>
> and an XML with
>
> There is also a different behaviour in the Java implementation. One may be
> right, but which one ?
> In \src\xercesc\validators\datatype\Base64BinaryDatatypeValidator.cpp
> we have :
> if (getLength(content) <= 0)
> In the JAVA Version of xerces, it seems the test is different :
> if (getLength( content) < 0) {
> Which version is right ? It would be fine if the two implementation have the
> same behaviour.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see:
http://www.atlassian.com/software/jira
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Assigned: (XERCESC-1115) Base64Binary validation failed when length is zero
[ http://issues.apache.org/jira/browse/XERCESC-1115?page=all ]
cargilld reassigned XERCESC-1115:
-
Assign To: cargilld (was: Xerces-C Developers Mailing List)
> Base64Binary validation failed when length is zero
> --
>
> Key: XERCESC-1115
> URL: http://issues.apache.org/jira/browse/XERCESC-1115
> Project: Xerces-C++
> Type: Bug
> Components: Validating Parser (Schema) (Xerces 1.5 or up only)
> Versions: 2.3.0
> Environment: Operating System: Other
> Platform: Other
> Reporter: Loic BAUDRY
> Assignee: cargilld
>
> If a base64binary element have no data, the validation failed with the
> following
> message :
> "Datatype error: Type:InvalidDatatypeValueException, Message:Value '' is not
> encoded in Base64 ."
> To reproduce, create an XD with
>
> and an XML with
>
> There is also a different behaviour in the Java implementation. One may be
> right, but which one ?
> In \src\xercesc\validators\datatype\Base64BinaryDatatypeValidator.cpp
> we have :
> if (getLength(content) <= 0)
> In the JAVA Version of xerces, it seems the test is different :
> if (getLength( content) < 0) {
> Which version is right ? It would be fine if the two implementation have the
> same behaviour.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see:
http://www.atlassian.com/software/jira
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Closed: (XERCESC-1115) Base64Binary validation failed when length is zero
[ http://issues.apache.org/jira/browse/XERCESC-1115?page=all ]
cargilld closed XERCESC-1115:
-
Fix is in cvs.
> Base64Binary validation failed when length is zero
> --
>
> Key: XERCESC-1115
> URL: http://issues.apache.org/jira/browse/XERCESC-1115
> Project: Xerces-C++
> Type: Bug
> Components: Validating Parser (Schema) (Xerces 1.5 or up only)
> Versions: 2.3.0
> Environment: Operating System: Other
> Platform: Other
> Reporter: Loic BAUDRY
> Assignee: cargilld
>
> If a base64binary element have no data, the validation failed with the
> following
> message :
> "Datatype error: Type:InvalidDatatypeValueException, Message:Value '' is not
> encoded in Base64 ."
> To reproduce, create an XD with
>
> and an XML with
>
> There is also a different behaviour in the Java implementation. One may be
> right, but which one ?
> In \src\xercesc\validators\datatype\Base64BinaryDatatypeValidator.cpp
> we have :
> if (getLength(content) <= 0)
> In the JAVA Version of xerces, it seems the test is different :
> if (getLength( content) < 0) {
> Which version is right ? It would be fine if the two implementation have the
> same behaviour.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see:
http://www.atlassian.com/software/jira
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Commented: (XERCESC-1348) IGXMLScanner allocates from wrong memory manager
[ http://issues.apache.org/jira/browse/XERCESC-1348?page=comments#action_12312561 ] cargilld commented on XERCESC-1348: --- Hi Dave, I reviewed the patch and it looks good. Please commit. David > IGXMLScanner allocates from wrong memory manager > > > Key: XERCESC-1348 > URL: http://issues.apache.org/jira/browse/XERCESC-1348 > Project: Xerces-C++ > Type: Bug > Components: SAX/SAX2, Validating Parser (DTD) > Versions: 2.6.0 > Environment: Found on solaris, but no a solaris issue. > Reporter: Mark Weissman > Assignee: David Bertoni > Attachments: patch.txt > > IGXMLScanner.c allocates from fGrammarPoolMemoryManager instead of > fMemoryManager. > This causes a memory leak and thread safety issues when sharing > an unsynchronized grammar pool across multiple threads. I included diffs > that affect my application but I suspect this problem exists for other > scanners too. It would be good if somebody could check all uses of > fGrammarPoolMemoryManager to verify the immutability of cached grammars > and thread safety for the GrammarPool. When not parsing grammars, the > pool should not change. > > > > diff IGXMLScanner.cpp IGXMLScanner.cpp.orig > 1256,1257c1256 > < MemoryManager *rootDeclMgr = /*MDW*/fUseCachedGrammar ? fMemoryManager > : fGrammarPoolMemoryManager; > < DTDElementDecl* rootDecl = new (/*MDW*/rootDeclMgr) DTDElementDecl > --- > > DTDElementDecl* rootDecl = new (fGrammarPoolMemoryManager) > > DTDElementDecl > 1262c1261 > < , /*MDW*/rootDeclMgr > --- > > , fGrammarPoolMemoryManager > 1497c1496 > < DTDEntityDecl* declDTD = new (fMemoryManager/*MDW*/) > DTDEntityDecl(gDTDStr, false, fMemoryManager/*MDW*/); > --- > > DTDEntityDecl* declDTD = new (fGrammarPoolMemoryManager) > > DTDEntityDecl(gDTDStr, false, fGrammarPoolMemoryManager); -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Commented: (XERCESC-1368) Catch-all handler are problematic on Windows
[ http://issues.apache.org/jira/browse/XERCESC-1368?page=comments#action_12312750 ] cargilld commented on XERCESC-1368: --- Hi Dave, I reviewed the patch and it looks good. Please commit. David > Catch-all handler are problematic on Windows > > > Key: XERCESC-1368 > URL: http://issues.apache.org/jira/browse/XERCESC-1368 > Project: Xerces-C++ > Type: Bug > Components: Miscellaneous > Versions: 2.6.0 > Environment: Windows XP with Visual Studio .NET 2003 > Reporter: David Bertoni > Assignee: David Bertoni > Attachments: patch.txt > > Exception handlers of the form "catch(...)" are causing problems in our > product code on Windows, because they are catching hardware exceptions, such > as access violations. > There is an article in the MSDN Knowledge Base that describes how this has > changed between Visual Studio 6, and Visual Studio .NET: > http://msdn.microsoft.com/library/default.asp?url=/library/en-us/vclang/html/_core_exception_handling.3a_.default_synchronous_exception_model.asp > However, my experience with Xerces-C using Visual Studio .NET 2003 is that > hardware exceptions (asynchronous exceptions, in the Microsoft parlance) are > still being caught in Xerces-C in catch-all handlers. This is problematic > because it interferes with normal diagnosis of hardware faults, and can lead > to code being executed in Xerces-C when the system is in an unknown state. > It is also a makes it difficult to write code that will behave the same on > other platforms. > Looking into the code reveals multiple places where a catch-all handler > resets some object (or some other similar behavior), then rethrows the same > exception. I'd like to propose that we try to eliminate as many of these > catch handlers as possible by replaces these actions with stack objects that > perform these actions automatically whether or not an exception is thrown > (auto_ptr-like behavior). This will also have the benefit of simplifying the > code. From a "philosophical" perspective, I also think its better for code > to catch the exceptions it's concerned with, and avoid catch-all handlers > except when absolutely necessary. > I will attach a proposed patch for a class that does this sort of thing, and > some modified code that uses this class. I would also like to see if anyone > else has observed this behavior in their Windows applications. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Resolved: (XERCESC-1423) Bugfix & Performance Update : IGXMLScanner::basicAttrValueScan(...)
[ http://issues.apache.org/jira/browse/XERCESC-1423?page=all ] cargilld resolved XERCESC-1423: --- Resolution: Fixed Hi Christian, I reviewed your patch and it looked good. I have committed it to svn (for both igxmlscanner2 and sgxmlscanner). David > Bugfix & Performance Update : IGXMLScanner::basicAttrValueScan(...) > --- > > Key: XERCESC-1423 > URL: http://issues.apache.org/jira/browse/XERCESC-1423 > Project: Xerces-C++ > Type: Bug > Components: Non-Validating Parser > Versions: 2.6.0 > Environment: all > Reporter: Christian Will > Attachments: IGXMLScanner2.cpp.patch, test_fail1.xml, test_fail2.xml, > test_ok.xml > > Hi folks, > I worked on a performance patch of IGXMLScanner::basicAttrValueScan(...) and > found at the same time some cases where xerces should report an error, where > it does not. > Here are two examples: (I'll attach some sample files) > - we have a leading surrogate, without the trailing surrogate, at the end of > our attribute value > (xerces just ignores this case) > - we have an entity ref. between a leading surrogate at and the associated > trailing surrogate > (xerces just ignores this case) > I'll attach my patch and I hope somebody has time to review it... > Regards, > Christian -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Commented: (XERCESC-1421) Inner element with schema generates EmptyStackException
[ http://issues.apache.org/jira/browse/XERCESC-1421?page=comments#action_12313834 ] cargilld commented on XERCESC-1421: --- Hi Jay, I think is a duplicate of xercesc-1282, which I fixed on Oct 13 (http://marc.theaimsgroup.com/?l=xerces-cvs&m=109769049513276&w=2). I believe that was just after the 2.6 release. Let me know if I can close this bug report. David > Inner element with schema generates EmptyStackException > --- > > Key: XERCESC-1421 > URL: http://issues.apache.org/jira/browse/XERCESC-1421 > Project: Xerces-C++ > Type: Bug > Components: SAX/SAX2 > Versions: 2.6.0 > Environment: Debian unstable xerces 2.6.0 > (I am the debian maintainer for xerces-c.) > Reporter: Jay Berkenbilt > > When using SAX2XMLReader, an EmptyStackException is thrown when parsing a > document whose top-level element has no grammar but which contains a > lower-level element that has a schema associated with it. (Perhaps I have > over-generalized -- example below.) XMLSpy is able to parse this document > and, as far as I can tell, it should be valid. In any case, an > EmptyStackException definitely seems to be out of order here. > To reproduce the problem, parse this document instance: > > > http://www.w3.org/2001/XMLSchema-instance"; >xsi:noNamespaceSchemaLocation="test.xsd" > >1415926535 > > with this schema: > > http://www.w3.org/2001/XMLSchema";> > > > using the SAX2Print example with no special arguments (valdation scheme = > auto). When I do this, I get the following result: > > > 1415926535 > Fatal Error at file > /u1/home/ejb/Q/bugs/xerces/empty-stack-exception/test.xml, line 5, char 19 > Message: An exception occurred! Type:EmptyStackException, Message:The stack > is empty, cannot access members > Ideally, a document should be able to contain any number of nested elements > with schemas. This document: > > > http://www.w3.org/2001/XMLSchema-instance"; >xsi:noNamespaceSchemaLocation="test.xsd" > >1415926535 > > http://www.w3.org/2001/XMLSchema-instance"; >xsi:noNamespaceSchemaLocation="test.xsd" > >7182818284 > > should also be okay. With the validation scheme set to "auto", I expect to > get schema validation errors reported for the "test" elements and > well-formedness checking for the rest of the document. That part seems to be > working in as much as I can introduce an error in the first test element and > see the error reported with val scheme = auto. > I will be traveling for the next 12 days, so I may not be able to be > immediately responsive to responses to this bug report. When I get a chance, > however, I will definitely do whatever checking is requested. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Created: (XERCESC-1447) make xerces-c_2_6.dll delay-loadable
make xerces-c_2_6.dll delay-loadable
Key: XERCESC-1447
URL: http://issues.apache.org/jira/browse/XERCESC-1447
Project: Xerces-C++
Type: Improvement
Components: Utilities
Versions: 2.6.0
Environment: Windows XP, VC 6.0
Reporter: eithanz
xerces-c_2_6.dll is not delay-loadable due to some static class data being
exported in headers.
The fixes are:
In utils/PlatformUtils.hpp, change locale to default to 0 instead of
XMLUni::fgXercescDefaultLocale:
static void Initialize(const char* const locale = 0 /*[ez]
XMLUni::fgXercescDefaultLocale*/
, const char* const nlsHome = 0
, PanicHandler* const panicHandler = 0
, MemoryManager* const memoryManager = 0);
In utils/PlatformUtils.cpp under XMLPlatformUtils::Initialize, if locale is
null then change to default XMLUni::fgXercescDefaultLocale:
XMLMsgLoader::setLocale(locale != 0 ? locale :
XMLUni::fgXercescDefaultLocale); //[ez] set locale to default if null
In parsers/XercesDOMParser.hpp, change default of manager to 0 instead of
XMLPlatformUtils::fgMemoryManager:
XercesDOMParser
(
XMLValidator* const valToAdopt = 0
, MemoryManager* const manager = 0 /*[ez]
XMLPlatformUtils::fgMemoryManager*/
, XMLGrammarPool* const gramPool = 0
);
In parsers/XercesDOMParser.cpp, if manager is null then set to default
XMLPlatformUtils::fgMemoryManager:
XercesDOMParser::XercesDOMParser( XMLValidator* const valToAdopt
, MemoryManager* const manager
, XMLGrammarPool* const gramPool):
// [ez] set manager to default if null
AbstractDOMParser(valToAdopt, (manager ? manager :
XMLPlatformUtils::fgMemoryManager), gramPool)
, fEntityResolver(0)
, fXMLEntityResolver(0)
, fErrorHandler(0)
{
}
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see:
http://www.atlassian.com/software/jira
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Created: (XERCESC-1469) Xerces-c.dll does not transcode UTF-8 string
Xerces-c.dll does not transcode UTF-8 string Key: XERCESC-1469 URL: http://issues.apache.org/jira/browse/XERCESC-1469 Project: Xerces-C++ Type: Bug Versions: 2.6.0 Environment: OS : Windows XP Compiler :Visual .NET 2003 Reporter: ganesh Attachments: SAX2Print.exe, simpletext.xml, xerces-c.dll I have built Xerces-c on Windows-xp. The build was successful. But the xerces-c.dll does not transcode UTF-8 characters properly. Here is the sample application SAX2Print.exe and the XML simpletext.xml with UTF-8 characters. When you execute SAX2Print.exe simpletext.xml it will return characters ->->->->-> for UTF-8 strings. The application returns correct UTF-8 string when xerces-c.dll downloaded from the Apache site is used. Can any one help me. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Updated: (XERCESC-1469) Xerces-c.dll does not transcode UTF-8 string
[ http://issues.apache.org/jira/browse/XERCESC-1469?page=all ] ganesh updated XERCESC-1469: Attachment: SAX2Print.exe > Xerces-c.dll does not transcode UTF-8 string > > > Key: XERCESC-1469 > URL: http://issues.apache.org/jira/browse/XERCESC-1469 > Project: Xerces-C++ > Type: Bug > Versions: 2.6.0 > Environment: OS : Windows XP > Compiler :Visual .NET 2003 > Reporter: ganesh > Attachments: SAX2Print.exe, simpletext.xml, xerces-c.dll > > I have built Xerces-c on Windows-xp. The build was successful. But the > xerces-c.dll does not transcode UTF-8 characters properly. Here is the sample > application SAX2Print.exe and the XML simpletext.xml with UTF-8 characters. > When you execute > SAX2Print.exe > simpletext.xml > it will return characters ->->->->-> for UTF-8 strings. The application > returns correct UTF-8 string when xerces-c.dll downloaded > from the Apache site is used. Can any one help me. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Updated: (XERCESC-1469) Xerces-c.dll does not transcode UTF-8 string
[ http://issues.apache.org/jira/browse/XERCESC-1469?page=all ] ganesh updated XERCESC-1469: Attachment: xerces-c.dll > Xerces-c.dll does not transcode UTF-8 string > > > Key: XERCESC-1469 > URL: http://issues.apache.org/jira/browse/XERCESC-1469 > Project: Xerces-C++ > Type: Bug > Versions: 2.6.0 > Environment: OS : Windows XP > Compiler :Visual .NET 2003 > Reporter: ganesh > Attachments: SAX2Print.exe, simpletext.xml, xerces-c.dll > > I have built Xerces-c on Windows-xp. The build was successful. But the > xerces-c.dll does not transcode UTF-8 characters properly. Here is the sample > application SAX2Print.exe and the XML simpletext.xml with UTF-8 characters. > When you execute > SAX2Print.exe > simpletext.xml > it will return characters ->->->->-> for UTF-8 strings. The application > returns correct UTF-8 string when xerces-c.dll downloaded > from the Apache site is used. Can any one help me. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Updated: (XERCESC-1469) Xerces-c.dll does not transcode UTF-8 string
[ http://issues.apache.org/jira/browse/XERCESC-1469?page=all ] ganesh updated XERCESC-1469: Attachment: simpletext.xml > Xerces-c.dll does not transcode UTF-8 string > > > Key: XERCESC-1469 > URL: http://issues.apache.org/jira/browse/XERCESC-1469 > Project: Xerces-C++ > Type: Bug > Versions: 2.6.0 > Environment: OS : Windows XP > Compiler :Visual .NET 2003 > Reporter: ganesh > Attachments: SAX2Print.exe, simpletext.xml, xerces-c.dll > > I have built Xerces-c on Windows-xp. The build was successful. But the > xerces-c.dll does not transcode UTF-8 characters properly. Here is the sample > application SAX2Print.exe and the XML simpletext.xml with UTF-8 characters. > When you execute > SAX2Print.exe > simpletext.xml > it will return characters ->->->->-> for UTF-8 strings. The application > returns correct UTF-8 string when xerces-c.dll downloaded > from the Apache site is used. Can any one help me. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Commented: (XERCESC-1470) segmentation fault in xerces 2.6.0 on this file for unknown reason
[ http://issues.apache.org/jira/browse/XERCESC-1470?page=comments#action_12317624 ] cargilld commented on XERCESC-1470: --- Hi, FYI, I tried this on the 2.7 branch and it works fine... David > segmentation fault in xerces 2.6.0 on this file for unknown reason > -- > > Key: XERCESC-1470 > URL: http://issues.apache.org/jira/browse/XERCESC-1470 > Project: Xerces-C++ > Type: Bug > Components: SAX/SAX2 > Versions: 2.6.0 > Environment: Debian 3.1 with patch for issues 1282 and 1421 > Reporter: Jay Berkenbilt > > Running SAX2Print on this file: > http://www.w3.org/2001/XMLSchema-instance"; > xsi:schemaLocation="T bug.xsd"> > > > > with this schema: > http://www.w3.org/2001/XMLSchema"; > xmlns:t="T" targetNamespace="T" elementFormDefault="qualified"> > > > > > > > > > > > > > results in a segmentation fault with this stack trace: > #0 0x4017bce0 in > xercesc_2_6::RefHashTableOf::findBucketElem () from > /usr/lib/libxerces-c.so.26 > #1 0x4017b9c1 in xercesc_2_6::RefHashTableOf::get () >from /usr/lib/libxerces-c.so.26 > #2 0x4017d028 in xercesc_2_6::DTDElementDecl::getAttDef () >from /usr/lib/libxerces-c.so.26 > #3 0x4019a212 in xercesc_2_6::IGXMLScanner::buildAttList () >from /usr/lib/libxerces-c.so.26 > #4 0x401a6da8 in xercesc_2_6::IGXMLScanner::scanStartTagNS () >from /usr/lib/libxerces-c.so.26 > #5 0x401a3332 in xercesc_2_6::IGXMLScanner::scanContent () >from /usr/lib/libxerces-c.so.26 > #6 0x401a1ee1 in xercesc_2_6::IGXMLScanner::scanDocument () >from /usr/lib/libxerces-c.so.26 > #7 0x40247150 in xercesc_2_6::XMLScanner::scanDocument () >from /usr/lib/libxerces-c.so.26 > #8 0x402471d9 in xercesc_2_6::XMLScanner::scanDocument () >from /usr/lib/libxerces-c.so.26 > #9 0x401cc66c in xercesc_2_6::SAX2XMLReaderImpl::parse () >from /usr/lib/libxerces-c.so.26 > #10 0x0804cc6c in main () > I'm sorry that I don't have full debug information, but hopefully this will > give a clue as to where this may be crashing. I have spent a few minutes > trying to track it down, but have not been successful up to this point. I > can try testing this problem with the current subversion HEAD, but I need to > be able to maintain binary compatibility with 2.6.0, so a small patch would > be most welcome. It's worth noting that no errors are reported when running > this in 2.3.0. We do not have an installation of 2.4.0 or 2.5.0 to test > with. Thanks. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Commented: (XERCESC-1469) Xerces-c.dll does not transcode UTF-8 string
[ http://issues.apache.org/jira/browse/XERCESC-1469?page=comments#action_12317626 ] cargilld commented on XERCESC-1469: --- Hi, I tried this on the 2.7 branch and it worked fine (although you didn't provide the schema referenced in simpletext.xml). What changes did you make to SAX2Print to get the ->->->->-> output? What version of xercesc are you using? David > Xerces-c.dll does not transcode UTF-8 string > > > Key: XERCESC-1469 > URL: http://issues.apache.org/jira/browse/XERCESC-1469 > Project: Xerces-C++ > Type: Bug > Versions: 2.6.0 > Environment: OS : Windows XP > Compiler :Visual .NET 2003 > Reporter: ganesh > Attachments: SAX2Print.exe, simpletext.xml, xerces-c.dll > > I have built Xerces-c on Windows-xp. The build was successful. But the > xerces-c.dll does not transcode UTF-8 characters properly. Here is the sample > application SAX2Print.exe and the XML simpletext.xml with UTF-8 characters. > When you execute > SAX2Print.exe > simpletext.xml > it will return characters ->->->->-> for UTF-8 strings. The application > returns correct UTF-8 string when xerces-c.dll downloaded > from the Apache site is used. Can any one help me. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Commented: (XERCESC-1365) Migrate CVS to SVN
[ http://issues.apache.org/jira/browse/XERCESC-1365?page=comments#action_12317901 ] cargilld commented on XERCESC-1365: --- Hi Jason, As the move to svn is complete can this bug (and 1367) be closed? David > Migrate CVS to SVN > -- > > Key: XERCESC-1365 > URL: http://issues.apache.org/jira/browse/XERCESC-1365 > Project: Xerces-C++ > Type: Task > Reporter: Jason E. Stewart > Priority: Blocker > > The Xerces-C CVS repository needs to be migrated to Subversion. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Commented: (XERCESC-1420) XMLPlatformUtils::makeMutex() creates mutex objects using the C++ runtime heap instead of using a MemoryManager instance
[ http://issues.apache.org/jira/browse/XERCESC-1420?page=comments#action_12317903 ] cargilld commented on XERCESC-1420: --- Hi Dave, I believe you checked in the patch for this bug so can this bug be closed? Thanks, David > XMLPlatformUtils::makeMutex() creates mutex objects using the C++ runtime > heap instead of using a MemoryManager instance > > > Key: XERCESC-1420 > URL: http://issues.apache.org/jira/browse/XERCESC-1420 > Project: Xerces-C++ > Type: Bug > Components: Utilities > Versions: 2.6.0 > Reporter: David Bertoni > Assignee: David Bertoni > Priority: Blocker > Attachments: XMLHolder.c, XMLHolder.hpp, patch.txt > > XMLPlatformUtils::makeMutex() needs to accept a MemoryManager instance as a > parameter to use pluggable memory management. As it stands now, mutex > objects on the various platforms are created using the C++ run-time heap. > This is causing memory allocation issues and crashes in our application. > I am preparing a patch, but it covers all platforms, so I won't be able to > test every one of them. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Closed: (XERCESC-1403) Compilation error using the Xcerces
[ http://issues.apache.org/jira/browse/XERCESC-1403?page=all ] cargilld closed XERCESC-1403: - > Compilation error using the Xcerces > --- > > Key: XERCESC-1403 > URL: http://issues.apache.org/jira/browse/XERCESC-1403 > Project: Xerces-C++ > Type: Bug > Components: Build > Versions: 2.6.0 > Environment: $ uname -a > SunOS 5.8 Generic_117350-02 sun4u sparc SUNW,Ultra-60 > Compiler - SunWorkShop Forte 6 > Reporter: Praveen Maruvekere > Priority: Blocker > > I have downloaded the Xerces binaries for SUNOS 5.8. > I am trying to call some API's present in Xerces Shared object from my code > which is written in C++. > I am getting these compilation errors while compiling , the error is pretty > confusing > "/include/xcerces/xercesc/framework/XMLErrorReporter.hpp", line > 181: Warning: Too many arguments in macro error. > "/include/xcerces/xercesc/framework/XMLErrorReporter.hpp", line > 182: Error: ")" expected instead of > "/include/xcerces/xercesc/framework/XMLErrorReporter.hpp"". > "/include/xcerces/xercesc/framework/XMLErrorReporter.hpp", line > 182: Error: "," expected instead of "XMLCh". > "/vobs/mynah/include/xcerces/xercesc/framework/XMLErrorReporter.hpp", line > 195: Error: Use ";" to terminate declarations. > I checked the Header file XMLErrorReported.hpp it appeared fine to me. > Please help > -Praveen -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Resolved: (XERCESC-1403) Compilation error using the Xcerces
[ http://issues.apache.org/jira/browse/XERCESC-1403?page=all ] cargilld resolved XERCESC-1403: --- Resolution: Invalid Closing as per previous comments. > Compilation error using the Xcerces > --- > > Key: XERCESC-1403 > URL: http://issues.apache.org/jira/browse/XERCESC-1403 > Project: Xerces-C++ > Type: Bug > Components: Build > Versions: 2.6.0 > Environment: $ uname -a > SunOS 5.8 Generic_117350-02 sun4u sparc SUNW,Ultra-60 > Compiler - SunWorkShop Forte 6 > Reporter: Praveen Maruvekere > Priority: Blocker > > I have downloaded the Xerces binaries for SUNOS 5.8. > I am trying to call some API's present in Xerces Shared object from my code > which is written in C++. > I am getting these compilation errors while compiling , the error is pretty > confusing > "/include/xcerces/xercesc/framework/XMLErrorReporter.hpp", line > 181: Warning: Too many arguments in macro error. > "/include/xcerces/xercesc/framework/XMLErrorReporter.hpp", line > 182: Error: ")" expected instead of > "/include/xcerces/xercesc/framework/XMLErrorReporter.hpp"". > "/include/xcerces/xercesc/framework/XMLErrorReporter.hpp", line > 182: Error: "," expected instead of "XMLCh". > "/vobs/mynah/include/xcerces/xercesc/framework/XMLErrorReporter.hpp", line > 195: Error: Use ";" to terminate declarations. > I checked the Header file XMLErrorReported.hpp it appeared fine to me. > Please help > -Praveen -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Resolved: (XERCESC-1431) rpmbuild -ta xerces-c-src_2_6_0.tar.gz failes with - error: Installed (but unpackaged) file(s) found:
[ http://issues.apache.org/jira/browse/XERCESC-1431?page=all ] cargilld resolved XERCESC-1431: --- Resolution: Duplicate This is a duplicate of xercesc-1287. > rpmbuild -ta xerces-c-src_2_6_0.tar.gz failes with - error: Installed (but > unpackaged) file(s) found: > -- > > Key: XERCESC-1431 > URL: http://issues.apache.org/jira/browse/XERCESC-1431 > Project: Xerces-C++ > Type: Bug > Components: Build > Versions: 2.6.0 > Environment: Fedora Core 3 > Reporter: Randy Zeitvogel > Priority: Blocker > Attachments: xerces-c.spec.patch > > rpmbuild -ta xerces-c-src_2_6_0.tar.gz > fails with > Checking for unpackaged file(s): /usr/lib/rpm/check-files > /var/tmp/xerces-c-rooterror: Installed (but unpackaged) file(s) found: >/usr/lib/libxerces-depdom.so.26.0 > RPM build errors: > Installed (but unpackaged) file(s) found: >/usr/lib/libxerces-depdom.so.26.0 -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Resolved: (XERCESC-1426) downloadin xerces on hp
[ http://issues.apache.org/jira/browse/XERCESC-1426?page=all ] cargilld resolved XERCESC-1426: --- Resolution: Incomplete Closing, since no response to provide additional information required. David > downloadin xerces on hp > --- > > Key: XERCESC-1426 > URL: http://issues.apache.org/jira/browse/XERCESC-1426 > Project: Xerces-C++ > Type: Bug > Components: Build > Versions: 2.6.0 > Environment: HP > Reporter: lior halp > Priority: Critical > > After installing xerces with no pthread, I stil see when doing ldd > libxerces-c.so.26.0 the phread. Do you know about it? -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Resolved: (XERCESC-1359) AbstractDOMParser cores on parse, try to allocate memory in a multithreaded application
[ http://issues.apache.org/jira/browse/XERCESC-1359?page=all ] cargilld resolved XERCESC-1359: --- Resolution: Incomplete Closing, since no response to provide additional information required. David > AbstractDOMParser cores on parse, try to allocate memory in a multithreaded > application > --- > > Key: XERCESC-1359 > URL: http://issues.apache.org/jira/browse/XERCESC-1359 > Project: Xerces-C++ > Type: Bug > Versions: 2.6.0 > Environment: AIX 5.2, Visual Age 6.0 > Reporter: Khomkrit Kaowthumrong > Priority: Critical > > The XercesDOMParser cores on a parse. It seems to be failing on the allocate > in the MemoryManagerImpl. This happens only in a multithreaded application. > If only a single thread exists then it is okay. > pthread_kill(??, ??) at 0x90001518158 > _p_raise(??) at 0x90001517b84 > raise.raise(??) at 0x903b73c > abort() at 0x9048c44 > myabort__3stdFv() at 0x900015341e4 > terminate__3stdFv() at 0x90001532834 > unexpected__3stdFv() at 0x90001532794 > __nw__FUl(??) at 0x90001534b04 > allocate(unsigned long)(0x11005dc30, 0x280a0), line 46 in > "MemoryManagerImpl.cpp" > XMemory.operator new(unsigned long,xercesc_2_6::MemoryManager*)(0x28098, > 0x11005dc30), line 66 in "XMemory.cpp" > unnamed block $b11085, line 424 in "ReaderMgr.cpp" > ReaderMgr.createReader(const > xercesc_2_6::InputSource&,bool,xercesc_2_6::XMLReader::RefFrom,xercesc_2_6::XMLReader::Types,xercesc_2_6::XMLReader::Sources,bool)(0x117fec470, > 0x112babb30, 0x101, 0x10001, 0x10001, 0x10001, 0x0), > line 424 in "ReaderMgr.cpp" > scanReset(const xercesc_2_6::InputSource&)(0x117fec3b8, 0x112babb30), line > 1251 in "IGXMLScanner2.cpp" > scanDocument(const xercesc_2_6::InputSource&)(0x117fec3b8, 0x112babb30), line > 185 in "IGXMLScanner.cpp" > AbstractDOMParser.parse(const xercesc_2_6::InputSource&)(0x117feac18, > 0x112babb30), line 464 in "AbstractDOMParser.cpp" -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Commented: (XERCESC-1339) Uninitialized memory read by XMLReader::getName(xercesc_2_5::XMLBuffer &, bool)
[ http://issues.apache.org/jira/browse/XERCESC-1339?page=comments#action_12317922 ] cargilld commented on XERCESC-1339: --- Hi, Can you try and reproduce this with the latest source in the 2.7 branch of svn? Thanks. I tried it on windows and got no purify errors. David > Uninitialized memory read by XMLReader::getName(xercesc_2_5::XMLBuffer &, > bool) > --- > > Key: XERCESC-1339 > URL: http://issues.apache.org/jira/browse/XERCESC-1339 > Project: Xerces-C++ > Type: Bug > Components: Non-Validating Parser > Versions: 2.5.0 > Environment: Solaris 5.8, Linux 2.4.9 > Reporter: Simeon de Dios > Priority: Critical > Attachments: test1.xml > > Purify testing of an application using Xerces 2.5.0 has revealved an > uninitialized memory read by the XMLReader class: > Purify instrumented ./i86-pc-linux2.x_GCC322_D/parse (pid 7830 at Thu > Feb 10 09:46:11 2005) > * Purify 2003a.06.13 FixPack 0172 041231 Linux (32-bit) (c) Copyright IBM > Corp. 1992, 2005 All rights reserved. > * For contact information type: "purify -help" > * For TTY output, use the option "-windows=no" > * Command-line: ./i86-pc-linux2.x_GCC322_D/parse test1.xml > * Options settings: -always-use-cache-dir \ > -linker=/opt/binutils/2.13/bin/ld -g++=yes -purify \ > -gcc3_path=/opt/gcc/3.2.2/bin/g++ \ > -hw_cap=yes -language=english > * License successfully checked out. > * Command-line: ./i86-pc-linux2.x_GCC322_D/parse test1.xml > Purify instrumented ./i86-pc-linux2.x_GCC322_D/parse (pid 7830) > UMR: Uninitialized memory read (325 times): > * This is occurring while in thread 8192: > xercesc_2_5::XMLReader::getName(xercesc_2_5::XMLBuffer &, bool) > [libxerces-c.so.25] > xercesc_2_5::IGXMLScanner::scanStartTag( bool &) [libxerces-c.so.25] > xercesc_2_5::IGXMLScanner::scanContent( void) [libxerces-c.so.25] > xercesc_2_5::IGXMLScanner::scanDocument(xercesc_2_5::InputSource const > &) [libxerces-c.so.25] > xercesc_2_5::XMLScanner::scanDocument( unsigned short const *) > [libxerces-c.so.25] > xercesc_2_5::XMLScanner::scanDocument( char const *) [libxerces-c.so.25] > xercesc_2_5::AbstractDOMParser::parse( char const *) [libxerces-c.so.25] > Rosetta::Parser::parse( char const *) > [Parser.hxx:106] > ... -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Commented: (XERCESC-1337) DOMMemTest fails with Segmentation violation(xserces1.7 + ICU transcode + windows2000)
[ http://issues.apache.org/jira/browse/XERCESC-1337?page=comments#action_12317923 ] cargilld commented on XERCESC-1337: --- Hi Leon, Can this bug be closed? David > DOMMemTest fails with Segmentation violation(xserces1.7 + ICU transcode + > windows2000) > > > Key: XERCESC-1337 > URL: http://issues.apache.org/jira/browse/XERCESC-1337 > Project: Xerces-C++ > Type: Bug > Components: Utilities > Versions: 1.7.0 > Environment: windows2000 + xseces 1.7 > Reporter: Leon Zhang > Priority: Critical > 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. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Commented: (XERCESC-1202) GeneralAttributeCheck initialize fails
[ http://issues.apache.org/jira/browse/XERCESC-1202?page=comments#action_12317924 ] cargilld commented on XERCESC-1202: --- Hi, Can you try and reproduce this with the latest source in the 2.7 branch of svn? Thanks. There have been a number of mutex fixes since 2.3 David > GeneralAttributeCheck initialize fails > -- > > Key: XERCESC-1202 > URL: http://issues.apache.org/jira/browse/XERCESC-1202 > Project: Xerces-C++ > Type: Bug > Components: Validating Parser (Schema) (Xerces 1.5 or up only) > Versions: 2.3.0 > Environment: Sun Solaris 8 > Reporter: Michael Kopp > Priority: Critical > > 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::ValueHashTableOf::findBucketElem(this = > (nil), key = 0x8ec3a4, hashVal = 4265683276U), line 252 in > "ValueHashTableOf.c" > [2] xercesc_2_3::ValueHashTableOf::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 =
[jira] Commented: (XERCESC-1196) Not recognising COURTYARD CAFÉ (from Bugzilla #28318)
[ http://issues.apache.org/jira/browse/XERCESC-1196?page=comments#action_12317925 ] cargilld commented on XERCESC-1196: --- Hi, Can you try and reproduce this with the latest source in the 2.7 branch of svn? Thanks. David > Not recognising COURTYARD CAFÉ (from Bugzilla #28318) > -- > > Key: XERCESC-1196 > URL: http://issues.apache.org/jira/browse/XERCESC-1196 > Project: Xerces-C++ > Type: Bug > Components: DOM > Versions: 1.7.0 > Environment: HP > Reporter: Alberto Massari > Priority: Critical > > Hi, > when submitting the XML having special character COURTYARD CAFÉ. > it throws the exception > Message: Expected end of tag 'NAME' > If i add space after special character COURTYARD CAFÉ then it > works ok. > Tried the same XML with xerces java validator and XML SPY, both are validated > ok. > This is causing production problem. > Thanks, > Noman Siddiqui > 732-699-7794 -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Commented: (XERCESC-1377) Error in SAXParser! invalid namespaces
[ http://issues.apache.org/jira/browse/XERCESC-1377?page=comments#action_12317926 ] cargilld commented on XERCESC-1377: --- Hi David & Gareth, Can one of you please do the documentation update? Thanks. David > Error in SAXParser! invalid namespaces > -- > > Key: XERCESC-1377 > URL: http://issues.apache.org/jira/browse/XERCESC-1377 > Project: Xerces-C++ > Type: Bug > Components: SAX/SAX2 > Versions: 2.6.0 > Environment: Windows XP > Borland Builder 6 > Reporter: Vadim Shapovalov > Priority: Blocker > > > > > > > > > > > > > > SAXParser tells me that root/node1/node2/node1 has ns1 namespace. it`s not > good!!! > Note that c2 has right ns2 namespace. > I used version 2.0 and there was no such a bug there. > If you cant fix it quickly, please tell me how to fix or avoid this bug. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Assigned: (XERCESC-1471) problems and solution with building in mingw-msys enviromen
[ http://issues.apache.org/jira/browse/XERCESC-1471?page=all ] cargilld reassigned XERCESC-1471: - Assign To: cargilld > problems and solution with building in mingw-msys enviromen > --- > > Key: XERCESC-1471 > URL: http://issues.apache.org/jira/browse/XERCESC-1471 > Project: Xerces-C++ > Type: Bug > Components: Build > Versions: 2.6.0 > Environment: Current MinGw with GCC 3.4.2, Win XP with SP2 and fixes. > Reporter: Michal Eibl > Assignee: cargilld > Priority: Blocker > Attachments: xerces-c-src_2_6_0.patch > > Cannot build froum sources. It seems like some library is missing. After > correction runConfig is problem in nonexisting linux/unix headers for > networking in util/NetAccessors/Socket/UnixHTTPURLInputStream.cpp.. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Assigned: (XERCESC-1357) Compiling problem on HPUX 11
[ http://issues.apache.org/jira/browse/XERCESC-1357?page=all ] cargilld reassigned XERCESC-1357: - Assign To: cargilld > Compiling problem on HPUX 11 > > > Key: XERCESC-1357 > URL: http://issues.apache.org/jira/browse/XERCESC-1357 > Project: Xerces-C++ > Type: Bug > Components: Build > Versions: 2.5.0 > Environment: HPUX 11, compiler aC++ (aCC) A.03.13 > Reporter: Guy Mougel > Assignee: cargilld > Priority: Critical > Attachments: hpfixes.zip > > There is a compiling problem between Xerces v2.4.0 and all the following > versions (v2.5.0 and v2.6.0). > The compilation option !defined(XML_HPUX) has been removed from v2.4.0 > resuting in that error : > Error 492: "/logiciel/xerces/xerces_c2.5.0/include/xercesc/util/XMemory.hpp", > line 138 # Operator delete cannot > be overloaded in same class; previously defined at > ["/logiciel/xerces/xerces_c2.5.0/include/xercesc/util/XMemory.hpp", line > 128]. > void operator delete(void* p, MemoryManager* memMgr); > ^^ > Error 568: "/logiciel/xerces/xerces_c2.5.0/include/xercesc/util/XMemory.hpp", > line 138 # The second parameter of > operator delete must be type size_t. > void operator delete(void* p, MemoryManager* memMgr); > NB: This error does not appear in v2.4.0. > Best regards, Guy M. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Commented: (XERCESC-1213) delete XercesDOMParser object does not release memory under Sun Solaris
[
http://issues.apache.org/jira/browse/XERCESC-1213?page=comments#action_12318147
]
cargilld commented on XERCESC-1213:
---
Hi,
Is this still failing with the 2.7 branch in svn?
Also, how are you detecting that memory is not released?
David
> delete XercesDOMParser object does not release memory under Sun Solaris
> ---
>
> Key: XERCESC-1213
> URL: http://issues.apache.org/jira/browse/XERCESC-1213
> Project: Xerces-C++
> Type: Bug
> Components: Non-Validating Parser
> Versions: 2.3.0
> Environment: Sun Solaris Xerces 2.3
> Reporter: Kirill Shiff
> Priority: Critical
>
> For following example Xerces does not release memory by delete m_pParser
> (nother by Terminate()) . It happends on Sun Solaris. Under windows it works
> OK.
> however for i > 0 there is no allocated memory increase...
> XMLPlatformUtils::Initialize();
> for(long i = 0; i < 5; i++)
> {
> DOMNode*m_pRoot = 0;
> DOMDocument*m_pDOMDocument = 0;
> XercesDOMParser* m_pParser = new XERCES_CPP_NAMESPACE_QUALIFIER
> XercesDOMParser();
> m_pParser->setDoNamespaces(true);
> m_pParser->setValidationScheme(AbstractDOMParser::Val_Auto);
> m_pParser->setExpandEntityReferences(false);
> m_pParser->setIncludeIgnorableWhitespace(false);
> m_pParser->useCachedGrammarInParse(false);
> m_pParser->parse(xmlFile);
> m_pDOMDocument = m_pParser->getDocument();
>
> m_pRoot = m_pDOMDocument->getFirstChild();
> m_pParser->resetDocumentPool();
> m_pParser->resetCachedGrammarPool();
> delete m_pParser, m_pParser = 0;
> }
> XMLPlatformUtils::Terminate();
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see:
http://www.atlassian.com/software/jira
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Resolved: (XERCESC-1434) Web site needs to be updated to point to SVN instead of CVS
[ http://issues.apache.org/jira/browse/XERCESC-1434?page=all ]
cargilld resolved XERCESC-1434:
---
Resolution: Fixed
Hi,
Gareth has updated the web site so am closing this bug.
> Web site needs to be updated to point to SVN instead of CVS
> ---
>
> Key: XERCESC-1434
> URL: http://issues.apache.org/jira/browse/XERCESC-1434
> Project: Xerces-C++
> Type: Task
> Components: Documentation
> Reporter: Jesse Pelton
> Priority: Minor
>
> The sidebar on http://xml.apache.org/xerces-c/ pages includes a "CVS
> Repository" item. This needs to be updated to reflect the move from CVS to
> SVN. I think three changes are needed:
> - The image should be updated to read "SVN Repository" or perhaps something
> more generic ("Project Repository"?).
> - The alt text on the img element should be updated to match.
> - The enclosing anchor's href should be changed from
> "http://xml.apache.org/websrc/cvsweb.cgi/xml-xerces/c/"; to
> "http://svn.apache.org/viewcvs.cgi/xerces/c/";.
> The affected image is named "side-ext-100" in the HTML as of today.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see:
http://www.atlassian.com/software/jira
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Resolved: (XERCESC-1402) RemoveChild() gets unexpected undocumented INVALID_CHARACTER_ERR
[ http://issues.apache.org/jira/browse/XERCESC-1402?page=all ]
cargilld resolved XERCESC-1402:
---
Resolution: Incomplete
Closing, since no response to provide additional information required.
David
> RemoveChild() gets unexpected undocumented INVALID_CHARACTER_ERR
>
>
> Key: XERCESC-1402
> URL: http://issues.apache.org/jira/browse/XERCESC-1402
> Project: Xerces-C++
> Type: Bug
> Components: DOM
> Versions: 2.5.0
> Environment: Windows XP 200 SP 2
> MS Visual C++ 6.0
> Reporter: Christopher Condit
> Priority: Minor
> Attachments: screenshot-1.jpg
>
> This code called to remove a child, throws INVALID_CHARACTER_ERR
> // REMOVE CHILD
> LONG dom_removeChild(LONG inParentNode, LONG inChildNode) {
> DOMNode* myParent = (DOMNode*)inParentNode;
> DOMNode* myChild = (DOMNode*)inChildNode;
> DOMNode* myNodeOut;
> try {
> myNodeOut = myParent->removeChild(myChild);
> } catch (DOMException& e) {
> // do something
> return(0);
> }
> return((LONG)myNodeOut);
> }
> Such an exception is undocumented and appears inappropriate, given the
> absence of any character parm.
> Walking through code, both parms look valid. DOM document has been loaded
> from a file that I know is valid. The parent in this case is an element that
> I know was validly added to said DOM via CreateElement(). All data is
> created, fetched, and used just fine, but when I am done with it, the
> RemoveChild() fails. Above example style of handle handling has been used
> successfully in countless other instances.
> Thanks, CXC
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see:
http://www.atlassian.com/software/jira
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Resolved: (XERCESC-1318) icu build with VC7 project files does not work
[ http://issues.apache.org/jira/browse/XERCESC-1318?page=all ] cargilld resolved XERCESC-1318: --- Resolution: Invalid Closing as per previous comment. David > icu build with VC7 project files does not work > -- > > Key: XERCESC-1318 > URL: http://issues.apache.org/jira/browse/XERCESC-1318 > Project: Xerces-C++ > Type: Improvement > Components: Build > Versions: 2.6.0 > Environment: Windows 2000 > Reporter: Tobias Sager > Priority: Minor > > It is not possible to build Xerces with ICU support using MSDEV VC7 solution > files. > There is no error, but the resulting dll does not have ICU dependencies. > Building with VC6 files results in a ICU enabled build. > Is it the missing preprocessor directive XML_USE_ICU_TRANSCODER? -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Closed: (XERCESC-1365) Migrate CVS to SVN
[ http://issues.apache.org/jira/browse/XERCESC-1365?page=all ] cargilld closed XERCESC-1365: - > Migrate CVS to SVN > -- > > Key: XERCESC-1365 > URL: http://issues.apache.org/jira/browse/XERCESC-1365 > Project: Xerces-C++ > Type: Task > Reporter: Jason E. Stewart > Priority: Blocker > > The Xerces-C CVS repository needs to be migrated to Subversion. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Resolved: (XERCESC-1365) Migrate CVS to SVN
[ http://issues.apache.org/jira/browse/XERCESC-1365?page=all ] cargilld resolved XERCESC-1365: --- Resolution: Fixed Closing as per previous comment. > Migrate CVS to SVN > -- > > Key: XERCESC-1365 > URL: http://issues.apache.org/jira/browse/XERCESC-1365 > Project: Xerces-C++ > Type: Task > Reporter: Jason E. Stewart > Priority: Blocker > > The Xerces-C CVS repository needs to be migrated to Subversion. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Resolved: (XERCESC-1367) Post SVN Migration code reorganization
[ http://issues.apache.org/jira/browse/XERCESC-1367?page=all ] cargilld resolved XERCESC-1367: --- Resolution: Fixed Closing as per comments in 1365. > Post SVN Migration code reorganization > -- > > Key: XERCESC-1367 > URL: http://issues.apache.org/jira/browse/XERCESC-1367 > Project: Xerces-C++ > Type: Sub-task > Reporter: Jason E. Stewart > > After moving to SVN, the codebase needs to be reorganized. This task tracks > what those pieces need to be. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Closed: (XERCESC-1367) Post SVN Migration code reorganization
[ http://issues.apache.org/jira/browse/XERCESC-1367?page=all ] cargilld closed XERCESC-1367: - > Post SVN Migration code reorganization > -- > > Key: XERCESC-1367 > URL: http://issues.apache.org/jira/browse/XERCESC-1367 > Project: Xerces-C++ > Type: Sub-task > Reporter: Jason E. Stewart > > After moving to SVN, the codebase needs to be reorganized. This task tracks > what those pieces need to be. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Commented: (XERCESC-1368) Catch-all handler are problematic on Windows
[ http://issues.apache.org/jira/browse/XERCESC-1368?page=comments#action_12318304 ] cargilld commented on XERCESC-1368: --- Hi Dave, Do you have more patches coming for this bug or should we close it? Thanks, David > Catch-all handler are problematic on Windows > > > Key: XERCESC-1368 > URL: http://issues.apache.org/jira/browse/XERCESC-1368 > Project: Xerces-C++ > Type: Bug > Components: Miscellaneous > Versions: 2.6.0 > Environment: Windows XP with Visual Studio .NET 2003 > Reporter: David Bertoni > Assignee: David Bertoni > Attachments: patch.txt > > Exception handlers of the form "catch(...)" are causing problems in our > product code on Windows, because they are catching hardware exceptions, such > as access violations. > There is an article in the MSDN Knowledge Base that describes how this has > changed between Visual Studio 6, and Visual Studio .NET: > http://msdn.microsoft.com/library/default.asp?url=/library/en-us/vclang/html/_core_exception_handling.3a_.default_synchronous_exception_model.asp > However, my experience with Xerces-C using Visual Studio .NET 2003 is that > hardware exceptions (asynchronous exceptions, in the Microsoft parlance) are > still being caught in Xerces-C in catch-all handlers. This is problematic > because it interferes with normal diagnosis of hardware faults, and can lead > to code being executed in Xerces-C when the system is in an unknown state. > It is also a makes it difficult to write code that will behave the same on > other platforms. > Looking into the code reveals multiple places where a catch-all handler > resets some object (or some other similar behavior), then rethrows the same > exception. I'd like to propose that we try to eliminate as many of these > catch handlers as possible by replaces these actions with stack objects that > perform these actions automatically whether or not an exception is thrown > (auto_ptr-like behavior). This will also have the benefit of simplifying the > code. From a "philosophical" perspective, I also think its better for code > to catch the exceptions it's concerned with, and avoid catch-all handlers > except when absolutely necessary. > I will attach a proposed patch for a class that does this sort of thing, and > some modified code that uses this class. I would also like to see if anyone > else has observed this behavior in their Windows applications. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Commented: (XERCESC-1360) compile error for 64bit solaris binary by GCC 3.3.2
[ http://issues.apache.org/jira/browse/XERCESC-1360?page=comments#action_12318305 ] cargilld commented on XERCESC-1360: --- Hi, Is this still a problem or can we close this bug? BTW, the error sounds like a compiler error, so maybe it is a problem with gcc... David > compile error for 64bit solaris binary by GCC 3.3.2 > --- > > Key: XERCESC-1360 > URL: http://issues.apache.org/jira/browse/XERCESC-1360 > Project: Xerces-C++ > Type: Bug > Components: Build > Versions: 2.6.0 > Reporter: Constellation Energy > > I am trying to build 64 bits xercesc 2.6 with gcc 3.3.2 on SunOS 5.9, and got > an error in an assemble file, here my steps: > xerces-c-src_2_6_0/src/xercesc> uname -a SunOS sasapp-msw-01 5.9 > Generic_117171-15 sun4u sparc SUNW,Sun-Fire-V440 > xerces-c-src_2_6_0/src/xercesc> ./runConfigure -psolaris -cgcc -xg++ -minmem > -nsocket -tnative -rpthread -l"-m64" -l"-mcpu=v9" -z"-m64" -z"-mcpu=v9" > xerces-c-src_2_6_0/src/xercesc> make > ... > ... > ... > g++ -fPIC -DSOLARIS -D_REENTRANT -c > -I/home/e11190/hawru/3rd_party/xerces-c-src_2_6_0/include -m64 -mcpu=v9 -w -O > -DPROJ_XMLPARSER -DPROJ_XMLUTIL -DPROJ_PARSERS -DPROJ_SAX4C -DPROJ_SAX2 > -DPROJ_DOM -DPROJ_DEPRECATED_DOM -DPROJ_VALIDATORS > -DXML_USE_NATIVE_TRANSCODER -DXML_USE_INMEM_MESSAGELOADER -DXML_USE_PTHREADS > -DXML_USE_NETACCESSOR_SOCKET -o > /home/e11190/hawru/3rd_party/xerces-c-src_2_6_0/obj/SOLARIS/DFAContentModel.o > DFAContentModel.cpp > /usr/ccs/bin/as: "/usr/tmp/ccCniKYa.s", line 2096: error: invalid > (misaligned) register > make[2]: *** [DFAContentModel.o] Error 1 -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Resolved: (XERCESC-1341) Gives IOT/Abort (core dump)
[ http://issues.apache.org/jira/browse/XERCESC-1341?page=all ] cargilld resolved XERCESC-1341: --- Resolution: Incomplete Closing, since no response to provide additional information required. David > Gives IOT/Abort (core dump) > --- > > Key: XERCESC-1341 > URL: http://issues.apache.org/jira/browse/XERCESC-1341 > Project: Xerces-C++ > Type: Bug > Components: SAX/SAX2 > Versions: 2.6.0 > Environment: Using in AIX 5.2 > Reporter: bikram kumar mishra > > I am using SAX Parser to some of my application. > My application also requires to validate the xml with xsd. > While validating if the data between the stat tag and end tag of xml doen't > validate with the mentioned in the xsd then it gives core dump. I need a > solution for this asap. > Can anyone help me out? > Thanks, > Bikram -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Resolved: (XERCESC-1292) multiple occurance of same attributes in Attributes
[ http://issues.apache.org/jira/browse/XERCESC-1292?page=all ]
cargilld resolved XERCESC-1292:
---
Resolution: Fixed
Closing, since no response to provide additional information required.
David
> multiple occurance of same attributes in Attributes
> ---
>
> Key: XERCESC-1292
> URL: http://issues.apache.org/jira/browse/XERCESC-1292
> Project: Xerces-C++
> Type: Bug
> Components: SAX/SAX2
> Versions: 2.5.0
> Environment: Sun Solaris 8,Sun Workshop 6 Update 2
> Reporter: Ralf Kubiza
>
> If you have a schema like this :
> ...
>
>
>
>
>
> ...
> and you have an instance of "someElement" like this:
>
> ..
>
> and then you want to process the attributes of an instance of
> "someElement" with code like this :
> void processAttributes(const Attributes& attrs)
> {
> const XMLCh* attrName;
> const XMLCh* attrValue;
> unsigned int noOfAttrs = attrs.getLength();
> unsigned int index;
> char* l_cptrAttrName = NULL;
> for ( index=0 ; index < noOfAttrs ; ++index )
> {
> attrName = attrs.getQName(index);
> attrValue = attrs.getValue(index);
> doSomeThing( attrName, attrValue );
> }
> }
> There is an unexpected behaviour now in version 2.5.0:
> noOfAttr is 2 !! In the first loop the value of someNumber is 3.
> And in the second loop the value is 0 that may override the correct
> value 3.
> If you remove the default="0" phrase in the schema, then processing is
> correct as expected with noOfAttrs=1 and value=3.
> For me this is an error is new in version 2.5.0 and not in version 2.3.0.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see:
http://www.atlassian.com/software/jira
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Resolved: (XERCESC-1289) Xerces-c++ version 2.60 crashes.
[ http://issues.apache.org/jira/browse/XERCESC-1289?page=all ] cargilld resolved XERCESC-1289: --- Resolution: Fixed Closing, since no response to provide additional information required. David > Xerces-c++ version 2.60 crashes. > > > Key: XERCESC-1289 > URL: http://issues.apache.org/jira/browse/XERCESC-1289 > Project: Xerces-C++ > Type: Bug > Components: DOM > Versions: 2.6.0 > Environment: Solaris 9. > Reporter: Mukund Sundararajan > > I'm using xerces-c++ version 2.6.0 in my multi-threaded client-server > application on solaris 9. I got the binaries for xerces-c from > xml.apache.org. Upon running a load test on my application, it crashed with > the following stack trace from dbx - > =>[1] > xercesc_2_6::NameIdPool::removeAll(0x21efe8, > 0x2487f0, 0xfeaf2248, 0xfeaf2248, 0xfec4eb88, 0x0), at 0xfea15b88 > [2] > xercesc_2_6::NameIdPool::~NameIdPool(0x21efe8, > 0x21eea0, 0xfecb30cc, 0xfeaf2248, 0x0, 0x21eea8), at 0xfea15b18 > [3] xercesc_2_6::IGXMLScanner::cleanUp(0x2b7818, 0xfeb1bd40, 0xfec6a998, > 0xfead4244, 0xfec5e030, 0xfea172c4), at 0xfeae0bc4 > [4] xercesc_2_6::IGXMLScanner::~IGXMLScanner(0x2b7818, 0x2f00, 0xf4b74, > 0x6d058, 0xfec4eb88, 0x6cf98), at 0xfeadfb48 > [5] __SLIP.DELETER__P(0x2b7818, 0x1, 0xfeae6790, 0x246ad0, 0x0, 0x1af400), > at 0xfeae6794 > [6] xercesc_2_6::AbstractDOMParser::cleanUp(0xf947bba4, 0xfec61034, 0x0, > 0xfec61088, 0xfec610ac, 0xfec610f8), at 0xfea6cf1c > [7] xercesc_2_6::AbstractDOMParser::~AbstractDOMParser(0xf947bba4, 0xf6a70, > 0x246ad4, 0xf947bb98, 0x0, 0x6), at 0xfea6ccac > [8] SocksClient::parseXMLResponse(0xf6a70, 0xf947bf28, 0x244310, 0x189, > 0x2c00, 0x2db4), at 0x49914 > My application uses the DOMWriter to generate xml documents and DOM parser to > parse them. The application does both generation and parsing. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Resolved: (XERCESC-1400) DOMWriter::writeNode throws DOMSystemException, but this class doesnt exists
[ http://issues.apache.org/jira/browse/XERCESC-1400?page=all ] cargilld resolved XERCESC-1400: --- Resolution: Fixed Hi, I removed the references to DOMSystemException in the 2.7 and 3.0 branches in svn. David > DOMWriter::writeNode throws DOMSystemException, but this class doesnt exists > > > Key: XERCESC-1400 > URL: http://issues.apache.org/jira/browse/XERCESC-1400 > Project: Xerces-C++ > Type: Bug > Components: Documentation > Versions: 2.6.0 > Reporter: Sergiy Michka > > According to: > http://xml.apache.org/xerces-c/apiDocs/classDOMWriter.html#z176_11 > DOMWriter::writeNode throws DOMSystemException, but this class doesnt exists. > The source ../dom/impl/DOMWriterImpl.cpp contains this comment: > "// REVISIT generate a DOMSystemException wrapping the underlying exception" -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Commented: (XERCESC-992) Internal compiler error
[ http://issues.apache.org/jira/browse/XERCESC-992?page=comments#action_12318463 ] cargilld commented on XERCESC-992: -- Hi, Is this still a problem or can we close this bug? A number of code changes have been made since 2.3. Can you try latest src? BTW, the error sounds like a compiler error, so maybe it is a problem with gcc... David > Internal compiler error > --- > > Key: XERCESC-992 > URL: http://issues.apache.org/jira/browse/XERCESC-992 > Project: Xerces-C++ > Type: Bug > Components: Build > Versions: 2.3.0 > Environment: Operating System: Linux > Platform: PC > Reporter: Christian Knoke > Assignee: Xerces-C Developers Mailing List > > I cannot build xerces on a SuSE 7.3 distribution. > I checked two ways of build: with runConfigure and configure (without params) > I get: > /home/chris/tmp/xerces-c-src_2_3_0/include/xercesc/dom/impl/DOMDeepNodeListPool.c: > In method > `xercesc_2_3::DOMDeepNodeListPool::DOMDeepNodeListPool(long > unsigned int, bool, long unsigned int = 128)': > DOMDocumentImpl.cpp:900: instantiated from here > /home/chris/tmp/xerces-c-src_2_3_0/include/xercesc/dom/impl/DOMDeepNodeListPool.c:104: > Internal compiler error. > /home/chris/tmp/xerces-c-src_2_3_0/include/xercesc/dom/impl/DOMDeepNodeListPool.c:104: > Please submit a full bug report. > /home/chris/tmp/xerces-c-src_2_3_0/include/xercesc/dom/impl/DOMDeepNodeListPool.c:104: > See http://www.gnu.org/software/gcc/bugs.html> for instructions. > make[2]: *** [DOMDocumentImpl.o] Error 1 > make[2]: Leaving directory > `/home/chris/tmp/xerces-c-src_2_3_0/src/xercesc/dom/impl' > make[1]: *** [impl] Error 2 > make[1]: Leaving directory > `/home/chris/tmp/xerces-c-src_2_3_0/src/xercesc/dom' > make: *** [Dom] Error 2 > I have: > [EMAIL PROTECTED]:~/tmp/xerces-c-src_2_3_0/doc> gcc --version > 2.95.3 > Any clues? > Christian -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Commented: (XERCESC-992) Internal compiler error
[ http://issues.apache.org/jira/browse/XERCESC-992?page=comments#action_12318463 ] cargilld commented on XERCESC-992: -- Hi, Is this still a problem or can we close this bug? A number of code changes have been made since 2.3. Can you try latest src? BTW, the error sounds like a compiler error, so maybe it is a problem with gcc... David > Internal compiler error > --- > > Key: XERCESC-992 > URL: http://issues.apache.org/jira/browse/XERCESC-992 > Project: Xerces-C++ > Type: Bug > Components: Build > Versions: 2.3.0 > Environment: Operating System: Linux > Platform: PC > Reporter: Christian Knoke > Assignee: Xerces-C Developers Mailing List > > I cannot build xerces on a SuSE 7.3 distribution. > I checked two ways of build: with runConfigure and configure (without params) > I get: > /home/chris/tmp/xerces-c-src_2_3_0/include/xercesc/dom/impl/DOMDeepNodeListPool.c: > In method > `xercesc_2_3::DOMDeepNodeListPool::DOMDeepNodeListPool(long > unsigned int, bool, long unsigned int = 128)': > DOMDocumentImpl.cpp:900: instantiated from here > /home/chris/tmp/xerces-c-src_2_3_0/include/xercesc/dom/impl/DOMDeepNodeListPool.c:104: > Internal compiler error. > /home/chris/tmp/xerces-c-src_2_3_0/include/xercesc/dom/impl/DOMDeepNodeListPool.c:104: > Please submit a full bug report. > /home/chris/tmp/xerces-c-src_2_3_0/include/xercesc/dom/impl/DOMDeepNodeListPool.c:104: > See http://www.gnu.org/software/gcc/bugs.html> for instructions. > make[2]: *** [DOMDocumentImpl.o] Error 1 > make[2]: Leaving directory > `/home/chris/tmp/xerces-c-src_2_3_0/src/xercesc/dom/impl' > make[1]: *** [impl] Error 2 > make[1]: Leaving directory > `/home/chris/tmp/xerces-c-src_2_3_0/src/xercesc/dom' > make: *** [Dom] Error 2 > I have: > [EMAIL PROTECTED]:~/tmp/xerces-c-src_2_3_0/doc> gcc --version > 2.95.3 > Any clues? > Christian -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Resolved: (XERCESC-1212) Xerces-C Conflicts with fdlibm: enum names too common
[ http://issues.apache.org/jira/browse/XERCESC-1212?page=all ] cargilld resolved XERCESC-1212: --- Resolution: Fixed Hi, The UNKNOWN enum in PSVIDefs has been removed, as well as the related deprecated code in the 3.0 branch of svn. The coding conventions have also been updated. David > Xerces-C Conflicts with fdlibm: enum names too common > - > > Key: XERCESC-1212 > URL: http://issues.apache.org/jira/browse/XERCESC-1212 > Project: Xerces-C++ > Type: Bug > Components: Build > Versions: 2.5.0 > Environment: ALL > Reporter: Robert Buck > > For those developers that use the freely distributable math library, or > fdlibm, a conflict exists between the definition of UNKNOWN. Specifically, if > you include fdlibm headers prior to xerces-c headers, xerces-c user > applications will not compile. > Choosing common names such as UNKNOWN is not helpful to those of us that link > in many third-party libraries, since the likelihood that a conflict will > exist with such a name is greatly increased. Please prefix the names with > something that distinguishes the enum value as being from Xerces-C. In the > very least, set it as a standard practice in future enum types to use more > conspicuous names. It would be nice if you changed these before these names > get entrenched in C++ user code. > I do have a work-around, but it's rather ugly. I just raise this to your > attention, mostly to suggest the adoption of such a coding practice. > Thanks -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
