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.
Related
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?
Lately, after I have been using VSCode for some time, opening and closing it repeatedly, I was surprised to see, in Process Explorer, a lot of wsl.exe processes. As it looks, 4 or 5 processes were started by VSCode each time I opened it, but were not terminating when I was closing VSCode, so I ended up with a lot of them (there are only 5 in the image, but actually there were several dozens).
I think this has something to do with the following dialog box I see (almost?) every time I open VSCode
(which I was just closing since I am not interested to install these extensions).
Does someone know how to disable the launching of these processes? I had a Docker extension which I uninstalled, but this behavior persists.
Ok, so the culprit is not this something which launches the dialog box (I still see it), but it appears to be the following setting (when checked)
After unchecking it, I don't see now any wsl.exe processes launched when I start VSCode.
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.
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.