Martin reported several QA tests were failing wrt pmval "samples" line.
What I've found is the problem either exists/doesn't exist depending on
several factors:
running on a 32 bit machine, Debian unstable, the problem never occurs
no matter how pmval is built.
running on a 64 bit machine, Debian unstable, the problem only happens
with the packaged binaries. The key factor appears to be the introduction
of -O2, which looks like it reliably changes certain values on the stack,
that would otherwise be zero (used uninitialised, in either case).
There's two problems here, I believe:
in pmval.c the getargs() call initialises the value of "smpls" (number
of samples to take) based on cntxt->desc.sem. However, at that point,
we have not established a context yet, and so that field is uninitialised.
this test doesn't match the comment above it, and doesn't make sense:
/* counters require 2 samples to produce reported sample */
if (*smpls > 0 && cntxt->desc.sem != PM_SEM_COUNTER)
that would seem to me that it should be "cntxt->desc.sem == PM_SEM_COUNTER".
Correct pmval sample count calculation.
Martin reported several QA tests were failing wrt pmval "samples" line.
What I've found is the problem either exists/doesn't exist depending on
several factors:
There's two problems here, I believe:
this test doesn't match the comment above it, and doesn't make sense:
that would seem to me that it should be "cntxt->desc.sem == PM_SEM_COUNTER".