bug#73752: 29.4; Ligatures are randomly rendered with extra spaces

[Yixuan Chen <xuan@xlk.me>]

On 10/28/24 10:59, Eli Zaretskii wrote:
>> From: Visuwesh <visuweshm@gmail.com>
>> Cc: luangruo@yahoo.com,  73752@debbugs.gnu.org,  xuan@xlk.me
>> Date: Mon, 28 Oct 2024 09:56:13 +0530
>>
>> Real-life Lisp programs certainly do not change face font attributes so
>> often but I believe the script does it so to reproduce the issue
>> quickly.  In a regular Emacs session, it is enough for the same text to
>> be shown in different font sizes (as a consequence of using C-x C-+) and
>> font weights to eventually exhibit this misalignment IME.
> 
> You need to catch this situation in some reproducible recipe.  Because
> up front I don't understand how is this possible: we cache each
> composition with its font object, which includes the font size (and
> also slant, weight, etc.), so a different variant of the same font
> ought to match only cache entries that use the exact same font.  Or
> maybe I don't understand well enough what
> composition_gstring_put_cache does to compute the hash of a
> glyph-string header (which is the hash key for a composition)?
> 
>> I do not understand the technical details but the width of the glyph
>> used to draw it is not the one that should be used for the underlying
>> font (weight, size, etc. included) which leads to this misalignment.
> 
> Which seems to indicate that we somehow use a different font's metric.
> 
>> To make it more clear, let's say that =:= is shaped for a font X with a
>> specific weight, size, etc.  At a later point in time, the width of the
>> glyph corresponding to X is used to draw =:= with font Y of same family.
>> This leads to the observed misalignment AFAIU.
> 
> But how can this happen?  Without a reproducible recipe, which can be
> reproduced without waiting for too long, it is very hard to
> investigate this.

Just my uninformed opinion. Considering,
- the fact that it's hard to reproduce the problem (the script I 
submitted is the best way to trigger the problem to my knowledge since 
it reproduces on multiple people's emacs consistently),
- the non-deterministic nature of this bug,
- changing fonts rapidly seems to help triggering the bug,
- my personal research bias,

This sounds like a concurrency problem, such as some kind of race 
condition leading to cache being over-written or else. But I have zero 
idea on how emacs works internally, so I can be completely wrong.