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 < [email protected]> 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 > [email protected] > https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/nut-upsdev >
_______________________________________________ Nut-upsdev mailing list [email protected] https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/nut-upsdev
