GNU bug report logs - #71178
Batch ert wrongly aborts a test run, and wrongly fails to say why.

Previous Next

Full log

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

From: "J.P." <jp <at> neverwas.me>
To: Alan Mackenzie <acm <at> muc.de>
Cc: Stefan Monnier <monnier <at> iro.umontreal.ca>, 71178 <at> debbugs.gnu.org
Subject: Re: bug#71178: Batch ert wrongly aborts a test run, and wrongly
 fails to say why.
Date: Tue, 28 May 2024 06:33:08 -0700

Hi Alan,

Alan Mackenzie <acm <at> muc.de> writes:

>> It seems you have identified the underlying cause:
>
>>   https://lists.gnu.org/archive/html/emacs-devel/2024-05/msg01140.html
>
> I've been looking at lisp/emacs-lisp/ert.el, and I think that suppressing
> the debug output (or rather, not invoking a backtrace dump in batch mode)
> is where the problem lies.  However, when I enabled these in my own copy,
> they produced an erc.log of over 100 MB.  But that was in my customised
> Emacs where I've changed quite a few things always to get a complete
> backtrace.  So I'm not sure what is best, here.

I too have bumped into failures that don't produce a backtrace, at least
in recent versions. However, the ones I typically see look more like:

  Error in process sentinel
  Make[3] *** [Makefile:184 lisp/erc/erc-*.log] Error 255

  ...

  1 files did not finish:
    lisp/erc/erc-*.log

  Make *** [Makefile:266 check-lisp-erc] Error 2

With these, it seems debug output is being intentionally suppressed on
account of the error originating from some process sentinel or timer.
And when I enable `debug-on-error', a backtrace appears as expected.
This leads me to assume such occurrences are somewhat unrelated to what
you're experiencing. That said, I'm fairly convinced I've encountered
the odd mystery failure with no specified error. And the "aborted" line
in your excerpt does look familiar. Sadly, though, I cannot reliably
reproduce anything similar (yet).

>> The test itself is of minimal utility and is therefore rubbish (if not
>> outright vandalism), so I will remove it unless you'd rather it stick
>> around until the conversation on the list gets going.
>
> I think I'd rather the test should stay there a bit longer.  It
> highlights problems in pcase.el and ert.el which might get fixed sooner
> if the test is still there.  _MIGHT_ (here's hoping!).

Good point. I've added a FIXME to remind myself or some future person to
delete the test once things have settled.

Cheers,
J.P.

Previous Next

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