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

Previous Next

Full log

View this message in rfc822 format

From: Gustavo Barros <gusbrs.2016 <at> gmail.com>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 54183 <at> debbugs.gnu.org
Subject: bug#54183: 28.0.91; Emacs crashes on bookmark-jump
Date: Mon, 28 Feb 2022 08:01:00 -0300

Hi Eli,

On Mon, 28 Feb 2022 at 05:24, Eli Zaretskii <eliz <at> gnu.org> wrote:

> Sure, I will try to help.

Thanks, I'll try my best here too.

> Can you describe step by step what you did to try to run Emacs under
> GDB?
>
> And btw, did I understand correctly that you can reproduce the problem
> in a standalone Emacs process (i.e. not when Emacs is run as a
> daemon)?  If so, try that first: it is easier that way.  Just start
> GDB and then run Emacs from GDB.

No, the contrary is the case: it does *not* occur on a stand alone 
Emacs, only in a daemon/client instance.  Indeed, it turns out I was 
able to run a standalone Emacs from GDB as you say, but not the daemon. 
Hence, to the steps I followed.

The first important thing I found out in attempting a second time is 
that the first try was bound not to work since I usually install, then 
run `make clean', and thus my binary was no longer there.  So I started 
the build process anew.  First, I tried to run configure with the 
options I use, plus those options/flags suggested at `etc/DEBUG'.  But I 
seemed that `make' would take some good hours with them, so I 
provisionally dropped the added options/flags, to see if I could get 
things running somehow.  So I went with:

#+begin_src bash
./configure --with-mailutils --with-xwidgets --with-modules 
--with-native-compilation
make
#+end_src

I did setup a `~/.gdbinit' file with an appropriate 
`add-auto-load-safe-path /path/to/emacs/src/.gdbinit' which, as far as I 
can tell, works as intended.

I went to `src/' and from there ran `./emacs'.  Then I opened an 
arbitrary C file in the same directory (just to get the 
default-directory right, as suggested in etc/DEBUG).  Then I called `M-x 
gdb RET gdb -i=mi ./emacs RET'.  With this, I was able to start `gdb' 
for the first time without obvious warning messages.

Then I called `run RET' from the gdb prompt.  That spawned me a new 
Emacs instance, presumably the one we are interested in.  I still don't 
know what to do with it, and how to get the information we need.  But, 
one step at a time, since this is a standalone Emacs instance and, as 
mentioned, the issue only occurs on a daemon/client instance, I went 
about to get a similar procedure to work for it.

The best idea I had in this regard what to try to do something similar 
to a call to `emacsclient'.  So I moved to a file in the `lib-scr/' 
directory, where the `emacsclient' binary is, and tried:

#+begin_example
M-x gdb RET gdb -i=mi './emacsclient -c -a=""' RET
#+end_example

and some variations thereof I could conceive.  But, alas, none which did 
not result in obvious errors.

The other thing I tried was the other way around.  To use your 
expression, to "attach GDB to the running Emacs".  So, from `/lib-src/' 
I started `./emacsclient -c -a=""'.  I presumed I'd be able to do it 
attach to it with the PID.  So I tried `M-x gdb RET gdb -i=mi -p <emacs 
pid> RET'.  But got the below as response:

#+begin_example
Attaching to process 979203
Could not attach to process.  If your uid matches the uid of the target
process, check the setting of /proc/sys/kernel/yama/ptrace_scope, or try
again as the root user.  For more details, see 
/etc/sysctl.d/10-ptrace.conf
ptrace: Operation not permitted.
#+end_example

So I tried (true, not very hopeful of it) `M-x gdb RET sudo gdb -i=mi -p 
<emacs pid> RET'.  But even if I type my password correctly, it does not 
go through, and GDB exits after "3 incorrect password attempts".

I think that is a fair short summary of the "most promising" attempts I 
made.  I hope it is sufficient for you to spot where I stumbled, and not 
too boring for you to point me in the right direction.

Best regards,
Gustavo.

Previous Next

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