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

Previous Next

Full log

View this message in rfc822 format

From: Pip Cet <pipcet <at> protonmail.com>
To: Eli Zaretskii <eliz <at> gnu.org>
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 22:13:48 +0000

"Eli Zaretskii" <eliz <at> gnu.org> writes:

>> 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.

It's not.  Maybe coccinelle can help, though (Stefan Kangas just used
it, so it seems to still exist, and coccigrep at least was updated
recently).

However, I don't believe we should go to the trouble of identifying bugs
and then decide not to fix them.

>> > 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.

Excellent.  I'll do the easy tests and report back with a patch, listing
those places I couldn't find a test for.

> (And Vfont_encoding_alist works on Windows like it works elsewhere.

xfont.c calls font_registry_charsets in four places; w32font.c doesn't
call it at all.

> Everything in font.c is platform-independent, with a small number of
> exceptions explicitly marked by #ifdef's.)

A lot of the code isn't reachable in the same way; for example, unless
I'm quite confused, there's no way to reach the code from bug#75521 on
Windows, while it might be possible to reach it on GNU/Linux.

I don't know much about font registries, though (it's a workaround for
the limitation of 65535 characters/"font", IIUC? Is that limitation
still relevant, or are we using new font formats now which aren't
subject to it?).

Pip

Previous Next

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