[GitHub] [xerces-c] scantor commented on pull request #31: XERCESC-2219: [Backport 3.2] XMLReader constructor: fix memory leak when refreshRawBuffer() throws
scantor commented on PR #31: URL: https://github.com/apache/xerces-c/pull/31#issuecomment-1268975788 Indeed, I fully believed that just about any change was inherently unsafe because of that, but I must be mistaken. -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: c-dev-unsubscr...@xerces.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org - To unsubscribe, e-mail: c-dev-unsubscr...@xerces.apache.org For additional commands, e-mail: c-dev-h...@xerces.apache.org
[jira] [Commented] (XERCESC-2212) AbstractDOMParser::parse potentially throws undocumented OutOfMemoryException
[
https://issues.apache.org/jira/browse/XERCESC-2212?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17613224#comment-17613224
]
Scott Cantor commented on XERCESC-2212:
---
I'll review but it would save some time if you can identify exactly what
functions are needing of an API update.
I would have to say though that any caller of just about any method in a
library like this should assume an OOM exception is a possibility. That may be
why it isn't listed, but if it's listed in other places than I may not be
correct about that.
> AbstractDOMParser::parse potentially throws undocumented OutOfMemoryException
> -
>
> Key: XERCESC-2212
> URL: https://issues.apache.org/jira/browse/XERCESC-2212
> Project: Xerces-C++
> Issue Type: Bug
> Components: DOM
>Affects Versions: 3.2.2, 3.2.3
>Reporter: Tamir Yehuda
>Assignee: Scott Cantor
>Priority: Minor
> Fix For: 3.2.4
>
>
> the code shows that
> {code:java}
> try
> {
> // ...
> }
> catch(const OutOfMemoryException&)
> {
> resetInProgress.release();
> throw;
> }
> {code}
> and the OutOfMemoryException could be thrown. However this is not shown in
> the documentation
--
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] [Assigned] (XERCESC-2212) AbstractDOMParser::parse potentially throws undocumented OutOfMemoryException
[
https://issues.apache.org/jira/browse/XERCESC-2212?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Scott Cantor reassigned XERCESC-2212:
-
Assignee: Scott Cantor
> AbstractDOMParser::parse potentially throws undocumented OutOfMemoryException
> -
>
> Key: XERCESC-2212
> URL: https://issues.apache.org/jira/browse/XERCESC-2212
> Project: Xerces-C++
> Issue Type: Bug
> Components: DOM
>Affects Versions: 3.2.2, 3.2.3
>Reporter: Tamir Yehuda
>Assignee: Scott Cantor
>Priority: Minor
> Fix For: 3.2.4
>
>
> the code shows that
> {code:java}
> try
> {
> // ...
> }
> catch(const OutOfMemoryException&)
> {
> resetInProgress.release();
> throw;
> }
> {code}
> and the OutOfMemoryException could be thrown. However this is not shown in
> the documentation
--
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
[GitHub] [xerces-c] rleigh-codelibre commented on pull request #31: XERCESC-2219: [Backport 3.2] XMLReader constructor: fix memory leak when refreshRawBuffer() throws
rleigh-codelibre commented on PR #31: URL: https://github.com/apache/xerces-c/pull/31#issuecomment-1268971222 Some searching around shows some examples where the ordinals in core Windows DLLs have changed, but it's not broken anything. This would break on any symbol addition of any sort except at the end of the list, and I'm not aware of that being a thing. If you have someone who you can check this with, that's great. -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: c-dev-unsubscr...@xerces.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org - To unsubscribe, e-mail: c-dev-unsubscr...@xerces.apache.org For additional commands, e-mail: c-dev-h...@xerces.apache.org
Re: Prepping a 3.2.4 release
>I'm afraid that due to other commitments, I've been unable to do any > further work on the master branch for 4.0.0, and it's unlikely that this will > change in the near future. If anything, I'm unlikely to be able to spend much > more time on the project at all, and I might have to end my involvement > entirely. That isn't surprising, but I appreciate the forewarning. That's why I didn't really favor trying to do a 4.0.0 originally, I just don't think there's enough long term resource commitment for that to be a wise choice. Were it my decision, I would post a warning that the code is being sunsetted and anybody on it should be getting off it. Which I think is pretty clear as it is, but it's the responsible and proper thing to just say so. > We do have a large accumulation of patches which would certainly be > worth carrying over to the 3.2 branch where applicable, Yes, that's my goal right now, within reason. I simply can't "fix" most things unfortunately because I don't know the code and the risk of breaking things is much higher than the payoff in most cases. > When it comes to ABI compatibility checking, I'll be happy to do runs of > some of the ABI checking tools to look for any compatibility issues with the > ABI or API, if you haven't already done this. My approach, as we've been debating, is just to avoid the possibility whereever I can by not touching headers, but I am willing to accept that I'm much more conservative about this than I should be and things may not work quite the way I've always thought they did. >It would be nice to get the CI fixed up again before making a release. > It's > probably not too difficult to get working again; the CI image and the build > logic probably need updating to cope with external changes which broke it > in the interim. I can try to find a bit of time to inspect this--it's not too > difficult, just takes time to wait for builds for each change to test it. I definitely can't spend time there, so if you can, that's great. If not, it's best to wind down anything I can't support unless somebody else steps up to take it over. Thanks for checking in. -- Scott
[GitHub] [xerces-c] scantor commented on pull request #31: XERCESC-2219: [Backport 3.2] XMLReader constructor: fix memory leak when refreshRawBuffer() throws
scantor commented on PR #31: URL: https://github.com/apache/xerces-c/pull/31#issuecomment-1268955305 It *links* by name but I believe after that point the connection from the calling code to the DLL is by ordinal. But I could also be wrong, and I have someone I can ask. I don't think it's really worth the time to worry that much over since the workaround is pretty simple to ensure the headers don't change when we're looking at just a cleanup patch. -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: c-dev-unsubscr...@xerces.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org - To unsubscribe, e-mail: c-dev-unsubscr...@xerces.apache.org For additional commands, e-mail: c-dev-h...@xerces.apache.org
[jira] [Resolved] (XERCESC-2214) Wrong delete[] in MemBufInputSource dtor
[
https://issues.apache.org/jira/browse/XERCESC-2214?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Scott Cantor resolved XERCESC-2214.
---
Fix Version/s: 4.0.0
Resolution: Fixed
Added a note to the docs for both branches.
> Wrong delete[] in MemBufInputSource dtor
>
>
> Key: XERCESC-2214
> URL: https://issues.apache.org/jira/browse/XERCESC-2214
> Project: Xerces-C++
> Issue Type: Bug
> Components: Miscellaneous
>Affects Versions: 3.2.3
>Reporter: Tobias Elbrandt
>Assignee: Scott Cantor
>Priority: Minor
> Fix For: 4.0.0, 3.2.4
>
>
> Our address sanatizer found a mismatching delete[] for memory allocated via
> {{new}} (not {{new[]}}) in the destructor of
> {color:#00}MemBufInputSource{color}.
> I looked at the code to find places where {{new[]}} is used which would make
> it necessary to use {{delete[]}} instead of {{delete}} - without success. It
> seems to me that using {{delete[]}} is simply wrong here.
>
--
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] [Closed] (XERCESC-2214) Wrong delete[] in MemBufInputSource dtor
[
https://issues.apache.org/jira/browse/XERCESC-2214?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Scott Cantor closed XERCESC-2214.
-
> Wrong delete[] in MemBufInputSource dtor
>
>
> Key: XERCESC-2214
> URL: https://issues.apache.org/jira/browse/XERCESC-2214
> Project: Xerces-C++
> Issue Type: Bug
> Components: Miscellaneous
>Affects Versions: 3.2.3
>Reporter: Tobias Elbrandt
>Assignee: Scott Cantor
>Priority: Minor
> Fix For: 4.0.0, 3.2.4
>
>
> Our address sanatizer found a mismatching delete[] for memory allocated via
> {{new}} (not {{new[]}}) in the destructor of
> {color:#00}MemBufInputSource{color}.
> I looked at the code to find places where {{new[]}} is used which would make
> it necessary to use {{delete[]}} instead of {{delete}} - without success. It
> seems to me that using {{delete[]}} is simply wrong here.
>
--
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
[xerces-c] 01/02: XERCESC-2242 - Non-default curl location breaks autoconf link detection
This is an automated email from the ASF dual-hosted git repository. scantor pushed a commit to branch master in repository https://gitbox.apache.org/repos/asf/xerces-c.git commit 2a64a944d59f3273e09e018bbe7f526b00910311 Author: Scott Cantor AuthorDate: Wed Oct 5 12:44:56 2022 -0400 XERCESC-2242 - Non-default curl location breaks autoconf link detection https://issues.apache.org/jira/browse/XERCESC-2242 --- m4/xerces_curl_prefix.m4 | 2 ++ 1 file changed, 2 insertions(+) diff --git a/m4/xerces_curl_prefix.m4 b/m4/xerces_curl_prefix.m4 index fec4418a7..d1d015ca8 100644 --- a/m4/xerces_curl_prefix.m4 +++ b/m4/xerces_curl_prefix.m4 @@ -66,6 +66,7 @@ AC_DEFUN([XERCES_CURL_PREFIX], orig_libs=$LIBS LIBS="$curl_libs $LIBS" +CPPFLAGS="$curl_flags $CPPFLAGS" AC_LINK_IFELSE( [AC_LANG_SOURCE([ @@ -82,6 +83,7 @@ AC_DEFUN([XERCES_CURL_PREFIX], [], [xerces_cv_curl_present=no]) LIBS=$orig_libs +CPPFLAGS=$orig_cppflags if test x"$xerces_cv_curl_present" != x"no"; then AC_MSG_RESULT([yes]) - To unsubscribe, e-mail: c-dev-unsubscr...@xerces.apache.org For additional commands, e-mail: c-dev-h...@xerces.apache.org
[xerces-c] branch master updated (0f109e531 -> 873fe028c)
This is an automated email from the ASF dual-hosted git repository. scantor pushed a change to branch master in repository https://gitbox.apache.org/repos/asf/xerces-c.git from 0f109e531 Merge pull request #49 from oci-labs/xercesc-2236 new 2a64a944d XERCESC-2242 - Non-default curl location breaks autoconf link detection new 873fe028c XERCESC-2214 - Wrong delete[] in MemBufInputSource dtor The 2 revisions listed above as "new" are entirely new to this repository and will be described in separate emails. The revisions listed as "add" were already present in the repository and have only been added to this reference. Summary of changes: m4/xerces_curl_prefix.m4| 2 ++ src/xercesc/framework/MemBufInputSource.hpp | 8 +--- 2 files changed, 7 insertions(+), 3 deletions(-) - To unsubscribe, e-mail: c-dev-unsubscr...@xerces.apache.org For additional commands, e-mail: c-dev-h...@xerces.apache.org
[xerces-c] 02/02: XERCESC-2214 - Wrong delete[] in MemBufInputSource dtor
This is an automated email from the ASF dual-hosted git repository. scantor pushed a commit to branch master in repository https://gitbox.apache.org/repos/asf/xerces-c.git commit 873fe028cfc3e7aa7ce07cdb7ec1d77b9b081472 Author: Scott Cantor AuthorDate: Wed Oct 5 16:40:38 2022 -0400 XERCESC-2214 - Wrong delete[] in MemBufInputSource dtor https://issues.apache.org/jira/browse/XERCESC-2214 --- src/xercesc/framework/MemBufInputSource.hpp | 8 +--- 1 file changed, 5 insertions(+), 3 deletions(-) diff --git a/src/xercesc/framework/MemBufInputSource.hpp b/src/xercesc/framework/MemBufInputSource.hpp index 677271b5c..b67cff8a5 100644 --- a/src/xercesc/framework/MemBufInputSource.hpp +++ b/src/xercesc/framework/MemBufInputSource.hpp @@ -48,9 +48,11 @@ class BinInputStream; * * The passed buffer can be adopted or merely referenced. If it is adopted, * then it must be dynamically allocated and will be destroyed when the - * input source is destroyed (no reference counting!.) If not adopted, the - * caller must insure that it remains valid until the input source object - * is destroyed. + * input source is destroyed (no reference counting!.) Note that the + * deallocation assumes that array deletion should be performed, so do + * not pass a non-array-allocated buffer if asking for adoption. + * If not adopted, the caller must insure that it remains valid until the + * input source object is destroyed. * * The other option indicates whether each stream created for this input * source should get its own copy of the data, or whether it should just - To unsubscribe, e-mail: c-dev-unsubscr...@xerces.apache.org For additional commands, e-mail: c-dev-h...@xerces.apache.org
[xerces-c] branch xerces-3.2 updated: XERCESC-2214 - Wrong delete[] in MemBufInputSource dtor
This is an automated email from the ASF dual-hosted git repository. scantor pushed a commit to branch xerces-3.2 in repository https://gitbox.apache.org/repos/asf/xerces-c.git The following commit(s) were added to refs/heads/xerces-3.2 by this push: new b403617d2 XERCESC-2214 - Wrong delete[] in MemBufInputSource dtor b403617d2 is described below commit b403617d281ae146dff3a62ea481753e32cf0def Author: Scott Cantor AuthorDate: Wed Oct 5 16:40:38 2022 -0400 XERCESC-2214 - Wrong delete[] in MemBufInputSource dtor https://issues.apache.org/jira/browse/XERCESC-2214 --- src/xercesc/framework/MemBufInputSource.hpp | 8 +--- 1 file changed, 5 insertions(+), 3 deletions(-) diff --git a/src/xercesc/framework/MemBufInputSource.hpp b/src/xercesc/framework/MemBufInputSource.hpp index 9bc7b5ad6..a35132eda 100644 --- a/src/xercesc/framework/MemBufInputSource.hpp +++ b/src/xercesc/framework/MemBufInputSource.hpp @@ -48,9 +48,11 @@ class BinInputStream; * * The passed buffer can be adopted or merely referenced. If it is adopted, * then it must be dynamically allocated and will be destroyed when the - * input source is destroyed (no reference counting!.) If not adopted, the - * caller must insure that it remains valid until the input source object - * is destroyed. + * input source is destroyed (no reference counting!.) Note that the + * deallocation assumes that array deletion should be performed, so do + * not pass a non-array-allocated buffer if asking for adoption. + * If not adopted, the caller must insure that it remains valid until the + * input source object is destroyed. * * The other option indicates whether each stream created for this input * source should get its own copy of the data, or whether it should just - To unsubscribe, e-mail: c-dev-unsubscr...@xerces.apache.org For additional commands, e-mail: c-dev-h...@xerces.apache.org
[GitHub] [xerces-c] rleigh-codelibre commented on pull request #31: XERCESC-2219: [Backport 3.2] XMLReader constructor: fix memory leak when refreshRawBuffer() throws
rleigh-codelibre commented on PR #31: URL: https://github.com/apache/xerces-c/pull/31#issuecomment-1268948199 I thought MSVC linked by name rather than by ordinal when you used `__declspec`? We aren't manually assigning ordinals in a `.def` file, we're linking by name, and the ordinals are sequentially assigned, and aren't used when linking either at build time or run time? If you run `dumpbin /EXPORTS` on the .lib and .dll you'll see that the lib file has names, the dll has both ordinals and names. If you run `dumpbin /IMPORTS` on any of the exes you'll see that it has both ordinals and names. My understanding of this is that the ordinals have to be unique but are otherwise a Win16 legacy and aren't used when the names are present--and for Xerces-C++ it will be using the names. I don't think there is an ABI issue here. However, I'm not a Windows COFF expert. -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: c-dev-unsubscr...@xerces.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org - To unsubscribe, e-mail: c-dev-unsubscr...@xerces.apache.org For additional commands, e-mail: c-dev-h...@xerces.apache.org
[jira] [Commented] (XERCESC-2214) Wrong delete[] in MemBufInputSource dtor
[
https://issues.apache.org/jira/browse/XERCESC-2214?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17613216#comment-17613216
]
Scott Cantor commented on XERCESC-2214:
---
Actually I think it's underdocumented, not so much wrong.
My review suggests that nothing is calling this with the adopt flag set to
true, so in fact nothing is running that code. But I suspect the underlying
thought was that if it were somebody doing that, it's a memory buffer and would
be allocated as an array. Of course that's an arbitrary assumption given no
flag to signal that.
I'm inclined to add a note to the API documentation comments about it and leave
the code as is.
> Wrong delete[] in MemBufInputSource dtor
>
>
> Key: XERCESC-2214
> URL: https://issues.apache.org/jira/browse/XERCESC-2214
> Project: Xerces-C++
> Issue Type: Bug
> Components: Miscellaneous
>Affects Versions: 3.2.3
>Reporter: Tobias Elbrandt
>Assignee: Scott Cantor
>Priority: Minor
> Fix For: 3.2.4
>
>
> Our address sanatizer found a mismatching delete[] for memory allocated via
> {{new}} (not {{new[]}}) in the destructor of
> {color:#00}MemBufInputSource{color}.
> I looked at the code to find places where {{new[]}} is used which would make
> it necessary to use {{delete[]}} instead of {{delete}} - without success. It
> seems to me that using {{delete[]}} is simply wrong here.
>
--
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-2241) Integer overflows in DFAContentModel class
[ https://issues.apache.org/jira/browse/XERCESC-2241?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Scott Cantor updated XERCESC-2241: -- Fix Version/s: 4.0.0 > Integer overflows in DFAContentModel class > -- > > Key: XERCESC-2241 > URL: https://issues.apache.org/jira/browse/XERCESC-2241 > Project: Xerces-C++ > Issue Type: Bug > Components: Validating Parser (XML Schema) >Affects Versions: 3.2.3 >Reporter: Even Rouault >Assignee: Scott Cantor >Priority: Major > Fix For: 4.0.0, 3.2.4 > > > On .xsd files like the following ones (generated by ossfuzz, so broken), > integer overflows can happen in DFAContentModel::countLeafNodes() and > DFAContentModel::buildDFA() which can later cause out-of-bounds access. > Found in [https://bugs.chromium.org/p/oss-fuzz/issues/detail?id=52025] > > ``` > http://www.w3.org/2001/XMLSchema; > xmlns:myns="http://myns; > targetNamespace="http://myns; > elementFormDefault="qualified" attributeFormDefault="unqualified"> > > > > > > > > > > > > > > ame="x" type="xs:int" maxOccurs="1"/> > > > > > > > ``` -- 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] [Closed] (XERCESC-2242) Non-default curl location breaks autoconf link detection
[ https://issues.apache.org/jira/browse/XERCESC-2242?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Scott Cantor closed XERCESC-2242. - > Non-default curl location breaks autoconf link detection > > > Key: XERCESC-2242 > URL: https://issues.apache.org/jira/browse/XERCESC-2242 > Project: Xerces-C++ > Issue Type: Bug > Components: Build >Affects Versions: 3.2.3 >Reporter: Scott Cantor >Assignee: Scott Cantor >Priority: Major > Fix For: 3.2.4 > > -- 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
RE: Prepping a 3.2.4 release
Hi Scott, I'm afraid that due to other commitments, I've been unable to do any further work on the master branch for 4.0.0, and it's unlikely that this will change in the near future. If anything, I'm unlikely to be able to spend much more time on the project at all, and I might have to end my involvement entirely. I'm no longer actively using Xerces-C++, since the projects I used it for have wound down. I don't think there are any particularly compelling features on the master branch which anyone would miss. It was primarily some cleanup to remove obsolete stuff and bring it up to date with modern C++ standards in a very limited way. While it would have been nice to continue this and make a 4.0.0 release, I'm afraid I will have to leave this to someone else. We do have a large accumulation of patches which would certainly be worth carrying over to the 3.2 branch where applicable, so I'm sure a point release with these fixes would be much appreciated by the wider community. When it comes to ABI compatibility checking, I'll be happy to do runs of some of the ABI checking tools to look for any compatibility issues with the ABI or API, if you haven't already done this. It would be nice to get the CI fixed up again before making a release. It's probably not too difficult to get working again; the CI image and the build logic probably need updating to cope with external changes which broke it in the interim. I can try to find a bit of time to inspect this--it's not too difficult, just takes time to wait for builds for each change to test it. Kind regards, Roger > -Original Message- > From: Cantor, Scott > Sent: 05 October 2022 14:57 > To: c-dev@xerces.apache.org > Subject: Prepping a 3.2.4 release > > Resending... > > As the traffic indicates, I've got a rare window to actually do some work on a > release, so I'm aiming to get a 3.2.4 patch done quickly. > > I do not have the cycles or the will (or believe it's in the interest of the > project) to get a 4.0 out so I'm not working on that. > > I need to get my arms around what's actually committed on the branch and > what might be left to commit that's safe to do, so I'm starting there.
[GitHub] [xerces-c] rouault commented on a diff in pull request #51: [XERCESC-2241] Fix integer overflows in DFAContentModel class
rouault commented on code in PR #51: URL: https://github.com/apache/xerces-c/pull/51#discussion_r986050269 ## src/xercesc/validators/common/DFAContentModel.cpp: ## @@ -661,8 +662,15 @@ void DFAContentModel::buildDFA(ContentSpecNode* const curNode) // in the fLeafCount member. // fLeafCount=countLeafNodes(curNode); +// Avoid integer overflow in below fLeafCount++ increment +if (fLeafCount > std::numeric_limits::max() - 1) +throw OutOfMemoryException(); fEOCPos = fLeafCount++; +// Avoid integer overflow in below memory allocatoin +if (fLeafCount > std::numeric_limits::max() / sizeof(CMLeaf*)) Review Comment: ah sorry for some reason I read your sentence as "would it be possible to *avoid* the division"... Brackets added -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: c-dev-unsubscr...@xerces.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org - To unsubscribe, e-mail: c-dev-unsubscr...@xerces.apache.org For additional commands, e-mail: c-dev-h...@xerces.apache.org
[GitHub] [xerces-c] rleigh-codelibre commented on a diff in pull request #51: [XERCESC-2241] Fix integer overflows in DFAContentModel class
rleigh-codelibre commented on code in PR #51: URL: https://github.com/apache/xerces-c/pull/51#discussion_r986046406 ## src/xercesc/validators/common/DFAContentModel.cpp: ## @@ -661,8 +662,15 @@ void DFAContentModel::buildDFA(ContentSpecNode* const curNode) // in the fLeafCount member. // fLeafCount=countLeafNodes(curNode); +// Avoid integer overflow in below fLeafCount++ increment +if (fLeafCount > std::numeric_limits::max() - 1) +throw OutOfMemoryException(); fEOCPos = fLeafCount++; +// Avoid integer overflow in below memory allocatoin +if (fLeafCount > std::numeric_limits::max() / sizeof(CMLeaf*)) Review Comment: I just meant `fLeafCount > (std::numeric_limits::max() / sizeof(CMLeaf*))` so that the operator precedence is explicit (and the same for below). -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: c-dev-unsubscr...@xerces.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org - To unsubscribe, e-mail: c-dev-unsubscr...@xerces.apache.org For additional commands, e-mail: c-dev-h...@xerces.apache.org
[GitHub] [xerces-c] rleigh-codelibre commented on a diff in pull request #51: [XERCESC-2241] Fix integer overflows in DFAContentModel class
rleigh-codelibre commented on code in PR #51:
URL: https://github.com/apache/xerces-c/pull/51#discussion_r986030234
##
src/xercesc/validators/common/DFAContentModel.cpp:
##
@@ -661,8 +662,15 @@ void DFAContentModel::buildDFA(ContentSpecNode* const
curNode)
// in the fLeafCount member.
//
fLeafCount=countLeafNodes(curNode);
+// Avoid integer overflow in below fLeafCount++ increment
+if (fLeafCount > std::numeric_limits::max() - 1)
Review Comment:
Should this be `XMLSize_t` (a.k.a. `size_t`) rather than `unsigned int` to
match the type of `fLeafCount`?
##
src/xercesc/validators/common/DFAContentModel.cpp:
##
@@ -661,8 +662,15 @@ void DFAContentModel::buildDFA(ContentSpecNode* const
curNode)
// in the fLeafCount member.
//
fLeafCount=countLeafNodes(curNode);
+// Avoid integer overflow in below fLeafCount++ increment
+if (fLeafCount > std::numeric_limits::max() - 1)
+throw OutOfMemoryException();
fEOCPos = fLeafCount++;
+// Avoid integer overflow in below memory allocatoin
Review Comment:
typo: allocation
##
src/xercesc/validators/common/DFAContentModel.cpp:
##
@@ -1364,14 +1372,27 @@ unsigned int
DFAContentModel::countLeafNodes(ContentSpecNode* const curNode)
if(nLoopCount!=0)
{
count += countLeafNodes(cursor);
-for(unsigned int i=0;i std::numeric_limits::max() /
nLoopCount)
Review Comment:
In all of the following changes, just want to check as above that the limit
check should use `XMLSize_t` rather than `unsigned int`?
And would it also be possible to put brackets around all expressions being
compared for clarity?
##
src/xercesc/validators/common/DFAContentModel.cpp:
##
@@ -661,8 +662,15 @@ void DFAContentModel::buildDFA(ContentSpecNode* const
curNode)
// in the fLeafCount member.
//
fLeafCount=countLeafNodes(curNode);
+// Avoid integer overflow in below fLeafCount++ increment
+if (fLeafCount > std::numeric_limits::max() - 1)
+throw OutOfMemoryException();
fEOCPos = fLeafCount++;
+// Avoid integer overflow in below memory allocatoin
+if (fLeafCount > std::numeric_limits::max() / sizeof(CMLeaf*))
Review Comment:
Should this also be `XMLSize_t`?
Would it be possible to add brackets around the division for clarity?
##
src/xercesc/validators/common/DFAContentModel.cpp:
##
@@ -661,8 +662,15 @@ void DFAContentModel::buildDFA(ContentSpecNode* const
curNode)
// in the fLeafCount member.
//
fLeafCount=countLeafNodes(curNode);
+// Avoid integer overflow in below fLeafCount++ increment
+if (fLeafCount > std::numeric_limits::max() - 1)
Review Comment:
Oops, I was looking at the wrong definition in
src/xercesc/validators/common/ContentLeafNameTypeVector.hpp when I was scanning
over the `git grep` output. In that case, that all looks fine!
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: c-dev-unsubscr...@xerces.apache.org
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
-
To unsubscribe, e-mail: c-dev-unsubscr...@xerces.apache.org
For additional commands, e-mail: c-dev-h...@xerces.apache.org
[GitHub] [xerces-c] rouault commented on a diff in pull request #51: [XERCESC-2241] Fix integer overflows in DFAContentModel class
rouault commented on code in PR #51:
URL: https://github.com/apache/xerces-c/pull/51#discussion_r986039665
##
src/xercesc/validators/common/DFAContentModel.cpp:
##
@@ -661,8 +662,15 @@ void DFAContentModel::buildDFA(ContentSpecNode* const
curNode)
// in the fLeafCount member.
//
fLeafCount=countLeafNodes(curNode);
+// Avoid integer overflow in below fLeafCount++ increment
+if (fLeafCount > std::numeric_limits::max() - 1)
Review Comment:
fLeafCount is actually declared as unsigned int at line 236 of
DFAContentModel.hpp (which is already much bigger than what is reasonable in
practice :-))
##
src/xercesc/validators/common/DFAContentModel.cpp:
##
@@ -661,8 +662,15 @@ void DFAContentModel::buildDFA(ContentSpecNode* const
curNode)
// in the fLeafCount member.
//
fLeafCount=countLeafNodes(curNode);
+// Avoid integer overflow in below fLeafCount++ increment
+if (fLeafCount > std::numeric_limits::max() - 1)
+throw OutOfMemoryException();
fEOCPos = fLeafCount++;
+// Avoid integer overflow in below memory allocatoin
+if (fLeafCount > std::numeric_limits::max() / sizeof(CMLeaf*))
Review Comment:
> Would it be possible to add brackets around the division for clarity?
this is the best way I can think of that doesn't rely on doing overflow
arithmetic... As it is unsigned type, we could do overflow arithmetic as it is
well defined in C/C++, but I tend to fuzz software with
-fsanitize=unsigned-integer-overflow because in practice > 90% unsigned
overflows that occur are actually bugs
##
src/xercesc/validators/common/DFAContentModel.cpp:
##
@@ -661,8 +662,15 @@ void DFAContentModel::buildDFA(ContentSpecNode* const
curNode)
// in the fLeafCount member.
//
fLeafCount=countLeafNodes(curNode);
+// Avoid integer overflow in below fLeafCount++ increment
+if (fLeafCount > std::numeric_limits::max() - 1)
+throw OutOfMemoryException();
fEOCPos = fLeafCount++;
+// Avoid integer overflow in below memory allocatoin
Review Comment:
fixed
##
src/xercesc/validators/common/DFAContentModel.cpp:
##
@@ -1364,14 +1372,27 @@ unsigned int
DFAContentModel::countLeafNodes(ContentSpecNode* const curNode)
if(nLoopCount!=0)
{
count += countLeafNodes(cursor);
-for(unsigned int i=0;i std::numeric_limits::max() /
nLoopCount)
Review Comment:
cf above comments regarding data type
brackets added
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: c-dev-unsubscr...@xerces.apache.org
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
-
To unsubscribe, e-mail: c-dev-unsubscr...@xerces.apache.org
For additional commands, e-mail: c-dev-h...@xerces.apache.org
[GitHub] [xerces-c] rouault commented on pull request #51: [XERCESC-2241] Fix integer overflows in DFAContentModel class
rouault commented on PR #51: URL: https://github.com/apache/xerces-c/pull/51#issuecomment-1265749924 CC @rleigh-codelibre This should be relatively safe to apply -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: c-dev-unsubscr...@xerces.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org - To unsubscribe, e-mail: c-dev-unsubscr...@xerces.apache.org For additional commands, e-mail: c-dev-h...@xerces.apache.org
[jira] [Resolved] (XERCESC-2236) Dependencies aren't loaded when using provided CMake config package
[
https://issues.apache.org/jira/browse/XERCESC-2236?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Scott Cantor resolved XERCESC-2236.
---
Resolution: Fixed
Thanks, applied to branch as well.
> Dependencies aren't loaded when using provided CMake config package
> ---
>
> Key: XERCESC-2236
> URL: https://issues.apache.org/jira/browse/XERCESC-2236
> Project: Xerces-C++
> Issue Type: Bug
> Components: Build
>Affects Versions: 3.2.3
> Environment: Ubuntu 18.04, CMake 3.22.2
>Reporter: Fred Hornsey
>Assignee: Scott Cantor
>Priority: Major
> Fix For: 3.2.4
>
> Attachments: xercesc-2236-fix.patch
>
>
> We have a CMake config package for our libraries that tries to load Xerces
> support like so:
> {code:java}
> find_package(XercesC PATHS "${OPENDDS_XERCES3}" NO_DEFAULT_PATH)
> if (NOT XercesC_FOUND)
> find_package(XercesC)
> endif(){code}
> Where {{OPENDDS_XERCES3}} is the path to the Xerces our libraries were built
> with. This works on Windows and Linux when using system-provided package.
> When building and installing from source on Linux it seem this doesn't work.
> In this case it's trying to use the CMake package provided by Xerces instead
> of the one builtin to CMake.
> I've created an example to demonstrate this. Xerces is built and installed to
> a location on Linux using CMake. Then we create a {{{}CMakeLists.txt{}}}:
> {code:java}
> cmake_minimum_required(VERSION 3.12.0)
> project(xerces_cmake_config_pkg_test)
> find_package(XercesC PATHS "${THE_XERCES_ROOT}" NO_DEFAULT_PATH)
> add_executable(testexe test.cpp)
> target_link_libraries(testexe XercesC::XercesC)
> {code}
> {{test.cpp}} has to be created, but it doesn't matter what it contains
> because CMake doesn't get far enough to allow us to attempt to build. When
> configuring, setting {{THE_XERCES_ROOT}} to the installed Xerces, CMake gives
> these errors:
> {code:java}
> CMake Error at CMakeLists.txt:10 (add_executable):
> Target "testexe" links to target "ICU::uc" but the target was not found.
> Perhaps a find_package() call is missing for an IMPORTED target, or an
> ALIAS target is missing?
> CMake Error at CMakeLists.txt:10 (add_executable):
> Target "testexe" links to target "ICU::data" but the target was not found.
> Perhaps a find_package() call is missing for an IMPORTED target, or an
> ALIAS target is missing?
> CMake Error at CMakeLists.txt:10 (add_executable):
> Target "testexe" links to target "Threads::Threads" but the target was not
> found. Perhaps a find_package() call is missing for an IMPORTED target, or
> an ALIAS target is missing? {code}
>
> This seems to be caused by the packages being specified by Xerces during its
> configure ([like
> ICU|https://github.com/apache/xerces-c/blob/045bdf8ac7755e1ce2735d5ef3f6741ec4718df9/src/CMakeLists.txt#L1113])
> being referenced in the Config package, but not being loaded for the using
> {{find_package}} or equivalent. [CMake
> documenation|https://cmake.org/cmake/help/latest/manual/cmake-packages.7.html#creating-a-package-configuration-file]
> suggests that this should be done in somewhere in the [config
> file|https://github.com/apache/xerces-c/blob/master/src/xercesc/util/XercesVersion.hpp.in].
>
>
>
>
--
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] [Closed] (XERCESC-2236) Dependencies aren't loaded when using provided CMake config package
[
https://issues.apache.org/jira/browse/XERCESC-2236?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Scott Cantor closed XERCESC-2236.
-
> Dependencies aren't loaded when using provided CMake config package
> ---
>
> Key: XERCESC-2236
> URL: https://issues.apache.org/jira/browse/XERCESC-2236
> Project: Xerces-C++
> Issue Type: Bug
> Components: Build
>Affects Versions: 3.2.3
> Environment: Ubuntu 18.04, CMake 3.22.2
>Reporter: Fred Hornsey
>Assignee: Scott Cantor
>Priority: Major
> Fix For: 3.2.4
>
> Attachments: xercesc-2236-fix.patch
>
>
> We have a CMake config package for our libraries that tries to load Xerces
> support like so:
> {code:java}
> find_package(XercesC PATHS "${OPENDDS_XERCES3}" NO_DEFAULT_PATH)
> if (NOT XercesC_FOUND)
> find_package(XercesC)
> endif(){code}
> Where {{OPENDDS_XERCES3}} is the path to the Xerces our libraries were built
> with. This works on Windows and Linux when using system-provided package.
> When building and installing from source on Linux it seem this doesn't work.
> In this case it's trying to use the CMake package provided by Xerces instead
> of the one builtin to CMake.
> I've created an example to demonstrate this. Xerces is built and installed to
> a location on Linux using CMake. Then we create a {{{}CMakeLists.txt{}}}:
> {code:java}
> cmake_minimum_required(VERSION 3.12.0)
> project(xerces_cmake_config_pkg_test)
> find_package(XercesC PATHS "${THE_XERCES_ROOT}" NO_DEFAULT_PATH)
> add_executable(testexe test.cpp)
> target_link_libraries(testexe XercesC::XercesC)
> {code}
> {{test.cpp}} has to be created, but it doesn't matter what it contains
> because CMake doesn't get far enough to allow us to attempt to build. When
> configuring, setting {{THE_XERCES_ROOT}} to the installed Xerces, CMake gives
> these errors:
> {code:java}
> CMake Error at CMakeLists.txt:10 (add_executable):
> Target "testexe" links to target "ICU::uc" but the target was not found.
> Perhaps a find_package() call is missing for an IMPORTED target, or an
> ALIAS target is missing?
> CMake Error at CMakeLists.txt:10 (add_executable):
> Target "testexe" links to target "ICU::data" but the target was not found.
> Perhaps a find_package() call is missing for an IMPORTED target, or an
> ALIAS target is missing?
> CMake Error at CMakeLists.txt:10 (add_executable):
> Target "testexe" links to target "Threads::Threads" but the target was not
> found. Perhaps a find_package() call is missing for an IMPORTED target, or
> an ALIAS target is missing? {code}
>
> This seems to be caused by the packages being specified by Xerces during its
> configure ([like
> ICU|https://github.com/apache/xerces-c/blob/045bdf8ac7755e1ce2735d5ef3f6741ec4718df9/src/CMakeLists.txt#L1113])
> being referenced in the Config package, but not being loaded for the using
> {{find_package}} or equivalent. [CMake
> documenation|https://cmake.org/cmake/help/latest/manual/cmake-packages.7.html#creating-a-package-configuration-file]
> suggests that this should be done in somewhere in the [config
> file|https://github.com/apache/xerces-c/blob/master/src/xercesc/util/XercesVersion.hpp.in].
>
>
>
>
--
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
[xerces-c] branch xerces-3.2 updated: Merge pull request #49 from oci-labs/xercesc-2236
This is an automated email from the ASF dual-hosted git repository.
scantor pushed a commit to branch xerces-3.2
in repository https://gitbox.apache.org/repos/asf/xerces-c.git
The following commit(s) were added to refs/heads/xerces-3.2 by this push:
new 0163ef33a Merge pull request #49 from oci-labs/xercesc-2236
0163ef33a is described below
commit 0163ef33abe8454c8a18f3347eb0328422709bac
Author: Roger Leigh
AuthorDate: Wed Oct 5 20:54:44 2022 +0100
Merge pull request #49 from oci-labs/xercesc-2236
Mark Dependencies as `PRIVATE` in CMake
---
src/CMakeLists.txt | 2 +-
tests/CMakeLists.txt | 1 +
2 files changed, 2 insertions(+), 1 deletion(-)
diff --git a/src/CMakeLists.txt b/src/CMakeLists.txt
index f396fc5ef..a168db125 100644
--- a/src/CMakeLists.txt
+++ b/src/CMakeLists.txt
@@ -1271,7 +1271,7 @@ set_target_properties(xerces-c-headers PROPERTIES FOLDER
"Library")
add_library(xerces-c
${libxerces_c_SOURCES}
${libxerces_c_RESOURCES})
-target_link_libraries(xerces-c ${libxerces_c_DEPS})
+target_link_libraries(xerces-c PRIVATE ${libxerces_c_DEPS})
if(XERCES_USE_NETACCESSOR_CURL)
target_include_directories(xerces-c SYSTEM PRIVATE ${CURL_INCLUDE_DIRS})
endif()
diff --git a/tests/CMakeLists.txt b/tests/CMakeLists.txt
index 78cd1171d..e87ccaa94 100644
--- a/tests/CMakeLists.txt
+++ b/tests/CMakeLists.txt
@@ -112,6 +112,7 @@ if(NOT XERCES_USE_MUTEXMGR_NOTHREAD)
add_test_executable(ThreadTest
src/ThreadTest/ThreadTest.cpp
)
+ target_link_libraries(ThreadTest Threads::Threads)
endif()
# Fails to compile under gcc 4 (ambiguous calls to NullPointerException)
-
To unsubscribe, e-mail: c-dev-unsubscr...@xerces.apache.org
For additional commands, e-mail: c-dev-h...@xerces.apache.org
[jira] [Assigned] (XERCESC-2236) Dependencies aren't loaded when using provided CMake config package
[
https://issues.apache.org/jira/browse/XERCESC-2236?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Scott Cantor reassigned XERCESC-2236:
-
Assignee: Scott Cantor (was: Roger Leigh)
> Dependencies aren't loaded when using provided CMake config package
> ---
>
> Key: XERCESC-2236
> URL: https://issues.apache.org/jira/browse/XERCESC-2236
> Project: Xerces-C++
> Issue Type: Bug
> Components: Build
>Affects Versions: 3.2.3
> Environment: Ubuntu 18.04, CMake 3.22.2
>Reporter: Fred Hornsey
>Assignee: Scott Cantor
>Priority: Major
> Fix For: 3.2.4
>
> Attachments: xercesc-2236-fix.patch
>
>
> We have a CMake config package for our libraries that tries to load Xerces
> support like so:
> {code:java}
> find_package(XercesC PATHS "${OPENDDS_XERCES3}" NO_DEFAULT_PATH)
> if (NOT XercesC_FOUND)
> find_package(XercesC)
> endif(){code}
> Where {{OPENDDS_XERCES3}} is the path to the Xerces our libraries were built
> with. This works on Windows and Linux when using system-provided package.
> When building and installing from source on Linux it seem this doesn't work.
> In this case it's trying to use the CMake package provided by Xerces instead
> of the one builtin to CMake.
> I've created an example to demonstrate this. Xerces is built and installed to
> a location on Linux using CMake. Then we create a {{{}CMakeLists.txt{}}}:
> {code:java}
> cmake_minimum_required(VERSION 3.12.0)
> project(xerces_cmake_config_pkg_test)
> find_package(XercesC PATHS "${THE_XERCES_ROOT}" NO_DEFAULT_PATH)
> add_executable(testexe test.cpp)
> target_link_libraries(testexe XercesC::XercesC)
> {code}
> {{test.cpp}} has to be created, but it doesn't matter what it contains
> because CMake doesn't get far enough to allow us to attempt to build. When
> configuring, setting {{THE_XERCES_ROOT}} to the installed Xerces, CMake gives
> these errors:
> {code:java}
> CMake Error at CMakeLists.txt:10 (add_executable):
> Target "testexe" links to target "ICU::uc" but the target was not found.
> Perhaps a find_package() call is missing for an IMPORTED target, or an
> ALIAS target is missing?
> CMake Error at CMakeLists.txt:10 (add_executable):
> Target "testexe" links to target "ICU::data" but the target was not found.
> Perhaps a find_package() call is missing for an IMPORTED target, or an
> ALIAS target is missing?
> CMake Error at CMakeLists.txt:10 (add_executable):
> Target "testexe" links to target "Threads::Threads" but the target was not
> found. Perhaps a find_package() call is missing for an IMPORTED target, or
> an ALIAS target is missing? {code}
>
> This seems to be caused by the packages being specified by Xerces during its
> configure ([like
> ICU|https://github.com/apache/xerces-c/blob/045bdf8ac7755e1ce2735d5ef3f6741ec4718df9/src/CMakeLists.txt#L1113])
> being referenced in the Config package, but not being loaded for the using
> {{find_package}} or equivalent. [CMake
> documenation|https://cmake.org/cmake/help/latest/manual/cmake-packages.7.html#creating-a-package-configuration-file]
> suggests that this should be done in somewhere in the [config
> file|https://github.com/apache/xerces-c/blob/master/src/xercesc/util/XercesVersion.hpp.in].
>
>
>
>
--
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
[GitHub] [xerces-c] rouault opened a new pull request, #51: [XERCESC-2241] Fix integer overflows in DFAContentModel class
rouault opened a new pull request, #51: URL: https://github.com/apache/xerces-c/pull/51 On .xsd files like the following ones (generated by ossfuzz, so broken), integer overflows can happen in DFAContentModel::countLeafNodes() and DFAContentModel::buildDFA() which can later cause out-of-bounds access. Found in https://bugs.chromium.org/p/oss-fuzz/issues/detail?id=52025 ``` http://www.w3.org/2001/XMLSchema; xmlns:myns="http://myns; targetNamespace="http://myns; elementFormDefault="qualified" attributeFormDefault="unqualified"> ame="x" type="xs:int" maxOccurs="1"/> ``` -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: c-dev-unsubscr...@xerces.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org - To unsubscribe, e-mail: c-dev-unsubscr...@xerces.apache.org For additional commands, e-mail: c-dev-h...@xerces.apache.org
[jira] [Commented] (XERCESC-2236) Dependencies aren't loaded when using provided CMake config package
[
https://issues.apache.org/jira/browse/XERCESC-2236?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17613131#comment-17613131
]
Roger Leigh commented on XERCESC-2236:
--
The change looks fine to me, and I've applied it to master.
> Dependencies aren't loaded when using provided CMake config package
> ---
>
> Key: XERCESC-2236
> URL: https://issues.apache.org/jira/browse/XERCESC-2236
> Project: Xerces-C++
> Issue Type: Bug
> Components: Build
>Affects Versions: 3.2.3
> Environment: Ubuntu 18.04, CMake 3.22.2
>Reporter: Fred Hornsey
>Assignee: Roger Leigh
>Priority: Major
> Fix For: 3.2.4
>
> Attachments: xercesc-2236-fix.patch
>
>
> We have a CMake config package for our libraries that tries to load Xerces
> support like so:
> {code:java}
> find_package(XercesC PATHS "${OPENDDS_XERCES3}" NO_DEFAULT_PATH)
> if (NOT XercesC_FOUND)
> find_package(XercesC)
> endif(){code}
> Where {{OPENDDS_XERCES3}} is the path to the Xerces our libraries were built
> with. This works on Windows and Linux when using system-provided package.
> When building and installing from source on Linux it seem this doesn't work.
> In this case it's trying to use the CMake package provided by Xerces instead
> of the one builtin to CMake.
> I've created an example to demonstrate this. Xerces is built and installed to
> a location on Linux using CMake. Then we create a {{{}CMakeLists.txt{}}}:
> {code:java}
> cmake_minimum_required(VERSION 3.12.0)
> project(xerces_cmake_config_pkg_test)
> find_package(XercesC PATHS "${THE_XERCES_ROOT}" NO_DEFAULT_PATH)
> add_executable(testexe test.cpp)
> target_link_libraries(testexe XercesC::XercesC)
> {code}
> {{test.cpp}} has to be created, but it doesn't matter what it contains
> because CMake doesn't get far enough to allow us to attempt to build. When
> configuring, setting {{THE_XERCES_ROOT}} to the installed Xerces, CMake gives
> these errors:
> {code:java}
> CMake Error at CMakeLists.txt:10 (add_executable):
> Target "testexe" links to target "ICU::uc" but the target was not found.
> Perhaps a find_package() call is missing for an IMPORTED target, or an
> ALIAS target is missing?
> CMake Error at CMakeLists.txt:10 (add_executable):
> Target "testexe" links to target "ICU::data" but the target was not found.
> Perhaps a find_package() call is missing for an IMPORTED target, or an
> ALIAS target is missing?
> CMake Error at CMakeLists.txt:10 (add_executable):
> Target "testexe" links to target "Threads::Threads" but the target was not
> found. Perhaps a find_package() call is missing for an IMPORTED target, or
> an ALIAS target is missing? {code}
>
> This seems to be caused by the packages being specified by Xerces during its
> configure ([like
> ICU|https://github.com/apache/xerces-c/blob/045bdf8ac7755e1ce2735d5ef3f6741ec4718df9/src/CMakeLists.txt#L1113])
> being referenced in the Config package, but not being loaded for the using
> {{find_package}} or equivalent. [CMake
> documenation|https://cmake.org/cmake/help/latest/manual/cmake-packages.7.html#creating-a-package-configuration-file]
> suggests that this should be done in somewhere in the [config
> file|https://github.com/apache/xerces-c/blob/master/src/xercesc/util/XercesVersion.hpp.in].
>
>
>
>
--
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
[xerces-c] branch master updated: Mark Xerces Dependencies as PRIVATE in CMake
This is an automated email from the ASF dual-hosted git repository.
rleigh pushed a commit to branch master
in repository https://gitbox.apache.org/repos/asf/xerces-c.git
The following commit(s) were added to refs/heads/master by this push:
new 549592880 Mark Xerces Dependencies as PRIVATE in CMake
new 0f109e531 Merge pull request #49 from oci-labs/xercesc-2236
549592880 is described below
commit 549592880ec8d97f1ab8140cb72b1414ed285768
Author: Fred Hornsey
AuthorDate: Tue May 17 16:37:21 2022 -0500
Mark Xerces Dependencies as PRIVATE in CMake
Fixes https://issues.apache.org/jira/browse/XERCESC-2236, where trying
to use the generated CMake config package doesn't work because the
dependencies are not loaded using find_package in the config package.
This change assumes they're not necessary for users of the library and
marks them as PRIVATE so they don't end up in the config package in the
first place.
---
src/CMakeLists.txt | 2 +-
tests/CMakeLists.txt | 1 +
2 files changed, 2 insertions(+), 1 deletion(-)
diff --git a/src/CMakeLists.txt b/src/CMakeLists.txt
index c29aa257b..9a81e50c6 100644
--- a/src/CMakeLists.txt
+++ b/src/CMakeLists.txt
@@ -1271,7 +1271,7 @@ set_target_properties(xerces-c-headers PROPERTIES FOLDER
"Library")
add_library(xerces-c
${libxerces_c_SOURCES}
${libxerces_c_RESOURCES})
-target_link_libraries(xerces-c ${libxerces_c_DEPS})
+target_link_libraries(xerces-c PRIVATE ${libxerces_c_DEPS})
if(XERCES_USE_NETACCESSOR_CURL)
target_include_directories(xerces-c SYSTEM PRIVATE ${CURL_INCLUDE_DIRS})
endif()
diff --git a/tests/CMakeLists.txt b/tests/CMakeLists.txt
index 78cd1171d..e87ccaa94 100644
--- a/tests/CMakeLists.txt
+++ b/tests/CMakeLists.txt
@@ -112,6 +112,7 @@ if(NOT XERCES_USE_MUTEXMGR_NOTHREAD)
add_test_executable(ThreadTest
src/ThreadTest/ThreadTest.cpp
)
+ target_link_libraries(ThreadTest Threads::Threads)
endif()
# Fails to compile under gcc 4 (ambiguous calls to NullPointerException)
-
To unsubscribe, e-mail: c-dev-unsubscr...@xerces.apache.org
For additional commands, e-mail: c-dev-h...@xerces.apache.org
[jira] [Commented] (XERCESC-2219) XMLReader constructor: memory leak when refreshRawBuffer() throws
[
https://issues.apache.org/jira/browse/XERCESC-2219?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17613126#comment-17613126
]
Roger Leigh commented on XERCESC-2219:
--
Yes, this was applied.
> XMLReader constructor: memory leak when refreshRawBuffer() throws
> -
>
> Key: XERCESC-2219
> URL: https://issues.apache.org/jira/browse/XERCESC-2219
> Project: Xerces-C++
> Issue Type: Bug
>Affects Versions: 3.2.3
>Reporter: Roger Leigh
>Assignee: Scott Cantor
>Priority: Major
> Fix For: 4.0.0, 3.2.4
>
>
> See https://bugs.chromium.org/p/oss-fuzz/issues/detail?id=37529 on GDAL
> The backtrace of the exception that caused the memory leak was:
> {noformat}
> Catchpoint 1 (exception thrown), 0x75547672 in __cxa_throw () from
> /lib/x86_64-linux-gnu/libstdc++.so.6
> (gdb) bt
> 0 0x75547672 in __cxa_throw () from
> /lib/x86_64-linux-gnu/libstdc++.so.6
> 1 0x724447c4 in xercesc_4_0::PosixFileMgr::fileRead (this= out>, f=, byteCount=, buffer=,
> manager=0x556df730)
>at xercesc/util/FileManagers/PosixFileMgr.cpp:160
> 2 0x724e6ec2 in xercesc_4_0::XMLReader::refreshRawBuffer
> (this=0x557e49f8) at xercesc/internal/XMLReader.cpp:1891
> 3 0x724e70d4 in xercesc_4_0::XMLReader::XMLReader
> (this=0x557e49f8, pubId=, sysId=0x55750920 u"/",
> streamToAdopt=0x5574e838, from=,
>type=xercesc_4_0::XMLReader::Type_General,
> source=xercesc_4_0::XMLReader::Source_External, throwAtEnd=false,
> calculateSrcOfs=false, lowWaterMark=100,
> version=xercesc_4_0::XMLReader::XMLV1_0,
>manager=0x556df730) at xercesc/internal/XMLReader.cpp:130
> 4 0x724ced75 in xercesc_4_0::ReaderMgr::createReader
> (this=this@entry=0x557896d8, src=...,
> refFrom=refFrom@entry=xercesc_4_0::XMLReader::RefFrom_NonLiteral,
>type=type@entry=xercesc_4_0::XMLReader::Type_General,
> source=source@entry=xercesc_4_0::XMLReader::Source_External,
> calcSrcOfs=false, lowWaterMark=100) at ./xercesc/sax/InputSource.hpp:314
> 5 0x724cb0af in xercesc_4_0::IGXMLScanner::scanReset
> (this=0x55789608, src=...) at xercesc/internal/IGXMLScanner2.cpp:1286
> 6 0x724c36e9 in xercesc_4_0::IGXMLScanner::scanDocument
> (this=0x55789608, src=...) at xercesc/internal/IGXMLScanner.cpp:198
> 7 0x7250abaf in xercesc_4_0::AbstractDOMParser::parse
> (this=0x7fffc2d0, source=...) at xercesc/parsers/AbstractDOMParser.cpp:545
> 8 0x724cbdbe in xercesc_4_0::IGXMLScanner::resolveSchemaGrammar
> (this=0x55792f78, loc=0x557dd694 u"/", uri=0x55737180 u"`",
> ignoreLoadSchema=)
>at xercesc/internal/IGXMLScanner2.cpp:1895
> 0x724cce7c in xercesc_4_0::IGXMLScanner::parseSchemaLocation
> (this=0x55792f78, schemaLocationStr=,
> ignoreLoadSchema=false) at ./xercesc/framework/XMLBuffer.hpp:171
> 10 0x724cd182 in
> xercesc_4_0::IGXMLScanner::scanRawAttrListforNameSpaces
> (this=this@entry=0x55792f78, attCount=attCount@entry=9) at
> xercesc/internal/IGXMLScanner2.cpp:1649
> 11 0x724c22cb in xercesc_4_0::IGXMLScanner::scanStartTagNS
> (this=0x55792f78, gotData=@0x7fffc91f: true) at
> xercesc/internal/IGXMLScanner.cpp:2213
> 12 0x724c3522 in xercesc_4_0::IGXMLScanner::scanContent
> (this=0x55792f78) at xercesc/internal/IGXMLScanner.cpp:890
> 13 0x724c3760 in xercesc_4_0::IGXMLScanner::scanDocument
> (this=0x55792f78, src=...) at xercesc/internal/IGXMLScanner.cpp:217
> 14 0x725158e3 in xercesc_4_0::SAX2XMLReaderImpl::parse
> (this=0x55731828, source=...) at xercesc/parsers/SAX2XMLReaderImpl.cpp:409
> {noformat}
--
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] [Closed] (XERCESC-2219) XMLReader constructor: memory leak when refreshRawBuffer() throws
[
https://issues.apache.org/jira/browse/XERCESC-2219?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Roger Leigh closed XERCESC-2219.
Resolution: Fixed
> XMLReader constructor: memory leak when refreshRawBuffer() throws
> -
>
> Key: XERCESC-2219
> URL: https://issues.apache.org/jira/browse/XERCESC-2219
> Project: Xerces-C++
> Issue Type: Bug
>Affects Versions: 3.2.3
>Reporter: Roger Leigh
>Assignee: Scott Cantor
>Priority: Major
> Fix For: 4.0.0, 3.2.4
>
>
> See https://bugs.chromium.org/p/oss-fuzz/issues/detail?id=37529 on GDAL
> The backtrace of the exception that caused the memory leak was:
> {noformat}
> Catchpoint 1 (exception thrown), 0x75547672 in __cxa_throw () from
> /lib/x86_64-linux-gnu/libstdc++.so.6
> (gdb) bt
> 0 0x75547672 in __cxa_throw () from
> /lib/x86_64-linux-gnu/libstdc++.so.6
> 1 0x724447c4 in xercesc_4_0::PosixFileMgr::fileRead (this= out>, f=, byteCount=, buffer=,
> manager=0x556df730)
>at xercesc/util/FileManagers/PosixFileMgr.cpp:160
> 2 0x724e6ec2 in xercesc_4_0::XMLReader::refreshRawBuffer
> (this=0x557e49f8) at xercesc/internal/XMLReader.cpp:1891
> 3 0x724e70d4 in xercesc_4_0::XMLReader::XMLReader
> (this=0x557e49f8, pubId=, sysId=0x55750920 u"/",
> streamToAdopt=0x5574e838, from=,
>type=xercesc_4_0::XMLReader::Type_General,
> source=xercesc_4_0::XMLReader::Source_External, throwAtEnd=false,
> calculateSrcOfs=false, lowWaterMark=100,
> version=xercesc_4_0::XMLReader::XMLV1_0,
>manager=0x556df730) at xercesc/internal/XMLReader.cpp:130
> 4 0x724ced75 in xercesc_4_0::ReaderMgr::createReader
> (this=this@entry=0x557896d8, src=...,
> refFrom=refFrom@entry=xercesc_4_0::XMLReader::RefFrom_NonLiteral,
>type=type@entry=xercesc_4_0::XMLReader::Type_General,
> source=source@entry=xercesc_4_0::XMLReader::Source_External,
> calcSrcOfs=false, lowWaterMark=100) at ./xercesc/sax/InputSource.hpp:314
> 5 0x724cb0af in xercesc_4_0::IGXMLScanner::scanReset
> (this=0x55789608, src=...) at xercesc/internal/IGXMLScanner2.cpp:1286
> 6 0x724c36e9 in xercesc_4_0::IGXMLScanner::scanDocument
> (this=0x55789608, src=...) at xercesc/internal/IGXMLScanner.cpp:198
> 7 0x7250abaf in xercesc_4_0::AbstractDOMParser::parse
> (this=0x7fffc2d0, source=...) at xercesc/parsers/AbstractDOMParser.cpp:545
> 8 0x724cbdbe in xercesc_4_0::IGXMLScanner::resolveSchemaGrammar
> (this=0x55792f78, loc=0x557dd694 u"/", uri=0x55737180 u"`",
> ignoreLoadSchema=)
>at xercesc/internal/IGXMLScanner2.cpp:1895
> 0x724cce7c in xercesc_4_0::IGXMLScanner::parseSchemaLocation
> (this=0x55792f78, schemaLocationStr=,
> ignoreLoadSchema=false) at ./xercesc/framework/XMLBuffer.hpp:171
> 10 0x724cd182 in
> xercesc_4_0::IGXMLScanner::scanRawAttrListforNameSpaces
> (this=this@entry=0x55792f78, attCount=attCount@entry=9) at
> xercesc/internal/IGXMLScanner2.cpp:1649
> 11 0x724c22cb in xercesc_4_0::IGXMLScanner::scanStartTagNS
> (this=0x55792f78, gotData=@0x7fffc91f: true) at
> xercesc/internal/IGXMLScanner.cpp:2213
> 12 0x724c3522 in xercesc_4_0::IGXMLScanner::scanContent
> (this=0x55792f78) at xercesc/internal/IGXMLScanner.cpp:890
> 13 0x724c3760 in xercesc_4_0::IGXMLScanner::scanDocument
> (this=0x55792f78, src=...) at xercesc/internal/IGXMLScanner.cpp:217
> 14 0x725158e3 in xercesc_4_0::SAX2XMLReaderImpl::parse
> (this=0x55731828, source=...) at xercesc/parsers/SAX2XMLReaderImpl.cpp:409
> {noformat}
--
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-2236) Dependencies aren't loaded when using provided CMake config package
[
https://issues.apache.org/jira/browse/XERCESC-2236?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17613121#comment-17613121
]
Scott Cantor commented on XERCESC-2236:
---
I don't use CMake so I would not be comfortable applying this, but will leave
for possible review if it's done in time for a 3.2.4.
> Dependencies aren't loaded when using provided CMake config package
> ---
>
> Key: XERCESC-2236
> URL: https://issues.apache.org/jira/browse/XERCESC-2236
> Project: Xerces-C++
> Issue Type: Bug
> Components: Build
>Affects Versions: 3.2.3
> Environment: Ubuntu 18.04, CMake 3.22.2
>Reporter: Fred Hornsey
>Assignee: Roger Leigh
>Priority: Major
> Fix For: 3.2.4
>
> Attachments: xercesc-2236-fix.patch
>
>
> We have a CMake config package for our libraries that tries to load Xerces
> support like so:
> {code:java}
> find_package(XercesC PATHS "${OPENDDS_XERCES3}" NO_DEFAULT_PATH)
> if (NOT XercesC_FOUND)
> find_package(XercesC)
> endif(){code}
> Where {{OPENDDS_XERCES3}} is the path to the Xerces our libraries were built
> with. This works on Windows and Linux when using system-provided package.
> When building and installing from source on Linux it seem this doesn't work.
> In this case it's trying to use the CMake package provided by Xerces instead
> of the one builtin to CMake.
> I've created an example to demonstrate this. Xerces is built and installed to
> a location on Linux using CMake. Then we create a {{{}CMakeLists.txt{}}}:
> {code:java}
> cmake_minimum_required(VERSION 3.12.0)
> project(xerces_cmake_config_pkg_test)
> find_package(XercesC PATHS "${THE_XERCES_ROOT}" NO_DEFAULT_PATH)
> add_executable(testexe test.cpp)
> target_link_libraries(testexe XercesC::XercesC)
> {code}
> {{test.cpp}} has to be created, but it doesn't matter what it contains
> because CMake doesn't get far enough to allow us to attempt to build. When
> configuring, setting {{THE_XERCES_ROOT}} to the installed Xerces, CMake gives
> these errors:
> {code:java}
> CMake Error at CMakeLists.txt:10 (add_executable):
> Target "testexe" links to target "ICU::uc" but the target was not found.
> Perhaps a find_package() call is missing for an IMPORTED target, or an
> ALIAS target is missing?
> CMake Error at CMakeLists.txt:10 (add_executable):
> Target "testexe" links to target "ICU::data" but the target was not found.
> Perhaps a find_package() call is missing for an IMPORTED target, or an
> ALIAS target is missing?
> CMake Error at CMakeLists.txt:10 (add_executable):
> Target "testexe" links to target "Threads::Threads" but the target was not
> found. Perhaps a find_package() call is missing for an IMPORTED target, or
> an ALIAS target is missing? {code}
>
> This seems to be caused by the packages being specified by Xerces during its
> configure ([like
> ICU|https://github.com/apache/xerces-c/blob/045bdf8ac7755e1ce2735d5ef3f6741ec4718df9/src/CMakeLists.txt#L1113])
> being referenced in the Config package, but not being loaded for the using
> {{find_package}} or equivalent. [CMake
> documenation|https://cmake.org/cmake/help/latest/manual/cmake-packages.7.html#creating-a-package-configuration-file]
> suggests that this should be done in somewhere in the [config
> file|https://github.com/apache/xerces-c/blob/master/src/xercesc/util/XercesVersion.hpp.in].
>
>
>
>
--
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] [Assigned] (XERCESC-2236) Dependencies aren't loaded when using provided CMake config package
[
https://issues.apache.org/jira/browse/XERCESC-2236?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Scott Cantor reassigned XERCESC-2236:
-
Assignee: Roger Leigh (was: Scott Cantor)
> Dependencies aren't loaded when using provided CMake config package
> ---
>
> Key: XERCESC-2236
> URL: https://issues.apache.org/jira/browse/XERCESC-2236
> Project: Xerces-C++
> Issue Type: Bug
> Components: Build
>Affects Versions: 3.2.3
> Environment: Ubuntu 18.04, CMake 3.22.2
>Reporter: Fred Hornsey
>Assignee: Roger Leigh
>Priority: Major
> Fix For: 3.2.4
>
> Attachments: xercesc-2236-fix.patch
>
>
> We have a CMake config package for our libraries that tries to load Xerces
> support like so:
> {code:java}
> find_package(XercesC PATHS "${OPENDDS_XERCES3}" NO_DEFAULT_PATH)
> if (NOT XercesC_FOUND)
> find_package(XercesC)
> endif(){code}
> Where {{OPENDDS_XERCES3}} is the path to the Xerces our libraries were built
> with. This works on Windows and Linux when using system-provided package.
> When building and installing from source on Linux it seem this doesn't work.
> In this case it's trying to use the CMake package provided by Xerces instead
> of the one builtin to CMake.
> I've created an example to demonstrate this. Xerces is built and installed to
> a location on Linux using CMake. Then we create a {{{}CMakeLists.txt{}}}:
> {code:java}
> cmake_minimum_required(VERSION 3.12.0)
> project(xerces_cmake_config_pkg_test)
> find_package(XercesC PATHS "${THE_XERCES_ROOT}" NO_DEFAULT_PATH)
> add_executable(testexe test.cpp)
> target_link_libraries(testexe XercesC::XercesC)
> {code}
> {{test.cpp}} has to be created, but it doesn't matter what it contains
> because CMake doesn't get far enough to allow us to attempt to build. When
> configuring, setting {{THE_XERCES_ROOT}} to the installed Xerces, CMake gives
> these errors:
> {code:java}
> CMake Error at CMakeLists.txt:10 (add_executable):
> Target "testexe" links to target "ICU::uc" but the target was not found.
> Perhaps a find_package() call is missing for an IMPORTED target, or an
> ALIAS target is missing?
> CMake Error at CMakeLists.txt:10 (add_executable):
> Target "testexe" links to target "ICU::data" but the target was not found.
> Perhaps a find_package() call is missing for an IMPORTED target, or an
> ALIAS target is missing?
> CMake Error at CMakeLists.txt:10 (add_executable):
> Target "testexe" links to target "Threads::Threads" but the target was not
> found. Perhaps a find_package() call is missing for an IMPORTED target, or
> an ALIAS target is missing? {code}
>
> This seems to be caused by the packages being specified by Xerces during its
> configure ([like
> ICU|https://github.com/apache/xerces-c/blob/045bdf8ac7755e1ce2735d5ef3f6741ec4718df9/src/CMakeLists.txt#L1113])
> being referenced in the Config package, but not being loaded for the using
> {{find_package}} or equivalent. [CMake
> documenation|https://cmake.org/cmake/help/latest/manual/cmake-packages.7.html#creating-a-package-configuration-file]
> suggests that this should be done in somewhere in the [config
> file|https://github.com/apache/xerces-c/blob/master/src/xercesc/util/XercesVersion.hpp.in].
>
>
>
>
--
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-2235) DFAContentModel::buildDFA(): correctly zero-initialize fFollowList
[ https://issues.apache.org/jira/browse/XERCESC-2235?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17613120#comment-17613120 ] Scott Cantor commented on XERCESC-2235: --- This is a fix to a patch I need to rework, so I'll pick up then. > DFAContentModel::buildDFA(): correctly zero-initialize fFollowList > -- > > Key: XERCESC-2235 > URL: https://issues.apache.org/jira/browse/XERCESC-2235 > Project: Xerces-C++ > Issue Type: Bug >Affects Versions: 3.2.3 >Reporter: Even Rouault >Assignee: Scott Cantor >Priority: Major > Fix For: 3.2.4 > > > Due to a copy issue, the intended zero-initialization of > fFollowList wasn't done (copy issue), and thus in case of > OutOfMemory exception when initializing the array, the memory freeing in > cleanup() could access uninitialized elements. > Follow-up of https://github.com/apache/xerces-c/pull/40 / > a65990d79d3fc333d7481f010da4e165a88b6cb3 > Fixes GDAL's https://bugs.chromium.org/p/oss-fuzz/issues/detail?id=42636 -- 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] [Assigned] (XERCESC-2230) DFAContentModel::buildSyntaxTree(): fix memory leaks when OutOfMemoryException occurs
[ https://issues.apache.org/jira/browse/XERCESC-2230?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Scott Cantor reassigned XERCESC-2230: - Assignee: Scott Cantor > DFAContentModel::buildSyntaxTree(): fix memory leaks when > OutOfMemoryException occurs > - > > Key: XERCESC-2230 > URL: https://issues.apache.org/jira/browse/XERCESC-2230 > Project: Xerces-C++ > Issue Type: Bug >Affects Versions: 3.2.3 >Reporter: Even Rouault >Assignee: Scott Cantor >Priority: Major > Fix For: 4.0.0, 3.2.4 > > > Fixes GDAL's [https://bugs.chromium.org/p/oss-fuzz/issues/detail?id=40866] -- 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] [Closed] (XERCESC-2230) DFAContentModel::buildSyntaxTree(): fix memory leaks when OutOfMemoryException occurs
[ https://issues.apache.org/jira/browse/XERCESC-2230?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Scott Cantor closed XERCESC-2230. - > DFAContentModel::buildSyntaxTree(): fix memory leaks when > OutOfMemoryException occurs > - > > Key: XERCESC-2230 > URL: https://issues.apache.org/jira/browse/XERCESC-2230 > Project: Xerces-C++ > Issue Type: Bug >Affects Versions: 3.2.3 >Reporter: Even Rouault >Assignee: Scott Cantor >Priority: Major > Fix For: 4.0.0, 3.2.4 > > > Fixes GDAL's [https://bugs.chromium.org/p/oss-fuzz/issues/detail?id=40866] -- 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-2230) DFAContentModel::buildSyntaxTree(): fix memory leaks when OutOfMemoryException occurs
[ https://issues.apache.org/jira/browse/XERCESC-2230?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Scott Cantor updated XERCESC-2230: -- Fix Version/s: 4.0.0 > DFAContentModel::buildSyntaxTree(): fix memory leaks when > OutOfMemoryException occurs > - > > Key: XERCESC-2230 > URL: https://issues.apache.org/jira/browse/XERCESC-2230 > Project: Xerces-C++ > Issue Type: Bug >Affects Versions: 3.2.3 >Reporter: Even Rouault >Priority: Major > Fix For: 4.0.0, 3.2.4 > > > Fixes GDAL's [https://bugs.chromium.org/p/oss-fuzz/issues/detail?id=40866] -- 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] [Resolved] (XERCESC-2230) DFAContentModel::buildSyntaxTree(): fix memory leaks when OutOfMemoryException occurs
[ https://issues.apache.org/jira/browse/XERCESC-2230?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Scott Cantor resolved XERCESC-2230. --- Resolution: Fixed Applied to both branches. > DFAContentModel::buildSyntaxTree(): fix memory leaks when > OutOfMemoryException occurs > - > > Key: XERCESC-2230 > URL: https://issues.apache.org/jira/browse/XERCESC-2230 > Project: Xerces-C++ > Issue Type: Bug >Affects Versions: 3.2.3 >Reporter: Even Rouault >Priority: Major > Fix For: 4.0.0, 3.2.4 > > > Fixes GDAL's [https://bugs.chromium.org/p/oss-fuzz/issues/detail?id=40866] -- 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
[xerces-c] branch xerces-3.2 updated: DFAContentModel::buildSyntaxTree(): fix memory leaks when OutOfMemoryException occurs
This is an automated email from the ASF dual-hosted git repository.
scantor pushed a commit to branch xerces-3.2
in repository https://gitbox.apache.org/repos/asf/xerces-c.git
The following commit(s) were added to refs/heads/xerces-3.2 by this push:
new c08ac7443 DFAContentModel::buildSyntaxTree(): fix memory leaks when
OutOfMemoryException occurs
c08ac7443 is described below
commit c08ac74438f3fff8df30ae1549ad1a9646e160fe
Author: Even Rouault
AuthorDate: Mon Nov 15 17:32:26 2021 +0100
DFAContentModel::buildSyntaxTree(): fix memory leaks when
OutOfMemoryException occurs
Fixes GDAL's https://bugs.chromium.org/p/oss-fuzz/issues/detail?id=40866
---
src/xercesc/validators/common/DFAContentModel.cpp | 60 ++-
1 file changed, 36 insertions(+), 24 deletions(-)
diff --git a/src/xercesc/validators/common/DFAContentModel.cpp
b/src/xercesc/validators/common/DFAContentModel.cpp
index 05f2dcd3f..2ae4b7d8e 100644
--- a/src/xercesc/validators/common/DFAContentModel.cpp
+++ b/src/xercesc/validators/common/DFAContentModel.cpp
@@ -1430,33 +1430,45 @@ CMNode*
DFAContentModel::buildSyntaxTree(ContentSpecNode* const curNode
retNode = buildSyntaxTree(cursor, curIndex);
for(unsigned int i=0;igetLastPos();
-const CMStateSet& first = newRight->getFirstPos();
+CMNode* newRight = nullptr;
+try
+{
+newRight = buildSyntaxTree(rightNode, curIndex);
-//
-// Now, for every position which is in our left child's last
set
-// add all of the states in our right child's first set to the
-// follow set for that position.
-//
-CMStateSetEnumerator enumLast();
-while(enumLast.hasMoreElements())
+//
+// Now handle our level. We use our left child's last pos
set and our
+// right child's first pos set, so get them now for
convenience.
+//
+const CMStateSet& last = retNode->getLastPos();
+const CMStateSet& first = newRight->getFirstPos();
+
+//
+// Now, for every position which is in our left child's
last set
+// add all of the states in our right child's first set
to the
+// follow set for that position.
+//
+CMStateSetEnumerator enumLast();
+while(enumLast.hasMoreElements())
+{
+XMLSize_t index=enumLast.nextElement();
+*fFollowList[index] |= first;
+}
+
+retNode = new (fMemoryManager) CMBinaryOp
+(
+ContentSpecNode::Sequence
+, retNode
+, newRight
+, fLeafCount
+, fMemoryManager
+);
+}
+catch( const OutOfMemoryException& )
{
-XMLSize_t index=enumLast.nextElement();
-*fFollowList[index] |= first;
+delete newRight;
+delete retNode;
+throw;
}
-retNode = new (fMemoryManager) CMBinaryOp
-(
-ContentSpecNode::Sequence
-, retNode
-, newRight
-, fLeafCount
-, fMemoryManager
-);
}
return retNode;
}
-
To unsubscribe, e-mail: c-dev-unsubscr...@xerces.apache.org
For additional commands, e-mail: c-dev-h...@xerces.apache.org
[jira] [Resolved] (XERCESC-2229) IGXMLScanner::scanDocTypeDecl(): fix memory leak on exception
[ https://issues.apache.org/jira/browse/XERCESC-2229?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Scott Cantor resolved XERCESC-2229. --- Resolution: Fixed Applied to both branches. > IGXMLScanner::scanDocTypeDecl(): fix memory leak on exception > - > > Key: XERCESC-2229 > URL: https://issues.apache.org/jira/browse/XERCESC-2229 > Project: Xerces-C++ > Issue Type: Bug >Affects Versions: 3.2.3 >Reporter: Even Rouault >Assignee: Scott Cantor >Priority: Major > Fix For: 4.0.0, 3.2.4 > > > The method can leak pubId and sysId when subsequent call to > fReaderMgr.skipPastSpaces() throws an exception (e.g. a > TranscodingException) -- 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-2229) IGXMLScanner::scanDocTypeDecl(): fix memory leak on exception
[ https://issues.apache.org/jira/browse/XERCESC-2229?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Scott Cantor updated XERCESC-2229: -- Fix Version/s: 4.0.0 > IGXMLScanner::scanDocTypeDecl(): fix memory leak on exception > - > > Key: XERCESC-2229 > URL: https://issues.apache.org/jira/browse/XERCESC-2229 > Project: Xerces-C++ > Issue Type: Bug >Affects Versions: 3.2.3 >Reporter: Even Rouault >Assignee: Scott Cantor >Priority: Major > Fix For: 4.0.0, 3.2.4 > > > The method can leak pubId and sysId when subsequent call to > fReaderMgr.skipPastSpaces() throws an exception (e.g. a > TranscodingException) -- 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] [Closed] (XERCESC-2229) IGXMLScanner::scanDocTypeDecl(): fix memory leak on exception
[ https://issues.apache.org/jira/browse/XERCESC-2229?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Scott Cantor closed XERCESC-2229. - > IGXMLScanner::scanDocTypeDecl(): fix memory leak on exception > - > > Key: XERCESC-2229 > URL: https://issues.apache.org/jira/browse/XERCESC-2229 > Project: Xerces-C++ > Issue Type: Bug >Affects Versions: 3.2.3 >Reporter: Even Rouault >Assignee: Scott Cantor >Priority: Major > Fix For: 4.0.0, 3.2.4 > > > The method can leak pubId and sysId when subsequent call to > fReaderMgr.skipPastSpaces() throws an exception (e.g. a > TranscodingException) -- 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
[xerces-c] branch xerces-3.2 updated: IGXMLScanner::scanDocTypeDecl(): fix memory leak on exception
This is an automated email from the ASF dual-hosted git repository.
scantor pushed a commit to branch xerces-3.2
in repository https://gitbox.apache.org/repos/asf/xerces-c.git
The following commit(s) were added to refs/heads/xerces-3.2 by this push:
new 35a0cb4a2 IGXMLScanner::scanDocTypeDecl(): fix memory leak on exception
35a0cb4a2 is described below
commit 35a0cb4a2eaeab18988e2fada2d6547ba2fdbbf7
Author: Even Rouault
AuthorDate: Fri Oct 29 01:20:14 2021 +0200
IGXMLScanner::scanDocTypeDecl(): fix memory leak on exception
The method can leak pubId and sysId when subsequent call to
fReaderMgr.skipPastSpaces() throws an exception (e.g. a
TranscodingException)
---
src/xercesc/internal/IGXMLScanner.cpp | 11 +++
1 file changed, 7 insertions(+), 4 deletions(-)
diff --git a/src/xercesc/internal/IGXMLScanner.cpp
b/src/xercesc/internal/IGXMLScanner.cpp
index 00624009d..912ec0c62 100644
--- a/src/xercesc/internal/IGXMLScanner.cpp
+++ b/src/xercesc/internal/IGXMLScanner.cpp
@@ -1374,7 +1374,14 @@ void IGXMLScanner::scanDocTypeDecl()
// Get copies of the ids we got
pubId = XMLString::replicate(bbPubId.getRawBuffer(), fMemoryManager);
sysId = XMLString::replicate(bbSysId.getRawBuffer(), fMemoryManager);
+}
+
+// Insure that the ids get cleaned up, if they got allocated
+ArrayJanitor janSysId(sysId, fMemoryManager);
+ArrayJanitor janPubId(pubId, fMemoryManager);
+if (hasExtSubset)
+{
// Skip spaces and check again for the opening of an internal subset
fReaderMgr.skipPastSpaces();
@@ -1384,10 +1391,6 @@ void IGXMLScanner::scanDocTypeDecl()
}
}
-// Insure that the ids get cleaned up, if they got allocated
-ArrayJanitor janSysId(sysId, fMemoryManager);
-ArrayJanitor janPubId(pubId, fMemoryManager);
-
// If we have a doc type handler and advanced callbacks are enabled,
// call the doctype event.
if (fDocTypeHandler)
-
To unsubscribe, e-mail: c-dev-unsubscr...@xerces.apache.org
For additional commands, e-mail: c-dev-h...@xerces.apache.org
[jira] [Commented] (XERCESC-2228) DFAContentModel: fix memory leaks when OutOfMemoryException occurs
[ https://issues.apache.org/jira/browse/XERCESC-2228?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17613114#comment-17613114 ] Scott Cantor commented on XERCESC-2228: --- Patch will need adjusting to avoid header change. The inlined method in the other header probably should be moved out, but the change itself is safe, albeit not sufficient to actually correct existing linked code in many cases. > DFAContentModel: fix memory leaks when OutOfMemoryException occurs > -- > > Key: XERCESC-2228 > URL: https://issues.apache.org/jira/browse/XERCESC-2228 > Project: Xerces-C++ > Issue Type: Bug >Affects Versions: 3.2.3 >Reporter: Even Rouault >Assignee: Scott Cantor >Priority: Major > Fix For: 3.2.4 > > > Fixes GDAL's [https://bugs.chromium.org/p/oss-fuzz/issues/detail?id=39159] -- 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-2227) Memleak fixes in ContentSpecNode and ComplexTypeInfo classes
[ https://issues.apache.org/jira/browse/XERCESC-2227?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17613113#comment-17613113 ] Scott Cantor commented on XERCESC-2227: --- Patch will need adjusting for 3.2 branch to avoid method addition. > Memleak fixes in ContentSpecNode and ComplexTypeInfo classes > > > Key: XERCESC-2227 > URL: https://issues.apache.org/jira/browse/XERCESC-2227 > Project: Xerces-C++ > Issue Type: Bug >Affects Versions: 3.2.3 >Reporter: Even Rouault >Assignee: Scott Cantor >Priority: Major > Fix For: 3.2.4 > > > when a OutOfMemory exception occurs. > Spotted by [https://bugs.chromium.org/p/oss-fuzz/issues/detail?id=39127] (on > GDAL) > The commits are a bit in increasing order of triviality. The ownership rules > of ContentSpecNode first and second members, as used by ComplexTypeInfo, are > super complex. shared_ptr would be much welcome here! I can just tell that > valgrind on my test case reports no double-free nor memory leak after those > fixes -- 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-2227) Memleak fixes in ContentSpecNode and ComplexTypeInfo classes
[ https://issues.apache.org/jira/browse/XERCESC-2227?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Scott Cantor updated XERCESC-2227: -- Fix Version/s: 4.0.0 > Memleak fixes in ContentSpecNode and ComplexTypeInfo classes > > > Key: XERCESC-2227 > URL: https://issues.apache.org/jira/browse/XERCESC-2227 > Project: Xerces-C++ > Issue Type: Bug >Affects Versions: 3.2.3 >Reporter: Even Rouault >Assignee: Scott Cantor >Priority: Major > Fix For: 4.0.0, 3.2.4 > > > when a OutOfMemory exception occurs. > Spotted by [https://bugs.chromium.org/p/oss-fuzz/issues/detail?id=39127] (on > GDAL) > The commits are a bit in increasing order of triviality. The ownership rules > of ContentSpecNode first and second members, as used by ComplexTypeInfo, are > super complex. shared_ptr would be much welcome here! I can just tell that > valgrind on my test case reports no double-free nor memory leak after those > fixes -- 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] [Resolved] (XERCESC-2226) Increment minimum CMake version to 3.12
[ https://issues.apache.org/jira/browse/XERCESC-2226?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Scott Cantor resolved XERCESC-2226. --- Resolution: Done Applied to both branches. > Increment minimum CMake version to 3.12 > --- > > Key: XERCESC-2226 > URL: https://issues.apache.org/jira/browse/XERCESC-2226 > Project: Xerces-C++ > Issue Type: Improvement > Components: Build >Reporter: Roger Leigh >Assignee: Scott Cantor >Priority: Major > Fix For: 4.0.0, 3.2.4 > > > Followup for XERCESC-2225 -- 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] [Closed] (XERCESC-2226) Increment minimum CMake version to 3.12
[ https://issues.apache.org/jira/browse/XERCESC-2226?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Scott Cantor closed XERCESC-2226. - > Increment minimum CMake version to 3.12 > --- > > Key: XERCESC-2226 > URL: https://issues.apache.org/jira/browse/XERCESC-2226 > Project: Xerces-C++ > Issue Type: Improvement > Components: Build >Reporter: Roger Leigh >Assignee: Scott Cantor >Priority: Major > Fix For: 4.0.0, 3.2.4 > > > Followup for XERCESC-2225 -- 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-2226) Increment minimum CMake version to 3.12
[ https://issues.apache.org/jira/browse/XERCESC-2226?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Scott Cantor updated XERCESC-2226: -- Fix Version/s: 4.0.0 > Increment minimum CMake version to 3.12 > --- > > Key: XERCESC-2226 > URL: https://issues.apache.org/jira/browse/XERCESC-2226 > Project: Xerces-C++ > Issue Type: Improvement > Components: Build >Reporter: Roger Leigh >Assignee: Scott Cantor >Priority: Major > Fix For: 4.0.0, 3.2.4 > > > Followup for XERCESC-2225 -- 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
[xerces-c] 02/02: XERCESC-2226: Update minimum CMake version to 3.12
This is an automated email from the ASF dual-hosted git repository. scantor pushed a commit to branch xerces-3.2 in repository https://gitbox.apache.org/repos/asf/xerces-c.git commit b1a22d46abcc61857f07d67f3b54256da3d951e3 Author: Roger Leigh AuthorDate: Mon Sep 20 22:07:33 2021 +0100 XERCESC-2226: Update minimum CMake version to 3.12 * Required for CURL imported target usage in XERCESC-2225 * Drop old cmake_policy settings which are now the default behaviour --- CMakeLists.txt | 13 + 1 file changed, 1 insertion(+), 12 deletions(-) diff --git a/CMakeLists.txt b/CMakeLists.txt index 4254f89bb..33bc40f41 100644 --- a/CMakeLists.txt +++ b/CMakeLists.txt @@ -19,18 +19,7 @@ # Run "cmake" to generate the build files for your platform -cmake_minimum_required(VERSION 3.2.0) - -# Use new variable expansion policy. -if (POLICY CMP0053) - cmake_policy(SET CMP0053 NEW) -endif(POLICY CMP0053) -if (POLICY CMP0054) - cmake_policy(SET CMP0054 NEW) -endif(POLICY CMP0054) -if (POLICY CMP0067) - cmake_policy(SET CMP0067 NEW) -endif(POLICY CMP0067) +cmake_minimum_required(VERSION 3.12.0) # Try C++14, then fall back to C++11 and C++98. Used for feature tests # for optional features. - To unsubscribe, e-mail: c-dev-unsubscr...@xerces.apache.org For additional commands, e-mail: c-dev-h...@xerces.apache.org
[xerces-c] 01/02: Merge pull request #34 from prince-chrismc/patch-1
This is an automated email from the ASF dual-hosted git repository.
scantor pushed a commit to branch xerces-3.2
in repository https://gitbox.apache.org/repos/asf/xerces-c.git
commit 1478b831d6fb49f5954353961a09760c76b9e4d0
Author: Roger Leigh
AuthorDate: Mon Sep 20 22:02:26 2021 +0100
Merge pull request #34 from prince-chrismc/patch-1
XERCESC-2225: Link to installed CMake targets of CURL
---
src/CMakeLists.txt | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/src/CMakeLists.txt b/src/CMakeLists.txt
index 344851fad..f396fc5ef 100644
--- a/src/CMakeLists.txt
+++ b/src/CMakeLists.txt
@@ -1085,7 +1085,7 @@ endif()
if(XERCES_USE_NETACCESSOR_CURL)
list(APPEND libxerces_c_SOURCES ${curl_sources})
list(APPEND libxerces_c_HEADERS ${curl_headers})
- list(APPEND libxerces_c_DEPS ${CURL_LIBRARIES})
+ list(APPEND libxerces_c_DEPS CURL::libcurl)
endif()
if(XERCES_USE_NETACCESSOR_SOCKET)
-
To unsubscribe, e-mail: c-dev-unsubscr...@xerces.apache.org
For additional commands, e-mail: c-dev-h...@xerces.apache.org
[xerces-c] branch xerces-3.2 updated (decafd46e -> b1a22d46a)
This is an automated email from the ASF dual-hosted git repository. scantor pushed a change to branch xerces-3.2 in repository https://gitbox.apache.org/repos/asf/xerces-c.git from decafd46e DFAContentModel::checkUniqueParticleAttribution (): speed enhancement new 1478b831d Merge pull request #34 from prince-chrismc/patch-1 new b1a22d46a XERCESC-2226: Update minimum CMake version to 3.12 The 2 revisions listed above as "new" are entirely new to this repository and will be described in separate emails. The revisions listed as "add" were already present in the repository and have only been added to this reference. Summary of changes: CMakeLists.txt | 13 + src/CMakeLists.txt | 2 +- 2 files changed, 2 insertions(+), 13 deletions(-) - To unsubscribe, e-mail: c-dev-unsubscr...@xerces.apache.org For additional commands, e-mail: c-dev-h...@xerces.apache.org
[jira] [Updated] (XERCESC-2225) Link to installed CMake targets of CURL
[ https://issues.apache.org/jira/browse/XERCESC-2225?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Scott Cantor updated XERCESC-2225: -- Fix Version/s: 4.0.0 > Link to installed CMake targets of CURL > --- > > Key: XERCESC-2225 > URL: https://issues.apache.org/jira/browse/XERCESC-2225 > Project: Xerces-C++ > Issue Type: Bug > Components: Build >Affects Versions: 3.2.3 >Reporter: Roger Leigh >Assignee: Roger Leigh >Priority: Major > Fix For: 4.0.0, 3.2.4 > > > Match ICU behaviour. > https://github.com/apache/xerces-c/pull/34 -- 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] [Closed] (XERCESC-2225) Link to installed CMake targets of CURL
[ https://issues.apache.org/jira/browse/XERCESC-2225?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Scott Cantor closed XERCESC-2225. - > Link to installed CMake targets of CURL > --- > > Key: XERCESC-2225 > URL: https://issues.apache.org/jira/browse/XERCESC-2225 > Project: Xerces-C++ > Issue Type: Bug > Components: Build >Affects Versions: 3.2.3 >Reporter: Roger Leigh >Assignee: Roger Leigh >Priority: Major > Fix For: 4.0.0, 3.2.4 > > > Match ICU behaviour. > https://github.com/apache/xerces-c/pull/34 -- 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] [Resolved] (XERCESC-2225) Link to installed CMake targets of CURL
[ https://issues.apache.org/jira/browse/XERCESC-2225?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Scott Cantor resolved XERCESC-2225. --- Resolution: Done Applied to both branches. > Link to installed CMake targets of CURL > --- > > Key: XERCESC-2225 > URL: https://issues.apache.org/jira/browse/XERCESC-2225 > Project: Xerces-C++ > Issue Type: Bug > Components: Build >Affects Versions: 3.2.3 >Reporter: Roger Leigh >Assignee: Roger Leigh >Priority: Major > Fix For: 4.0.0, 3.2.4 > > > Match ICU behaviour. > https://github.com/apache/xerces-c/pull/34 -- 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] [Closed] (XERCESC-2224) DFAContentModel::checkUniqueParticleAttribution (): speed enhancement
[ https://issues.apache.org/jira/browse/XERCESC-2224?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Scott Cantor closed XERCESC-2224. - > DFAContentModel::checkUniqueParticleAttribution (): speed enhancement > - > > Key: XERCESC-2224 > URL: https://issues.apache.org/jira/browse/XERCESC-2224 > Project: Xerces-C++ > Issue Type: Improvement >Reporter: Even Rouault >Assignee: Scott Cantor >Priority: Major > Fix For: 4.0.0, 3.2.4 > > > The complexity of this method is roughly O(n^3). Fuzzers can generate > schemas with n = several thousands. The test fTransTable[i][j] == > XMLContentModel::gInvalidTrans > is independant of the k loop, and can thus being moved at a upper level > to improve runtime. -- 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] [Resolved] (XERCESC-2224) DFAContentModel::checkUniqueParticleAttribution (): speed enhancement
[ https://issues.apache.org/jira/browse/XERCESC-2224?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Scott Cantor resolved XERCESC-2224. --- Resolution: Fixed Applied to both branches. > DFAContentModel::checkUniqueParticleAttribution (): speed enhancement > - > > Key: XERCESC-2224 > URL: https://issues.apache.org/jira/browse/XERCESC-2224 > Project: Xerces-C++ > Issue Type: Improvement >Reporter: Even Rouault >Assignee: Scott Cantor >Priority: Major > Fix For: 4.0.0, 3.2.4 > > > The complexity of this method is roughly O(n^3). Fuzzers can generate > schemas with n = several thousands. The test fTransTable[i][j] == > XMLContentModel::gInvalidTrans > is independant of the k loop, and can thus being moved at a upper level > to improve runtime. -- 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-2224) DFAContentModel::checkUniqueParticleAttribution (): speed enhancement
[ https://issues.apache.org/jira/browse/XERCESC-2224?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Scott Cantor updated XERCESC-2224: -- Fix Version/s: 4.0.0 > DFAContentModel::checkUniqueParticleAttribution (): speed enhancement > - > > Key: XERCESC-2224 > URL: https://issues.apache.org/jira/browse/XERCESC-2224 > Project: Xerces-C++ > Issue Type: Improvement >Reporter: Even Rouault >Assignee: Scott Cantor >Priority: Major > Fix For: 4.0.0, 3.2.4 > > > The complexity of this method is roughly O(n^3). Fuzzers can generate > schemas with n = several thousands. The test fTransTable[i][j] == > XMLContentModel::gInvalidTrans > is independant of the k loop, and can thus being moved at a upper level > to improve runtime. -- 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
[xerces-c] branch xerces-3.2 updated: DFAContentModel::checkUniqueParticleAttribution (): speed enhancement
This is an automated email from the ASF dual-hosted git repository.
scantor pushed a commit to branch xerces-3.2
in repository https://gitbox.apache.org/repos/asf/xerces-c.git
The following commit(s) were added to refs/heads/xerces-3.2 by this push:
new decafd46e DFAContentModel::checkUniqueParticleAttribution (): speed
enhancement
decafd46e is described below
commit decafd46e1473e976566008a6b689e58bcb44285
Author: Even Rouault
AuthorDate: Mon Sep 20 11:59:45 2021 +0200
DFAContentModel::checkUniqueParticleAttribution (): speed enhancement
The complexity of this method is roughly O(n^3). Fuzzers can generate
schemas with n = several thousands. The test fTransTable[i][j] ==
XMLContentModel::gInvalidTrans
is independant of the k loop, and can thus being moved at a upper level
to improve runtime.
---
src/xercesc/validators/common/DFAContentModel.cpp | 5 +++--
1 file changed, 3 insertions(+), 2 deletions(-)
diff --git a/src/xercesc/validators/common/DFAContentModel.cpp
b/src/xercesc/validators/common/DFAContentModel.cpp
index a6187ca59..05f2dcd3f 100644
--- a/src/xercesc/validators/common/DFAContentModel.cpp
+++ b/src/xercesc/validators/common/DFAContentModel.cpp
@@ -1642,9 +1642,10 @@ void DFAContentModel::checkUniqueParticleAttribution
(SchemaGrammar*const pG
// for each state, check whether it has overlap transitions
for (i = 0; i < fTransTableSize; i++) {
for (j = 0; j < fElemMapSize; j++) {
+if (fTransTable[i][j] == XMLContentModel::gInvalidTrans)
+continue;
for (k = j+1; k < fElemMapSize; k++) {
-if (fTransTable[i][j] != XMLContentModel::gInvalidTrans &&
-fTransTable[i][k] != XMLContentModel::gInvalidTrans &&
+if (fTransTable[i][k] != XMLContentModel::gInvalidTrans &&
conflictTable[j][k] == 0) {
// If this is text in a Schema mixed content model, skip
it.
-
To unsubscribe, e-mail: c-dev-unsubscr...@xerces.apache.org
For additional commands, e-mail: c-dev-h...@xerces.apache.org
[jira] [Closed] (XERCESC-2223) SAX2XMLReaderImpl::error(): potential memory leak
[ https://issues.apache.org/jira/browse/XERCESC-2223?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Scott Cantor closed XERCESC-2223. - > SAX2XMLReaderImpl::error(): potential memory leak > - > > Key: XERCESC-2223 > URL: https://issues.apache.org/jira/browse/XERCESC-2223 > Project: Xerces-C++ > Issue Type: Bug >Reporter: Even Rouault >Assignee: Scott Cantor >Priority: Major > Fix For: 4.0.0, 3.2.4 > > > SAX2XMLReaderImpl::error() uses the regular memory manager to create the > SAXParseException. It might fail to fully initialize the object, and > potentially throw an exception when building it, causing it to leak a bit. -- 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] [Resolved] (XERCESC-2223) SAX2XMLReaderImpl::error(): potential memory leak
[ https://issues.apache.org/jira/browse/XERCESC-2223?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Scott Cantor resolved XERCESC-2223. --- Resolution: Fixed Applied to both branches. > SAX2XMLReaderImpl::error(): potential memory leak > - > > Key: XERCESC-2223 > URL: https://issues.apache.org/jira/browse/XERCESC-2223 > Project: Xerces-C++ > Issue Type: Bug >Reporter: Even Rouault >Assignee: Scott Cantor >Priority: Major > Fix For: 4.0.0, 3.2.4 > > > SAX2XMLReaderImpl::error() uses the regular memory manager to create the > SAXParseException. It might fail to fully initialize the object, and > potentially throw an exception when building it, causing it to leak a bit. -- 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-2223) SAX2XMLReaderImpl::error(): potential memory leak
[ https://issues.apache.org/jira/browse/XERCESC-2223?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Scott Cantor updated XERCESC-2223: -- Fix Version/s: 4.0.0 > SAX2XMLReaderImpl::error(): potential memory leak > - > > Key: XERCESC-2223 > URL: https://issues.apache.org/jira/browse/XERCESC-2223 > Project: Xerces-C++ > Issue Type: Bug >Reporter: Even Rouault >Assignee: Scott Cantor >Priority: Major > Fix For: 4.0.0, 3.2.4 > > > SAX2XMLReaderImpl::error() uses the regular memory manager to create the > SAXParseException. It might fail to fully initialize the object, and > potentially throw an exception when building it, causing it to leak a bit. -- 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
[xerces-c] branch xerces-3.2 updated: SAX2XMLReaderImpl::error(): use exception memory manager, otherwise regular memory manager might fail to fully allocate the strings in the exception and cause mem
This is an automated email from the ASF dual-hosted git repository. scantor pushed a commit to branch xerces-3.2 in repository https://gitbox.apache.org/repos/asf/xerces-c.git The following commit(s) were added to refs/heads/xerces-3.2 by this push: new 4227d220a SAX2XMLReaderImpl::error(): use exception memory manager, otherwise regular memory manager might fail to fully allocate the strings in the exception and cause memory leaks 4227d220a is described below commit 4227d220a797792019ee1337868e8af65cb982aa Author: Even Rouault AuthorDate: Wed Sep 15 21:08:40 2021 +0200 SAX2XMLReaderImpl::error(): use exception memory manager, otherwise regular memory manager might fail to fully allocate the strings in the exception and cause memory leaks --- src/xercesc/parsers/SAX2XMLReaderImpl.cpp | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/src/xercesc/parsers/SAX2XMLReaderImpl.cpp b/src/xercesc/parsers/SAX2XMLReaderImpl.cpp index fda4a8b58..24e980c37 100644 --- a/src/xercesc/parsers/SAX2XMLReaderImpl.cpp +++ b/src/xercesc/parsers/SAX2XMLReaderImpl.cpp @@ -1229,7 +1229,7 @@ void SAX2XMLReaderImpl::error( const unsigned int , systemId , lineNum , colNum -, fMemoryManager +, fMemoryManager->getExceptionMemoryManager() ); if (!fErrorHandler) - To unsubscribe, e-mail: c-dev-unsubscr...@xerces.apache.org For additional commands, e-mail: c-dev-h...@xerces.apache.org
[jira] [Closed] (XERCESC-2222) DFAContentModel::checkUniqueParticleAttribution(): fix memory leak
[ https://issues.apache.org/jira/browse/XERCESC-?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Scott Cantor closed XERCESC-. - > DFAContentModel::checkUniqueParticleAttribution(): fix memory leak > -- > > Key: XERCESC- > URL: https://issues.apache.org/jira/browse/XERCESC- > Project: Xerces-C++ > Issue Type: Bug > Components: Validating Parser (XML Schema) >Reporter: Even Rouault >Assignee: Scott Cantor >Priority: Major > Fix For: 4.0.0, 3.2.4 > > > If a memory allocation of conflictTable[] fails, or later in the > function, the array is not freed. > Fixes [https://bugs.chromium.org/p/oss-fuzz/issues/detail?id=38533] -- 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] [Resolved] (XERCESC-2222) DFAContentModel::checkUniqueParticleAttribution(): fix memory leak
[ https://issues.apache.org/jira/browse/XERCESC-?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Scott Cantor resolved XERCESC-. --- Resolution: Fixed I applied this back to the 3.2 branch so it's applied to both. > DFAContentModel::checkUniqueParticleAttribution(): fix memory leak > -- > > Key: XERCESC- > URL: https://issues.apache.org/jira/browse/XERCESC- > Project: Xerces-C++ > Issue Type: Bug > Components: Validating Parser (XML Schema) >Reporter: Even Rouault >Assignee: Scott Cantor >Priority: Major > Fix For: 4.0.0, 3.2.4 > > > If a memory allocation of conflictTable[] fails, or later in the > function, the array is not freed. > Fixes [https://bugs.chromium.org/p/oss-fuzz/issues/detail?id=38533] -- 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-2222) DFAContentModel::checkUniqueParticleAttribution(): fix memory leak
[ https://issues.apache.org/jira/browse/XERCESC-?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Scott Cantor updated XERCESC-: -- Fix Version/s: 4.0.0 > DFAContentModel::checkUniqueParticleAttribution(): fix memory leak > -- > > Key: XERCESC- > URL: https://issues.apache.org/jira/browse/XERCESC- > Project: Xerces-C++ > Issue Type: Bug > Components: Validating Parser (XML Schema) >Reporter: Even Rouault >Assignee: Scott Cantor >Priority: Major > Fix For: 4.0.0, 3.2.4 > > > If a memory allocation of conflictTable[] fails, or later in the > function, the array is not freed. > Fixes [https://bugs.chromium.org/p/oss-fuzz/issues/detail?id=38533] -- 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
[xerces-c] branch xerces-3.2 updated: DFAContentModel::checkUniqueParticleAttribution(): fix memory leak
This is an automated email from the ASF dual-hosted git repository.
scantor pushed a commit to branch xerces-3.2
in repository https://gitbox.apache.org/repos/asf/xerces-c.git
The following commit(s) were added to refs/heads/xerces-3.2 by this push:
new 583943826 DFAContentModel::checkUniqueParticleAttribution(): fix
memory leak
583943826 is described below
commit 5839438265cc5983132f6101644d32ddebaddd74
Author: Even Rouault
AuthorDate: Sat Sep 11 23:31:37 2021 +0200
DFAContentModel::checkUniqueParticleAttribution(): fix memory leak
If a memory allocation of conflictTable[] fails, or later in the
function, the array is not freed.
Fixes https://bugs.chromium.org/p/oss-fuzz/issues/detail?id=38533
---
src/xercesc/validators/common/DFAContentModel.cpp | 30 ---
1 file changed, 26 insertions(+), 4 deletions(-)
diff --git a/src/xercesc/validators/common/DFAContentModel.cpp
b/src/xercesc/validators/common/DFAContentModel.cpp
index 589efeaca..a6187ca59 100644
--- a/src/xercesc/validators/common/DFAContentModel.cpp
+++ b/src/xercesc/validators/common/DFAContentModel.cpp
@@ -1603,6 +1603,32 @@ void DFAContentModel::checkUniqueParticleAttribution
(SchemaGrammar*const pG
(
fElemMapSize * sizeof(signed char*)
);
+memset(conflictTable, 0, fElemMapSize * sizeof(signed char*));
+
+struct ConflictTableKeeper
+{
+MemoryManager* fMemoryManager;
+signed char** fConflictTable;
+unsigned int fElemMapSize;
+
+ConflictTableKeeper(MemoryManager* memoryManager,
+signed char** conflictTable,
+unsigned int elemMapSize):
+fMemoryManager(memoryManager),
+fConflictTable(conflictTable),
+fElemMapSize(elemMapSize)
+{
+}
+
+~ConflictTableKeeper()
+{
+for (int i = 0; i < fElemMapSize; i++)
+fMemoryManager->deallocate(fConflictTable[i]);
+fMemoryManager->deallocate(fConflictTable);
+}
+};
+
+ConflictTableKeeper keeper(fMemoryManager, conflictTable, fElemMapSize);
// initialize the conflict table
for (j = 0; j < fElemMapSize; j++) {
@@ -1676,10 +1702,6 @@ void DFAContentModel::checkUniqueParticleAttribution
(SchemaGrammar*const pG
}
}
}
-
-for (i = 0; i < fElemMapSize; i++)
-fMemoryManager->deallocate(conflictTable[i]);
-fMemoryManager->deallocate(conflictTable);
}
XERCES_CPP_NAMESPACE_END
-
To unsubscribe, e-mail: c-dev-unsubscr...@xerces.apache.org
For additional commands, e-mail: c-dev-h...@xerces.apache.org
[jira] [Commented] (XERCESC-2219) XMLReader constructor: memory leak when refreshRawBuffer() throws
[
https://issues.apache.org/jira/browse/XERCESC-2219?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17613095#comment-17613095
]
Scott Cantor commented on XERCESC-2219:
---
Another ABI change, this will have to be reverted and attacked a different way.
Using internal static functions for cleanup in the interim releases is usually
the best workaround for this kind of thing.
> XMLReader constructor: memory leak when refreshRawBuffer() throws
> -
>
> Key: XERCESC-2219
> URL: https://issues.apache.org/jira/browse/XERCESC-2219
> Project: Xerces-C++
> Issue Type: Bug
>Affects Versions: 3.2.3
>Reporter: Roger Leigh
>Assignee: Roger Leigh
>Priority: Major
> Fix For: 4.0.0, 3.2.4
>
>
> See https://bugs.chromium.org/p/oss-fuzz/issues/detail?id=37529 on GDAL
> The backtrace of the exception that caused the memory leak was:
> {noformat}
> Catchpoint 1 (exception thrown), 0x75547672 in __cxa_throw () from
> /lib/x86_64-linux-gnu/libstdc++.so.6
> (gdb) bt
> 0 0x75547672 in __cxa_throw () from
> /lib/x86_64-linux-gnu/libstdc++.so.6
> 1 0x724447c4 in xercesc_4_0::PosixFileMgr::fileRead (this= out>, f=, byteCount=, buffer=,
> manager=0x556df730)
>at xercesc/util/FileManagers/PosixFileMgr.cpp:160
> 2 0x724e6ec2 in xercesc_4_0::XMLReader::refreshRawBuffer
> (this=0x557e49f8) at xercesc/internal/XMLReader.cpp:1891
> 3 0x724e70d4 in xercesc_4_0::XMLReader::XMLReader
> (this=0x557e49f8, pubId=, sysId=0x55750920 u"/",
> streamToAdopt=0x5574e838, from=,
>type=xercesc_4_0::XMLReader::Type_General,
> source=xercesc_4_0::XMLReader::Source_External, throwAtEnd=false,
> calculateSrcOfs=false, lowWaterMark=100,
> version=xercesc_4_0::XMLReader::XMLV1_0,
>manager=0x556df730) at xercesc/internal/XMLReader.cpp:130
> 4 0x724ced75 in xercesc_4_0::ReaderMgr::createReader
> (this=this@entry=0x557896d8, src=...,
> refFrom=refFrom@entry=xercesc_4_0::XMLReader::RefFrom_NonLiteral,
>type=type@entry=xercesc_4_0::XMLReader::Type_General,
> source=source@entry=xercesc_4_0::XMLReader::Source_External,
> calcSrcOfs=false, lowWaterMark=100) at ./xercesc/sax/InputSource.hpp:314
> 5 0x724cb0af in xercesc_4_0::IGXMLScanner::scanReset
> (this=0x55789608, src=...) at xercesc/internal/IGXMLScanner2.cpp:1286
> 6 0x724c36e9 in xercesc_4_0::IGXMLScanner::scanDocument
> (this=0x55789608, src=...) at xercesc/internal/IGXMLScanner.cpp:198
> 7 0x7250abaf in xercesc_4_0::AbstractDOMParser::parse
> (this=0x7fffc2d0, source=...) at xercesc/parsers/AbstractDOMParser.cpp:545
> 8 0x724cbdbe in xercesc_4_0::IGXMLScanner::resolveSchemaGrammar
> (this=0x55792f78, loc=0x557dd694 u"/", uri=0x55737180 u"`",
> ignoreLoadSchema=)
>at xercesc/internal/IGXMLScanner2.cpp:1895
> 0x724cce7c in xercesc_4_0::IGXMLScanner::parseSchemaLocation
> (this=0x55792f78, schemaLocationStr=,
> ignoreLoadSchema=false) at ./xercesc/framework/XMLBuffer.hpp:171
> 10 0x724cd182 in
> xercesc_4_0::IGXMLScanner::scanRawAttrListforNameSpaces
> (this=this@entry=0x55792f78, attCount=attCount@entry=9) at
> xercesc/internal/IGXMLScanner2.cpp:1649
> 11 0x724c22cb in xercesc_4_0::IGXMLScanner::scanStartTagNS
> (this=0x55792f78, gotData=@0x7fffc91f: true) at
> xercesc/internal/IGXMLScanner.cpp:2213
> 12 0x724c3522 in xercesc_4_0::IGXMLScanner::scanContent
> (this=0x55792f78) at xercesc/internal/IGXMLScanner.cpp:890
> 13 0x724c3760 in xercesc_4_0::IGXMLScanner::scanDocument
> (this=0x55792f78, src=...) at xercesc/internal/IGXMLScanner.cpp:217
> 14 0x725158e3 in xercesc_4_0::SAX2XMLReaderImpl::parse
> (this=0x55731828, source=...) at xercesc/parsers/SAX2XMLReaderImpl.cpp:409
> {noformat}
--
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] [Assigned] (XERCESC-2219) XMLReader constructor: memory leak when refreshRawBuffer() throws
[
https://issues.apache.org/jira/browse/XERCESC-2219?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Scott Cantor reassigned XERCESC-2219:
-
Assignee: Scott Cantor (was: Roger Leigh)
> XMLReader constructor: memory leak when refreshRawBuffer() throws
> -
>
> Key: XERCESC-2219
> URL: https://issues.apache.org/jira/browse/XERCESC-2219
> Project: Xerces-C++
> Issue Type: Bug
>Affects Versions: 3.2.3
>Reporter: Roger Leigh
>Assignee: Scott Cantor
>Priority: Major
> Fix For: 4.0.0, 3.2.4
>
>
> See https://bugs.chromium.org/p/oss-fuzz/issues/detail?id=37529 on GDAL
> The backtrace of the exception that caused the memory leak was:
> {noformat}
> Catchpoint 1 (exception thrown), 0x75547672 in __cxa_throw () from
> /lib/x86_64-linux-gnu/libstdc++.so.6
> (gdb) bt
> 0 0x75547672 in __cxa_throw () from
> /lib/x86_64-linux-gnu/libstdc++.so.6
> 1 0x724447c4 in xercesc_4_0::PosixFileMgr::fileRead (this= out>, f=, byteCount=, buffer=,
> manager=0x556df730)
>at xercesc/util/FileManagers/PosixFileMgr.cpp:160
> 2 0x724e6ec2 in xercesc_4_0::XMLReader::refreshRawBuffer
> (this=0x557e49f8) at xercesc/internal/XMLReader.cpp:1891
> 3 0x724e70d4 in xercesc_4_0::XMLReader::XMLReader
> (this=0x557e49f8, pubId=, sysId=0x55750920 u"/",
> streamToAdopt=0x5574e838, from=,
>type=xercesc_4_0::XMLReader::Type_General,
> source=xercesc_4_0::XMLReader::Source_External, throwAtEnd=false,
> calculateSrcOfs=false, lowWaterMark=100,
> version=xercesc_4_0::XMLReader::XMLV1_0,
>manager=0x556df730) at xercesc/internal/XMLReader.cpp:130
> 4 0x724ced75 in xercesc_4_0::ReaderMgr::createReader
> (this=this@entry=0x557896d8, src=...,
> refFrom=refFrom@entry=xercesc_4_0::XMLReader::RefFrom_NonLiteral,
>type=type@entry=xercesc_4_0::XMLReader::Type_General,
> source=source@entry=xercesc_4_0::XMLReader::Source_External,
> calcSrcOfs=false, lowWaterMark=100) at ./xercesc/sax/InputSource.hpp:314
> 5 0x724cb0af in xercesc_4_0::IGXMLScanner::scanReset
> (this=0x55789608, src=...) at xercesc/internal/IGXMLScanner2.cpp:1286
> 6 0x724c36e9 in xercesc_4_0::IGXMLScanner::scanDocument
> (this=0x55789608, src=...) at xercesc/internal/IGXMLScanner.cpp:198
> 7 0x7250abaf in xercesc_4_0::AbstractDOMParser::parse
> (this=0x7fffc2d0, source=...) at xercesc/parsers/AbstractDOMParser.cpp:545
> 8 0x724cbdbe in xercesc_4_0::IGXMLScanner::resolveSchemaGrammar
> (this=0x55792f78, loc=0x557dd694 u"/", uri=0x55737180 u"`",
> ignoreLoadSchema=)
>at xercesc/internal/IGXMLScanner2.cpp:1895
> 0x724cce7c in xercesc_4_0::IGXMLScanner::parseSchemaLocation
> (this=0x55792f78, schemaLocationStr=,
> ignoreLoadSchema=false) at ./xercesc/framework/XMLBuffer.hpp:171
> 10 0x724cd182 in
> xercesc_4_0::IGXMLScanner::scanRawAttrListforNameSpaces
> (this=this@entry=0x55792f78, attCount=attCount@entry=9) at
> xercesc/internal/IGXMLScanner2.cpp:1649
> 11 0x724c22cb in xercesc_4_0::IGXMLScanner::scanStartTagNS
> (this=0x55792f78, gotData=@0x7fffc91f: true) at
> xercesc/internal/IGXMLScanner.cpp:2213
> 12 0x724c3522 in xercesc_4_0::IGXMLScanner::scanContent
> (this=0x55792f78) at xercesc/internal/IGXMLScanner.cpp:890
> 13 0x724c3760 in xercesc_4_0::IGXMLScanner::scanDocument
> (this=0x55792f78, src=...) at xercesc/internal/IGXMLScanner.cpp:217
> 14 0x725158e3 in xercesc_4_0::SAX2XMLReaderImpl::parse
> (this=0x55731828, source=...) at xercesc/parsers/SAX2XMLReaderImpl.cpp:409
> {noformat}
--
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
[xerces-c] 02/02: Revert "Merge pull request #31 from rouault/fix_ossfuzz_37529_backport_3_2"
This is an automated email from the ASF dual-hosted git repository.
scantor pushed a commit to branch xerces-3.2
in repository https://gitbox.apache.org/repos/asf/xerces-c.git
commit 05dbb6a5fd5a8992ae249b0d2fa13729e6b8122f
Author: Scott Cantor
AuthorDate: Wed Oct 5 13:58:28 2022 -0400
Revert "Merge pull request #31 from rouault/fix_ossfuzz_37529_backport_3_2"
This reverts commit a3be9dc2060a1921157dca652524f1841d948616, reversing
changes made to 9ac2a9cb749e307b67e4622f77ff66cb9f05f584.
---
src/xercesc/internal/ReaderMgr.cpp | 6 -
src/xercesc/internal/XMLReader.cpp | 47 +-
src/xercesc/internal/XMLReader.hpp | 2 --
3 files changed, 6 insertions(+), 49 deletions(-)
diff --git a/src/xercesc/internal/ReaderMgr.cpp
b/src/xercesc/internal/ReaderMgr.cpp
index 18d859602..d14483e3c 100644
--- a/src/xercesc/internal/ReaderMgr.cpp
+++ b/src/xercesc/internal/ReaderMgr.cpp
@@ -436,12 +436,6 @@ XMLReader* ReaderMgr::createReader( const InputSource&
src
);
}
}
-catch(const XMLPlatformUtilsException&)
-{
-streamJanitor.release();
-
-throw;
-}
catch(const OutOfMemoryException&)
{
streamJanitor.release();
diff --git a/src/xercesc/internal/XMLReader.cpp
b/src/xercesc/internal/XMLReader.cpp
index 9acfad8c0..405474a02 100644
--- a/src/xercesc/internal/XMLReader.cpp
+++ b/src/xercesc/internal/XMLReader.cpp
@@ -124,16 +124,8 @@ XMLReader::XMLReader(const XMLCh* const pubId
{
setXMLVersion(version);
-try
-{
-// Do an initial load of raw bytes
-refreshRawBuffer();
-}
-catch (const XMLPlatformUtilsException&)
-{
-cleanup();
-throw;
-}
+// Do an initial load of raw bytes
+refreshRawBuffer();
// Ask the transcoding service if it supports src offset info
fSrcOfsSupported = XMLPlatformUtils::fgTransService->supportsSrcOfs();
@@ -215,16 +207,8 @@ XMLReader::XMLReader(const XMLCh* const pubId
{
setXMLVersion(version);
-try
-{
-// Do an initial load of raw bytes
-refreshRawBuffer();
-}
-catch (const XMLPlatformUtilsException&)
-{
-cleanup();
-throw;
-}
+// Do an initial load of raw bytes
+refreshRawBuffer();
// Copy the encoding string to our member
fEncodingStr = XMLString::replicate(encodingStr, fMemoryManager);
@@ -406,16 +390,8 @@ XMLReader::XMLReader(const XMLCh* const pubId
{
setXMLVersion(version);
-try
-{
-// Do an initial load of raw bytes
-refreshRawBuffer();
-}
-catch (const XMLPlatformUtilsException&)
-{
-cleanup();
-throw;
-}
+// Do an initial load of raw bytes
+refreshRawBuffer();
// Ask the transcoding service if it supports src offset info
fSrcOfsSupported = XMLPlatformUtils::fgTransService->supportsSrcOfs();
@@ -479,23 +455,12 @@ XMLReader::XMLReader(const XMLCh* const pubId
XMLReader::~XMLReader()
-{
-cleanup();
-}
-
-
-void XMLReader::cleanup()
{
fMemoryManager->deallocate(fEncodingStr);
-fEncodingStr = NULL;
fMemoryManager->deallocate(fPublicId);
-fPublicId = NULL;
fMemoryManager->deallocate(fSystemId);
-fSystemId = NULL;
delete fStream;
-fStream = NULL;
delete fTranscoder;
-fTranscoder = NULL;
}
diff --git a/src/xercesc/internal/XMLReader.hpp
b/src/xercesc/internal/XMLReader.hpp
index fbacb2685..966ca224d 100644
--- a/src/xercesc/internal/XMLReader.hpp
+++ b/src/xercesc/internal/XMLReader.hpp
@@ -253,8 +253,6 @@ private:
// ---
// Private helper methods
// ---
-void cleanup();
-
void checkForSwapped();
void doInitCharSizeChecks();
-
To unsubscribe, e-mail: c-dev-unsubscr...@xerces.apache.org
For additional commands, e-mail: c-dev-h...@xerces.apache.org
[xerces-c] 01/02: Revert "Merge pull request #29 from rouault/backport_3_2_curl_memleak_fix"
This is an automated email from the ASF dual-hosted git repository.
scantor pushed a commit to branch xerces-3.2
in repository https://gitbox.apache.org/repos/asf/xerces-c.git
commit e751104cadac7634293e54d325d6ed7c9a1ed571
Author: Scott Cantor
AuthorDate: Wed Oct 5 13:54:19 2022 -0400
Revert "Merge pull request #29 from rouault/backport_3_2_curl_memleak_fix"
This reverts commit 9ac2a9cb749e307b67e4622f77ff66cb9f05f584, reversing
changes made to 19428fbac5d0b4de89f780e485fd924482678309.
---
.../util/NetAccessors/Curl/CurlURLInputStream.cpp | 28 +-
.../util/NetAccessors/Curl/CurlURLInputStream.hpp | 2 --
2 files changed, 1 insertion(+), 29 deletions(-)
diff --git a/src/xercesc/util/NetAccessors/Curl/CurlURLInputStream.cpp
b/src/xercesc/util/NetAccessors/Curl/CurlURLInputStream.cpp
index 2980dc211..5ed659389 100644
--- a/src/xercesc/util/NetAccessors/Curl/CurlURLInputStream.cpp
+++ b/src/xercesc/util/NetAccessors/Curl/CurlURLInputStream.cpp
@@ -160,20 +160,7 @@ CurlURLInputStream::CurlURLInputStream(const XMLURL&
urlSource, const XMLNetHTTP
while(fBufferHeadPtr == fBuffer)
{
int runningHandles = 0;
-try
-{
-readMore();
-}
-catch(const MalformedURLException&)
-{
-cleanup();
-throw;
-}
-catch(const NetAccessorException&)
-{
-cleanup();
-throw;
-}
+readMore();
if(runningHandles == 0) break;
}
@@ -187,31 +174,18 @@ CurlURLInputStream::CurlURLInputStream(const XMLURL&
urlSource, const XMLNetHTTP
CurlURLInputStream::~CurlURLInputStream()
{
-cleanup();
-}
-
-
-void CurlURLInputStream::cleanup()
-{
-if (!fMulti )
-return;
-
// Remove the easy handle from the multi stack
curl_multi_remove_handle(fMulti, fEasy);
// Cleanup the easy handle
curl_easy_cleanup(fEasy);
-fEasy = NULL;
// Cleanup the multi handle
curl_multi_cleanup(fMulti);
-fMulti = NULL;
if(fContentType) fMemoryManager->deallocate(fContentType);
-fContentType = NULL;
if(fHeadersList) curl_slist_free_all(fHeadersList);
-fHeadersList = NULL;
}
diff --git a/src/xercesc/util/NetAccessors/Curl/CurlURLInputStream.hpp
b/src/xercesc/util/NetAccessors/Curl/CurlURLInputStream.hpp
index 3900d4db5..f75857b92 100644
--- a/src/xercesc/util/NetAccessors/Curl/CurlURLInputStream.hpp
+++ b/src/xercesc/util/NetAccessors/Curl/CurlURLInputStream.hpp
@@ -61,8 +61,6 @@ private :
CurlURLInputStream(const CurlURLInputStream&);
CurlURLInputStream& operator=(const CurlURLInputStream&);
-void cleanup();
-
static size_t staticWriteCallback(char *buffer,
size_t size,
size_t nitems,
-
To unsubscribe, e-mail: c-dev-unsubscr...@xerces.apache.org
For additional commands, e-mail: c-dev-h...@xerces.apache.org
[xerces-c] branch xerces-3.2 updated (cf20b46a8 -> 05dbb6a5f)
This is an automated email from the ASF dual-hosted git repository. scantor pushed a change to branch xerces-3.2 in repository https://gitbox.apache.org/repos/asf/xerces-c.git from cf20b46a8 Merge pull request #32 from rouault/fix_ossfuzz_37666 new e751104ca Revert "Merge pull request #29 from rouault/backport_3_2_curl_memleak_fix" new 05dbb6a5f Revert "Merge pull request #31 from rouault/fix_ossfuzz_37529_backport_3_2" The 2 revisions listed above as "new" are entirely new to this repository and will be described in separate emails. The revisions listed as "add" were already present in the repository and have only been added to this reference. Summary of changes: src/xercesc/internal/ReaderMgr.cpp | 6 --- src/xercesc/internal/XMLReader.cpp | 47 +++--- src/xercesc/internal/XMLReader.hpp | 2 - .../util/NetAccessors/Curl/CurlURLInputStream.cpp | 28 + .../util/NetAccessors/Curl/CurlURLInputStream.hpp | 2 - 5 files changed, 7 insertions(+), 78 deletions(-) - To unsubscribe, e-mail: c-dev-unsubscr...@xerces.apache.org For additional commands, e-mail: c-dev-h...@xerces.apache.org
[jira] [Assigned] (XERCESC-2218) CurlURLInputStream constructor memory leak
[ https://issues.apache.org/jira/browse/XERCESC-2218?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Scott Cantor reassigned XERCESC-2218: - Assignee: Scott Cantor (was: Roger Leigh) > CurlURLInputStream constructor memory leak > -- > > Key: XERCESC-2218 > URL: https://issues.apache.org/jira/browse/XERCESC-2218 > Project: Xerces-C++ > Issue Type: Bug >Affects Versions: 3.2.3 >Reporter: Roger Leigh >Assignee: Scott Cantor >Priority: Major > Fix For: 4.0.0, 3.2.4 > > > CurlURLInputStream constructor calls the readMore() method, which can > throw exceptions. In that situation, the destructor is not called, which > results in resource/memory leaks. To fix that, catch the exceptions, > manually do the cleanup and rethrow the exceptions. > Found by ossfuzz (locally) -- 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-2218) CurlURLInputStream constructor memory leak
[ https://issues.apache.org/jira/browse/XERCESC-2218?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17613093#comment-17613093 ] Scott Cantor commented on XERCESC-2218: --- I reviewed this patch and it's not applicable to the 3.2 branch, you can't add methods to a class like this without breaking the ABI in general. I will roll it back and if there's time review whether it can be done a different way. > CurlURLInputStream constructor memory leak > -- > > Key: XERCESC-2218 > URL: https://issues.apache.org/jira/browse/XERCESC-2218 > Project: Xerces-C++ > Issue Type: Bug >Affects Versions: 3.2.3 >Reporter: Roger Leigh >Assignee: Roger Leigh >Priority: Major > Fix For: 4.0.0, 3.2.4 > > > CurlURLInputStream constructor calls the readMore() method, which can > throw exceptions. In that situation, the destructor is not called, which > results in resource/memory leaks. To fix that, catch the exceptions, > manually do the cleanup and rethrow the exceptions. > Found by ossfuzz (locally) -- 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] [Closed] (XERCESC-2217) ICUTranscoder::transcodeFrom buffer overflow
[ https://issues.apache.org/jira/browse/XERCESC-2217?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Scott Cantor closed XERCESC-2217. - > ICUTranscoder::transcodeFrom buffer overflow > > > Key: XERCESC-2217 > URL: https://issues.apache.org/jira/browse/XERCESC-2217 > Project: Xerces-C++ > Issue Type: Bug >Affects Versions: 3.2.3 >Reporter: Roger Leigh >Assignee: Roger Leigh >Priority: Major > Fix For: 4.0.0, 3.2.4 > > > See https://bugs.chromium.org/p/oss-fuzz/issues/detail?id=35373 > When charsDecoded == 0, the line for (index = 0; index < charsDecoded - 1; > index++) will cause to read out of bounds of fSrcOffsets, due to unsigned > integer underflow rules. -- 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] [Resolved] (XERCESC-2217) ICUTranscoder::transcodeFrom buffer overflow
[ https://issues.apache.org/jira/browse/XERCESC-2217?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Scott Cantor resolved XERCESC-2217. --- Resolution: Fixed Verified this was applied to both branches. > ICUTranscoder::transcodeFrom buffer overflow > > > Key: XERCESC-2217 > URL: https://issues.apache.org/jira/browse/XERCESC-2217 > Project: Xerces-C++ > Issue Type: Bug >Affects Versions: 3.2.3 >Reporter: Roger Leigh >Assignee: Roger Leigh >Priority: Major > Fix For: 4.0.0, 3.2.4 > > > See https://bugs.chromium.org/p/oss-fuzz/issues/detail?id=35373 > When charsDecoded == 0, the line for (index = 0; index < charsDecoded - 1; > index++) will cause to read out of bounds of fSrcOffsets, due to unsigned > integer underflow rules. -- 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] [Closed] (XERCESC-2221) InMemMsgLoader::loadMsg(): fix memory leak when transcoding fails
[
https://issues.apache.org/jira/browse/XERCESC-2221?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Scott Cantor closed XERCESC-2221.
-
> InMemMsgLoader::loadMsg(): fix memory leak when transcoding fails
> -
>
> Key: XERCESC-2221
> URL: https://issues.apache.org/jira/browse/XERCESC-2221
> Project: Xerces-C++
> Issue Type: Bug
> Components: Utilities
>Affects Versions: 3.2.3
>Reporter: Even Rouault
>Assignee: Scott Cantor
>Priority: Minor
> Fix For: 4.0.0, 3.2.4
>
>
> Seen with the IconvGNU transcoder when parsing " The reason is that XMLString::transcode(repText2, manager) throws a
> TranscodingException
> which causes the tmp1 string to leak.
> {noformat}
> 0 0x8791409 in operator new(unsigned int)
> /src/llvm-project/compiler-rt/lib/asan/asan_new_delete.cpp:99:3
> 1 0xbd147f7 in xercesc_4_0::MemoryManagerImpl::allocate(unsigned int)
> gdal/xerces-c/src/xercesc/internal/MemoryManagerImpl.cpp:40:18
> 2 0xbe8c73e in xercesc_4_0::IconvGNULCPTranscoder::transcode(char const*,
> xercesc_4_0::MemoryManager*)
> gdal/xerces-c/src/xercesc/util/Transcoders/IconvGNU/IconvGNUTransService.cpp:870:32
> 3 0xbc22ca2 in xercesc_4_0::XMLString::transcode(char const*,
> xercesc_4_0::MemoryManager*)
> gdal/xerces-c/src/xercesc/util/XMLString.cpp:621:25
> 4 0xbe8f4ad in xercesc_4_0::InMemMsgLoader::loadMsg(unsigned int, char16_t*,
> unsigned int, char const*, char const*, char const*, char const*,
> xercesc_4_0::MemoryManager*)
> gdal/xerces-c/src/xercesc/util/MsgLoaders/InMemory/InMemMsgLoader.cpp:157:16
> 5 0xbc20175 in
> xercesc_4_0::XMLException::loadExceptText(xercesc_4_0::XMLExcepts::Codes,
> char const*, char const*, char const*, char const*)
> gdal/xerces-c/src/xercesc/util/XMLException.cpp:241:23
> 6 0xbc48bee in
> xercesc_4_0::UTFDataFormatException::UTFDataFormatException(char const*,
> unsigned long long, xercesc_4_0::XMLExcepts::Codes, char const*, char const*,
> char const*, char const*, xercesc_4_0::MemoryManager*)
> gdal/xerces-c/src/xercesc/util/UTFDataFormatException.hpp:31:1
> 7 0xbc4824e in xercesc_4_0::XMLUTF8Transcoder::transcodeFrom(unsigned char
> const*, unsigned int, char16_t*, unsigned int, unsigned int&, unsigned char*)
> gdal/xerces-c/src/xercesc/util/XMLUTF8Transcoder.cpp:182:13
> 8 0xbd27d7e in xercesc_4_0::XMLReader::xcodeMoreChars(char16_t*, unsigned
> char*, unsigned int) gdal/xerces-c/src/xercesc/internal/XMLReader.cpp:1926:34
> 9 0xbd271dd in xercesc_4_0::XMLReader::refreshCharBuffer()
> gdal/xerces-c/src/xercesc/internal/XMLReader.cpp:571:19
> 10 0xbd15c63 in xercesc_4_0::XMLReader::peekNextChar(char16_t&)
> gdal/xerces-c/src/xercesc/internal/XMLReader.hpp:767:14
> 11 0xbd15aaf in xercesc_4_0::ReaderMgr::peekNextChar()
> gdal/xerces-c/src/xercesc/internal/ReaderMgr.cpp:158:21
> 12 0xbd328da in xercesc_4_0::XMLScanner::scanProlog()
> gdal/xerces-c/src/xercesc/internal/XMLScanner.cpp:1241:45
> 13 0xbd31ef4 in xercesc_4_0::XMLScanner::scanFirst(xercesc_4_0::InputSource
> const&, xercesc_4_0::XMLPScanToken&)
> gdal/xerces-c/src/xercesc/internal/XMLScanner.cpp:549:9
> 14 0xbdadcff in
> xercesc_4_0::SAX2XMLReaderImpl::parseFirst(xercesc_4_0::InputSource const&,
> xercesc_4_0::XMLPScanToken&)
> gdal/xerces-c/src/xercesc/parsers/SAX2XMLReaderImpl.cpp:500:22 {noformat}
>
--
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] [Resolved] (XERCESC-2221) InMemMsgLoader::loadMsg(): fix memory leak when transcoding fails
[
https://issues.apache.org/jira/browse/XERCESC-2221?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Scott Cantor resolved XERCESC-2221.
---
Resolution: Fixed
Cherry-picked the master commit back to the 3.2 branch, closing.
> InMemMsgLoader::loadMsg(): fix memory leak when transcoding fails
> -
>
> Key: XERCESC-2221
> URL: https://issues.apache.org/jira/browse/XERCESC-2221
> Project: Xerces-C++
> Issue Type: Bug
> Components: Utilities
>Affects Versions: 3.2.3
>Reporter: Even Rouault
>Assignee: Scott Cantor
>Priority: Major
> Fix For: 4.0.0, 3.2.4
>
>
> Seen with the IconvGNU transcoder when parsing " The reason is that XMLString::transcode(repText2, manager) throws a
> TranscodingException
> which causes the tmp1 string to leak.
> {noformat}
> 0 0x8791409 in operator new(unsigned int)
> /src/llvm-project/compiler-rt/lib/asan/asan_new_delete.cpp:99:3
> 1 0xbd147f7 in xercesc_4_0::MemoryManagerImpl::allocate(unsigned int)
> gdal/xerces-c/src/xercesc/internal/MemoryManagerImpl.cpp:40:18
> 2 0xbe8c73e in xercesc_4_0::IconvGNULCPTranscoder::transcode(char const*,
> xercesc_4_0::MemoryManager*)
> gdal/xerces-c/src/xercesc/util/Transcoders/IconvGNU/IconvGNUTransService.cpp:870:32
> 3 0xbc22ca2 in xercesc_4_0::XMLString::transcode(char const*,
> xercesc_4_0::MemoryManager*)
> gdal/xerces-c/src/xercesc/util/XMLString.cpp:621:25
> 4 0xbe8f4ad in xercesc_4_0::InMemMsgLoader::loadMsg(unsigned int, char16_t*,
> unsigned int, char const*, char const*, char const*, char const*,
> xercesc_4_0::MemoryManager*)
> gdal/xerces-c/src/xercesc/util/MsgLoaders/InMemory/InMemMsgLoader.cpp:157:16
> 5 0xbc20175 in
> xercesc_4_0::XMLException::loadExceptText(xercesc_4_0::XMLExcepts::Codes,
> char const*, char const*, char const*, char const*)
> gdal/xerces-c/src/xercesc/util/XMLException.cpp:241:23
> 6 0xbc48bee in
> xercesc_4_0::UTFDataFormatException::UTFDataFormatException(char const*,
> unsigned long long, xercesc_4_0::XMLExcepts::Codes, char const*, char const*,
> char const*, char const*, xercesc_4_0::MemoryManager*)
> gdal/xerces-c/src/xercesc/util/UTFDataFormatException.hpp:31:1
> 7 0xbc4824e in xercesc_4_0::XMLUTF8Transcoder::transcodeFrom(unsigned char
> const*, unsigned int, char16_t*, unsigned int, unsigned int&, unsigned char*)
> gdal/xerces-c/src/xercesc/util/XMLUTF8Transcoder.cpp:182:13
> 8 0xbd27d7e in xercesc_4_0::XMLReader::xcodeMoreChars(char16_t*, unsigned
> char*, unsigned int) gdal/xerces-c/src/xercesc/internal/XMLReader.cpp:1926:34
> 9 0xbd271dd in xercesc_4_0::XMLReader::refreshCharBuffer()
> gdal/xerces-c/src/xercesc/internal/XMLReader.cpp:571:19
> 10 0xbd15c63 in xercesc_4_0::XMLReader::peekNextChar(char16_t&)
> gdal/xerces-c/src/xercesc/internal/XMLReader.hpp:767:14
> 11 0xbd15aaf in xercesc_4_0::ReaderMgr::peekNextChar()
> gdal/xerces-c/src/xercesc/internal/ReaderMgr.cpp:158:21
> 12 0xbd328da in xercesc_4_0::XMLScanner::scanProlog()
> gdal/xerces-c/src/xercesc/internal/XMLScanner.cpp:1241:45
> 13 0xbd31ef4 in xercesc_4_0::XMLScanner::scanFirst(xercesc_4_0::InputSource
> const&, xercesc_4_0::XMLPScanToken&)
> gdal/xerces-c/src/xercesc/internal/XMLScanner.cpp:549:9
> 14 0xbdadcff in
> xercesc_4_0::SAX2XMLReaderImpl::parseFirst(xercesc_4_0::InputSource const&,
> xercesc_4_0::XMLPScanToken&)
> gdal/xerces-c/src/xercesc/parsers/SAX2XMLReaderImpl.cpp:500:22 {noformat}
>
--
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-2221) InMemMsgLoader::loadMsg(): fix memory leak when transcoding fails
[
https://issues.apache.org/jira/browse/XERCESC-2221?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Scott Cantor updated XERCESC-2221:
--
Priority: Minor (was: Major)
> InMemMsgLoader::loadMsg(): fix memory leak when transcoding fails
> -
>
> Key: XERCESC-2221
> URL: https://issues.apache.org/jira/browse/XERCESC-2221
> Project: Xerces-C++
> Issue Type: Bug
> Components: Utilities
>Affects Versions: 3.2.3
>Reporter: Even Rouault
>Assignee: Scott Cantor
>Priority: Minor
> Fix For: 4.0.0, 3.2.4
>
>
> Seen with the IconvGNU transcoder when parsing " The reason is that XMLString::transcode(repText2, manager) throws a
> TranscodingException
> which causes the tmp1 string to leak.
> {noformat}
> 0 0x8791409 in operator new(unsigned int)
> /src/llvm-project/compiler-rt/lib/asan/asan_new_delete.cpp:99:3
> 1 0xbd147f7 in xercesc_4_0::MemoryManagerImpl::allocate(unsigned int)
> gdal/xerces-c/src/xercesc/internal/MemoryManagerImpl.cpp:40:18
> 2 0xbe8c73e in xercesc_4_0::IconvGNULCPTranscoder::transcode(char const*,
> xercesc_4_0::MemoryManager*)
> gdal/xerces-c/src/xercesc/util/Transcoders/IconvGNU/IconvGNUTransService.cpp:870:32
> 3 0xbc22ca2 in xercesc_4_0::XMLString::transcode(char const*,
> xercesc_4_0::MemoryManager*)
> gdal/xerces-c/src/xercesc/util/XMLString.cpp:621:25
> 4 0xbe8f4ad in xercesc_4_0::InMemMsgLoader::loadMsg(unsigned int, char16_t*,
> unsigned int, char const*, char const*, char const*, char const*,
> xercesc_4_0::MemoryManager*)
> gdal/xerces-c/src/xercesc/util/MsgLoaders/InMemory/InMemMsgLoader.cpp:157:16
> 5 0xbc20175 in
> xercesc_4_0::XMLException::loadExceptText(xercesc_4_0::XMLExcepts::Codes,
> char const*, char const*, char const*, char const*)
> gdal/xerces-c/src/xercesc/util/XMLException.cpp:241:23
> 6 0xbc48bee in
> xercesc_4_0::UTFDataFormatException::UTFDataFormatException(char const*,
> unsigned long long, xercesc_4_0::XMLExcepts::Codes, char const*, char const*,
> char const*, char const*, xercesc_4_0::MemoryManager*)
> gdal/xerces-c/src/xercesc/util/UTFDataFormatException.hpp:31:1
> 7 0xbc4824e in xercesc_4_0::XMLUTF8Transcoder::transcodeFrom(unsigned char
> const*, unsigned int, char16_t*, unsigned int, unsigned int&, unsigned char*)
> gdal/xerces-c/src/xercesc/util/XMLUTF8Transcoder.cpp:182:13
> 8 0xbd27d7e in xercesc_4_0::XMLReader::xcodeMoreChars(char16_t*, unsigned
> char*, unsigned int) gdal/xerces-c/src/xercesc/internal/XMLReader.cpp:1926:34
> 9 0xbd271dd in xercesc_4_0::XMLReader::refreshCharBuffer()
> gdal/xerces-c/src/xercesc/internal/XMLReader.cpp:571:19
> 10 0xbd15c63 in xercesc_4_0::XMLReader::peekNextChar(char16_t&)
> gdal/xerces-c/src/xercesc/internal/XMLReader.hpp:767:14
> 11 0xbd15aaf in xercesc_4_0::ReaderMgr::peekNextChar()
> gdal/xerces-c/src/xercesc/internal/ReaderMgr.cpp:158:21
> 12 0xbd328da in xercesc_4_0::XMLScanner::scanProlog()
> gdal/xerces-c/src/xercesc/internal/XMLScanner.cpp:1241:45
> 13 0xbd31ef4 in xercesc_4_0::XMLScanner::scanFirst(xercesc_4_0::InputSource
> const&, xercesc_4_0::XMLPScanToken&)
> gdal/xerces-c/src/xercesc/internal/XMLScanner.cpp:549:9
> 14 0xbdadcff in
> xercesc_4_0::SAX2XMLReaderImpl::parseFirst(xercesc_4_0::InputSource const&,
> xercesc_4_0::XMLPScanToken&)
> gdal/xerces-c/src/xercesc/parsers/SAX2XMLReaderImpl.cpp:500:22 {noformat}
>
--
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-2221) InMemMsgLoader::loadMsg(): fix memory leak when transcoding fails
[
https://issues.apache.org/jira/browse/XERCESC-2221?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Scott Cantor updated XERCESC-2221:
--
Fix Version/s: 4.0.0
> InMemMsgLoader::loadMsg(): fix memory leak when transcoding fails
> -
>
> Key: XERCESC-2221
> URL: https://issues.apache.org/jira/browse/XERCESC-2221
> Project: Xerces-C++
> Issue Type: Bug
> Components: Utilities
>Affects Versions: 3.2.3
>Reporter: Even Rouault
>Assignee: Scott Cantor
>Priority: Major
> Fix For: 4.0.0, 3.2.4
>
>
> Seen with the IconvGNU transcoder when parsing " The reason is that XMLString::transcode(repText2, manager) throws a
> TranscodingException
> which causes the tmp1 string to leak.
> {noformat}
> 0 0x8791409 in operator new(unsigned int)
> /src/llvm-project/compiler-rt/lib/asan/asan_new_delete.cpp:99:3
> 1 0xbd147f7 in xercesc_4_0::MemoryManagerImpl::allocate(unsigned int)
> gdal/xerces-c/src/xercesc/internal/MemoryManagerImpl.cpp:40:18
> 2 0xbe8c73e in xercesc_4_0::IconvGNULCPTranscoder::transcode(char const*,
> xercesc_4_0::MemoryManager*)
> gdal/xerces-c/src/xercesc/util/Transcoders/IconvGNU/IconvGNUTransService.cpp:870:32
> 3 0xbc22ca2 in xercesc_4_0::XMLString::transcode(char const*,
> xercesc_4_0::MemoryManager*)
> gdal/xerces-c/src/xercesc/util/XMLString.cpp:621:25
> 4 0xbe8f4ad in xercesc_4_0::InMemMsgLoader::loadMsg(unsigned int, char16_t*,
> unsigned int, char const*, char const*, char const*, char const*,
> xercesc_4_0::MemoryManager*)
> gdal/xerces-c/src/xercesc/util/MsgLoaders/InMemory/InMemMsgLoader.cpp:157:16
> 5 0xbc20175 in
> xercesc_4_0::XMLException::loadExceptText(xercesc_4_0::XMLExcepts::Codes,
> char const*, char const*, char const*, char const*)
> gdal/xerces-c/src/xercesc/util/XMLException.cpp:241:23
> 6 0xbc48bee in
> xercesc_4_0::UTFDataFormatException::UTFDataFormatException(char const*,
> unsigned long long, xercesc_4_0::XMLExcepts::Codes, char const*, char const*,
> char const*, char const*, xercesc_4_0::MemoryManager*)
> gdal/xerces-c/src/xercesc/util/UTFDataFormatException.hpp:31:1
> 7 0xbc4824e in xercesc_4_0::XMLUTF8Transcoder::transcodeFrom(unsigned char
> const*, unsigned int, char16_t*, unsigned int, unsigned int&, unsigned char*)
> gdal/xerces-c/src/xercesc/util/XMLUTF8Transcoder.cpp:182:13
> 8 0xbd27d7e in xercesc_4_0::XMLReader::xcodeMoreChars(char16_t*, unsigned
> char*, unsigned int) gdal/xerces-c/src/xercesc/internal/XMLReader.cpp:1926:34
> 9 0xbd271dd in xercesc_4_0::XMLReader::refreshCharBuffer()
> gdal/xerces-c/src/xercesc/internal/XMLReader.cpp:571:19
> 10 0xbd15c63 in xercesc_4_0::XMLReader::peekNextChar(char16_t&)
> gdal/xerces-c/src/xercesc/internal/XMLReader.hpp:767:14
> 11 0xbd15aaf in xercesc_4_0::ReaderMgr::peekNextChar()
> gdal/xerces-c/src/xercesc/internal/ReaderMgr.cpp:158:21
> 12 0xbd328da in xercesc_4_0::XMLScanner::scanProlog()
> gdal/xerces-c/src/xercesc/internal/XMLScanner.cpp:1241:45
> 13 0xbd31ef4 in xercesc_4_0::XMLScanner::scanFirst(xercesc_4_0::InputSource
> const&, xercesc_4_0::XMLPScanToken&)
> gdal/xerces-c/src/xercesc/internal/XMLScanner.cpp:549:9
> 14 0xbdadcff in
> xercesc_4_0::SAX2XMLReaderImpl::parseFirst(xercesc_4_0::InputSource const&,
> xercesc_4_0::XMLPScanToken&)
> gdal/xerces-c/src/xercesc/parsers/SAX2XMLReaderImpl.cpp:500:22 {noformat}
>
--
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
[xerces-c] 01/02: Update version.
This is an automated email from the ASF dual-hosted git repository. scantor pushed a commit to branch xerces-3.2 in repository https://gitbox.apache.org/repos/asf/xerces-c.git commit 0ee7c65ca390942dc17806d0decaaa5e8ed1534e Author: Scott Cantor AuthorDate: Wed Oct 5 12:45:50 2022 -0400 Update version. --- configure.ac | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/configure.ac b/configure.ac index 1a38ec8fd..6e1319d1a 100644 --- a/configure.ac +++ b/configure.ac @@ -24,7 +24,7 @@ # AC_PREREQ(2.60) -AC_INIT([xerces-c],[3.2.3]) +AC_INIT([xerces-c],[3.2.4]) INTERFACE_VERSION=3.2 GRAMMAR_SERIALIZATION_LEVEL=7 - To unsubscribe, e-mail: c-dev-unsubscr...@xerces.apache.org For additional commands, e-mail: c-dev-h...@xerces.apache.org
[xerces-c] 02/02: Merge pull request #32 from rouault/fix_ossfuzz_37666
This is an automated email from the ASF dual-hosted git repository.
scantor pushed a commit to branch xerces-3.2
in repository https://gitbox.apache.org/repos/asf/xerces-c.git
commit cf20b46a842a05c597146ad48c2ccabfd106f98b
Author: Roger Leigh
AuthorDate: Thu Sep 9 08:38:15 2021 +0100
Merge pull request #32 from rouault/fix_ossfuzz_37666
XERCESC-2221: InMemMsgLoader::loadMsg(): fix memory leak when transcoding
fails.
---
.../util/MsgLoaders/InMemory/InMemMsgLoader.cpp| 31 --
1 file changed, 23 insertions(+), 8 deletions(-)
diff --git a/src/xercesc/util/MsgLoaders/InMemory/InMemMsgLoader.cpp
b/src/xercesc/util/MsgLoaders/InMemory/InMemMsgLoader.cpp
index d95a13685..0e0336c60 100644
--- a/src/xercesc/util/MsgLoaders/InMemory/InMemMsgLoader.cpp
+++ b/src/xercesc/util/MsgLoaders/InMemory/InMemMsgLoader.cpp
@@ -25,6 +25,7 @@
// ---
#include
#include
+#include
#include
#include
#include
@@ -153,14 +154,28 @@ bool InMemMsgLoader::loadMsg(const
XMLMsgLoader::XMLMsgId msgToLoad
XMLCh* tmp4 = 0;
bool bRet = false;
-if (repText1)
-tmp1 = XMLString::transcode(repText1, manager);
-if (repText2)
-tmp2 = XMLString::transcode(repText2, manager);
-if (repText3)
-tmp3 = XMLString::transcode(repText3, manager);
-if (repText4)
-tmp4 = XMLString::transcode(repText4, manager);
+try
+{
+if (repText1)
+tmp1 = XMLString::transcode(repText1, manager);
+if (repText2)
+tmp2 = XMLString::transcode(repText2, manager);
+if (repText3)
+tmp3 = XMLString::transcode(repText3, manager);
+if (repText4)
+tmp4 = XMLString::transcode(repText4, manager);
+}
+catch( const TranscodingException& )
+{
+if (tmp1)
+manager->deallocate(tmp1);
+if (tmp2)
+manager->deallocate(tmp2);
+if (tmp3)
+manager->deallocate(tmp3);
+// Note: tmp4 cannot leak
+throw;
+}
bRet = loadMsg(msgToLoad, toFill, maxChars, tmp1, tmp2, tmp3, tmp4,
manager);
-
To unsubscribe, e-mail: c-dev-unsubscr...@xerces.apache.org
For additional commands, e-mail: c-dev-h...@xerces.apache.org
[xerces-c] branch xerces-3.2 updated (fb8e5881a -> cf20b46a8)
This is an automated email from the ASF dual-hosted git repository. scantor pushed a change to branch xerces-3.2 in repository https://gitbox.apache.org/repos/asf/xerces-c.git from fb8e5881a XERCESC-2242 - Non-default curl location breaks autoconf link detection new 0ee7c65ca Update version. new cf20b46a8 Merge pull request #32 from rouault/fix_ossfuzz_37666 The 2 revisions listed above as "new" are entirely new to this repository and will be described in separate emails. The revisions listed as "add" were already present in the repository and have only been added to this reference. Summary of changes: configure.ac | 2 +- .../util/MsgLoaders/InMemory/InMemMsgLoader.cpp| 31 -- 2 files changed, 24 insertions(+), 9 deletions(-) - To unsubscribe, e-mail: c-dev-unsubscr...@xerces.apache.org For additional commands, e-mail: c-dev-h...@xerces.apache.org
[jira] [Commented] (XERCESC-2237) NetAccessors do not work
[ https://issues.apache.org/jira/browse/XERCESC-2237?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17613076#comment-17613076 ] Scott Cantor commented on XERCESC-2237: --- Well, I do indeed see it hanging. In the case of curl, it's stuck in the select() call waiting for data inside the readMore method. My project uses its own variant of the Curl accessor that we use via customized entity resolution code to give us more control so I have custom code that I know works, but I don't have any experience using the built-in ones. They do seem to be non-functional. Before I do a release I'll run a try on Windows since I can debug more easily there and I'll see if I can spot anything obvious, and eyeball the code a bit, but realistically I doubt I can do much. I will do some more testing on more controlled sources of files though, it's possible something is up with the W3C site though I doubt that's the problem. > NetAccessors do not work > > > Key: XERCESC-2237 > URL: https://issues.apache.org/jira/browse/XERCESC-2237 > Project: Xerces-C++ > Issue Type: Bug > Components: Utilities >Affects Versions: 3.0.1, 3.1.0, 3.1.1, 3.1.2, 3.2.0, 3.1.3, 3.1.4, 3.2.1, > 3.2.2, 3.2.3 > Environment: Mainly Linux, but could reproduce the issue on Windows > too. >Reporter: Guillaume BOTTEX >Assignee: Scott Cantor >Priority: Blocker > Fix For: 3.2.4 > > Attachments: test-1.xhtml > > > Hello, > We are using xerces in our project to parse XHTML files. > However, we noticed that none of the NetAccessors (Socket, Curl, WinSock, > could not try on MacOS) are working in our case, and are freezing our > application. > You can reproduce the issue by using the attached sample XHTML file, and use > it as input of the xerces "PParse" sample. -- 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] [Resolved] (XERCESC-2242) Non-default curl location breaks autoconf link detection
[ https://issues.apache.org/jira/browse/XERCESC-2242?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Scott Cantor resolved XERCESC-2242. --- Resolution: Fixed > Non-default curl location breaks autoconf link detection > > > Key: XERCESC-2242 > URL: https://issues.apache.org/jira/browse/XERCESC-2242 > Project: Xerces-C++ > Issue Type: Bug > Components: Build >Affects Versions: 3.2.3 >Reporter: Scott Cantor >Assignee: Scott Cantor >Priority: Major > Fix For: 3.2.4 > > -- 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
[xerces-c] branch xerces-3.2 updated: XERCESC-2242 - Non-default curl location breaks autoconf link detection
This is an automated email from the ASF dual-hosted git repository. scantor pushed a commit to branch xerces-3.2 in repository https://gitbox.apache.org/repos/asf/xerces-c.git The following commit(s) were added to refs/heads/xerces-3.2 by this push: new fb8e5881a XERCESC-2242 - Non-default curl location breaks autoconf link detection fb8e5881a is described below commit fb8e5881ae243975b6f941117c7374b6845c3446 Author: Scott Cantor AuthorDate: Wed Oct 5 12:44:56 2022 -0400 XERCESC-2242 - Non-default curl location breaks autoconf link detection https://issues.apache.org/jira/browse/XERCESC-2242 --- m4/xerces_curl_prefix.m4 | 2 ++ 1 file changed, 2 insertions(+) diff --git a/m4/xerces_curl_prefix.m4 b/m4/xerces_curl_prefix.m4 index fec4418a7..d1d015ca8 100644 --- a/m4/xerces_curl_prefix.m4 +++ b/m4/xerces_curl_prefix.m4 @@ -66,6 +66,7 @@ AC_DEFUN([XERCES_CURL_PREFIX], orig_libs=$LIBS LIBS="$curl_libs $LIBS" +CPPFLAGS="$curl_flags $CPPFLAGS" AC_LINK_IFELSE( [AC_LANG_SOURCE([ @@ -82,6 +83,7 @@ AC_DEFUN([XERCES_CURL_PREFIX], [], [xerces_cv_curl_present=no]) LIBS=$orig_libs +CPPFLAGS=$orig_cppflags if test x"$xerces_cv_curl_present" != x"no"; then AC_MSG_RESULT([yes]) - To unsubscribe, e-mail: c-dev-unsubscr...@xerces.apache.org For additional commands, e-mail: c-dev-h...@xerces.apache.org
[jira] [Assigned] (XERCESC-2242) Non-default curl location breaks autoconf link detection
[ https://issues.apache.org/jira/browse/XERCESC-2242?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Scott Cantor reassigned XERCESC-2242: - Assignee: Scott Cantor > Non-default curl location breaks autoconf link detection > > > Key: XERCESC-2242 > URL: https://issues.apache.org/jira/browse/XERCESC-2242 > Project: Xerces-C++ > Issue Type: Bug > Components: Build >Affects Versions: 3.2.3 >Reporter: Scott Cantor >Assignee: Scott Cantor >Priority: Major > Fix For: 3.2.4 > > -- 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] [Created] (XERCESC-2242) Non-default curl location breaks autoconf link detection
Scott Cantor created XERCESC-2242: - Summary: Non-default curl location breaks autoconf link detection Key: XERCESC-2242 URL: https://issues.apache.org/jira/browse/XERCESC-2242 Project: Xerces-C++ Issue Type: Bug Components: Build Affects Versions: 3.2.3 Reporter: Scott Cantor Fix For: 3.2.4 -- 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] [Resolved] (XERCESC-2213) Not able to build XERCESS 3.2.3 on MAC for arm64 configuration
[ https://issues.apache.org/jira/browse/XERCESC-2213?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Scott Cantor resolved XERCESC-2213. --- Resolution: Invalid > Not able to build XERCESS 3.2.3 on MAC for arm64 configuration > -- > > Key: XERCESC-2213 > URL: https://issues.apache.org/jira/browse/XERCESC-2213 > Project: Xerces-C++ > Issue Type: Bug > Components: SAX/SAX2 >Affects Versions: 3.2.3 > Environment: MAC 10.15 >Reporter: Ratan Kumar Burnwal >Priority: Major > > I am trying to build terces 3.2.3 for ARM64 configuration on MAC 10.15 using > XCODE 12.2 but it fails with error that ** > *This header is for x86 only* > This is coming from Cupid.h > > can Xerces-c 3.2,3 build on MAC for *ARM64 configuration?* -- 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] [Closed] (XERCESC-2213) Not able to build XERCESS 3.2.3 on MAC for arm64 configuration
[ https://issues.apache.org/jira/browse/XERCESC-2213?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Scott Cantor closed XERCESC-2213. - > Not able to build XERCESS 3.2.3 on MAC for arm64 configuration > -- > > Key: XERCESC-2213 > URL: https://issues.apache.org/jira/browse/XERCESC-2213 > Project: Xerces-C++ > Issue Type: Bug > Components: SAX/SAX2 >Affects Versions: 3.2.3 > Environment: MAC 10.15 >Reporter: Ratan Kumar Burnwal >Priority: Major > > I am trying to build terces 3.2.3 for ARM64 configuration on MAC 10.15 using > XCODE 12.2 but it fails with error that ** > *This header is for x86 only* > This is coming from Cupid.h > > can Xerces-c 3.2,3 build on MAC for *ARM64 configuration?* -- 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] [Assigned] (XERCESC-2213) Not able to build XERCESS 3.2.3 on MAC for arm64 configuration
[ https://issues.apache.org/jira/browse/XERCESC-2213?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Scott Cantor reassigned XERCESC-2213: - Assignee: (was: Scott Cantor) > Not able to build XERCESS 3.2.3 on MAC for arm64 configuration > -- > > Key: XERCESC-2213 > URL: https://issues.apache.org/jira/browse/XERCESC-2213 > Project: Xerces-C++ > Issue Type: Bug > Components: SAX/SAX2 >Affects Versions: 3.2.3 > Environment: MAC 10.15 >Reporter: Ratan Kumar Burnwal >Priority: Major > Fix For: 3.2.4 > > > I am trying to build terces 3.2.3 for ARM64 configuration on MAC 10.15 using > XCODE 12.2 but it fails with error that ** > *This header is for x86 only* > This is coming from Cupid.h > > can Xerces-c 3.2,3 build on MAC for *ARM64 configuration?* -- 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-2213) Not able to build XERCESS 3.2.3 on MAC for arm64 configuration
[ https://issues.apache.org/jira/browse/XERCESC-2213?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Scott Cantor updated XERCESC-2213: -- Fix Version/s: (was: 3.2.4) > Not able to build XERCESS 3.2.3 on MAC for arm64 configuration > -- > > Key: XERCESC-2213 > URL: https://issues.apache.org/jira/browse/XERCESC-2213 > Project: Xerces-C++ > Issue Type: Bug > Components: SAX/SAX2 >Affects Versions: 3.2.3 > Environment: MAC 10.15 >Reporter: Ratan Kumar Burnwal >Priority: Major > > I am trying to build terces 3.2.3 for ARM64 configuration on MAC 10.15 using > XCODE 12.2 but it fails with error that ** > *This header is for x86 only* > This is coming from Cupid.h > > can Xerces-c 3.2,3 build on MAC for *ARM64 configuration?* -- 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] [Reopened] (XERCESC-2213) Not able to build XERCESS 3.2.3 on MAC for arm64 configuration
[ https://issues.apache.org/jira/browse/XERCESC-2213?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Scott Cantor reopened XERCESC-2213: --- Reopening to adjust issue metadata. > Not able to build XERCESS 3.2.3 on MAC for arm64 configuration > -- > > Key: XERCESC-2213 > URL: https://issues.apache.org/jira/browse/XERCESC-2213 > Project: Xerces-C++ > Issue Type: Bug > Components: SAX/SAX2 >Affects Versions: 3.2.3 > Environment: MAC 10.15 >Reporter: Ratan Kumar Burnwal >Assignee: Scott Cantor >Priority: Major > Fix For: 3.2.4 > > > I am trying to build terces 3.2.3 for ARM64 configuration on MAC 10.15 using > XCODE 12.2 but it fails with error that ** > *This header is for x86 only* > This is coming from Cupid.h > > can Xerces-c 3.2,3 build on MAC for *ARM64 configuration?* -- 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-2241) Integer overflows in DFAContentModel class
[ https://issues.apache.org/jira/browse/XERCESC-2241?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Scott Cantor updated XERCESC-2241: -- Affects Version/s: 3.2.3 > Integer overflows in DFAContentModel class > -- > > Key: XERCESC-2241 > URL: https://issues.apache.org/jira/browse/XERCESC-2241 > Project: Xerces-C++ > Issue Type: Bug > Components: Validating Parser (XML Schema) >Affects Versions: 3.2.3 >Reporter: Even Rouault >Assignee: Scott Cantor >Priority: Major > Fix For: 3.2.4 > > > On .xsd files like the following ones (generated by ossfuzz, so broken), > integer overflows can happen in DFAContentModel::countLeafNodes() and > DFAContentModel::buildDFA() which can later cause out-of-bounds access. > Found in [https://bugs.chromium.org/p/oss-fuzz/issues/detail?id=52025] > > ``` > http://www.w3.org/2001/XMLSchema; > xmlns:myns="http://myns; > targetNamespace="http://myns; > elementFormDefault="qualified" attributeFormDefault="unqualified"> > > > > > > > > > > > > > > ame="x" type="xs:int" maxOccurs="1"/> > > > > > > > ``` -- 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-2241) Integer overflows in DFAContentModel class
[ https://issues.apache.org/jira/browse/XERCESC-2241?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Scott Cantor updated XERCESC-2241: -- Fix Version/s: 3.2.4 > Integer overflows in DFAContentModel class > -- > > Key: XERCESC-2241 > URL: https://issues.apache.org/jira/browse/XERCESC-2241 > Project: Xerces-C++ > Issue Type: Bug > Components: Validating Parser (XML Schema) >Reporter: Even Rouault >Assignee: Scott Cantor >Priority: Major > Fix For: 3.2.4 > > > On .xsd files like the following ones (generated by ossfuzz, so broken), > integer overflows can happen in DFAContentModel::countLeafNodes() and > DFAContentModel::buildDFA() which can later cause out-of-bounds access. > Found in [https://bugs.chromium.org/p/oss-fuzz/issues/detail?id=52025] > > ``` > http://www.w3.org/2001/XMLSchema; > xmlns:myns="http://myns; > targetNamespace="http://myns; > elementFormDefault="qualified" attributeFormDefault="unqualified"> > > > > > > > > > > > > > > ame="x" type="xs:int" maxOccurs="1"/> > > > > > > > ``` -- 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] [Assigned] (XERCESC-2241) Integer overflows in DFAContentModel class
[ https://issues.apache.org/jira/browse/XERCESC-2241?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Scott Cantor reassigned XERCESC-2241: - Assignee: Scott Cantor > Integer overflows in DFAContentModel class > -- > > Key: XERCESC-2241 > URL: https://issues.apache.org/jira/browse/XERCESC-2241 > Project: Xerces-C++ > Issue Type: Bug > Components: Validating Parser (XML Schema) >Reporter: Even Rouault >Assignee: Scott Cantor >Priority: Major > > On .xsd files like the following ones (generated by ossfuzz, so broken), > integer overflows can happen in DFAContentModel::countLeafNodes() and > DFAContentModel::buildDFA() which can later cause out-of-bounds access. > Found in [https://bugs.chromium.org/p/oss-fuzz/issues/detail?id=52025] > > ``` > http://www.w3.org/2001/XMLSchema; > xmlns:myns="http://myns; > targetNamespace="http://myns; > elementFormDefault="qualified" attributeFormDefault="unqualified"> > > > > > > > > > > > > > > ame="x" type="xs:int" maxOccurs="1"/> > > > > > > > ``` -- 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-2240) Junk characters (including null) allowed in XML declaration
[ https://issues.apache.org/jira/browse/XERCESC-2240?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17613049#comment-17613049 ] Scott Cantor commented on XERCESC-2240: --- Unless somebody who knows the code better can propose a patch I definitely don't see much that I could do about this. > Junk characters (including null) allowed in XML declaration > --- > > Key: XERCESC-2240 > URL: https://issues.apache.org/jira/browse/XERCESC-2240 > Project: Xerces-C++ > Issue Type: Bug > Components: Non-Validating Parser >Affects Versions: 3.2.3 > Environment: Linux >Reporter: Benjamin Fritz >Priority: Minor > Attachments: basic_bad_bytes.xml, basic_bad_bytes2.xml > > > In a library we've written using Xerces-C++ to validate XML files against a > given XSD, we have discovered that the XercesDOMParser::parse() function does > not record any errors if the XML declaration at the beginning of an XML > document contains "junk" characters, including control characters (^K) or > null bytes. The null control character specifically should be invalid in any > XML document. I.e. the following XML file (attaching as basic_bad_bytes.xml) > parses without error, but it should not: > > > > > > The following XML (attaching as basic_bad_bytes2.xml) correctly reports an > error: > > > > > > This is similar to XERCESC-1701, where the end of the document after the root > element was found to allow "junk" characters during parsing. -- 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-2239) When XMLUni::fgDOMWRTSplitCdataSections is true (the default), invalid XML characters are allowed by DOMWriter
[
https://issues.apache.org/jira/browse/XERCESC-2239?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17613048#comment-17613048
]
Scott Cantor commented on XERCESC-2239:
---
I'll at least take a look but I doubt I would have the confidence to make a fix
to this.
> When XMLUni::fgDOMWRTSplitCdataSections is true (the default), invalid XML
> characters are allowed by DOMWriter
> --
>
> Key: XERCESC-2239
> URL: https://issues.apache.org/jira/browse/XERCESC-2239
> Project: Xerces-C++
> Issue Type: Bug
> Components: DOM
>Affects Versions: 3.2.0
> Environment: Operating System: All
> Platform: All
>Reporter: David Leffingwell
>Priority: Major
> Fix For: 3.2.4
>
>
> // Create a Document with a CDATA section that contains an invalid XML
> character (e.g. 0x1b).
> // This should fail when serializing the Document, but it does not when
> XMLUni::fgDOMWRTSplitCdataSections is true.
> struct XercesDeleter
> {
> template
> void operator()(T* data) const
> {
> if (data) { data->release(); };
> }
> };
> typedef std::unique_ptr
> DOMWriterPtr;
> typedef std::unique_ptr
> DOMDocumentPtr;
> XMLPlatformUtils::Initialize();
> DOMImplementation* impl =
> DOMImplementationRegistry::getDOMImplementation(XMLString::transcode("LS"));
> // Create DOM with a CDATA section
> DOMDocumentPtr document(impl->createDocument());
> DOMElement* element =
> document->createElementNS(XMLString::transcode("http://schemas.openxmlformats.org/wordprocessingml/2006/main;),
> XMLString::transcode("w:t"));
> document->appendChild(element);
> DOMCDATASection* codesection = document->createCDATASection(XercesString("c =
> '';")); // 0x1B is not a valid XML 1.0 character
> element->appendChild(codesection);
> DOMWriterPtr writer(impl->createLSSerializer());
> writer->writeToString(document.get())
--
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-2238) Missing AttributesImpl or AttributesListImpl or VecAttrListImpl copy constructor
[ https://issues.apache.org/jira/browse/XERCESC-2238?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17613047#comment-17613047 ] Scott Cantor commented on XERCESC-2238: --- If I interpret any of this correctly (I don't use SAX so I know nothing about it or any of that part of the code base) what this is proposing is an ABI change, so I will schedule this for 4.0.0 for clarity. As for the Stack Overflow comment, I happen to agree with it but it's not my decision to admit what should be obvious to any observers about the state of the project. Take it up with the ASF (seriously, I encourage that). > Missing AttributesImpl or AttributesListImpl or VecAttrListImpl copy > constructor > - > > Key: XERCESC-2238 > URL: https://issues.apache.org/jira/browse/XERCESC-2238 > Project: Xerces-C++ > Issue Type: Bug > Components: SAX/SAX2 >Affects Versions: 3.2.3 >Reporter: Charles Shoopak >Priority: Minor > Labels: easyfix > > In VecAttributesImpl.hpp (and same for VecAttrListImpl): > // Unimplemented constructors and operators > // --- > VecAttributesImpl(const VecAttributesImpl&); > VecAttributesImpl& operator=(const VecAttributesImpl&); > > We can read of the storied AttributesImpl in Attributes.hpp, it says: > "The instance provided will return valid results only during the scope of > the startElement invocation (to save it for future use, the application must > make a copy: the AttributesImpl helper class provides a convenient > constructor for doing so)." > And notes elsewhere say AttributesListImpl is deprecated, use (non existent) > AttributesImpl instead. > Dom has cloneNode. I could go looking for an older version of xerces that > contains AttributesListImpl? Or write some hack for now. Am I missing > something obvious? > -- 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-2238) Missing AttributesImpl or AttributesListImpl or VecAttrListImpl copy constructor
[ https://issues.apache.org/jira/browse/XERCESC-2238?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Scott Cantor updated XERCESC-2238: -- Affects Version/s: 3.2.4 > Missing AttributesImpl or AttributesListImpl or VecAttrListImpl copy > constructor > - > > Key: XERCESC-2238 > URL: https://issues.apache.org/jira/browse/XERCESC-2238 > Project: Xerces-C++ > Issue Type: Bug > Components: SAX/SAX2 >Affects Versions: 3.2.3, 3.2.4 >Reporter: Charles Shoopak >Priority: Minor > Labels: easyfix > Fix For: 4.0.0 > > > In VecAttributesImpl.hpp (and same for VecAttrListImpl): > // Unimplemented constructors and operators > // --- > VecAttributesImpl(const VecAttributesImpl&); > VecAttributesImpl& operator=(const VecAttributesImpl&); > > We can read of the storied AttributesImpl in Attributes.hpp, it says: > "The instance provided will return valid results only during the scope of > the startElement invocation (to save it for future use, the application must > make a copy: the AttributesImpl helper class provides a convenient > constructor for doing so)." > And notes elsewhere say AttributesListImpl is deprecated, use (non existent) > AttributesImpl instead. > Dom has cloneNode. I could go looking for an older version of xerces that > contains AttributesListImpl? Or write some hack for now. Am I missing > something obvious? > -- 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
