bug-gnu-emacs
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

bug#54183: 28.0.91; Emacs crashes on bookmark-jump


From: Gustavo Barros
Subject: bug#54183: 28.0.91; Emacs crashes on bookmark-jump
Date: Tue, 01 Mar 2022 15:04:38 -0300
User-agent: mu4e 1.6.10; emacs 28.0.91


On Tue, 01 Mar 2022 at 16:43, Eli Zaretskii <eliz@gnu.org> wrote:

OK.  I think I have an idea what's going on, but more details are
needed to find the culprit and devise the solution.  So I need you to
perform a more complex experiment and report the results.

Below are the GDB commands I'd like you to use this time:

  source /path/to/emacs/src/.gdbinit
  break xterm.c:587
  commands
   bt
   print which
   print max_fringe_bmp
   continue
   end
  break xterm.c:602
  commands
   bt
   print which
   print max_fringe_bmp
   continue
   end
  continue

(Replace "/path/to/emacs/src" with the actual absolute file name of
the directory where you have the Emacs C source files, and where the
.gdbinit file is.  If you don't have the source tree, perhaps install
it.)

The above is a lot to type, so I suggest to prepare a file with all of
those commands, so that you could tell GDB to read all of them in one
swell whoop.

There's a complication here: to have a clear idea what happens with
the fringe bitmaps, we need to activate the above commands _before_
Emacs reads your init files.  To make sure we succeed, we need to
cause Emacs to pause during startup, so that you will have enough time
to attach to it and type the commands we need, before the init files
are read.  So here's what I ask you to do: prepare a file
~/.emacs.d/early-init.el, and make this its first line:

   (sleep-for 100)

(If you already have an early-init.el file, just insert the above line
at its very beginning.)

(The number 100 is in seconds; if it is not enough for what I describe
below, enlarge it and try again.)

Now start Emacs as you do via emacsclient, so that the problem
reproduces.  It will start and shortly pause for 100 sec.  During that
time, attach GDB to the Emacs process, as you did before, and once GDB
gets control, type this command at GDB prompt:

  source /path/to/command/file

where /path/to/command/file is the file name of the file where you
stored the above GDB commands.  Then wait.  Emacs will continue
running, will hit those 2 breakpoints, and will collect the backtraces
from each time it hits the breakpoint.  Now perform the commands you
need to cause it to crash.  Eventually, Emacs will crash.  Then post
everything GDB printed until and including the crash (it could be a
lot, so compressing it is an option) here, and let's hope it will give
us enough info to understand the root cause of the crash.

TIA

I send attached the GDB session of the experiment as you instructed. I'm keeping this session alive, in case you need any further info from it.

Attachment: gdboutput.txt
Description: Text document


reply via email to

[Prev in Thread] Current Thread [Next in Thread]