Emacs crash when start omnisharp server on windows #315

hateonion · 2017-06-16T09:10:45Z

platform: windows 10
emacs_Version: 25.1.1 via chocolatey
omnisharp version: v1.21.0
omnisharp release using: omnisharp-win-x64-net46
spacemacs version: 0.200.7

When I trying to start omnisharp server, Emacs just showing an abort dialog and then crashed. The error message showed: A fatal error has occurred.

It should not be caused by my environment not set up cause my omnisharp running well when I use vscode.

waiting for the Answer

razzmatazz · 2017-06-16T11:21:19Z

this is can be hard to debug because the crash occurs somewhere within unmanaged emacs code and hard crash bugs on emacs /should/ not be related to elisp code..

have you tried running a different emacs version and/or from a different windows emacs distribution?

ghost · 2017-06-21T19:43:47Z

I have the same problem, tested with both Emacs 25.2.1 and Emacs 24.5.1. I also used omnisharp 4.0 and 3.9 with both versions of Emacs.

k-ode · 2017-06-22T09:53:00Z

More info here: OmniSharp/omnisharp-roslyn#647

I have not tested this personally as I currently use VS Code for csharp, but the 32-bit version of OmniSharp is supposed to be working (at least not crashing).

razzmatazz · 2017-06-22T09:58:47Z

@kimgronqvist — in your case the server itself is/was crashing, not emacs, right?

I think in this issue people about complaining about emacs (host) crash..

Or am I wrong?

neeasade · 2017-06-22T13:56:31Z

Or am I wrong?

You are not wrong, host/emacs is crashing (I found this thread after experiencing same issue).

edit:

@kimgronqvist — in your case the server itself is/was crashing, not emacs, right?

I believe that thread is also emacs crash.

k-ode · 2017-06-22T15:43:29Z

Indeed, my issue was also that Emacs crashes when you run OmniSharp from Emacs itself.

Running the server from the console works fine.

ihdavids · 2017-06-24T09:05:54Z

Same here.
It is definitely crashing in emacs proper:

KernelBase.dll!00007ff9573d2d52() Unknown
emacs.exe!0000000400174278() Unknown
emacs.exe!00000004000a6262() Unknown
emacs.exe!00000004000be00e() Unknown
emacs.exe!00000004000becfc() Unknown

razzmatazz · 2017-06-24T13:24:19Z

ok, this seems to be happening to many people, I am trying to build emacs with msys2 on windows with "-g -O"

dropping down to C is rarely fun..

razzmatazz · 2017-06-26T11:08:21Z

I couldn't replicate this myself by building a new emacs.exe from source (emacs-25) branch on windows/mingw-64 in debug mode. I got a fairly complicated solution loaded and autocomplete worked for me:

plain, almost empty emacs init.el
csharp-mode + omnisharp-emacs + company installed from (m)elpa
omnisharp-roslyn v1.21.0 from https://github.com/OmniSharp/omnisharp-roslyn/releases/download/v1.21.0/omnisharp-win-x64-net46.zip

This is on Windows 10 x64

Could any of you provide more details about:

Which version of Windows are you using?
Exact emacs version, which distribution are you using (from which site)?
your init.el configuration excerpt, i.e. the part that concerns omnisharp-emacs?

k-ode · 2017-06-26T13:47:29Z

I run the modified Emacs build from https://sourceforge.net/projects/emacsbinw64/

But I get the same issue when I use the default build from https://www.gnu.org/software/emacs/download.html#windows

In both cases it's this version: GNU Emacs 25.2.1 (x86_64-w64-mingw32)

Windows 10 x64

I used Emacs -Q, and the minimum stuff that is needed for omnisharp-emacs. But I can also reproduce this by running OmniSharp from start-process without any settings applied.

razzmatazz · 2017-06-26T20:24:19Z

@kimgronqvist – I wasn't able to replicate the issue with any of the builds you mentioned when performing the following script with emacs -Q:

omnisharp-start-omnisharp-server
load arbitrary .cs file from the project
enable company-mode
do M-x company-complete <--- I get autocomplete list here and no emacs crashes..

do you have a list of dlls loaded in the process? with process explorer or I don't know..

this is interesting, since I am not able to replicate even if I have almost the same configuration...

razzmatazz · 2017-06-26T20:25:46Z

I do run it in a VirtualBox VM, but I guess this shouldn't matter much..

razzmatazz · 2017-06-26T20:36:00Z

also doing (start-process "test" "*test*" omnisharp-server-executable-path) doesn't crash either of my emacs binaries (custom build and downloaded off the internet) on windows 10 x64 either.. weird..

k-ode · 2017-06-26T21:59:03Z

Very odd. I just tested on another machine with Windows 8 x64, and Emacs still crashes on me.

razzmatazz · 2017-06-27T16:45:18Z

I have another idea..

It could also be related to this code in omnisharp-server-actions.el:

        (make-omnisharp--server-info
         ;; use a pipe for the connection instead of a pty
         (let ((process-connection-type nil))
           (-doto (start-process
                   "OmniServer" ; process name

I believe the way process-connection-type is set here is not good and I had problems with it myself with the legacy (non-roslyn) version before..

If someone could try to do (setq process-connection-type nil) on their init.el or REPL and then try to invoke omnisharp-start-omnisharp-server, and then report if that has helped..

My idea is that it could be that start-process tries to open a `pty’ on windows to communicate with the process and fails for some reason spectacularly (as pty is a foreign concept on Windows and emacs devs could have implemented it in a buggy fashion somehow).

Not sure what is the default value of process-connection-type is on Windows for you , but on my macOS version is says 't which means it DOES try to open a pty instead of a plain pipe by default.

And we don’t need pty here, as the comment says; – but the code below the comment is defective, it creates a let-bound variable instead of setting a global var as start-process would expect.

razzmatazz · 2017-06-29T07:11:16Z

Ok, nevermind.. Tried it myself, didn't help

razzmatazz · 2017-06-29T08:36:56Z

The crash happens in emacs/src/w32proc.c:w32_executable_type

Backtrace stopped: previous frame inner to this frame (corrupt stack?)
(gdb) bt
#0  0x000007fefd9b31f3 in KERNELBASE!DebugBreak () from /c/Windows/system32/KERNELBASE.dll
#1  0x000000040023c953 in emacs_abort () at ../../emacs/src/w32fns.c:10923
#2  0x00000004000fe2ec in terminate_due_to_signal (sig=11, backtrace_limit=40) at ../../emacs/src/emacs.c:394
#3  0x0000000400123f15 in handle_fatal_signal (sig=11) at ../../emacs/src/sysdep.c:1714
#4  0x0000000400123ee5 in deliver_thread_signal (sig=11, handler=0x400123efd <handle_fatal_signal>) at ../../emacs/src/sysdep.c:1688
#5  0x0000000400123f51 in deliver_fatal_thread_signal (sig=11) at ../../emacs/src/sysdep.c:1726
#6  0x00000004002a5ea8 in _gnu_exception_handler (exception_data=0x82aff0) at C:/repo/mingw-w64-crt-git/src/mingw-w64/mingw-w64-crt/crt/crt_handler.c:223
#7  0x0000000077bf7958 in ntdll!__C_specific_handler () from /c/Windows/SYSTEM32/ntdll.dll
#8  0x0000000077c0812d in ntdll!RtlDecodePointer () from /c/Windows/SYSTEM32/ntdll.dll
#9  0x0000000077bf855f in ntdll!RtlUnwindEx () from /c/Windows/SYSTEM32/ntdll.dll
#10 0x0000000077c2bcb8 in ntdll!KiUserExceptionDispatcher () from /c/Windows/SYSTEM32/ntdll.dll
#11 0x0000000400275bc0 in w32_executable_type (filename=0x82bfc0 "c:\\csharp\\omnisharp\\omnisharp.exe", is_dos_app=0x82c134, is_cygnus_app=0x82c130, is_msys_app=0x82c12c, is_gui_app=0x82c128) at ../../emacs/src/w32proc.c:1626
#12 0x0000000400276148 in sys_spawnve (mode=1, cmdname=0x82bfc0 "c:\\csharp\\omnisharp\\omnisharp.exe", argv=0x82c590, envp=0x82c250) at ../../emacs/src/w32proc.c:1802
#13 0x000000040020bf9e in child_setup (in=3, out=6, err=6, new_argv=0x82c590, set_pgrp=true, current_dir=...) at ../../emacs/src/callproc.c:1329
#14 0x00000004001fea90 in create_process (process=..., new_argv=0x82c590, current_dir=...) at ../../emacs/src/process.c:2182
#15 0x00000004001fe685 in Fmake_process (nargs=6, args=0x82c958) at ../../emacs/src/process.c:1904
#16 0x00000004001ac435 in funcall_subr (subr=0x4005df370 <Smake_process>, numargs=6, args=0x82c958) at ../../emacs/src/eval.c:2802
#17 0x00000004001ac156 in Ffuncall (nargs=7, args=0x82c950) at ../../emacs/src/eval.c:2747
#18 0x00000004001ab60b in Fapply (nargs=2, args=0x82cbf0) at ../../emacs/src/eval.c:2378
#19 0x00000004001ac435 in funcall_subr (subr=0x4005dc8d0 <Sapply>, numargs=2, args=0x82cbf0) at ../../emacs/src/eval.c:2802
#20 0x00000004001ac156 in Ffuncall (nargs=3, args=0x82cbe8) at ../../emacs/src/eval.c:2747
#21 0x00000004001f7012 in exec_byte_code (bytestr=..., vector=..., maxdepth=..., args_template=..., nargs=3, args=0x82d2c8) at ../../emacs/src/bytecode.c:641
#22 0x00000004001acb81 in funcall_lambda (fun=..., nargs=3, arg_vector=0x82d2b0) at ../../emacs/src/eval.c:2948
#23 0x00000004001ac8d0 in apply_lambda (fun=..., args=..., count=14) at ../../emacs/src/eval.c:2884
#24 0x00000004001aaf60 in eval_sub (form=...) at ../../emacs/src/eval.c:2268
#25 0x00000004001aa3a5 in Feval (form=..., lexical=...) at ../../emacs/src/eval.c:2045
#26 0x00000004001ac525 in funcall_subr (subr=0x4005dc8a0 <Seval>, numargs=2, args=0x82d710) at ../../emacs/src/eval.c:2824
#27 0x00000004001ac156 in Ffuncall (nargs=3, args=0x82d708) at ../../emacs/src/eval.c:2747
#28 0x00000004001f7012 in exec_byte_code (bytestr=..., vector=..., maxdepth=..., args_template=..., nargs=1, args=0x82de70) at ../../emacs/src/bytecode.c:641
#29 0x00000004001acb81 in funcall_lambda (fun=..., nargs=1, arg_vector=0x82de68) at ../../emacs/src/eval.c:2948
#30 0x00000004001ac19a in Ffuncall (nargs=2, args=0x82de60) at ../../emacs/src/eval.c:2749
#31 0x00000004001f7012 in exec_byte_code (bytestr=..., vector=..., maxdepth=..., args_template=..., nargs=1, args=0x82e768) at ../../emacs/src/bytecode.c:641
#32 0x00000004001acb81 in funcall_lambda (fun=..., nargs=1, arg_vector=0x82e760) at ../../emacs/src/eval.c:2948
#33 0x00000004001ac19a in Ffuncall (nargs=2, args=0x82e758) at ../../emacs/src/eval.c:2749
#34 0x00000004001a3c25 in Ffuncall_interactively (nargs=2, args=0x82e758) at ../../emacs/src/callint.c:252
#35 0x00000004001ac435 in funcall_subr (subr=0x4005dc2c8 <Sfuncall_interactively>, numargs=2, args=0x82e758) at ../../emacs/src/eval.c:2802
#36 0x00000004001ac156 in Ffuncall (nargs=3, args=0x82e750) at ../../emacs/src/eval.c:2747
#37 0x00000004001a63fb in Fcall_interactively (function=..., record_flag=..., keys=...) at ../../emacs/src/callint.c:844
#38 0x00000004001ac551 in funcall_subr (subr=0x4005dc2f8 <Scall_interactively>, numargs=3, args=0x82ec70) at ../../emacs/src/eval.c:2827
#39 0x00000004001ac156 in Ffuncall (nargs=4, args=0x82ec68) at ../../emacs/src/eval.c:2747
#40 0x00000004001f7012 in exec_byte_code (bytestr=..., vector=..., maxdepth=..., args_template=..., nargs=1, args=0x82f450) at ../../emacs/src/bytecode.c:641
#41 0x00000004001acb81 in funcall_lambda (fun=..., nargs=1, arg_vector=0x82f448) at ../../emacs/src/eval.c:2948
#42 0x00000004001ac19a in Ffuncall (nargs=2, args=0x82f440) at ../../emacs/src/eval.c:2749
#43 0x00000004001abbcd in call1 (fn=..., arg1=...) at ../../emacs/src/eval.c:2609
#44 0x0000000400103dd5 in command_loop_1 () at ../../emacs/src/keyboard.c:1486
#45 0x00000004001a8c50 in internal_condition_case (bfun=0x4001034d3 <command_loop_1>, handlers=..., hfun=0x400102ad0 <cmd_error>) at ../../emacs/src/eval.c:1326
#46 0x000000040010314b in command_loop_2 (ignore=...) at ../../emacs/src/keyboard.c:1114
#47 0x00000004001a850e in internal_catch (tag=..., func=0x400103119 <command_loop_2>, arg=...) at ../../emacs/src/eval.c:1091
#48 0x000000040010309e in command_loop () at ../../emacs/src/keyboard.c:1093
#49 0x0000000000000000 in ?? ()

There has been recently (in 24-25 timeframe) been this commit added that touches w32_executable_type:

emacs-mirror/emacs@eedff18

I am trying now to revert it and see if it helps, otherwise I need to fix it somehow myself..

I think the cause here is that the code in w32_executable_type does not check for .NET binaries at all, maybe those have a slightly different PE format that causes the function to crash..

In any case the fix will require a patch to be added upstream and new binaries released before this is fixed.

razzmatazz · 2017-06-29T08:46:24Z

Ok, found a workaround!

You should use omnisharp-win-x86-net46.zip bundle from https://github.com/OmniSharp/omnisharp-roslyn/releases page for emacs not to crash.

Apparently x64 .net binaries cause emacs to crash when those are invoked with start-process (some of the time).

I will update omnisharp-emacs README.md to reflect this.

…ggest a solution. Sometimes emacs crashes on Windows when omnisharp-win-x64-net46.zip bundle is used. The cause is detailed more thoroughly in OmniSharp#315. Using x86 (32bit) binaries keeps emacs from crashing. The actual fix will need to be submitted to emacs upstream.

razzmatazz · 2017-06-29T09:45:43Z

This crash and a patch has been submitted to upstream emacs.

https://debbugs.gnu.org/cgi/bugreport.cgi?bug=27527

I am closing this issue as a workaround is there and upstream should fix the bug in emacs eventually.

Please reopen if this doesn't help you.

k-ode · 2017-06-30T09:50:31Z

Great work!

mikavilpas · 2017-06-30T13:13:30Z

Yeah good job!

vermiculus · 2019-01-18T20:19:09Z

I got here from this documentation -- does it need to be updated?

razzmatazz added the platform-windows label Jun 16, 2017

razzmatazz mentioned this issue Jun 29, 2017

Reflect the problem with x64 omnisharp-roslyn server binary on windows and suggest a solution. #319

Merged

razzmatazz closed this as completed Jun 29, 2017

razzmatazz added the emacs-crash label Jun 29, 2017

razzmatazz mentioned this issue Jun 29, 2017

OmniSharp-Roslyn features #178

Open

This was referenced Jul 5, 2017

Issue with auto complete #306

Closed

OmniSharp.exe using Windows Subsystem for Linux #316

Open

This was referenced Jul 17, 2017

feature-omnisharp-rosalyn-support branch crashes Windows emacs 24.5.1 when starting server #260

Closed

Failure loading Import from csproj OmniSharp/omnisharp-roslyn#888

Closed

razzmatazz mentioned this issue Oct 31, 2017

omnisharp-server: "System.NotSupportedException: Command '*' is not supported." #394

Closed

sebasmonia mentioned this issue Nov 13, 2017

Emacs 26.09 on Windows - Omnisharp server 64 bits hangs Emacs #402

Closed

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Emacs crash when start omnisharp server on windows #315

Emacs crash when start omnisharp server on windows #315

hateonion commented Jun 16, 2017

razzmatazz commented Jun 16, 2017 •

edited

Loading

ghost commented Jun 21, 2017

k-ode commented Jun 22, 2017 •

edited

Loading

razzmatazz commented Jun 22, 2017

neeasade commented Jun 22, 2017 •

edited

Loading

k-ode commented Jun 22, 2017

ihdavids commented Jun 24, 2017

razzmatazz commented Jun 24, 2017

razzmatazz commented Jun 26, 2017 •

edited

Loading

k-ode commented Jun 26, 2017 •

edited

Loading

razzmatazz commented Jun 26, 2017 •

edited

Loading

razzmatazz commented Jun 26, 2017

razzmatazz commented Jun 26, 2017 •

edited

Loading

k-ode commented Jun 26, 2017

razzmatazz commented Jun 27, 2017 •

edited

Loading

razzmatazz commented Jun 29, 2017

razzmatazz commented Jun 29, 2017 •

edited

Loading

razzmatazz commented Jun 29, 2017 •

edited

Loading

razzmatazz commented Jun 29, 2017 •

edited

Loading

k-ode commented Jun 30, 2017

mikavilpas commented Jun 30, 2017

vermiculus commented Jan 18, 2019

Emacs crash when start omnisharp server on windows #315

Emacs crash when start omnisharp server on windows #315

Comments

hateonion commented Jun 16, 2017

razzmatazz commented Jun 16, 2017 • edited Loading

ghost commented Jun 21, 2017

k-ode commented Jun 22, 2017 • edited Loading

razzmatazz commented Jun 22, 2017

neeasade commented Jun 22, 2017 • edited Loading

k-ode commented Jun 22, 2017

ihdavids commented Jun 24, 2017

razzmatazz commented Jun 24, 2017

razzmatazz commented Jun 26, 2017 • edited Loading

k-ode commented Jun 26, 2017 • edited Loading

razzmatazz commented Jun 26, 2017 • edited Loading

razzmatazz commented Jun 26, 2017

razzmatazz commented Jun 26, 2017 • edited Loading

k-ode commented Jun 26, 2017

razzmatazz commented Jun 27, 2017 • edited Loading

razzmatazz commented Jun 29, 2017

razzmatazz commented Jun 29, 2017 • edited Loading

razzmatazz commented Jun 29, 2017 • edited Loading

razzmatazz commented Jun 29, 2017 • edited Loading

k-ode commented Jun 30, 2017

mikavilpas commented Jun 30, 2017

vermiculus commented Jan 18, 2019

razzmatazz commented Jun 16, 2017 •

edited

Loading

k-ode commented Jun 22, 2017 •

edited

Loading

neeasade commented Jun 22, 2017 •

edited

Loading

razzmatazz commented Jun 26, 2017 •

edited

Loading

k-ode commented Jun 26, 2017 •

edited

Loading

razzmatazz commented Jun 26, 2017 •

edited

Loading

razzmatazz commented Jun 26, 2017 •

edited

Loading

razzmatazz commented Jun 27, 2017 •

edited

Loading

razzmatazz commented Jun 29, 2017 •

edited

Loading

razzmatazz commented Jun 29, 2017 •

edited

Loading

razzmatazz commented Jun 29, 2017 •

edited

Loading