GNU bug report logs -
#54183
28.0.91; Emacs crashes on bookmark-jump
Previous Next
Reported by: Gustavo Barros <gusbrs.2016 <at> gmail.com>
Date: Sun, 27 Feb 2022 15:08:01 UTC
Severity: normal
Found in version 28.0.91
Done: Eli Zaretskii <eliz <at> gnu.org>
Bug is archived. No further changes may be made.
Full log
Message #17 received at 54183 <at> debbugs.gnu.org (full text, mbox):
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.
This bug report was last modified 3 years and 162 days ago.
Previous Next
GNU bug tracking system
Copyright (C) 1999 Darren O. Benham,
1997,2003 nCipher Corporation Ltd,
1994-97 Ian Jackson.