Thanks,
you're likely on to something!
While NUT CI farm runs, give or take, 10^3 builds and tests across the
matrix of platforms, toolkits and dependencies fir each iteration, and most
of these pass green or catch true coding errors, I did occasionally see
failed C++ tests (and also NIT where it waits for both OL and OB to be seen
on a dummy-ups over certain time).
Mostly this correlated with slow-down of build agents (esp. VMs on
congested hosts), and maybe kernel or its context-switching-under-stress
tuning (openbsd and macos seen more often than others), but I did not
succeed pinpointing the problem for the C++ case.
In that OL-OB test of NIT, had to sort of write it off - if the VM is too
busy that a 1-second timer flip is not happening/detected over 10 seconds,
it is a SUT problem more than NUT problem. A real system on battery and
frantically shutting down (causing stress/slowness) might have power lost
during that time though.
IPC tests are similarly flawed by nature, communicating two processes
that both have to get a slice of CPU in a given time frame for the test (or
real-life reaction), but if you can get something to fail reliably in
reasonable conditions (relevant under normal load) - that's really
encouraging for the prospect of fixing it.
Jim
On Mon, Dec 2, 2024, 01:36 Greg Troxel via Nut-upsdev <
nut-upsdev at alioth-lists.debian.net> wrote:
> After not paying such close attention for a while, for no particular
> reason, I'm bringing the pkgsrc-wip package (which tracks master) up to
> date.
>
> I am doing a full build of .1412, 3e004e9.
>
> Things are mostly ok, but in tests, cppunittest seems to crash. I
> wonder: what was expected?
>
> Reading nutipc_ut.cpp, I don't understand the test, and in particular I
> don't understand the assumption that the signal handler will run
> promptly.
>
> Do tests pass for everyone else with git master?
>
> I am using gcc 10.
>
> I got a core file and here's the backtrace. Seems to be gnu extension
> new_allocator?
>
> (gdb) bt
> #0 0x00007bba8957eeea in _lwp_kill () from /usr/lib/libc.so.12
> #1 0x00007bba895846e0 in abort () from /usr/lib/libc.so.12
> #2 0x00007bba8a2fd165 in ?? () from /usr/lib/libstdc++.so.9
> #3 0x00007bba8a2f2e2d in __cxxabiv1::__terminate(void (*)()) () from
> /usr/lib/libstdc++.so.9
> #4 0x00007bba8a2f2e6f in std::terminate() () from /usr/lib/libstdc++.so.9
> #5 0x00007bba8a2f2dd0 in __cxa_throw () from /usr/lib/libstdc++.so.9
> #6 0x0000000000479485 in
> nut::Signal::HandlerThread<TestSignalHandler>::main
> (comm_pipe_read_end=<optimized out>) at
> /usr/include/g++/ext/new_allocator.h:89
> #7 0x00007bba8a60c89f in ?? () from /usr/lib/libpthread.so.1
> #8 0x00007bba894930e0 in ?? () from /usr/lib/libc.so.12
> #9 0x0000000000400000 in ?? ()
> #10 0x00007bba89200000 in ?? ()
> #11 0x0000001003a0efff in ?? ()
> #12 0x00007bba890000c0 in ?? ()
> #13 0x00000000001fff40 in ?? ()
> #14 0x0000000000000000 in ?? ()
>
> _______________________________________________
> Nut-upsdev mailing list
> Nut-upsdev at alioth-lists.debian.net
> https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/nut-upsdev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://alioth-lists.debian.net/pipermail/nut-upsdev/attachments/20241202/c76a3f67/attachment-0001.htm>