Bug 2284431 - 6.2.2 regression: pmResult.numpmid has bogus values on i686
Summary: 6.2.2 regression: pmResult.numpmid has bogus values on i686
Keywords:
Status: CLOSED CURRENTRELEASE
Alias: None
Product: Fedora
Classification: Fedora
Component: pcp
Version: 39
Hardware: Unspecified
OS: Linux
unspecified
medium
Target Milestone: ---
Assignee: Nathan Scott
QA Contact: Fedora Extras Quality Assurance
URL: https://kojipkgs.fedoraproject.org//w...
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2024-06-03 09:56 UTC by Martin Pitt
Modified: 2024-07-30 06:37 UTC (History)
5 users (show)

Fixed In Version:
Clone Of:
Environment:
Last Closed: 2024-07-30 06:37:08 UTC
Type: ---
Embargoed:


Attachments (Terms of Use)

Description Martin Pitt 2024-06-03 09:56:49 UTC
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

Comment 1 Martin Pitt 2024-06-04 11:09:31 UTC
This also affects C9S now, see https://kojihub.stream.rdu2.redhat.com/koji/taskinfo?taskID=4160964

Comment 2 Nathan Scott 2024-06-05 04:46:46 UTC
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.

Comment 3 Martin Pitt 2024-06-05 05:04:12 UTC
Thanks Nathan! Let me know if you want me to verify a test build/copr or similar.

Comment 4 Nathan Scott 2024-07-30 06:37:08 UTC
Resolved some time back by reverting the change.


Note You need to log in before you can comment on or make changes to this bug.