[jira] [Resolved] (XERCESC-2038) Problems with TranscodeToStr
[ https://issues.apache.org/jira/browse/XERCESC-2038?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Scott Cantor resolved XERCESC-2038. --- Resolution: Fixed > Problems with TranscodeToStr > > > Key: XERCESC-2038 > URL: https://issues.apache.org/jira/browse/XERCESC-2038 > Project: Xerces-C++ > Issue Type: Bug > Components: DOM >Affects Versions: 3.1.1, 3.1.2, 3.1.3, 3.1.4 > Environment: bash-4.1$ uname -a > Linux sadbprodcompile1 2.6.32-431.23.3.el6.x86_64 #1 SMP Wed Jul 16 06:12:23 > EDT 2014 x86_64 x86_64 x86_64 GNU/Linux >Reporter: Old Account That Somhow Should Be Erased >Assignee: Scott Cantor > Fix For: 3.2.0 > > > This is actually 3 reports in one (but hey, sue me;-) > 1. TranscodeToStr fails of the XMLCh-string contains just one character when > encoding is "WCHAR_T" or "UTF-32" (i.e. types larger than XMLCh) and you get > "invalid-multibyte-character" > 2. In the constructor of TranscodeToStr, the result (or 'failReason') from > makeNewTranscoderFrom is never checked and if it fails the > ::transcode-function dumps miserably. An exception would be preffered > 3. It is not documented why the parameter 'manager' is not used (in the call > to makeNewTranscoderFrom instead and not to the ::transcode-function) but the > (global) fMemoryManager is used instead -- 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-2038) Problems with TranscodeToStr
[ https://issues.apache.org/jira/browse/XERCESC-2038?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16090931#comment-16090931 ] Scott Cantor commented on XERCESC-2038: --- r1802231 Added fix to check for null return and throw exception if transcoder isn't available. I don't believe the last issue is accurate, it's populating the input parameter memory manager into a member variable, that's what fMemoryManager is, not a global. I can't really speak for #1 but with all the various fixes to this stuff across versions, I'd rather deal with that in a separate bug if it still fails. > Problems with TranscodeToStr > > > Key: XERCESC-2038 > URL: https://issues.apache.org/jira/browse/XERCESC-2038 > Project: Xerces-C++ > Issue Type: Bug > Components: DOM >Affects Versions: 3.1.1, 3.1.2, 3.1.3, 3.1.4 > Environment: bash-4.1$ uname -a > Linux sadbprodcompile1 2.6.32-431.23.3.el6.x86_64 #1 SMP Wed Jul 16 06:12:23 > EDT 2014 x86_64 x86_64 x86_64 GNU/Linux >Reporter: Old Account That Somhow Should Be Erased >Assignee: Scott Cantor > Fix For: 3.2.0 > > > This is actually 3 reports in one (but hey, sue me;-) > 1. TranscodeToStr fails of the XMLCh-string contains just one character when > encoding is "WCHAR_T" or "UTF-32" (i.e. types larger than XMLCh) and you get > "invalid-multibyte-character" > 2. In the constructor of TranscodeToStr, the result (or 'failReason') from > makeNewTranscoderFrom is never checked and if it fails the > ::transcode-function dumps miserably. An exception would be preffered > 3. It is not documented why the parameter 'manager' is not used (in the call > to makeNewTranscoderFrom instead and not to the ::transcode-function) but the > (global) fMemoryManager is used instead -- 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] [Assigned] (XERCESC-2038) Problems with TranscodeToStr
[ https://issues.apache.org/jira/browse/XERCESC-2038?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Scott Cantor reassigned XERCESC-2038: - Assignee: Scott Cantor > Problems with TranscodeToStr > > > Key: XERCESC-2038 > URL: https://issues.apache.org/jira/browse/XERCESC-2038 > Project: Xerces-C++ > Issue Type: Bug > Components: DOM >Affects Versions: 3.1.1, 3.1.2, 3.1.3, 3.1.4 > Environment: bash-4.1$ uname -a > Linux sadbprodcompile1 2.6.32-431.23.3.el6.x86_64 #1 SMP Wed Jul 16 06:12:23 > EDT 2014 x86_64 x86_64 x86_64 GNU/Linux >Reporter: Old Account That Somhow Should Be Erased >Assignee: Scott Cantor > Fix For: 3.2.0 > > > This is actually 3 reports in one (but hey, sue me;-) > 1. TranscodeToStr fails of the XMLCh-string contains just one character when > encoding is "WCHAR_T" or "UTF-32" (i.e. types larger than XMLCh) and you get > "invalid-multibyte-character" > 2. In the constructor of TranscodeToStr, the result (or 'failReason') from > makeNewTranscoderFrom is never checked and if it fails the > ::transcode-function dumps miserably. An exception would be preffered > 3. It is not documented why the parameter 'manager' is not used (in the call > to makeNewTranscoderFrom instead and not to the ::transcode-function) but the > (global) fMemoryManager is used instead -- 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] [Updated] (XERCESC-2038) Problems with TranscodeToStr
[ https://issues.apache.org/jira/browse/XERCESC-2038?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Scott Cantor updated XERCESC-2038: -- Affects Version/s: 3.1.2 3.1.3 3.1.4 > Problems with TranscodeToStr > > > Key: XERCESC-2038 > URL: https://issues.apache.org/jira/browse/XERCESC-2038 > Project: Xerces-C++ > Issue Type: Bug > Components: DOM >Affects Versions: 3.1.1, 3.1.2, 3.1.3, 3.1.4 > Environment: bash-4.1$ uname -a > Linux sadbprodcompile1 2.6.32-431.23.3.el6.x86_64 #1 SMP Wed Jul 16 06:12:23 > EDT 2014 x86_64 x86_64 x86_64 GNU/Linux >Reporter: Old Account That Somhow Should Be Erased >Assignee: Scott Cantor > Fix For: 3.2.0 > > > This is actually 3 reports in one (but hey, sue me;-) > 1. TranscodeToStr fails of the XMLCh-string contains just one character when > encoding is "WCHAR_T" or "UTF-32" (i.e. types larger than XMLCh) and you get > "invalid-multibyte-character" > 2. In the constructor of TranscodeToStr, the result (or 'failReason') from > makeNewTranscoderFrom is never checked and if it fails the > ::transcode-function dumps miserably. An exception would be preffered > 3. It is not documented why the parameter 'manager' is not used (in the call > to makeNewTranscoderFrom instead and not to the ::transcode-function) but the > (global) fMemoryManager is used instead -- 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] [Updated] (XERCESC-2038) Problems with TranscodeToStr
[ https://issues.apache.org/jira/browse/XERCESC-2038?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Scott Cantor updated XERCESC-2038: -- Fix Version/s: 3.2.0 > Problems with TranscodeToStr > > > Key: XERCESC-2038 > URL: https://issues.apache.org/jira/browse/XERCESC-2038 > Project: Xerces-C++ > Issue Type: Bug > Components: DOM >Affects Versions: 3.1.1, 3.1.2, 3.1.3, 3.1.4 > Environment: bash-4.1$ uname -a > Linux sadbprodcompile1 2.6.32-431.23.3.el6.x86_64 #1 SMP Wed Jul 16 06:12:23 > EDT 2014 x86_64 x86_64 x86_64 GNU/Linux >Reporter: Old Account That Somhow Should Be Erased >Assignee: Scott Cantor > Fix For: 3.2.0 > > > This is actually 3 reports in one (but hey, sue me;-) > 1. TranscodeToStr fails of the XMLCh-string contains just one character when > encoding is "WCHAR_T" or "UTF-32" (i.e. types larger than XMLCh) and you get > "invalid-multibyte-character" > 2. In the constructor of TranscodeToStr, the result (or 'failReason') from > makeNewTranscoderFrom is never checked and if it fails the > ::transcode-function dumps miserably. An exception would be preffered > 3. It is not documented why the parameter 'manager' is not used (in the call > to makeNewTranscoderFrom instead and not to the ::transcode-function) but the > (global) fMemoryManager is used instead -- 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
RE: Porting XERCESC-2052 fix to 3.1 branch
Don't know if the OP (cc'd) is still around but since I'm trying to get us moving toward a 3.2 release, I wanted to clarify this... > So just for the record, the error is really a regression, it worked in > 3.1.1 and the fix in trunk was this commit: I don't see how this "worked" in 3.1.1, the patch in question: > http://svn.apache.org/viewvc?view=revision=1701594 Was applied only to trunk, not to 3.1.0/3.1.1, and the test case is only on trunk. It couldn't have been working on 3.1.1 or the "fix" is something else. I was concerned that one of the security fixes to 3.1.2 and up broke something, and had filed this away to follow up before a 3.2.0, but this seems to be something else entirely, just a fix that didn't ever get done on the branch, and therefore can be closed out once we release trunk. -- Scott - To unsubscribe, e-mail: c-dev-unsubscr...@xerces.apache.org For additional commands, e-mail: c-dev-h...@xerces.apache.org
[jira] [Closed] (XERCESC-2059) Typo in XMLUni::fgUnknownURIName constant
[ https://issues.apache.org/jira/browse/XERCESC-2059?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Scott Cantor closed XERCESC-2059. - > Typo in XMLUni::fgUnknownURIName constant > - > > Key: XERCESC-2059 > URL: https://issues.apache.org/jira/browse/XERCESC-2059 > Project: Xerces-C++ > Issue Type: Bug > Components: Miscellaneous >Affects Versions: 3.1.0, 3.1.1, 3.1.2 >Reporter: Scott Cantor >Assignee: Scott Cantor >Priority: Trivial > Fix For: 3.2.0, 3.1.3 > > > Missing an 'n' in Unknown -- 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=16090430#comment-16090430 ] Scott Cantor commented on XERCESC-2106: --- I'm not sure what class you're referring to, but unless this is addressing a real problem, or eliminating a lot of duplicate code somewhere, I think the bar is pretty high to be taking this on just to make changes. There are dozens of serious complex bugs open and that's where time should be spent, I think. > 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] [Closed] (XERCESC-1692) A createElement() - release() call sequence doesn't release the allocated memory. The memory is blocked until the document is released.
[
https://issues.apache.org/jira/browse/XERCESC-1692?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Scott Cantor closed XERCESC-1692.
-
> A createElement() - release() call sequence doesn't release the allocated
> memory. The memory is blocked until the document is released.
> ---
>
> Key: XERCESC-1692
> URL: https://issues.apache.org/jira/browse/XERCESC-1692
> Project: Xerces-C++
> Issue Type: Wish
> Components: DOM
>Affects Versions: 2.7.0
> Environment: Windows XP
> Mircosoft MSVC 8.0 (Visual Studio 2005)
>Reporter: Luzius Blatter
>
> // We have long jobs over night where DOM documents are manipulated
> // with frequent "AddChild" and "RemoveChild" calls.
> // The documents are released at the end of the jobs.
> //
> // Now we have the problem the the system goes out of memory.
> // The reason is that all memory allocations aren't deallocated before
> // the the document is released.
> //
> // My wish is: I would like to release DOM elements with a true memory
> deallocation.
> //
> // The following code fragment shows the problem:
> //
> // Get the DOM implementation
> DOMImplementation *pDOMImplementation =
> DOMImplementationRegistry::getDOMImplementation(NULL);
> // Create a DOM document
> XERCES_CPP_NAMESPACE_QUALIFIER DOMDocument *pDocument =
> pDOMImplementation->createDocument();
> // Create and release many DOM elements
> int iElement = 0;
> while(iElement < 100)
> {
> // Create a element:
> DOMElement *pElement = pDocument->createElement(L"A");
> // Release the element:
> pElement->release();
> //Note: Although the orphaned element is now released, the memory remains
> blocked
> // and can't be reused (even not for the next element in the loop!)
> iElement++;
> }
> // Now we have around 24 MB blocked.
> pDocument->release();
> //Note: Now the memory is deallocated and can be reused.
--
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] [Resolved] (XERCESC-1692) A createElement() - release() call sequence doesn't release the allocated memory. The memory is blocked until the document is released.
[
https://issues.apache.org/jira/browse/XERCESC-1692?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Scott Cantor resolved XERCESC-1692.
---
Resolution: Won't Fix
3.x works the same way and barring a major change isn't going to do anything
differently.
> A createElement() - release() call sequence doesn't release the allocated
> memory. The memory is blocked until the document is released.
> ---
>
> Key: XERCESC-1692
> URL: https://issues.apache.org/jira/browse/XERCESC-1692
> Project: Xerces-C++
> Issue Type: Wish
> Components: DOM
>Affects Versions: 2.7.0
> Environment: Windows XP
> Mircosoft MSVC 8.0 (Visual Studio 2005)
>Reporter: Luzius Blatter
>
> // We have long jobs over night where DOM documents are manipulated
> // with frequent "AddChild" and "RemoveChild" calls.
> // The documents are released at the end of the jobs.
> //
> // Now we have the problem the the system goes out of memory.
> // The reason is that all memory allocations aren't deallocated before
> // the the document is released.
> //
> // My wish is: I would like to release DOM elements with a true memory
> deallocation.
> //
> // The following code fragment shows the problem:
> //
> // Get the DOM implementation
> DOMImplementation *pDOMImplementation =
> DOMImplementationRegistry::getDOMImplementation(NULL);
> // Create a DOM document
> XERCES_CPP_NAMESPACE_QUALIFIER DOMDocument *pDocument =
> pDOMImplementation->createDocument();
> // Create and release many DOM elements
> int iElement = 0;
> while(iElement < 100)
> {
> // Create a element:
> DOMElement *pElement = pDocument->createElement(L"A");
> // Release the element:
> pElement->release();
> //Note: Although the orphaned element is now released, the memory remains
> blocked
> // and can't be reused (even not for the next element in the loop!)
> iElement++;
> }
> // Now we have around 24 MB blocked.
> pDocument->release();
> //Note: Now the memory is deallocated and can be reused.
--
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] [Resolved] (XERCESC-2039) Shared library not built on mingw
[ https://issues.apache.org/jira/browse/XERCESC-2039?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Scott Cantor resolved XERCESC-2039. --- Resolution: Won't Fix The non-Linux/Unix build has been rebased on cmake for 3.2 so any issues with the older makefiles won't be addressed. > Shared library not built on mingw > - > > Key: XERCESC-2039 > URL: https://issues.apache.org/jira/browse/XERCESC-2039 > Project: Xerces-C++ > Issue Type: Bug > Components: Build >Affects Versions: 3.1.1 > Environment: mingw64 >Reporter: Zane U. Ji > Attachments: mingwdll.patch > > > 1. msys was downloaded from > http://sourceforge.net/projects/mingw-w64/files/External%20binary%20packages%20%28Win64%20hosted%29/MSYS%20%2832-bit%29/MSYS-2023.zip/download > 2. mingw64 was downloaded from > http://sourceforge.net/projects/mingw-w64/files/Toolchains%20targetting%20Win64/Personal%20Builds/mingw-builds/4.8.2/threads-posix/seh/x86_64-4.8.2-release-posix-seh-rt_v3-rev4.7z/download > 3. Extract both of them > 4. start msys console: > D:\msys\bin\sh.exe --login -i > 5. mount mingw: > mount D:/mingw64 /mingw > 6. change to xerces-c directory > 7. build xerces-c > ./configure && make > 8. Shared library can't be found and there is a warning: > libtool: link: warning: undefined symbols not allowed in i686-pc-mingw32 > shared libraries -- 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] [Closed] (XERCESC-2039) Shared library not built on mingw
[ https://issues.apache.org/jira/browse/XERCESC-2039?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Scott Cantor closed XERCESC-2039. - > Shared library not built on mingw > - > > Key: XERCESC-2039 > URL: https://issues.apache.org/jira/browse/XERCESC-2039 > Project: Xerces-C++ > Issue Type: Bug > Components: Build >Affects Versions: 3.1.1 > Environment: mingw64 >Reporter: Zane U. Ji > Attachments: mingwdll.patch > > > 1. msys was downloaded from > http://sourceforge.net/projects/mingw-w64/files/External%20binary%20packages%20%28Win64%20hosted%29/MSYS%20%2832-bit%29/MSYS-2023.zip/download > 2. mingw64 was downloaded from > http://sourceforge.net/projects/mingw-w64/files/Toolchains%20targetting%20Win64/Personal%20Builds/mingw-builds/4.8.2/threads-posix/seh/x86_64-4.8.2-release-posix-seh-rt_v3-rev4.7z/download > 3. Extract both of them > 4. start msys console: > D:\msys\bin\sh.exe --login -i > 5. mount mingw: > mount D:/mingw64 /mingw > 6. change to xerces-c directory > 7. build xerces-c > ./configure && make > 8. Shared library can't be found and there is a warning: > libtool: link: warning: undefined symbols not allowed in i686-pc-mingw32 > shared libraries -- 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
