-0
tl;dr - c-fdlimit-test failed on Fedora 34 with both gcc and clang, likely
due to default ulimit settings. As this can easily be configured around its
not great but not a blocker either.
Tested on Fedora 34
- Lenovo T450s, GCC 9.3.1, 2c4t
-- ctest full pass consistently, default build options and test options on
0.36.0-rc1 tag
- HP Z820, Clang 12.0.1, 16c32t
-- ctest fails consistently:
The following tests FAILED:
6 - c-fdlimit-tests (Failed)
28 - c-example-tests (Failed)
Errors while running CTest
Due to valgrind failures like:
28: ==774604== Syscall param socketcall.sendto(msg) points to uninitialised
byte(s)
28: ==774604== at 0x48ECD10: send (in /usr/lib64/libpthread-2.33.so)
28: ==774604== by 0x485D7DC: pconnection_write (src/
github.com/apache/qpid-proton/c/src/proactor/epoll.c:1042)
28: ==774604== by 0x485D7DC: write_flush (src/
github.com/apache/qpid-proton/c/src/proactor/epoll.c:1087)
28: ==774604== by 0x485D626: pconnection_batch_next (src/
github.com/apache/qpid-proton/c/src/proactor/epoll.c:892)
28: ==774604== by 0x202EB7: run (src/
github.com/apache/qpid-proton/c/examples/send-ssl.c:203)
28: ==774604== by 0x2033EE: main (src/
github.com/apache/qpid-proton/c/examples/send-ssl.c:249)
28: ==774604== Address 0x5126885 is 37 bytes inside a block of size 8,192
alloc'd
28: ==774604== at 0x484086F: malloc (vg_replace_malloc.c:380)
28: ==774604== by 0x489C514: UnknownInlinedFun (src/
github.com/apache/qpid-proton/c/src/core/memory.c:274)
28: ==774604== by 0x489C514: pn_transport (src/
github.com/apache/qpid-proton/c/src/core/transport.c:557)
28: ==774604== by 0x20338F: main (src/
github.com/apache/qpid-proton/c/examples/send-ssl.c:230)
Discussed with astitcher and similar to failure on FreeBSD, likely build
toolchain differences responsible.
- HP Z820, GCC 9.3.1, 16c32t
-- ctest fails c-fdlimit-test, default build options and test options on
0.36.0-rc1 tag
The following tests FAILED:
6 - c-fdlimit-tests (Failed)
Many errors like this last one:
6: /usr/lib64/python3.10/subprocess.py:1067: ResourceWarning: subprocess
875991 is still running
6: _warn("subprocess %s is still running" % self.pid,
6: ResourceWarning: Enable tracemalloc to get the object allocation
traceback
6:
6: ======================================================================
6: FAIL: test_fd_limit_broker (__main__.FdLimitTest)
6: Check behaviour when running out of file descriptors on accept
6: ----------------------------------------------------------------------
6: Traceback (most recent call last):
6: File "/wip/src/github.com/apache/qpid-proton/c/tests/fdlimit.py", line
77, in test_fd_limit_broker
6: self.assertNotEqual(sender.poll(), 0)
6: AssertionError: 0 == 0
Tested on macOS 11.1
- MBP, AppleClang 12.0.0.12000032
-- w/default build options build fails due to 'ruby.swg' but could be local
problem
[ 98%] Swig compile cproton.i for ruby
:3: Error: Unable to find 'ruby.swg'
gmake[2]: ***
[ruby/CMakeFiles/cproton-ruby_swig_compilation.dir/build.make:110:
ruby/CMakeFiles/cproton-ruby.dir/cprotonRUBY.stamp] Error 1
gmake[2]: *** Deleting file
'ruby/CMakeFiles/cproton-ruby.dir/cprotonRUBY.stamp'
gmake[1]: *** [CMakeFiles/Makefile2:3294:
ruby/CMakeFiles/cproton-ruby_swig_compilation.dir/all] Error 2
-- build using -DBUILD_RUBY=OFF succeeds; could be a local ruby
configuration issue
-- ctest fails as AppleClang as above
Roddie
On Thu, Nov 4, 2021 at 8:46 AM Andrew Stitcher <astitc...@redhat.com> wrote:
> I've now found the causes of the caveats I mention below. They are
> actually small but harmless/irrelevant bugs in the release. I'll commit
> fixes for them to main today, but I don't think they should delay this.
>
> Andrew
>
> On Wed, 2021-11-03 at 17:30 +0000, Andrew Stitcher wrote:
> > +1 (with some caveats)
> >
> > Build (cmake+ninja) and build tested (ctest) on:
> > * Fedora 34 tested with valgrind - python, ruby, go
> > Complete success, no test failures
> >
> > * RPi4 with current Raspberry Pi OS -
> > * Built Tested no valgrind (too slow), python only
> > * Built/Tested with asan sanitizer
> > No test failures
> >
> > * FreeBSD12 tested with valgrind
> > valgrind some real issues on this platform:
> > * Found an incorrect use of memcpy in the pn_buffer code - this is
> > due to a recent change. However it's caused by a very dubious hack
> > used
> > in the messenger code. Where messenger delves into the internals of
> > pn_buffer_t. The memcpy has the same source and destination so it is
> > benign but technically undefined. I will commit a mitigation into
> > main,
> > but I don't think it should hold up the release.
> >
> > It is puzzling that valgrind didn't find the issue on Linux, maybe
> > due
> > to different compile chain and libc
> >
> > It also found a use of an undefined value in the codec code relating
> > to
> > null - I'm not 100% sure of the validity of this as to my eye it
> > looks
> > like the value referred to is initialised, but in that case it's
> > likely
> > that the location being reported is itself some sort of copy of
> > another
> > undefined value. Again this is not reported anywhere else so
> > shouldn't
> > hold up the release.
> >
> > Besides the valgrind reports the tests succeeded on FreeBSD 12.
> >
> > Andrew
> >
> >
> > On Mon, 2021-11-01 at 13:12 +0000, Robbie Gemmell wrote:
> > > Hi folks,
> > >
> > > I have put together a first spin for a Qpid Proton 0.36.0 release,
> > > please give it a test out and vote accordingly.
> > >
> > > The files can be grabbed from:
> > > https://dist.apache.org/repos/dist/dev/qpid/proton/0.36.0-rc1/
> > >
> > > The JIRAs assigned are:
> > >
> https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12313720&version=12350346
> > >
> > > It is tagged as 0.36.0-rc1.
> > >
> > > Regards,
> > > Robbie
> > >
> > > -------------------------------------------------------------------
> > > --
> > > To unsubscribe, e-mail: users-unsubscr...@qpid.apache.org
> > > For additional commands, e-mail: users-h...@qpid.apache.org
> > >
> >
> >
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscr...@qpid.apache.org
> For additional commands, e-mail: users-h...@qpid.apache.org
>
>
