bug#71712: 29.3; Crash on OpenBSD

[Eli Zaretskii]

> Date: Wed, 26 Jun 2024 23:00:27 +0100
> From: Kirill A. Korinsky <kirill@korins.ky>
> Cc: luangruo@yahoo.com,
>       71712@debbugs.gnu.org
> 
> On Wed, 26 Jun 2024 17:11:41 +0100,
> Eli Zaretskii <eliz@gnu.org> wrote:
> > 
> > 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.
> 
> I tried to attach GDB to running process, or start a new emacs under GDB.
> 
> Both attemt leads to massive amount of SIGSTOP signals

??? Which software on your system issues SIGSTOPs?  And on what
occasions?  And why?

FWIW, I'm running Emacs under GDB a lot (albeit not on OpenBSD), and I
never see any SIGSTOP, unless I manually issue "kill -STOP" from the
shell prompt, or something similar.

> and if I switch handler to nostop, I stop to get it, but resulted
> emacs is unresponsible.

Please show the GDB command you typed to change the handling of
SIGSTOP.

> I've rebuild emacs with
> 
>   --enable-checking='yes,glyphs' --enable-check-lisp-object-type \
>     CFLAGS='-O0 -g3'
> 
> with hope that produced .core will be usefull.

It will produce more useful core file, but as I explained, the problem
happens before the segfault, and the important question is: which code
between init_iterator and gui_produce_glyphs causes the frame's face
cache to be reset without immediately recomputing the basic faces.
This requires to examine the code _before_ the segfault location.