The recent Cockpit update in Fedora 39 failed to build due to unit test regressions on i686 [1]. This started with pcp-6.2.2-1.fc39 but *only* on i686. Later Fedora version don't build pcp on i686 any more, so the status there is unknown (and uninteresting). I can reproduce this with `fedpkg mockbuild -N --mock-config fedora-39-i386`, and --shell. When I downgrade to 6.2.1, doing a pmFetch() and iterating over pmResult.vset[i] for i between 0 and pmResult.numpmid works fine. In our tests we usually expect small values like 1 or 2. But with 6.2.2, the test started give completely bogus results: (gdb) p *result $2 = {timestamp = {tv_sec = 1717407857, tv_usec = 0}, numpmid = 998643, vset = {0x0}} or in another run (gdb) p *result $2 = {timestamp = {tv_sec = 1717407619, tv_usec = 0}, numpmid = 233042, vset = {0x0}} This is unreasonably high and looks rather random (corrupted memory), and vset is NULL. I don't have a standalone reproducer yet, just `./configure; make check` in Cockpit. [1] https://koji.fedoraproject.org/koji/taskinfo?taskID=118496753 . [1] https://bodhi.fedoraproject.org/updates/FEDORA-2024-729b5ca69e Reproducible: Always
This also affects C9S now, see https://kojihub.stream.rdu2.redhat.com/koji/taskinfo?taskID=4160964
Hi Martin, Thanks - this is some known fallout from time64_t changes in the last upstream PCP release. It's being reworked for pcp-6.3.0, I'll see if I can get a back-port/revert build to sort out 6.2.2 in the meantime.
Thanks Nathan! Let me know if you want me to verify a test build/copr or similar.
Resolved some time back by reverting the change.