GNU bug report logs - #71712
29.3; Crash on OpenBSD

Previous Next

Full log

View this message in rfc822 format

From: Eli Zaretskii <eliz <at> gnu.org>
To: kirill <at> korins.ky
Cc: luangruo <at> yahoo.com, 71712 <at> debbugs.gnu.org, kirill <at> korins.ky
Subject: bug#71712: 29.3; Crash on OpenBSD
Date: Wed, 26 Jun 2024 19:11:41 +0300

> Date: Wed, 26 Jun 2024 16:58:24 +0100
> From: Kirill A. Korinsky <kirill <at> korins.ky>
> Cc: luangruo <at> yahoo.com,
> 	71712 <at> debbugs.gnu.org
> 
> On Wed, 26 Jun 2024 14:14:43 +0100,
> Eli Zaretskii <eliz <at> gnu.org> 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.

Previous Next

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