GNU bug report logs - #66098
Crash in itree.c on macOS with incomplete backtrace

Previous Next

Full log

Message #47 received at 66098 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Stefan Kangas <stefankangas <at> gmail.com>
Cc: 66098 <at> debbugs.gnu.org, rpluim <at> gmail.com
Subject: Re: bug#66098: Crash in itree.c on macOS with incomplete backtrace
Date: Sat, 23 Sep 2023 15:42:38 +0300

> From: Stefan Kangas <stefankangas <at> gmail.com>
> Date: Sat, 23 Sep 2023 04:56:56 -0700
> Cc: 66098 <at> debbugs.gnu.org
> 
> Robert Pluim <rpluim <at> gmail.com> writes:
> 
> >     Eli> Does "git reflog" help?
> >
> > This is why we have the numbered emacs builds in 'src/', no? Of
> > course that wonʼt help if you clean before building.
> 
> My workflow is that I pull and rebuild many times a day, in the same
> repository as I run the Emacs I use daily from.  When I start or restart
> Emacs, that version is just whatever happens to have been built last.
> 
> So I unfortunately don't think git reflog or numbered builds will help
> with finding this information in my case.

The numbered builds will help if you don't bootstrap each time (which
removes all the previous binaries).  If you still have the numbered
builds from past rebuild procedures, you can "bisect" the problem by
finding the latest numbered build which doesn't crash, then look at
its recorded Git SHA of the commit it was produced from.  Knowing that
commit will help identify the potential culprit much easier.

Previous Next

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