<div dir="auto">Thanks,<div dir="auto"><br></div><div dir="auto"> you're likely on to something!</div><div dir="auto"><br></div><div dir="auto"> 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).</div><div dir="auto"><br></div><div dir="auto"> 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.<br><br></div><div dir="auto"> 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.</div><div dir="auto"><br></div><div dir="auto"> 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.</div><div dir="auto"><br></div><div dir="auto">Jim</div><div dir="auto"><br></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Mon, Dec 2, 2024, 01:36 Greg Troxel via Nut-upsdev <<a href="mailto:nut-upsdev@alioth-lists.debian.net">nut-upsdev@alioth-lists.debian.net</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">After not paying such close attention for a while, for no particular<br>
reason, I'm bringing the pkgsrc-wip package (which tracks master) up to<br>
date.<br>
<br>
I am doing a full build of .1412, 3e004e9.<br>
<br>
Things are mostly ok, but in tests, cppunittest seems to crash. I<br>
wonder: what was expected?<br>
<br>
Reading nutipc_ut.cpp, I don't understand the test, and in particular I<br>
don't understand the assumption that the signal handler will run<br>
promptly.<br>
<br>
Do tests pass for everyone else with git master?<br>
<br>
I am using gcc 10.<br>
<br>
I got a core file and here's the backtrace. Seems to be gnu extension<br>
new_allocator?<br>
<br>
(gdb) bt<br>
#0 0x00007bba8957eeea in _lwp_kill () from /usr/lib/libc.so.12<br>
#1 0x00007bba895846e0 in abort () from /usr/lib/libc.so.12<br>
#2 0x00007bba8a2fd165 in ?? () from /usr/lib/libstdc++.so.9<br>
#3 0x00007bba8a2f2e2d in __cxxabiv1::__terminate(void (*)()) () from /usr/lib/libstdc++.so.9<br>
#4 0x00007bba8a2f2e6f in std::terminate() () from /usr/lib/libstdc++.so.9<br>
#5 0x00007bba8a2f2dd0 in __cxa_throw () from /usr/lib/libstdc++.so.9<br>
#6 0x0000000000479485 in nut::Signal::HandlerThread<TestSignalHandler>::main (comm_pipe_read_end=<optimized out>) at /usr/include/g++/ext/new_allocator.h:89<br>
#7 0x00007bba8a60c89f in ?? () from /usr/lib/libpthread.so.1<br>
#8 0x00007bba894930e0 in ?? () from /usr/lib/libc.so.12<br>
#9 0x0000000000400000 in ?? ()<br>
#10 0x00007bba89200000 in ?? ()<br>
#11 0x0000001003a0efff in ?? ()<br>
#12 0x00007bba890000c0 in ?? ()<br>
#13 0x00000000001fff40 in ?? ()<br>
#14 0x0000000000000000 in ?? ()<br>
<br>
_______________________________________________<br>
Nut-upsdev mailing list<br>
<a href="mailto:Nut-upsdev@alioth-lists.debian.net" target="_blank" rel="noreferrer">Nut-upsdev@alioth-lists.debian.net</a><br>
<a href="https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/nut-upsdev" rel="noreferrer noreferrer" target="_blank">https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/nut-upsdev</a><br>
</blockquote></div>