From: "J.P." <jp@neverwas.me>
To: Alan Mackenzie <acm@muc.de>
Cc: Stefan Monnier <monnier@iro.umontreal.ca>, 71178@debbugs.gnu.org
Subject: bug#71178: Batch ert wrongly aborts a test run, and wrongly fails to say why.
Date: Tue, 28 May 2024 06:33:08 -0700 [thread overview]
Message-ID: <871q5moycr.fsf@neverwas.me> (raw)
In-Reply-To: <ZlSmlVuv0lE8Upnv@ACM> (Alan Mackenzie's message of "Mon, 27 May 2024 15:28:21 +0000")
Hi Alan,
Alan Mackenzie <acm@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.
next prev parent reply other threads:[~2024-05-28 13:33 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-05-24 19:23 bug#71178: Batch ert wrongly aborts a test run, and wrongly fails to say why Alan Mackenzie
2024-05-26 20:13 ` J.P.
2024-05-27 15:28 ` Alan Mackenzie
2024-05-28 13:33 ` J.P. [this message]
2024-06-05 22:13 ` J.P.
2024-10-28 18:10 ` Alan Mackenzie
2024-10-28 18:20 ` J.P.
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
List information: https://www.gnu.org/software/emacs/
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=871q5moycr.fsf@neverwas.me \
--to=jp@neverwas.me \
--cc=71178@debbugs.gnu.org \
--cc=acm@muc.de \
--cc=monnier@iro.umontreal.ca \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
Code repositories for project(s) associated with this public inbox
https://git.savannah.gnu.org/cgit/emacs.git
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).