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.
Related
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
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'm trying to use gdb with emacs. The library that I'm trying to debug is loaded by a process and can't be run directly. Hence I attach to the process by using the attach command inside gdb. Attaching to a process and setting breakpoints works fine when I use gdb from a shell, but when I use gdb in emacs (by pressing M-x gdb or M-x gud-gdb), it can't set breakpoints. It shows me an error which says "Can't access memory at 0x7efb04". I'm using emacs 23.1.1.
Here is a breakdown of the process I follow:
Press M-x gdb or M-x gud-gdb to launch gdb inside emacs.
Enter the name of the executable built with debugging symbols.
Type "attach [PID]" to attach gdb to a running process.
Set a breakpoint by typing: filename:line number.
The last step gives me an error which says "Can't access memory at 0x7efb04".
Any ideas why this is happening?
EDIT : I get the same error when using DDD (UI for GDB). So I guess it's not an emacs specific issue.
Have you compiled with debug-information? Do you have some code which shows the problem?
Does this happen in other IDEs also?
I figured it out. The problem is with step 2. Entering the name of the executable built with debugging symbol causes the problem. Instead, just launching GDB and attaching to process works fine. I'm not sure if this is the expected behavior.
In DDD, the executable with debugging symbols has to be opened first before we can attach to process. I don't know how to get around that in DDD.
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.
I was trying out tramp-mode, but now I cannot seem to get rid of it.. Whenever I start emacs, it spends about 20 seconds going through various tramp-related initialisations..
tramp: Waiting 60s for prompt from remote shell
tramp: Setting up remote shell environment
..and so on.
How on earth do I unload tramp? grep'ing my ~/.emacs.d found nothing aside from the plugin itself (which doesn't seem to be loaded anywhere..)
I've cleared the recent-files history, but that made no difference..
Aha, I found where tramp was being loaded:
Loading /Users/dbr/.recentf...done
Loading tramp-mode..
I had a two files in my ~/.recentf file-history which were opened with tramp, removing them stops tramp from loading..
I just found this section of the emacs wiki explaining the problem,
When using TrampMode with recentf.el, it’s advisable to turn off the cleanup feature of recentf that attempts to stat all the files and remove them from the recently accessed list if they are readable. Tramp means that this requires recentf to open up a remote site which will block your emacs process at the most inopportune times.
(require 'recentf)
(setq recentf-auto-cleanup 'never) ;; disable before we start recentf!
(recentf-mode 1)
Another possibility is a listing in ~/.ido.last, if you are using ido-mode. In that case, the remedy is just "rm ~/.ido.last".
It sounds to me like you have a file that is opened via tramp and is being reopened at startup. Have to set emacs to restore your session?
From the tramp faq:
How can I disable tramp?
Shame on you, why did you read until now?
If you just want to have Ange-FTP as default remote files access package, you should > apply the following code:
(setq tramp-default-method "ftp")
Unloading tramp can be achieved by applying M-x tramp-unload-tramp. This resets also > the Ange-FTP plugins.
Note that I haven't tried this but hope it works for you!