为什么我的 Cygwin 中的 Emacs 在 Windows 7 上运行时总是创建故障转储?
我对 GNU 工具在 Windows 7 上的 Cygwin 中运行的方式非常满意。我认为使用 GNU/Linux 更容易,但我公司的政策是使用 Windows 7 作为程序员编程环境。所以,解决方案是 Cygwin。我出于编程目的大量使用 Emacs。
但是,在 Cygwin 中运行的 Emacs 似乎创建了一个一致的(phrew)故障转储并打印在控制台上。我必须使用 Cl 来刷新它,但这让我想知道:到底是什么问题?
这里有人有同样的问题吗?以及解决办法是什么。 这是我运行 org-googlecl 的示例。
进程 googlecl-list 完成
* 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
并且它总是创建 emacs-X11.exe.stackdump。当我从 emacs 中运行另一个进程时,即从 Emacs 中运行批处理文件时,总会发生这种情况。
谢谢
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
如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱,如果其他用户或者作者回复了您的评论,将不能在第一时间通知您!
发布评论
评论(4)
我最近在将 Cygwin 版本升级到 1.7.9-1 时遇到了这个问题。 pserice的解决方案 看起来很有希望,但对我来说不起作用。对我有用的解决方案是运行 rebaseall< /a>:
cd \cygwin\bin
ash
PATH=.
rebaseall -v
之后,emacs 不再崩溃了它尝试运行子进程的时间。
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:
cd \cygwin\bin
ash
PATH=.
rebaseall -v
After that, emacs stopped crashing every time it tried to run a subprocess.
Win7 中止覆盖部分堆栈的进程。如果您信任 cygwin 可执行文件,您可以有选择地排除它们,如下所示:
我排除了以下内容:
Win7 aborts processes that overwrite parts of the stack. If you trust cygwin executables, you can selectively exclude them as follows:
I excluded the following:
我在 Windows 7 上通过 cygwin 运行控制台 emacs 时遇到了同样的问题。
我的解决方案是安装本机 GNU Emacs Windows 客户端: http://ftp.gnu.org/gnu/emacs/windows/ 并将 cygwin 的 bash.exe 设置为我的 shell。
你可以在 https://github 看到我的 emacs.d/init.el .com/tildedave/init.el/blob/master/init.el:这是与确保 Windows 7 Emacs 与 cygwin 良好配合相关的部分——
对于轻量级控制台内编辑,我使用nano,它不会核心转储。
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 --
For light-weight in-console editing I use nano, which does not core dump.
我无法帮助解决具体问题,但作为一种可能的替代方案,您可以考虑在 Windows 机器上托管的 Linux VM 中运行 Emacs。您可以使用 Cygwin 的 X.org 服务器作为显示,因此最终结果与使用 Cygwin 的 Emacs 大致相同。
这意味着要跳过更多的障碍,但是 我发现它很好的解决方案,它有望避免崩溃。
我正在使用 VirtualBox 来托管我的虚拟机。
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.