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.
Related
I currently use MINGW64 (Git Bash) as my terminal on my Windows 10 machine. It works great, I like it, but it only has Vim installed as an editor and I prefer Emacs. I'm unfortunately having a really awful time getting it to work in my terminal.
What's weirder still is that I have Emacs working in Cygwin64; but I don't like using that as my terminal. The most logical fix is simply that it Emacs to my Path ENV, however that doesn't seem to help (perhaps I'm doing that wrong?). I just get bash: emacs: command not found. I found a command to install it, using Pacman, however the Pacman command cannot be found either (which is weird because I thought that was installed by default with MINGW64.
Would love any and all help on this.
A couple of options:
Use Cygwin and the Cygwin emacs. Consider your Cygwin environment completely separate from Windows, so set your PATH from within the .bashrc, not within Windows. Launch emacs from the bash command-line.
Use the Emacs Windows binary distribution, but point to the utilities within Cygwin (there's an emacs package to help with this). Again, launch from the bash command line to inherit the bash environment within emacs.
Use the Windows Subsystem for Linux, with a Linux installation, and stick with emacs from there. You get the best of the Linux world, and access to the Windows directories and files as well.
My goto choice for MANY years was the Emacs Windows binary in conjunction with Cygwin. Once I started using the WSL, however, it just worked a lot better, in a clean Linux environment, and I could get terminal and GUI emacs (and other apps) running using the VcXsrv X Server. WSL has a version that directly supports X Windows, but I don't care for the windowing environment it uses, so I stick with VcXsrv.
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've got 129 packets from marmalade-repo.org , many of which list Marmalade package entries, in my Wireshark log. I'm not behind a proxy and HTTP_PROXY is unset. And ELPA (at 'http://tromey.com/elpa/') works fine.
But I get:
Failed to download `marmalade' archive
every time.
I'm on Max OS X Mavericks, all-up-to-date, with Aquamacs, and using the package.el (byte-compiled) as described here: http://marmalade-repo.org/ (since I am on < Emacs 24).
M-x version:
GNU Emacs 23.4.1 (x86_64-apple-darwin12.3.0, NS apple-appkit-1187.37) of 2013-06-13 on acs-trailblazer.ist.psu.edu - Aquamacs Distribution 2.5
What are the next troubleshooting steps I should take?
I've taken Aaron Miller's suggestion and fully migrated to the OS X port of Emacs 24.3 .
I do miss being able to use the 'command' key to go to the top of the current file, and the slightly smoother gui of Aquamacs, but it's no doubt a great port. Due to the issue with Marmalade, Emacs 23.4 won't work with some of the packages I now need (unless they were hand-built).
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 can't figure out why this isn't easy to find on Google, but after searching for about 10 minutes, I just decided to give up and post here.
The subject basically says it all. I'm running MinTTY as a cygwin terminal on a Windows XP desktop. All I want to do is have emacs open up in a new window rather than inside my terminal. What would be best is a switch for this, so I could toggle it depending on my current needs. This seems like something that would be useful to a lot of people, and I know I've done it before on Linux boxes, so I imagine there must be a way to do this in cygwin too. Anyone know how?
Just start a new mintty, telling it to invoke emacs:
mintty emacs
There are a couple of scenarios that you might clarify:
Running the cygwin version of emacs within a standard windows environment will call emacs within the current shell
If the Cygwin X-Windows server (i.e., “XWin Server”) has been started and the DISPLAY environment variable has been set in the mintty terminal (e.g., export DISPLAY=":0"), calling emacs will start it in its own window.
running the Windows version of emacs within the cygwin terminal should launch the new frame you are seeking.
If you want a separate emacs 'window', you would be best served by installing the Windows native version of emacs (I use the gnu emacs precompiled binaries), and calling it from the cygwin terminal.