GNU bug report logs - #72004
30.0.50, master: 'erc--check-prompt-input-for-multiline-blanks' test fail

Previous Next

Package: emacs;

Reported by: Andrea Corallo <acorallo <at> gnu.org>

Date: Tue, 9 Jul 2024 08:09:01 UTC

Severity: normal

Found in version 30.0.50

Done: Andrea Corallo <acorallo <at> gnu.org>

Bug is archived. No further changes may be made.

Full log


Message #22 received at 72004-done <at> debbugs.gnu.org (full text, mbox):

From: Andrea Corallo <acorallo <at> gnu.org>
To: "J.P." <jp <at> neverwas.me>
Cc: Eli Zaretskii <eliz <at> gnu.org>, emacs-erc <at> gnu.org, 72004-done <at> debbugs.gnu.org
Subject: Re: bug#72004: 30.0.50, master:
 'erc--check-prompt-input-for-multiline-blanks' test fail
Date: Fri, 12 Jul 2024 03:30:55 -0400
"J.P." <jp <at> neverwas.me> writes:

> Andrea Corallo <acorallo <at> gnu.org> writes:
>
>> I buy the theory of this being related to trampoline generation under
>> high system load, looking at my logs I see this test failing only with
>> native compilation an passing without.
>>
>> I'm wondering if we could work around the issue somehow 🤔
>
> I'm afraid I can offer next to nothing when it comes to serious insights
> about Emacs internals and related magic 😞
>
>>
>> Also I'm not sure the right tag is :expensive, shouldn't be :unstable?
>
> If we want to prevent the test from running completely (at least on
> EMBA), then :unstable would indeed make sense. However, if we'd like the
> test to run on the 3x daily expensive pipelines, I'm fairly confident my
> latest change sidesteps the issue. It now waits to start the subprocess,
> which was previously too short-lived, until after the macro has done its
> (potentially time-consuming) advising. Thus, the liveliness check that
> was signaling the error should now always find a running process.
> (Although, for good measure, I also lengthened the timeout from 10s to
> 5m.) All this said, I'm happy to change it to :unstable or try a safer
> approach, such as mocking `process-status'. Thanks.

Generally speaking I think we should flag tests for what they are and
then tune the EMBA testing strategy to our needs afterward.  That said
with a 5m timeout the test is now probably more expansive than unstable
so I think the classificaiton it's fine :)

Thanks closing this.

  Andrea




This bug report was last modified 1 year and 7 days ago.

Previous Next


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