I am trying to set up Emacs and GDB such that I can have the gdb-many-windows option running. However, m-x gdb hangs after running any binary, and Emacs starts consuming 100% CPU and becomes unresponsive.
I am running on:
OS X 10.10.1.
Emacs 25.0.50 (the one in Homebrew)
GDB 7.8.1 (the one in Homebrew)
My Emacs setup is here: https://github.com/ChrKroer/emacs-setup
Here's what happens:
I run some binary with m-x gdb and then 'gdb --i=mi [name of binary]'. Everything works fine, the correct windows set up and everything. I then give the command 'run' to GDB, and it runs the code correctly. But once the code finishes, Emacs becomes unresponsive and start consuming 100% CPU power. This happens even with a simple hello world program. I have tried giving various options like --annotate=3, --fullname etc.
If I instead run m-x gud-gdb, I can run the same binary just fine, gdb exits normally and I can continue using Emacs.
Any help would be much appreciated.
The bug is confirmed in my mac. What's more, emacs with the same configuration (actually no configuration at all) works well in my Linux machines. So it is a bug related to Mac OS X.
Update:
It seems that some modes/plugins in emacs which conflicts with "gdb". When I run it without loading anything in .emacs, it stops hanging emacs when gdb debug finished.
I will try to track which mode causes such problems, and report it here.
It seems that many modes could lead to freezing emacs when gdb finishes debugging, e.g. "helm" and any modes using helm, "function-args" (which enables some features of helm in its source codes)
To my configuration, dozens of modes enable, helm is the critical mode that cause gdb to freeze emacs when it reaches the end.
It's not due to helm, but due to semantic-mode, which might be enabled when you want to use helm-semantic-or-imenu.
Conclusions:
It is caused by semantic-mode, which performs poorly in Mac OS X, even its basic functionality has bugs. Under Linux, it doesn't have any obvious issues, that's why gdb works in Linux. Search around your .emacs and make sure disable all semantic-mode, then it should work.
Note that, even though you disabled semantic-mode before run gdb, if semantic-mode is initially enabled, it will still freeze emacs. semantic-mode has be initially disabled.
Thanks to thierryvolpiatto for help in debugging:
https://github.com/emacs-helm/helm/issues/1168#issuecomment-140132443
Related
I'm using GDB 8.0.1 on Mac OS High Sierra 10.13.3. Basically, doing:
(gdb) r < some_input_file.in
ignores the input file. It acts as if the command ran was simply
(gdb) r
The closest thread I found about this problem was Input redirection from file gdb but no solution was posted.
Any clues?
Thanks!
You are probably running into an interaction between gdb and macOS SIP ("System Integrity Protection").
gdb implements run redirections by passing the command line to the shell; then it waits for the shell to invoke your program before starting to "really debug". The shell is actually still controlled by gdb using ptrace -- gdb uses this to observe the eventual exec and to ensure that your process is also traced.
However, SIP prevents certain programs from being traced, and in particular programs in /usr/bin, like most shells. This causes run to stop working entirely, because the shell can't be started.
So, to make gdb continue to work, users often set startup-with-shell off. Perhaps whatever gdb build you are using does this by default (or maybe, like me, you put this in your .gdbinit and forgot about it). This setting lets run work -- but at the cost of disabling redirections.
There's a gdb bug for this which you can follow.
I use Emacs for many things (the list seems to be growing every day). I like to have several frames open (so I can keep them in separate workspaces), so I first start it with emacs --daemon and then connect various clients to it with emacsclient -t.
One thing I have recently added to that list is writing papers. I write in Markdown, which allows easy version tracking with Git. In order to make it more readable, I usually split the frame into 3 or 4 windows vertically, and use follow-mode to split the paper between them.
I recently ran into a problem with this setup. Emacs would randomly stop accepting connections, and any time I ran emacsclient -t it would hang, never opening the frame. It took me a while to figure out why it happened, but I finally did. To reproduce:
Start emacs with emacs --daemon
Connect the first client with emacsclient -t <file> where <file> is some plaintext file.
Activate follow-mode with M-x follow-mode
Attempt to connect another client with emacsclient -t. This client will hang and never connect.
Deactivating follow-mode after that point had no effect, clients were still unable to connect. If I never activate follow-mode, I never have a problem.
I also tried it without loading any init files (emacs --daemon --no-init-file --no-site-file), with the same result.
I'm running GNU Emacs 23.4.1, from the Ubuntu software repositories.
Why does this happen?
Looks like a bug in follow-mode (I cannot reproduce it with with emacs 24.3). Upgrading emacs would be a solution for fixing the problem.
This seem to be the official thread for this problem, which provides some adittional information and a workaround for those unable or unwilling to upgrade emacs.
I'm checking out a segfault in one of our apps. A short time after starting the app, the main gdb status bar changes to:
(Debugger:run [signal-received])
A (gdb) prompt appears but the contents of all other windows remain unchanged (empty). Typing anything at the prompt does nothing - gdb appears to be hanging. Running the same steps on the command line results in the expected output from gdb with a complete and correct backtrace.
This is my first time debugging with the -i=mi integration between emacs and gdb. I'm using emacs 24.2 and gdb 7.5.
Are there any suggestions on how I can debug this further?
Is it possible to reduce the level of integration? Would that allow me to determine which area is causing the problem?
A final point is that the initial loading of the app takes around 70s compared with around 3s from the command line.
Load time can be reduced by setting gdb-create-source-file-list to nil (use customize). See the documentation for what this does and why it substantially increases load times in some instances.
You can use M-x gud-gdb to use the old gud mode (i.e. without the mi interaction). Less fancy but more reliable.
It appears that gdb-ui from emacs 23 will still work in emacs 24:
Find a copy of gdb-ui (In my case gdb-ui.el.gz and gdb-ui.elc from a backup)
Place these into a directory (I have added ~/emacs-modes)
Then add the following to your .emacs:
(add-to-list 'load-path "~/emacs-modes")
(require 'gdb-ui)
Running gdb will now use the old --annotate=3 mode rather than -i=mi.
I'm having difficulties with gdb under emacs 24.
I compiled my c code with the -g switch, and the symbol table loads in gdb.
The problem I'm having is that no source code is shown when I load my application, no breakpoints are visible. I guess there appears to be no connection between the source code buffer and gdb buffer.
I have used gdb under emacs before (emacs 22, and 23) and it worked well and now it doesn't.
I also tried it under emacs -q so no plugins are loaded in case my .emacs was at fault, no joy.
Just to recap (so I don't get "compile with -g" answers):
I compiled with -g I loaded emacs with no plugins
I used annotate=3with gud-gdb
I even tried gdb-mi (doesn't work at all, didn't pursue
this road any further)
Gdb ain't working with source code showing (with breakpoints).
What can I do to fix it, or at least how can I find out what's wrong?
M-x gud-gdb is not for use with annotate=3 but with --fullname (aka --annotate=1, IIRC).
Try M-x gdb with -i=mi instead of --annotate=3.
Then it worked for me, but it's damn slow in my case :/
When did you build Emacs 24? There's been a lot of churn in the gdb/gud area from emacs-devel. If you repro problems in the latest (i.e. today's) build, report bugs ASAP. The pretest is coming to an end very soon.
I quite satisfied of how GNU tools run in my Cygwin on Windows Seven. I think it's easier just to use GNU/Linux, but my company here has the policy of using Windows Seven for the Programmer programming environment. So, the solution is Cygwin. And I use Emacs intensively for my programming purpose.
But, it seems that Emacs running in Cygwin create a consistent (phrew) crash dump that printed on the console. I had to refresh it using C-l, but that makes me wonder : what is the problem anyway?
Does anyone has the same problem here? And what is the solution.
This is my example of running org-googlecl.
Process googlecl-list finished
* List of blogs with in the * List of blogs with in the title :gblog:
12719501 [main] emacs-X11 1168 exception::handle: Exception: STATUS_ACCESS_VIOLATION
12720164 [main] emacs-X11 1168 open_stackdumpfile: Dumping stack trace to emacs-X11.exe.stackdump
12889237 [main] emacs-X11 764 exception::handle: Exception: STATUS_ACCESS_VIOLATION
12889852 [main] emacs-X11 764 open_stackdumpfile: Dumping stack trace to emacs-X11.exe.stackdump
And it always create emacs-X11.exe.stackdump. It always happen when I run another process from within emacs, that is if I run a batch file from Emacs.
Thank you
I recently ran into this issue when upgrading my version of Cygwin to 1.7.9-1. pserice's solution looked promising but did not work for me. The solution that worked for me was to run rebaseall:
Close ALL Cygwin processes (use Process Explorer to make sure that nothing has cygwin1.dll loaded in it)
Start > Run > Cmd.exe
cd \cygwin\bin
ash
PATH=.
rebaseall -v
After that, emacs stopped crashing every time it tried to run a subprocess.
Win7 aborts processes that overwrite parts of the stack. If you trust cygwin executables, you can selectively exclude them as follows:
Computer -> Properties
-> Advanced System Settings
-> Performance
-> Settings...
-> Data Execution Prevention
I excluded the following:
C:\cygwin\bin\bash.exe
C:\cygwin\bin\emacs.exe
C:\cygwin\bin\emacs-nox.exe
C:\cygwin\bin\emacs-X11.exe
C:\cygwin\bin\startxwin.exe
I have had this same problem in running console emacs through cygwin on Windows 7.
My solution to this was to install the native GNU Emacs Windows client: http://ftp.gnu.org/gnu/emacs/windows/ and set cygwin's bash.exe as my shell.
You can see my emacs.d/init.el at https://github.com/tildedave/init.el/blob/master/init.el: here is the part relevant to making sure that the Windows 7 Emacs plays well with cygwin --
(if is-windows
(progn
(add-hook 'comint-output-filter-functions
'shell-strip-ctrl-m nil t)
(add-hook 'comint-output-filter-functions
'comint-watch-for-password-prompt nil t)
(setq explicit-shell-file-name "bash.exe")
(setq shell-file-name explicit-shell-file-name)))
For light-weight in-console editing I use nano, which does not core dump.
I can't help with the specific issue, but as a possible alternative you could look at running Emacs in a Linux VM hosted on your Windows box. You can use Cygwin's X.org server as the display, so the end result is largely the same as using Cygwin's Emacs.
It means jumping through a few more hoops, but I find it a good solution, and it will hopefully avoid the crashes.
I'm using VirtualBox to host my VM.