ci: Roll NetBSD releases to 11.0, drop 9.4

[hebasto]

No description provided.

[DrahtBot]

The following sections might be updated with supplementary metadata relevant to reviewers and maintainers.

Reviews

See the guideline and AI policy for information on the review process.

Type	Reviewers
ACK	maflcko

If your review is incorrectly listed, please copy-paste <!--meta-tag:bot-skip--> into the comment that the bot should ignore.

[hebasto]

https://github.com/bitcoin-core/libmultiprocess/actions/runs/30274461317/job/90004862019?pr=321:

Test project /home/runner/work/libmultiprocess/libmultiprocess/build-netbsd
    Start 1: mptest
1/1 Test #1: mptest ...........................***Failed    0.18 sec
[ TEST ] listen_tests.cpp:214: ListenConnections accepts incoming connections
[ PASS ] listen_tests.cpp:214: ListenConnections accepts incoming connections (5338 μs)
[ TEST ] listen_tests.cpp:224: ListenConnections enforces a local connection limit
[ PASS ] listen_tests.cpp:224: ListenConnections enforces a local connection limit (5166 μs)
[ TEST ] listen_tests.cpp:262: ListenConnections accepts multiple connections
[ PASS ] listen_tests.cpp:262: ListenConnections accepts multiple connections (4218 μs)
[ TEST ] spawn_tests.cpp:50: SpawnProcess does not run callback in child
[ PASS ] spawn_tests.cpp:50: SpawnProcess does not run callback in child (66370 μs)
[ TEST ] test.cpp:143: Call FooInterface methods
[ PASS ] test.cpp:143: Call FooInterface methods (36477 μs)
[ TEST ] test.cpp:274: Call IPC method after client connection is closed
[ PASS ] test.cpp:274: Call IPC method after client connection is closed (1379 μs)
[ TEST ] test.cpp:284: Calling IPC method after server connection is closed
[ PASS ] test.cpp:284: Calling IPC method after server connection is closed (1220 μs)
[ TEST ] test.cpp:294: Calling IPC method and disconnecting during the call
[ PASS ] test.cpp:294: Calling IPC method and disconnecting during the call (1323 μs)
[ TEST ] test.cpp:307: Calling IPC method, disconnecting and blocking during the call
[ PASS ] test.cpp:307: Calling IPC method, disconnecting and blocking during the call (3011 μs)
[ TEST ] test.cpp:349: Worker thread destroyed before it is initialized
[ PASS ] test.cpp:349: Worker thread destroyed before it is initialized (16281 μs)
[ TEST ] test.cpp:379: Calling async IPC method, with server disconnect racing the call
[ PASS ] test.cpp:379: Calling async IPC method, with server disconnect racing the call (20428 μs)
[ TEST ] test.cpp:404: Calling async IPC method, with server disconnect after cleanup
[ PASS ] test.cpp:404: Calling async IPC method, with server disconnect after cleanup (2712 μs)
[ TEST ] test.cpp:428: Destroying ProxyClient<> with destroy method after peer disconnect
terminate called after throwing an instance of 'std::runtime_error'
  what():  IPC client method called after disconnect.
*** Received signal #6: Abort trap
stack: 
0% tests passed, 1 tests failed out of 1
Total Test time (real) =   0.18 sec
The following tests FAILED:
	  1 - mptest (Failed)
Errors while running CTest

Related (?): bitcoin/bitcoin#35823

[maflcko]

Can you share the stacktrace?

[hebasto]

Can you share the stacktrace?

(gdb) bt
#0  0x00007eb8253b853a in ___lwp_park60 () from /usr/lib/libc.so.12
#1  0x00007eb8259b6cd0 in pthread_cond_timedwait () from /usr/lib/libpthread.so.1
#2  0x000000000043618a in operator() (__closure=0x7eb82527d028) at /home/hebasto/dev/libmultiprocess/src/mp/proxy.cpp:373
#3  0x0000000000439f52 in std::__invoke_impl<void, mp::EventLoop::startAsyncThread()::<lambda()> >(std::__invoke_other, struct {...} &&) (__f=...)
    at /usr/include/g++/bits/invoke.h:61
#4  0x0000000000439e89 in std::__invoke<mp::EventLoop::startAsyncThread()::<lambda()> >(struct {...} &&) (__fn=...) at /usr/include/g++/bits/invoke.h:96
#5  0x0000000000439d7e in std::thread::_Invoker<std::tuple<mp::EventLoop::startAsyncThread()::<lambda()> > >::_M_invoke<0>(std::_Index_tuple<0>) (this=0x7eb82527d028)
    at /usr/include/g++/bits/std_thread.h:279
#6  0x0000000000439cf4 in std::thread::_Invoker<std::tuple<mp::EventLoop::startAsyncThread()::<lambda()> > >::operator()(void) (this=0x7eb82527d028)
    at /usr/include/g++/bits/std_thread.h:286
#7  0x0000000000439c38 in std::thread::_State_impl<std::thread::_Invoker<std::tuple<mp::EventLoop::startAsyncThread()::<lambda()> > > >::_M_run(void) (this=0x7eb82527d020)
    at /usr/include/g++/bits/std_thread.h:231
#8  0x00007eb825848c7b in execute_native_thread_routine () from /usr/lib/libstdc++.so.9
#9  0x00007eb8259b82e1 in pthread.create_tramp () from /usr/lib/libpthread.so.1
#10 0x00007eb82539dd60 in ?? () from /usr/lib/libc.so.12
#11 0x0000000000200000 in ?? ()
#12 0x0000000000000000 in ?? ()

[hebasto]

Apparently, until this is fixed upstream, GCC <14.x requires -DKJ_NO_EXCEPTIONS=0 whenever it processes capnproto/c++/src/kj/common.h.

On NetBSD 11.0, the default compiler is GCC 12.5, which means the devel/capnproto binary package cannot be used.

[maflcko]

lgtm ACK 278af3d

[maflcko]

unrelated, as this is just move-only, but this could be explained a bit better.

I presume this is just about the c++20 features and has nothing to do with netbsd? I presume netbsd 10 ships with gcc 10?

In that case, I wonder if there should be a CI task to confirm the C++20 used here compiles with gcc 11. edit: done in #330

Also, if true, maybe the comment can instead say:

Force later GCC version, because on NetBSD 10 the default GCC 10 is too old to compile the C++ code in this repo.

[hebasto]

I presume netbsd 10 ships with gcc 10?

Yes, It's 10.5.0.

I presume this is just about the c++20 features and has nothing to do with netbsd?

I've just built on NetBSD 10.1 using the default GCC 10.5.0 compiler.

UPDATE:

$ env CXXFLAGS="-Wpedantic" cmake -B build -G Ninja
-- The CXX compiler identification is GNU 10.5.0
-- Detecting CXX compiler ABI info
-- Detecting CXX compiler ABI info - done
-- Check for working CXX compiler: /usr/bin/c++ - skipped
-- Detecting CXX compile features
-- Detecting CXX compile features - done
-- Performing Test CMAKE_HAVE_LIBC_PTHREAD
-- Performing Test CMAKE_HAVE_LIBC_PTHREAD - Failed
-- Looking for pthread_create in pthreads
-- Looking for pthread_create in pthreads - not found
-- Looking for pthread_create in pthread
-- Looking for pthread_create in pthread - found
-- Found Threads: TRUE
-- Performing Test HAVE_PTHREAD_GETNAME_NP
-- Performing Test HAVE_PTHREAD_GETNAME_NP - Success
-- Performing Test HAVE_PTHREAD_THREADID_NP
-- Performing Test HAVE_PTHREAD_THREADID_NP - Failed
-- Performing Test HAVE_PTHREAD_GETTHREADID_NP
-- Performing Test HAVE_PTHREAD_GETTHREADID_NP - Failed
-- Configuring done (0.9s)
-- Generating done (0.0s)
-- Build files have been written to: /home/hebasto/dev/libmultiprocess/build
$ cmake --build build
[6/7] Building CXX object CMakeFiles/multiprocess.dir/src/mp/proxy.cpp.o
In file included from /home/hebasto/dev/libmultiprocess/src/mp/proxy.cpp:8:
/home/hebasto/dev/libmultiprocess/include/mp/proxy-types.h:630:2: warning: extra ';' [-Wpedantic]
  630 | };
      |  ^
[7/7] Linking CXX static library libmultiprocess.a

[hebasto]

@maflcko

Thank you for your feedback. I reworked this PR and switched all NetBSD jobs to the system's default compilers.

[maflcko]

lgtm ACK a9e70db

[ryanofsky]

I'm very confused by this PR. There is no description. The first comment is a link to a failing CI job with no context and link to a Bitcoin bug. Then there is a request for a stack trace, then a stack trace, and then discussion GCC versions and and c++20 features. Unclear what the CI failure and stack trace have to do with KJ_NO_EXCEPTIONS.

The code changes here seem fine. It does seem good to drop netbsd 9.4, add netbsd 11.0, stop hardcoding GCC 14, drop unneeded semicolons, and use -DKJ_NO_EXCEPTIONS=0 to work around capnproto/capnproto#2756.

But it would be really helpful if PR had a description and commit messages that said what the motivation for the individual changes to make this less confusing and make understanding these change possible in the future

[ryanofsky]

In commit "ci: Switch to default compiler on NetBSD 9.4" (2d33b14)

I was confused by inconsistency here between CPPFLAGS and CXXFLAGS but apparently this is needed because cmake ignores uses CXXFLAGS and ignores CPPFLAGS

[ryanofsky]

In commit "ci: Switch to default compiler on NetBSD 9.4" (2d33b14)

It'd be nice if commit message said what motivation was for this change. It seems like this is switching to an older compiler and adding a workaround only needed in the older compiler. Unclear why this is better than just using the newer compiler.

EDIT: Looking at next commit, reason for doing this seems to be newer netbsd version added in next commit that maybe doesn't support GCC 14, or maybe defaults to a newer version that would be preferred for wider coverage?

[maflcko]

I presume the rationale is that the default compiler is more likely used (by default), so documenting the workaround for it seems fine.

However, using GCC 14, or anything else, will work equally as a workaround and seems fine as well.