[jira] [Created] (XERCESC-2104) Add automake unit tests to match cmake tests
Roger Leigh created XERCESC-2104: Summary: Add automake unit tests to match cmake tests Key: XERCESC-2104 URL: https://issues.apache.org/jira/browse/XERCESC-2104 Project: Xerces-C++ Issue Type: Improvement Components: Build Affects Versions: 3.2.0 Reporter: Roger Leigh Attachments: 0001-cmake-Add-test-corrections-to-align-with-sanityTest-.patch, 0002-Add-individual-automake-checks.patch, 0003-automake-Use-silent-rules-in-place-of-custom-logic.patch The attached patches replace the sanityTest perl script with a set of small scripts which allow the automake test-runner to run the unit tests individually, as for cmake, including individual logs containing diffs where there are errors. It also replaces some of the custom boilerplate in the Makefile.ams with AM_SILENT_RULES, which does the same thing now it's directly supported in automake (for a long time now, so all recent automake versions will support it in practice). -- This message was sent by Atlassian JIRA (v6.4.14#64029) - To unsubscribe, e-mail: c-dev-unsubscr...@xerces.apache.org For additional commands, e-mail: c-dev-h...@xerces.apache.org
Re: Upporting status
On 2017-06-29 20:25, Roger Leigh wrote: On 29/06/17 20:17, Cantor, Scott wrote: On 6/29/17, 3:02 PM, "Roger Leigh" wrote: The recent trunk changes broke a few of the unit tests. I don't understand how, other than the ones that are for some reason depending on the output of the parameter options for the DOMCount sample. That seems like an odd test, but it certainly would have broken. Since nothing should be actually invoking the sample with the new option, I don't know why a new error would be raised in the tests, it defaults to behaving the same as before, allowing DTDs. Do you need a hand looking at fixing any of these bits? I don't know any of the tests or even how to run them, so probably. If the tests can be run locally with an autotools build, I haven't found that trick yet. It's "scripts/sanityTest.pl", a Perl script which runs all the tests, concatenates their output, and then diffs it with the expected output. It fails if the output differs or the tests fail prematurely. You might find https://issues.apache.org/jira/browse/XERCESC-2104 of interest. This replaces sanityTest.pl with separate automake checks. You can still run "make check", but it now shows you each individual test being run and stores the logs in separate files. This makes it much clearer what's breaking. You can see this working in https://travis-ci.org/rleigh-codelibre/xerces-c/builds/249590170 #1 #5 and #7. Regards, Roger - To unsubscribe, e-mail: c-dev-unsubscr...@xerces.apache.org For additional commands, e-mail: c-dev-h...@xerces.apache.org
RE: Upporting status
> You might find https://issues.apache.org/jira/browse/XERCESC-2104 of > interest. This replaces sanityTest.pl with separate automake checks. > You can still run "make check", but it now shows you each individual > test being run and stores the logs in separate files. This makes it > much clearer what's breaking. I don't know what XFAIL means but the tests all pass for me on Windows and Linux at the moment. -- Scott - To unsubscribe, e-mail: c-dev-unsubscr...@xerces.apache.org For additional commands, e-mail: c-dev-h...@xerces.apache.org
RE: Upporting status
Roger, is that separate fork updated with the master copy? It looks like maybe it's missing the bug fixes I checked in Friday after you let me know they were failing. That would certainly explain it. The link issue was just a dangling reference to 3_1 in the ICU build from the version change, which I probably should see if we can get indirected into a macro. I'm not familiar with Travis yet but I interpreted the output here [1] as successful (the #9 link). -- Scott [1] https://travis-ci.org/apache/xerces-c/builds - To unsubscribe, e-mail: c-dev-unsubscr...@xerces.apache.org For additional commands, e-mail: c-dev-h...@xerces.apache.org
[jira] [Commented] (XERCESC-2088) Bad casting from DOMTextImpl to DOMElementImpl
[
https://issues.apache.org/jira/browse/XERCESC-2088?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16072477#comment-16072477
]
Roger Leigh commented on XERCESC-2088:
--
[~canto...@osu.edu] I tried out the patch, but
{{xercesc/dom/impl/DOMNodeBase.hpp}} is missing from the patch contents.
> Bad casting from DOMTextImpl to DOMElementImpl
> --
>
> Key: XERCESC-2088
> URL: https://issues.apache.org/jira/browse/XERCESC-2088
> Project: Xerces-C++
> Issue Type: Bug
> Components: DOM
>Affects Versions: 3.1.1, 3.1.2, 3.1.3, 3.1.4
> Environment: ubuntu 16.04 LTS, Intel(R) Core(TM) i7-6700 CPU @
> 3.40GHz, 16GB
>Reporter: Yuseok Jeon
>Assignee: Scott Cantor
> Fix For: 3.2.0
>
> Attachments: Actual_result.txt, casting.patch, relationship_tree.jpeg
>
>
> Hi all,
> Our recently developed type confusion detection tool reports a type_confusion
> error in the "xercesc/dom/imple/DOMCasts.hpp"
> xercesc/dom/imple/DOMCasts.hpp, line 146
> static inline DOMNodeImpl *castToNodeImpl(const DOMNode *p)
> {
> DOMElementImpl *pE = (DOMElementImpl *)p;
> return &(pE->fNode);
> }
> p is pointing to the object allocated as DOMTextImpl, and it is casted into
> DOMElementImpl. However, since DOMElementImpl is not a subobject of
> DOMTextImpl, it is violating C++ standard rules 5.2.9/11 (down casting is
> undefined if the object that the pointer to be casted points to is not a
> suboject of down casting type) and causes undefined behaviors.
> There are similar type-confusion cases as below links.
> - (libstdc++) https://gcc.gnu.org/bugzilla/show_bug.cgi?id=60734
> - (Firefox) https://bugzilla.mozilla.org/show_bug.cgi?id=1074280
> I attached a actual type confusion report and object relationship
> information.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
-
To unsubscribe, e-mail: c-dev-unsubscr...@xerces.apache.org
For additional commands, e-mail: c-dev-h...@xerces.apache.org
[jira] [Commented] (XERCESC-2088) Bad casting from DOMTextImpl to DOMElementImpl
[
https://issues.apache.org/jira/browse/XERCESC-2088?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16072484#comment-16072484
]
Scott Cantor commented on XERCESC-2088:
---
Yeah, I noticed myself. Will attach after a meeting I have to run to, thanks
for trying it.
> Bad casting from DOMTextImpl to DOMElementImpl
> --
>
> Key: XERCESC-2088
> URL: https://issues.apache.org/jira/browse/XERCESC-2088
> Project: Xerces-C++
> Issue Type: Bug
> Components: DOM
>Affects Versions: 3.1.1, 3.1.2, 3.1.3, 3.1.4
> Environment: ubuntu 16.04 LTS, Intel(R) Core(TM) i7-6700 CPU @
> 3.40GHz, 16GB
>Reporter: Yuseok Jeon
>Assignee: Scott Cantor
> Fix For: 3.2.0
>
> Attachments: Actual_result.txt, casting.patch, relationship_tree.jpeg
>
>
> Hi all,
> Our recently developed type confusion detection tool reports a type_confusion
> error in the "xercesc/dom/imple/DOMCasts.hpp"
> xercesc/dom/imple/DOMCasts.hpp, line 146
> static inline DOMNodeImpl *castToNodeImpl(const DOMNode *p)
> {
> DOMElementImpl *pE = (DOMElementImpl *)p;
> return &(pE->fNode);
> }
> p is pointing to the object allocated as DOMTextImpl, and it is casted into
> DOMElementImpl. However, since DOMElementImpl is not a subobject of
> DOMTextImpl, it is violating C++ standard rules 5.2.9/11 (down casting is
> undefined if the object that the pointer to be casted points to is not a
> suboject of down casting type) and causes undefined behaviors.
> There are similar type-confusion cases as below links.
> - (libstdc++) https://gcc.gnu.org/bugzilla/show_bug.cgi?id=60734
> - (Firefox) https://bugzilla.mozilla.org/show_bug.cgi?id=1074280
> I attached a actual type confusion report and object relationship
> information.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
-
To unsubscribe, e-mail: c-dev-unsubscr...@xerces.apache.org
For additional commands, e-mail: c-dev-h...@xerces.apache.org
RE: Upporting status
On 2017-07-03 14:55, Cantor, Scott wrote: Roger, is that separate fork updated with the master copy? It looks like maybe it's missing the bug fixes I checked in Friday after you let me know they were failing. That would certainly explain it. The link issue was just a dangling reference to 3_1 in the ICU build from the version change, which I probably should see if we can get indirected into a macro. I'm not familiar with Travis yet but I interpreted the output here [1] as successful (the #9 link). Yes, thanks. After that fix went in, everything passed across the board. - To unsubscribe, e-mail: c-dev-unsubscr...@xerces.apache.org For additional commands, e-mail: c-dev-h...@xerces.apache.org
RE: Upporting status
On 2017-07-03 14:32, Cantor, Scott wrote: You might find https://issues.apache.org/jira/browse/XERCESC-2104 of interest. This replaces sanityTest.pl with separate automake checks. You can still run "make check", but it now shows you each individual test being run and stores the logs in separate files. This makes it much clearer what's breaking. I don't know what XFAIL means but the tests all pass for me on Windows and Linux at the moment. XFAIL is "expected fail". Some of the tests expect a nonzero exit status; mainly just tests which display usage information when run with no options. It's treated the same as PASS in that it's not counted as an error. If they ever pass unexpectedly then you'll get an XPASS which is treated as an error. These are XFAIL_TESTS in Makefile.am, and EXPECT_FAIL in CMakeLists.txt. Regards, Roger - To unsubscribe, e-mail: c-dev-unsubscr...@xerces.apache.org For additional commands, e-mail: c-dev-h...@xerces.apache.org
[jira] [Updated] (XERCESC-2088) Bad casting from DOMTextImpl to DOMElementImpl
[
https://issues.apache.org/jira/browse/XERCESC-2088?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Scott Cantor updated XERCESC-2088:
--
Attachment: DOMNodeBase.hpp
Attaching missing header file from patch, goes in dom/impl/
> Bad casting from DOMTextImpl to DOMElementImpl
> --
>
> Key: XERCESC-2088
> URL: https://issues.apache.org/jira/browse/XERCESC-2088
> Project: Xerces-C++
> Issue Type: Bug
> Components: DOM
>Affects Versions: 3.1.1, 3.1.2, 3.1.3, 3.1.4
> Environment: ubuntu 16.04 LTS, Intel(R) Core(TM) i7-6700 CPU @
> 3.40GHz, 16GB
>Reporter: Yuseok Jeon
>Assignee: Scott Cantor
> Fix For: 3.2.0
>
> Attachments: Actual_result.txt, casting.patch, DOMNodeBase.hpp,
> relationship_tree.jpeg
>
>
> Hi all,
> Our recently developed type confusion detection tool reports a type_confusion
> error in the "xercesc/dom/imple/DOMCasts.hpp"
> xercesc/dom/imple/DOMCasts.hpp, line 146
> static inline DOMNodeImpl *castToNodeImpl(const DOMNode *p)
> {
> DOMElementImpl *pE = (DOMElementImpl *)p;
> return &(pE->fNode);
> }
> p is pointing to the object allocated as DOMTextImpl, and it is casted into
> DOMElementImpl. However, since DOMElementImpl is not a subobject of
> DOMTextImpl, it is violating C++ standard rules 5.2.9/11 (down casting is
> undefined if the object that the pointer to be casted points to is not a
> suboject of down casting type) and causes undefined behaviors.
> There are similar type-confusion cases as below links.
> - (libstdc++) https://gcc.gnu.org/bugzilla/show_bug.cgi?id=60734
> - (Firefox) https://bugzilla.mozilla.org/show_bug.cgi?id=1074280
> I attached a actual type confusion report and object relationship
> information.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
-
To unsubscribe, e-mail: c-dev-unsubscr...@xerces.apache.org
For additional commands, e-mail: c-dev-h...@xerces.apache.org
[jira] [Commented] (XERCESC-2088) Bad casting from DOMTextImpl to DOMElementImpl
[
https://issues.apache.org/jira/browse/XERCESC-2088?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16072780#comment-16072780
]
Roger Leigh commented on XERCESC-2088:
--
Tested in [this
branch|https://github.com/rleigh-codelibre/xerces-c/commits/casting-2088].
Green in
[travis|https://travis-ci.org/rleigh-codelibre/xerces-c/builds/249694130]
[appveyor|https://ci.appveyor.com/project/rleigh-codelibre/xerces-c/build/1.0.104].
Looks good. I was having odd segfaults with FreeBSD and xalan last year, and I
would not be at all surprised if some of this was at fault. Making it
conforming should be a big improvement.
> Bad casting from DOMTextImpl to DOMElementImpl
> --
>
> Key: XERCESC-2088
> URL: https://issues.apache.org/jira/browse/XERCESC-2088
> Project: Xerces-C++
> Issue Type: Bug
> Components: DOM
>Affects Versions: 3.1.1, 3.1.2, 3.1.3, 3.1.4
> Environment: ubuntu 16.04 LTS, Intel(R) Core(TM) i7-6700 CPU @
> 3.40GHz, 16GB
>Reporter: Yuseok Jeon
>Assignee: Scott Cantor
> Fix For: 3.2.0
>
> Attachments: Actual_result.txt, casting.patch, DOMNodeBase.hpp,
> relationship_tree.jpeg
>
>
> Hi all,
> Our recently developed type confusion detection tool reports a type_confusion
> error in the "xercesc/dom/imple/DOMCasts.hpp"
> xercesc/dom/imple/DOMCasts.hpp, line 146
> static inline DOMNodeImpl *castToNodeImpl(const DOMNode *p)
> {
> DOMElementImpl *pE = (DOMElementImpl *)p;
> return &(pE->fNode);
> }
> p is pointing to the object allocated as DOMTextImpl, and it is casted into
> DOMElementImpl. However, since DOMElementImpl is not a subobject of
> DOMTextImpl, it is violating C++ standard rules 5.2.9/11 (down casting is
> undefined if the object that the pointer to be casted points to is not a
> suboject of down casting type) and causes undefined behaviors.
> There are similar type-confusion cases as below links.
> - (libstdc++) https://gcc.gnu.org/bugzilla/show_bug.cgi?id=60734
> - (Firefox) https://bugzilla.mozilla.org/show_bug.cgi?id=1074280
> I attached a actual type confusion report and object relationship
> information.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
-
To unsubscribe, e-mail: c-dev-unsubscr...@xerces.apache.org
For additional commands, e-mail: c-dev-h...@xerces.apache.org
[jira] [Commented] (XERCESC-2088) Bad casting from DOMTextImpl to DOMElementImpl
[
https://issues.apache.org/jira/browse/XERCESC-2088?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16072817#comment-16072817
]
Scott Cantor commented on XERCESC-2088:
---
At the extremes (files of sizes like 25+M and 80+M), parsing and signature
verification are horrendous, but not any different from my results with 3.1.4.
That suggests no real significant impact from the change, perhaps a bit of RAM
increase.
Thanks for the independent testing.
My testing does not include Xalan, so that would be something to test if
possible. I'm pretty confident in the aggregate this is a safe change, but
every bit helps.
With the holiday I'll hold off but I'll probably commit it later this week.
> Bad casting from DOMTextImpl to DOMElementImpl
> --
>
> Key: XERCESC-2088
> URL: https://issues.apache.org/jira/browse/XERCESC-2088
> Project: Xerces-C++
> Issue Type: Bug
> Components: DOM
>Affects Versions: 3.1.1, 3.1.2, 3.1.3, 3.1.4
> Environment: ubuntu 16.04 LTS, Intel(R) Core(TM) i7-6700 CPU @
> 3.40GHz, 16GB
>Reporter: Yuseok Jeon
>Assignee: Scott Cantor
> Fix For: 3.2.0
>
> Attachments: Actual_result.txt, casting.patch, DOMNodeBase.hpp,
> relationship_tree.jpeg
>
>
> Hi all,
> Our recently developed type confusion detection tool reports a type_confusion
> error in the "xercesc/dom/imple/DOMCasts.hpp"
> xercesc/dom/imple/DOMCasts.hpp, line 146
> static inline DOMNodeImpl *castToNodeImpl(const DOMNode *p)
> {
> DOMElementImpl *pE = (DOMElementImpl *)p;
> return &(pE->fNode);
> }
> p is pointing to the object allocated as DOMTextImpl, and it is casted into
> DOMElementImpl. However, since DOMElementImpl is not a subobject of
> DOMTextImpl, it is violating C++ standard rules 5.2.9/11 (down casting is
> undefined if the object that the pointer to be casted points to is not a
> suboject of down casting type) and causes undefined behaviors.
> There are similar type-confusion cases as below links.
> - (libstdc++) https://gcc.gnu.org/bugzilla/show_bug.cgi?id=60734
> - (Firefox) https://bugzilla.mozilla.org/show_bug.cgi?id=1074280
> I attached a actual type confusion report and object relationship
> information.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
-
To unsubscribe, e-mail: c-dev-unsubscr...@xerces.apache.org
For additional commands, e-mail: c-dev-h...@xerces.apache.org
