GNU bug report logs - #73441
31.0.50; Unstable proced-refine-test failure

Previous Next

Full log

Message #66 received at 73441 <at> debbugs.gnu.org (full text, mbox):

From: Michael Albinus <michael.albinus <at> gmx.de>
To: Laurence Warne <laurencewarne <at> gmail.com>
Cc: mattiase <at> acm.org, 73441 <at> debbugs.gnu.org, Sam James <sam <at> gentoo.org>
Subject: Re: bug#73441: 31.0.50; Unstable proced-refine-test failure
Date: Sun, 10 Nov 2024 09:35:55 +0100

Laurence Warne <laurencewarne <at> gmail.com> writes:

Hi Laurence,

>> 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?
>
> I was thinking more along the lines of a 'isnan' check in 'proced-<'
> to the effect of making it not appear in any refinements at all,

This might be useful, yes. But I don't know whether this is a restriction
people could dislike.

> but if you think it's too much fretting about an edge case, I'm happy
> to provide a patch for the tests only (as you describe)?

The backtrace of the last seen error on emba was

--8<---------------cut here---------------start------------->8---
Test proced-refine-test backtrace:
  signal(ert-test-failed (((wrong-type-argument number-or-marker-p nil
  ert-fail(((wrong-type-argument number-or-marker-p nil) (unexpected-r
  (condition-case err (>= (thing-at-point 'number) cpu) (error (ert-fa
  proced--assert-process-valid-cpu-refinement(30.5)
  apply(proced--assert-process-valid-cpu-refinement 30.5)
  (setq value-7 (apply fn-5 args-6))
  (unwind-protect (setq value-7 (apply fn-5 args-6)) (setq form-descri
  (if (unwind-protect (setq value-7 (apply fn-5 args-6)) (setq form-de
  (let (form-description-9) (if (unwind-protect (setq value-7 (apply f
  (let ((value-7 'ert-form-evaluation-aborted-8)) (let (form-descripti
  (let* ((fn-5 #'proced--assert-process-valid-cpu-refinement) (args-6
  (while (not (eobp)) (let* ((fn-5 #'proced--assert-process-valid-cpu-
  (let ((cpu (thing-at-point 'number))) (proced-refine) (while (not (e
  (save-current-buffer (set-buffer "*Proced*") (proced--move-to-column
  (unwind-protect (save-current-buffer (set-buffer "*Proced*") (proced
  (let ((proced-format 'verbose) (proced-filter 'user) (proced-auto-up
  #f(lambda () [t] (let ((proced-format 'verbose) (proced-filter 'user
  #f(compiled-function () #<bytecode -0x147321e8017461ef>)()
  handler-bind-1(#f(compiled-function () #<bytecode -0x147321e8017461e
  ert--run-test-internal(#s(ert--test-execution-info :test #s(ert-test
  ert-run-test(#s(ert-test :name proced-refine-test :documentation nil
  ert-run-or-rerun-test(#s(ert--stats :selector ... :tests ... :test-m
  ert-run-tests((not (or (tag :unstable) (tag :nativecomp))) #f(compil
  ert-run-tests-batch((not (or (tag :unstable) (tag :nativecomp))))
  ert-run-tests-batch-and-exit((not (or (tag :unstable) (tag :nativeco
  eval((ert-run-tests-batch-and-exit '(not (or (tag :unstable) (tag :n
  command-line-1(("-L" ":." "-l" "ert" "--eval" "(setq treesit-extra-l
  command-line()
  normal-top-level()
Test proced-refine-test condition:
    (ert-test-failed
     ((wrong-type-argument number-or-marker-p nil)
      (unexpected-refinement
       (header-line
	"  User EUID Group EGID   PID PPID  PGrp  Sess Pr  Ni %CPU %Mem Stat THCount   VSize    RSS TTY TPGID MinFlt MajFlt CMinFlt CMajFlt Start   Time UTime STime CTime CUTime CSTime ETime Args")
       (process
	"  root    0 root     0 73235 1467 73235 73235 20   0 -nan  0.0 Z          1     0 B    0 B        -1     71      0       0       0  06:10 00:00 00:00 00:00 00:00  00:00  00:00 00:00 [chown]\n")
       (refined-value 30.5) (process-value nil))))
   FAILED  3/6  proced-refine-test (0.188194 sec) at lisp/proced-tests.el:104
--8<---------------cut here---------------end--------------->8---

So if we harden the (thing-at-point 'number) calls it would stabilize
the tests as well.

>> (see sysdep.c). If one of the operands is not proper, the result can be
>> a NaN indeed, like -0.0e+NaN.
>
> Could you explain what is meant by proper?

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

For example, if mtime is 0. This returns 1.0e+INF, but that is a NaN as
well. Or if s_time or u_time aren't floating point numbers.

Best regards, Michael.

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.