GNU bug report logs - #75520
Circular code or data can hang Emacs unquittably

Previous Next

Package: emacs;

Reported by: Pip Cet <pipcet <at> protonmail.com>

Date: Sun, 12 Jan 2025 17:09:02 UTC

Severity: normal

Full log


View this message in rfc822 format

From: Eli Zaretskii <eliz <at> gnu.org>
To: Pip Cet <pipcet <at> protonmail.com>
Cc: acorallo <at> gnu.org, mattiase <at> acm.org, eggert <at> cs.ucla.edu, 75520 <at> debbugs.gnu.org, monnier <at> iro.umontreal.ca
Subject: bug#75520: Circular code or data can hang Emacs unquittably
Date: Tue, 14 Jan 2025 23:13:27 +0200
> Date: Tue, 14 Jan 2025 18:45:51 +0000
> From: Pip Cet <pipcet <at> protonmail.com>
> Cc: Paul Eggert <eggert <at> cs.ucla.edu>, mattiase <at> acm.org, monnier <at> iro.umontreal.ca, acorallo <at> gnu.org, 75520 <at> debbugs.gnu.org
> 
> > Seems like we have a consensus here that this should be fixed.
> 
> I agree, but it's a significant task: My git grep caught ~8 bugs, but
> covered only 22% of cases (at best), so I'd naively expect at least 20
> bugs, and fixing them is usually simple but occasionally tedious
> (because one might forget to include an additional check, for example,
> as I did when I accidentally removed a STRINGP (XCAR (tem)) on
> scratch/igc).

We can fix only the most painful ones.  We don't need to make sure
none remain, if it isn't easy.

> > But can we please have at least one test for every place where we fix
> > this kind of bug?
> 
> Assuming you mean a test case that reliably infloops unfixed Emacs:
> probably not.  If the requirement is simply to make some variable
> circular and call code which might refer to it, on the off chance that
> that code would infloop once in a while, maybe.
> 
> And what if we can't find such a test?  I'm pretty sure
> find_font_encoding isn't unused, and it will infloop if
> Vfont_encoding_alist is circular and we don't want to return one of its
> elements, but how do I trigger it?  Even if I managed to trigger it on
> my system (no luck so far), would that do anything on Windows, with its
> totally different font handling code?  Wouldn't it depend on which fonts
> are installed?

I thought concocting tests for this would be easy.  If it isn't, we
don't have to have such tests.

(And Vfont_encoding_alist works on Windows like it works elsewhere.
Everything in font.c is platform-independent, with a small number of
exceptions explicitly marked by #ifdef's.)

Thanks.




This bug report was last modified 151 days ago.

Previous Next


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