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

[Gustavo Barros]

Hi Eli,

On Mon, 28 Feb 2022 at 05:24, Eli Zaretskii <eliz@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.