Subject: bug#73441: 31.0.50; Unstable proced-refine-test failure

From: Michael Albinus <[email-masked]>
Date: Sat, 09 Nov 2024 21:06:34 +0100

Laurence Warne <[email-masked]> writes:

> Hi Michael,

Hi Laurence,

> How strange, AFAICS the attribute values Proced uses are straight from
> 'process-attributes' so perhaps the issue is there? - we could add '
> (process-attributes pid)' to the ert explainer to confirm it.

We could add it to the explainer. However, the result of this
process-attributes call is not the same as we see in proced, because it
happens later.

Well, the pcpu slot of process-attributes is computed as

--8<---------------cut here---------------start------------->8---
		  pcpu = (100.0 * (s_time + u_time)
			  / (clocks_per_sec * float_time (etime)));
--8<---------------cut here---------------end--------------->8---

(see sysdep.c). If one of the operands is not proper, the result can be
a NaN indeed, like -0.0e+NaN.

proced-format-cpu formats with (format "%.1f" cpu). And if cpu is a NaN,
we see that string indeed, because (format "%.1f" -0.0e+NaN) => "-nan".

> On the other hand, I don't see any harm in checking for degenerate
> values like -nan in 'proced-<' (the doc of 'process-attributes'
> doesn't appear to mention nan, not sure about the internals of that
> function but it doesn't look like a legal value to me)?

Yes, checking for -nan seems to be the best choice we have. So we must
replace (thing-at-point 'number) with something else in proced-refine-test,
proced-refine-with-update-test, proced--assert-process-valid-cpu-refinement
and proced--assert-process-valid-cpu-refinement-explainer. Would you
like to provide a patch?

> Thanks, Laurence

Best regards, Michael.