Failed Test Results Observed
8 views
Skip to first unread message
Scott Furry
Oct 17, 2022, 11:59:20 PM10/17/22
to xmlwrapp
Platform: Linux x86_64(Gentoo)
Clang/LLVM: 13.0.1
libxml2: 2.10.3
libxslt: 1.1.37
xmlwrapp: git head (4bcdbd633a9c37ec74b527e053ffdd34c669291a)
autoreconf and compile w/o error using clang/clang++.
Executing tests on the command line, problems were encountered when excuting the test regime outside of the `xmlwrapp/tests` directory. Paths are not resolved to find `xmlwrapp/tests/attributes/data` directory.
After cd into `xmlwrapp/tests`, executing `test` produced incomplete results. It appears that testing did not run to the end but with a SIGSEGV on `node/test_node.cxx:264`. I reviewed the code for test and located output file `03a.out`. Contents are shown below:
----- 03a.out -----
<?xml version="1.0"?>
<root>
<replace><replace_child/></replace>
</root>
<root>
<replace><replace_child/></replace>
</root>
------
Something about the self-test appears out of order.
----- output of testing -----
$ ./test
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
test is a Catch v1.12.2 host application.
Run with -? for options
-------------------------------------------------------------------------------
node/replace
-------------------------------------------------------------------------------
node/test_node.cxx:264
...............................................................................
node/test_node.cxx:264: FAILED:
{Unknown expression after the reported line}
with expansion:
due to a fatal error condition:
SIGSEGV - Segmentation violation signal
===============================================================================
test cases: 58 | 57 passed | 1 failed
assertions: 181 | 180 passed | 1 failed
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
test is a Catch v1.12.2 host application.
Run with -? for options
-------------------------------------------------------------------------------
node/replace
-------------------------------------------------------------------------------
node/test_node.cxx:264
...............................................................................
node/test_node.cxx:264: FAILED:
{Unknown expression after the reported line}
with expansion:
due to a fatal error condition:
SIGSEGV - Segmentation violation signal
===============================================================================
test cases: 58 | 57 passed | 1 failed
assertions: 181 | 180 passed | 1 failed
-----
Vadim Zeitlin
Oct 18, 2022, 9:59:17 AM10/18/22
to xmlw...@googlegroups.com
On Mon, 17 Oct 2022 20:59:20 -0700 (PDT) Scott Furry <scott.w...@gmail.com> wrote:
SF> Platform: Linux x86_64(Gentoo)
SF> Clang/LLVM: 13.0.1
SF> libxml2: 2.10.3
SF> libxslt: 1.1.37
SF> xmlwrapp: git head (4bcdbd633a9c37ec74b527e053ffdd34c669291a)
SF>
SF> autoreconf and compile w/o error using clang/clang++.
Hi Scott,
SF> Executing tests on the command line, problems were encountered when
SF> excuting the test regime outside of the `xmlwrapp/tests` directory. Paths
SF> are not resolved to find `xmlwrapp/tests/attributes/data` directory.
The tests resolve paths relative to "srcdir" environment variable, see
https://github.com/vslavik/xmlwrapp/blob/4bcdbd633a9c37ec74b527e053ffdd34c669291a/tests/test_main.cxx#L43
so it can (and must) be set when running them from another directory. I'm
not sure it's really worth improving this except for, maybe, giving a
better error explaining this if the files are not found.
SF> After cd into `xmlwrapp/tests`, executing `test` produced incomplete
SF> results. It appears that testing did not run to the end but with a SIGSEGV
SF> on `node/test_node.cxx:264`.
This looks very much like https://github.com/vslavik/xmlwrapp/pull/77
could you please confirm that applying it fixes the problem for you too?
If so, it should be merged, even though I still don't understand neither
why I don't see it nor why does this fix work.
I'd just like to ask if running only the "node/replace" test crashes on
its own, or does it need to be run as part of the full test suite to see
the crash? Also, if you can rebuild it with -fsanitize=address and check if
you get anything useful from ASAN when running this test, please let me
know!
TIA!
VZ
SF> Platform: Linux x86_64(Gentoo)
SF> Clang/LLVM: 13.0.1
SF> libxml2: 2.10.3
SF> libxslt: 1.1.37
SF> xmlwrapp: git head (4bcdbd633a9c37ec74b527e053ffdd34c669291a)
SF>
SF> autoreconf and compile w/o error using clang/clang++.
Hi Scott,
SF> Executing tests on the command line, problems were encountered when
SF> excuting the test regime outside of the `xmlwrapp/tests` directory. Paths
SF> are not resolved to find `xmlwrapp/tests/attributes/data` directory.
The tests resolve paths relative to "srcdir" environment variable, see
https://github.com/vslavik/xmlwrapp/blob/4bcdbd633a9c37ec74b527e053ffdd34c669291a/tests/test_main.cxx#L43
so it can (and must) be set when running them from another directory. I'm
not sure it's really worth improving this except for, maybe, giving a
better error explaining this if the files are not found.
SF> After cd into `xmlwrapp/tests`, executing `test` produced incomplete
SF> results. It appears that testing did not run to the end but with a SIGSEGV
SF> on `node/test_node.cxx:264`.
This looks very much like https://github.com/vslavik/xmlwrapp/pull/77
could you please confirm that applying it fixes the problem for you too?
If so, it should be merged, even though I still don't understand neither
why I don't see it nor why does this fix work.
I'd just like to ask if running only the "node/replace" test crashes on
its own, or does it need to be run as part of the full test suite to see
the crash? Also, if you can rebuild it with -fsanitize=address and check if
you get anything useful from ASAN when running this test, please let me
know!
TIA!
VZ
Scott Furry
Oct 18, 2022, 4:33:39 PM10/18/22
to xmlw...@googlegroups.com
On 2022-10-18 07:59, Vadim Zeitlin wrote:
On Mon, 17 Oct 2022 20:59:20 -0700 (PDT) Scott Furry <scott.w...@gmail.com> wrote: SF> Platform: Linux x86_64(Gentoo) SF> Clang/LLVM: 13.0.1 SF> libxml2: 2.10.3 SF> libxslt: 1.1.37 SF> xmlwrapp: git head (4bcdbd633a9c37ec74b527e053ffdd34c669291a) SF> SF> autoreconf and compile w/o error using clang/clang++. Hi Scott, SF> Executing tests on the command line, problems were encountered when SF> excuting the test regime outside of the `xmlwrapp/tests` directory. Paths SF> are not resolved to find `xmlwrapp/tests/attributes/data` directory. The tests resolve paths relative to "srcdir" environment variable, see https://github.com/vslavik/xmlwrapp/blob/4bcdbd633a9c37ec74b527e053ffdd34c669291a/tests/test_main.cxx#L43 so it can (and must) be set when running them from another directory. I'm not sure it's really worth improving this except for, maybe, giving a better error explaining this if the files are not found.
This feels similar to what python3 went
though. Everyone could see the utility of
the pathlib.Path module but integrating took tremendous effort. For C++ we've had
the Boost::filesystem library for some time - not everyone uses Boost. Starting
with C++17, std::filesystem was available. Working with path objects, vice
std::string representations of paths, will take some "encouragement". In the end,
IMHO, it would be worth it. Resolving the testing path is not difficult. I'll take
a swing at this a little latter.
the pathlib.Path module but integrating took tremendous effort. For C++ we've had
the Boost::filesystem library for some time - not everyone uses Boost. Starting
with C++17, std::filesystem was available. Working with path objects, vice
std::string representations of paths, will take some "encouragement". In the end,
IMHO, it would be worth it. Resolving the testing path is not difficult. I'll take
a swing at this a little latter.
SF> After cd into `xmlwrapp/tests`, executing `test` produced incomplete SF> results. It appears that testing did not run to the end but with a SIGSEGV SF> on `node/test_node.cxx:264`. This looks very much like https://github.com/vslavik/xmlwrapp/pull/77 could you please confirm that applying it fixes the problem for you too? If so, it should be merged, even though I still don't understand neither why I don't see it nor why does this fix work.
Applying the suggested code (commit ID cef8547f78deabb3588be5fad202dbe12df6a93c)
results in testing running successfully to completion.
Results:
```
$ ./test
===============================================================================
All tests passed (391 assertions in 123 test cases)
```
results in testing running successfully to completion.
Results:
```
$ ./test
===============================================================================
All tests passed (391 assertions in 123 test cases)
```
I'd just like to ask if running only the "node/replace" test crashes on its own, or does it need to be run as part of the full test suite to see the crash? Also, if you can rebuild it with -fsanitize=address and check if you get anything useful from ASAN when running this test, please let me know!
I'll attempt ASAN testing a little latter
today and report back.
Regards,
SF
Regards,
SF
Vadim Zeitlin
Oct 18, 2022, 5:23:08 PM10/18/22
to xmlw...@googlegroups.com
On Tue, 18 Oct 2022 14:33:29 -0600 Scott Furry <scott.w...@gmail.com> wrote:
SF> On 2022-10-18 07:59, Vadim Zeitlin wrote:
SF> > SF> Platform: Linux x86_64(Gentoo)
SF> > SF> Clang/LLVM: 13.0.1
SF> > SF> libxml2: 2.10.3
SF> > SF> libxslt: 1.1.37
SF> > SF> xmlwrapp: git head (4bcdbd633a9c37ec74b527e053ffdd34c669291a)
SF> > Hi Scott,
SF> >
SF> > SF> Executing tests on the command line, problems were encountered when
SF> > SF> excuting the test regime outside of the `xmlwrapp/tests` directory. Paths
SF> > SF> are not resolved to find `xmlwrapp/tests/attributes/data` directory.
SF> >
SF> > The tests resolve paths relative to "srcdir" environment variable, see
SF> >
SF> > https://github.com/vslavik/xmlwrapp/blob/4bcdbd633a9c37ec74b527e053ffdd34c669291a/tests/test_main.cxx#L43
SF> >
SF> > so it can (and must) be set when running them from another directory. I'm
SF> > not sure it's really worth improving this except for, maybe, giving a
SF> > better error explaining this if the files are not found.
[...]
SF> I'll take a swing at this a little latter.
Sorry, I'm not sure it's the same situation. It's not a question of not
using std::filesystem, but of actually needing some outside help for
finding the files because the test, located in the build directory, simply
can't know where they are without this.
The alternative is to copy the files to the build directory, but I'm not
sure it's such a great idea neither.
SF> > SF> After cd into `xmlwrapp/tests`, executing `test` produced incomplete
SF> > SF> results. It appears that testing did not run to the end but with a SIGSEGV
SF> > SF> on `node/test_node.cxx:264`.
SF> >
SF> > This looks very much like https://github.com/vslavik/xmlwrapp/pull/77
SF> > could you please confirm that applying it fixes the problem for you too?
SF> > If so, it should be merged, even though I still don't understand neither
SF> > why I don't see it nor why does this fix work.
SF> Applying the suggested code (commit ID
SF> cef8547f78deabb3588be5fad202dbe12df6a93c)
SF> results in testing running successfully to completion.
Thanks!
SF> > I'd just like to ask if running only the "node/replace" test crashes on
SF> > its own, or does it need to be run as part of the full test suite to see
SF> > the crash? Also, if you can rebuild it with -fsanitize=address and check if
SF> > you get anything useful from ASAN when running this test, please let me
SF> > know!
SF> I'll attempt ASAN testing a little latter today and report back.
TIA, I'd really like to understand what's going on here because I just
don't know why I don't see the problem. FWIW I've tested with clang 13.1.6
under macOS and 13.0.1 and 14.0.6 under Debian and the tests stubbornly
pass for me with all of them...
VZ
SF> On 2022-10-18 07:59, Vadim Zeitlin wrote:
SF> > SF> Platform: Linux x86_64(Gentoo)
SF> > SF> Clang/LLVM: 13.0.1
SF> > SF> libxml2: 2.10.3
SF> > SF> libxslt: 1.1.37
SF> > SF> xmlwrapp: git head (4bcdbd633a9c37ec74b527e053ffdd34c669291a)
SF> > SF>
SF> > SF> autoreconf and compile w/o error using clang/clang++.
SF> >
SF> > SF> autoreconf and compile w/o error using clang/clang++.
SF> > Hi Scott,
SF> >
SF> > SF> Executing tests on the command line, problems were encountered when
SF> > SF> excuting the test regime outside of the `xmlwrapp/tests` directory. Paths
SF> > SF> are not resolved to find `xmlwrapp/tests/attributes/data` directory.
SF> >
SF> > The tests resolve paths relative to "srcdir" environment variable, see
SF> >
SF> > https://github.com/vslavik/xmlwrapp/blob/4bcdbd633a9c37ec74b527e053ffdd34c669291a/tests/test_main.cxx#L43
SF> >
SF> > so it can (and must) be set when running them from another directory. I'm
SF> > not sure it's really worth improving this except for, maybe, giving a
SF> > better error explaining this if the files are not found.
[...]
SF> I'll take a swing at this a little latter.
Sorry, I'm not sure it's the same situation. It's not a question of not
using std::filesystem, but of actually needing some outside help for
finding the files because the test, located in the build directory, simply
can't know where they are without this.
The alternative is to copy the files to the build directory, but I'm not
sure it's such a great idea neither.
SF> > SF> After cd into `xmlwrapp/tests`, executing `test` produced incomplete
SF> > SF> results. It appears that testing did not run to the end but with a SIGSEGV
SF> > SF> on `node/test_node.cxx:264`.
SF> >
SF> > This looks very much like https://github.com/vslavik/xmlwrapp/pull/77
SF> > could you please confirm that applying it fixes the problem for you too?
SF> > If so, it should be merged, even though I still don't understand neither
SF> > why I don't see it nor why does this fix work.
SF> Applying the suggested code (commit ID
SF> cef8547f78deabb3588be5fad202dbe12df6a93c)
SF> results in testing running successfully to completion.
Thanks!
SF> > I'd just like to ask if running only the "node/replace" test crashes on
SF> > its own, or does it need to be run as part of the full test suite to see
SF> > the crash? Also, if you can rebuild it with -fsanitize=address and check if
SF> > you get anything useful from ASAN when running this test, please let me
SF> > know!
SF> I'll attempt ASAN testing a little latter today and report back.
TIA, I'd really like to understand what's going on here because I just
don't know why I don't see the problem. FWIW I've tested with clang 13.1.6
under macOS and 13.0.1 and 14.0.6 under Debian and the tests stubbornly
pass for me with all of them...
VZ
Vadim Zeitlin
Oct 18, 2022, 5:43:44 PM10/18/22
to xmlw...@googlegroups.com
On Tue, 18 Oct 2022 23:23:06 +0200 I wrote:
Me> TIA, I'd really like to understand what's going on here because I just
Me> don't know why I don't see the problem. FWIW I've tested with clang 13.1.6
Me> under macOS and 13.0.1 and 14.0.6 under Debian
Sorry, I should have thought about it (much) sooner, but this has nothing
to do with the compiler, of course (this is painfully obvious
retrospectively), but all to do with libxml2 version. I do see the problem
with 2.10, so there is no need to run it under ASAN.
I'll merge the fix for this a.s.a.p., now that I can see it, it shouldn't
take long.
Sorry again,
VZ
Me> TIA, I'd really like to understand what's going on here because I just
Me> don't know why I don't see the problem. FWIW I've tested with clang 13.1.6
Me> under macOS and 13.0.1 and 14.0.6 under Debian
Sorry, I should have thought about it (much) sooner, but this has nothing
to do with the compiler, of course (this is painfully obvious
retrospectively), but all to do with libxml2 version. I do see the problem
with 2.10, so there is no need to run it under ASAN.
I'll merge the fix for this a.s.a.p., now that I can see it, it shouldn't
take long.
Sorry again,
VZ
Scott Furry
Oct 18, 2022, 6:43:40 PM10/18/22
to xmlw...@googlegroups.com
I guess this is an extension of "dependency hell".
Glad it got sorted out.
I can see the changes that you pushed to the repository but they haven't
hit the master branch yet.
No need for apologies. Thanks you for your efforts.
SF
Reply all
Reply to author
Forward
0 new messages