If the tests cant handle certain changes to ulimit defaults that should be fixed, but given they passed for most and can be easily configured around then its definitely not a blocker as you say.
Given the changes actually in 0.36.0 since 0.35.0 [1] I wouldnt be too surprised if the situation was the same for 0.35.0, and if so it wouldnt even be a regression either. [1] https://github.com/apache/qpid-proton/compare/0.35.0...0.36.0-rc1#files_bucket On Thu, 4 Nov 2021 at 11:42, Roddie Kieley <rkie...@gmail.com> wrote: > > -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 > > > > --------------------------------------------------------------------- To unsubscribe, e-mail: users-unsubscr...@qpid.apache.org For additional commands, e-mail: users-h...@qpid.apache.org
