The easiest way to debug an Emacs crash is to start Emacs under gdb, and then do whatever thing it is that reproduces the crash.
Assuming you're building your Emacs from source, you should pass CFLAGS="-O0 -g3" to the ./configure script. This makes the C compiler turn off optimisations (which can make things confusing while debugging) and activates maximum ...
For two processes A and B mutually killing each other you can use the following approach:
Start the first process just with start-process and remember its process (as lisp object).
Start the second process B with async-start-process and kill A in its finish-func.
Define a process sentinel for A which kills B at exit of A.
Emacs does generally use C-p and C-n for moving the cursor up and down, <up> and <down> are usually bound to the same command. That's why you get the unfamiliar behaviour of the arrow keys not cycling the history. As a compromise M-p and M-n are bound in these contexts to history cycling commands. The only exception I'm aware of would be term-...
When you M-x gdb, Emacs will present you with a command-line in the minibuffer, like:
Run gdb (like this): gdb -i=mi something
You can edit this to supply a path to gdb, like:
~/my/install/bin/gdb -i=mi something
Since I do not have enough reputation to comment, I will post this as an answer.
The Emacs manual states:
To toggle between the many windows layout and a simple layout with just the GUD interaction buffer and a source file, type M-x gdb-many-windows.
Does this help you?
TL;DR wrap gdb in a script that has been put in your path like so:
gdb -i=mi "$@"
then call it with
rr replay -d name_of_script_i_just_created
If that doesn't work either address the error message in rr to stop it complaining, or patch gdb.el as mentioned below. Long version below.
Alright, I figured it out. It does, (currently) ...
After googling around and tweaking the code snippets from the internet, I got this solution and it works as expected:
'(gud-mode comint-mode gdb-locals-mode gdb-frames-mode gdb-breakpoints-mode)
"A list of modes when using gdb")
(defun kill-all-gud-buffers ()
"Kill all gud buffers including Debugger, Locals, Frames, Breakpoints.
If your project uses cmake, cmake-ide is a good start.
Or else, use company(auto completion)+counsel-gtags(code navigation)+global
You can use helm-gtags instead of counsel-gtags. Both packages are developed by the same person. The difference is they are based on different completion frameworks (helm vs counsel/ivy). I think counsel/ivy is faster and more ...
The answer to the question is to use the Lucid version of emacs. With Ubuntu, the package is called emacs25-lucid. From comments in the code and it also pops out on stderr if you can managed to get it:
When compiled with GTK, Emacs cannot recover from X disconnects.\n\
This is a GTK bug: https://bugzilla.gnome.org/show_bug.cgi?id=85715\n\
For details, see ...
The hook variable gdb-mode-hook is probably what you are looking for.
Citation from the GUD-manual
On startup, GUD runs one of the following hooks: gdb-mode-hook, if you are using GDB; dbx-mode-hook, if you are using DBX; sdb-mode-hook, if you are using SDB; xdb-mode-hook, if you are using XDB; guiler-mode-hook for Guile REPL debugging; perldb-mode-hook, ...
After some research, I found out that the <complex data type> string is indeed added by Emacs. In particular, Emacs uses the "--simple-values" flag sent to the GDB-MI interface to only retrieve values that are "simple". Currently, there is no way of customizing this behavior, save for editing the gdb-mi.el in the Emacs source itself.
For this reason ...
You can pass options to Emacs to make it run code when it starts: -l /path/to/file.el, -f function-called-without-arguments, --eval "(some-lisp-code 'taking-care-of \"quoting for the shell\")".
The function gdb is autoloaded, so you don't need to load a package explicitly. It takes an argument. You'll have to write some Lisp code to grab it from the command ...
man emacs gives the following - perhaps one of these invocations would help:
The following options are Lisp-oriented (these options are processed in the order encountered):
-f function, --funcall=function
Execute the lisp function function.
-l file, --load=file
Load the lisp code in the file file.
This is the solution I came up with using hl-line. I needed to advise the function that updates the disassembly buffer and invoke hl-line-highlight directly to make it work.
(after nispio/ad-after-disas-handler-hl-line activate)
"Make sure that `hl-line' gets updated after updating disassembly buffer"
Thanks to @lawlist nudging me into the source code, I found out that gdb mode will highlight the line for me, but only on the condition that the window containing the disassembly does not have fringes. The following was enough to make that happen:
;; Enable automatic highlighting of the active line in disassembly window
(defun nispio/disable-window-fringes (...
There's nothing you can do with Emacs that will change how this works, since you're just asking Emacs to ask gdb to step. Try compiling your program with -Og -ggdb, to ensure that you have the maximum amount of debugging information available.
And of course there are about a billion related options that you can use to control the amount of optimization the ...
The right place is gud-minor-mode-map.
I have got the following bindings in my setup. Pick whatever suits you for your setup.
(defun gdbTZA-gud-run-or-cont (arg)
"Combination of `gud-run' and `gud-cont'.
If the debugged program is already running use `gdb-cont' and use `gdb-run' otherwise."
(if (assoc-string gdb-inferior-status '("...
The automatic pop-up of the i/o buffer can be disabled by setting gdb-display-io-nopopup to t. In your .emacs file, add:
;; Prevent gdb from popping i/o window to the foreground on every output op
(setq-default gdb-display-io-nopopup t)
I learned this from ajp's answer here.
Apparently the doc in info format is not directly available. However the texinfo file (from wich the info file is generated) is included in the sources as doc/gdb.texinfo. So if you install gdb from the sources, you should have the info file properly installed and accessible from emacs.
On debian systems, the documentation is not included in the gdb ...
Maybe something like this?
(add-hook 'gdb-mode-hook 'my-buffer-face-mode-fixed)
(advice-add 'gdb-parent-mode :after 'my-buffer-face-mode-fixed)
Some of the buffers are in non-gdb modes, however (e.g. buffer-menu-mode, comint-mode), so you would need to do those separately if you want them as well.
If thats indeed gdb-many-windows problem. One can avoid using gdb-many-windows and define similar functionality inside the function gdb-get-source-file. You can modify the source file and build from source, but can also defadvice gdb-get-source-file, e.g.
(defadvice gdb-get-source-file (after new-setup-gdb-windows activate)
;; Select a register number which is unlikely to get used elsewere
(defconst my-windows-config-register 313465989
(defvar my-windows-config nil)
(defun set-my-windows-config ()
(setq my-windows-config (window-configuration-to-register my-windows-config-register)))
(defun jump-to-my-windows-config ()
Given the "rough edge" I referenced in my original question I decided to investigate prompt handling in gud.el. Based on nothing more than a hunch I tried changing the two lines (~783 in function gud-gdb) from:
(setq comint-prompt-regexp "^(.*gdb[+]?) *")
(setq paragraph-start comint-prompt-regexp)
(setq comint-prompt-regexp "^>|((.*gdb[+]?) *...
As suggested in the comments, this was an issue with my LD_LIBRARY_PATH, which contained a relative path.
Emacs GDB launches with the working directory equal to that of the buffer you are in when you call the file.
That means that in order to load a library from ./ I had to make sure that I was in that directory when launching the debugger. The shared ...