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.
Related
I have problems debugging a program in Eclipse 2019-03 using GDB on Windows 10 with MinGW.
Whenever I stop in the program, I get the error message ERROR: Unexpected GDB output from command "-exec-step 1". Cannot find bounds of current function.
I got this also when debugging a new C/C++ project with just printing a line to the console, so it seems unrelated to the actual program that was executing.
Both programs could be debugged fine when running gdb manually on the command line.
Answering my own question: the problem was caused by a number of watch expressions that I had configured in Eclipse. I discovered this when I enabled GDB traces in Eclipse to see the MI commands between Eclipse and GDB.
Removing all watch expressions in Eclipse solved the problem for me.
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 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 am trying to use gdb within emacs, i have gdb running but the first command i need to input is for example;
target remote 192.168.1.1:1234
to communicate with the target. I type this in at (gdb) after I have some output from gdb about versions.
For some reason gdb in emacs does not respond to this command and instead does nothing. It works fine on the command line in a shell so i thought it would simply work in emacs aswell.
Does anybody have any ideas as to why this would not work in emacs?
Thanks for your help
what you actually want is to run gdb like this:
M-x gdb ret
gdb --annotate=3 myprog
(gdb) target remote 192.168.1.1:1234
The key appears to be the --annotate=3, I am not sure what tramp is or why you would want to use ssh for anything (gdb will connect directly to the host you pass to it), but this works for me. I was having the same problem connecting to qemu running on localhost.
Have a look at the relevant section of the tramp documentation - you can use Tramp together with gdb to debug remotely. For example:
M-xgdbRET
Run gdb (like this): gdb --annotate=3 /ssh:host:~/myprog RET