GNU bug report logs - #54183
28.0.91; Emacs crashes on bookmark-jump

Previous Next

Full log

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

From: Gustavo Barros <gusbrs.2016 <at> gmail.com>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 54183 <at> debbugs.gnu.org
Subject: Re: bug#54183: 28.0.91; Emacs crashes on bookmark-jump
Date: Tue, 01 Mar 2022 15:04:38 -0300

[Message part 1 (text/plain, inline)]

On Tue, 01 Mar 2022 at 16:43, Eli Zaretskii <eliz <at> 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.

[gdboutput.txt (text/plain, attachment)]

Previous Next

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