I'm having an issue when debugging c++ programs in emacs (using dap-mode, LSP, projectile...):
I have no problem with the debugger, as long as my code doesn't crash. But when the debugger hits a segmentation fault, I get the usual messages that I would see in gdb for instance, but then I also get this line:
Stopping due to fatal error: NotImplementedException: No handler implemented for request type: 'ExceptionInfoRequest'!
Then emacs freezes and the only way to unfreeze it is to kill clangd. however, when I get back control over emacs, LSP detects that clangd crashed, and suggests I restart the server. Even if I say no, emacs hangs again and I can only kill emacs to close it.
I am fairly new to emacs, and just discovered LSP / DAP integration, so I apologize if I missed anything obvious during the setup process. I don't know how to get further information on this error, I am not sure if the problem is in the vscode-cpptools, in clangd, emacs, or in the dap-mode package.
Has anyone encountered the issue, or knows how to fix this?
Related
I was using a very old version of Emacs on Windows 7 Professional 64 bit so I upgraded to Emacs 25.3.1 64 bit. The installation went well.
When I ran Emacs, I started reading the messages in the initial buffer and then I heard a "ding" sound and the message "<noname> is undefined" was displayed.
I started typing into the buffer and approximately 10 seconds after the first "ding" sound there was another and the message "<noname> is undefined" message was displayed again.
If I try to enter text into the buffer or enter a command, I'm interrupted by the "ding" and "<noname> is undefined" message. This makes Emacs useless.
Thinking that perhaps there was something in my Emacs initialization file which is no longer valid, I closed Emacs and renamed the Emacs initialization file, then launched Emacs again. Same "ding" sound and same message.
I'm not sure what "noname" Emacs is complaining about or how to fix it. It is now almost 3 AM (US Eastern time) so I'm going to get some sleep and attack this in the daylight hours.
Oh! One other thing - I access the Windows 7 Professional 64 bit box via Remote Desktop, as the computer is in a facility in another state.
Any idea as to what is going on?
More Information:
I rebooted after installing the new version of Emacs. When the computer rebooted it automatically launched the DishAnywhere player.
Normally I kill the DishAnywhere player shortly after launch, but last night I didn't, so DishAnywhere was running when I launched Emacs.
Today I've run some experiments and found:
-- If DishAnywhere is running and I launch Emacs, Emacs will "Ding" and display the "<noname> is undefined" message every 10 seconds.
-- If I exit Emacs and kill off DishAnywhere, then launch Emacs, Emacs runs correctly - no "Ding" or error message.
-- If I launch DishAnywhere AFTER Emacs has started running, no "Ding" or error message.
-- If I then exit Emacs, wait a few minutes, and then launch Emacs again (while DishAnywhere is running), Emacs runs correctly - no "Ding" or error message.
So...
If DishAnywhere runs BEFORE Emacs is launched, Emacs has a problem, "Dings" and displays an error message.
If Emacs is launched BEFORE DishAnywhere and is running when DishAnywhere is launched, then Emacs runs correctly.
The workaround is to:
Kill DishAnywhere before launching Emacs, then launch DishAnywhere.
But the question is what is the interaction between DishAnywhere and Emacs that causes the issue?
Does this happen when you start Emacs using emacs -Q? If so then use M-x report-emacs-bug, providing a recipe of what you are doing and what you see.
If not (which is what I'm guessing) then recursively bisect your init file to find the culprit code. You can use command comment-region to comment out a block of code. If you use C-u with comment-region then it uncomments a block of code.
Comment out 1/2, then 3/4, then 7/8, ... of your init file, to narrow the problematic part. This is a binary search, so it is very quick to do, even if it means restarting Emacs multiple times.
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 have an issue using cider: emacs freezes after nREPL server started on 54308 is written. C-g helps, but I have cider not working. My question is: how can I debug cider and get some usefull output to find the source of this problem?
P.S. After a long time I get error in process filter: error during connect: connection timed out. But I would like to debug underlying process (as nrepl-server is started).
M-x toggle-debug-on-error should make it easy to obtain the stacktrace of the problem. After that you can you use any general debugging technique (personally, I'm fond using the debugger). I see you've also reported your problem here - that's always a good idea.
In emacs - every now and then I'm running a command I don't want (don't know which one) and the status bar says "Loading compile...done" and emacs doesn't respond. How do I fix this?
try to start emacs via emacs -Q. If the error still persists, you need to debug yourself. If you cannot debug, you should send an email to GNU emacs-devel lists.
If the error dissapears, that means you have a bad .emacs or startup.el.
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.