Subject: Re: bug#71712: 29.3; Crash on OpenBSD

From: Eli Zaretskii <[email-masked]>
Date: Wed, 26 Jun 2024 19:11:41 +0300

> Date: Wed, 26 Jun 2024 16:58:24 +0100
> From: Kirill A. Korinsky <[email-masked]>
> Cc: [email-masked],
> 	[email-masked]
> 
> On Wed, 26 Jun 2024 14:14:43 +0100,
> Eli Zaretskii <[email-masked]> wrote:
> > 
> > The way to find the culprit in these cases is to run the recipe with a
> > watchpoint on the frame cache's 'used' count, and see which code
> > causes it to be zeroed.  Usually, it is some crazy Lisp run from one
> > of the hooks which we so graciously offer for grabs.  The tricky part
> > is to find that code and/or the recipe which could be used to
> > reproduce the problem at will, which I understand you don't have...
> 
> Well, I don't have any reproducer, indeed.
> 
> I may attach debuger and add watch point, but the best that I can share is
> stacktrace when and if it happen.

There's also the "reverse execution" in GDB.  You could set a
breakpoint where it segfaults, with the condition that face == 0, and
when that breaks, do reverse-step until you get to the place where the
frame's face_cache is emptied (cache->used == 0); then produce a
backtrace, including xbacktrace, and hopefully we will see the
culprit.