neovim / go-client

Nvim Go client
https://pkg.go.dev/github.com/neovim/go-client
Apache License 2.0
578 stars 36 forks source link

Error: bootstrap_look_up: Unknown service name (1102) #35

Closed akiyosi closed 6 years ago

akiyosi commented 6 years ago

Hi. I'm using Gonvim which I forked the original. Gonvim can generate a additional neovim session with command :GonvimWorkspaceNew, but sometimes the application crashes when creating a new session. (There are also cases not to crash.) I debuged this problem, I found SEGV in the following section of neovim/go-client.

https://github.com/neovim/go-client/blob/master/nvim/nvim.go#L235

Received signal 11 SEGV_MAPERR 000000000000
[end of stack trace]
Segmentation fault: 11
logout
Saving session...[0430/215716.953392:ERROR:mach_port_broker.mm(43)] bootstrap_look_up: Unknown service name (1102)

Are there any ideas to avoid this problem?

akiyosi commented 6 years ago

My environment is the following:

OS: macOS High Sierra (10.13.4) golang: go1.10 darwin/amd64

garyburd commented 6 years ago

A SEGV is Cmd.Start is likely outside the control of this package. Please provide more information:

akiyosi commented 6 years ago

Thank you for reply. I continue to investigate this issue, which may be a bug in macOS :( I tracing the problem, So I confirmed to the point that the cause seems to be ahead of startProcess function in exec_posix.go of golang os package.

Arguments to NewChildProcess

It is cause via NewEmbeded() function with arg [].

stack trace

Here is the Delve stacktrace. The message bootstrap_look_up: Unknown service name (1102) was output by Gonvim debug build to Stdout.

   535: // func mach_semaphore_wait(sema uint32) int32
   536: TEXT runtimeツキmach_semaphore_wait(SB),NOSPLIT,$0
   537:         MOVL    sema+0(FP), DI
   538:         MOVL    $(0x1000000+36), AX     // semaphore_wait_trap
   539:         SYSCALL
=> 540:         MOVL    AX, ret+8(FP)
   541:         RET
   542:
   543: // func mach_semaphore_timedwait(sema, sec, nsec uint32) int32
   544: TEXT runtimeツキmach_semaphore_timedwait(SB),NOSPLIT,$0
   545:         MOVL    sema+0(FP), DI
Command failed: bad access
(dlv) bt
0  0x00000000040998eb in runtime.mach_semaphore_wait
   at /Users/akiyoshi/.goenv/versions/1.10.0/src/runtime/sys_darwin_amd64.s:540
1  0x0000000004066052 in runtime.semasleep1
   at /Users/akiyoshi/.goenv/versions/1.10.0/src/runtime/os_darwin.go:438
2  0x0000000004094023 in runtime.semasleep.func1
   at /Users/akiyoshi/.goenv/versions/1.10.0/src/runtime/os_darwin.go:457
3  0x0000000004066184 in runtime.semasleep
   at /Users/akiyoshi/.goenv/versions/1.10.0/src/runtime/os_darwin.go:456
4  0x000000000404a569 in runtime.notesleep
   at /Users/akiyoshi/.goenv/versions/1.10.0/src/runtime/lock_sema.go:167
5  0x000000000406ddff in runtime.stoplockedm
   at /Users/akiyoshi/.goenv/versions/1.10.0/src/runtime/proc.go:2096
6  0x000000000406f31c in runtime.schedule
   at /Users/akiyoshi/.goenv/versions/1.10.0/src/runtime/proc.go:2488
7  0x000000000406f511 in runtime.park_m
   at /Users/akiyoshi/.goenv/versions/1.10.0/src/runtime/proc.go:2599
8  0x00000000040957ab in runtime.mcall

Instructions for reproducing the problem

  1. Download Gonvim
  2. Deploy the Neovim
  3. Start Gonvim and excute the command :GonvimWorkspaceNew (Run it several times until it is reproduced)

Anyway it seems not to be a problem of neovim/goclient, so I will close this issue.

garyburd commented 6 years ago

Thank you for providing the details.

Because NewChildProcess is a simple wrapper around the os/exec package and the panic is in the runtime it seems unlikely that the issue is in NewChildProcess.

Is it possible that the application leaks file descriptors or some other resource and the panic is the result of a resource limit?

The child process is started with the environment and working directory of the current process. Are these values constant from run to run of the command?

akiyosi commented 6 years ago

Thank you for your opinion.

Is it possible that the application leaks file descriptors or some other resource and the panic is the result of a resource limit?

I confirmed that there is no possibility of resource limit.

The child process is started with the environment and working directory of the current process. Are these values constant from run to run of the command?

Is there any possibility of crashing by accessing with go-client/nvim while the new neovim process starting?(Is it executed asynchronously?) Currently the application is running neovim with the following code.

https://github.com/akiyosi/gonvim/blob/master/editor/workspace.go#L227

akiyosi commented 6 years ago

The cause was found out.

The application executes neovim asynchronously in the following code, and it goes to a function which accessing the go-client/nvim package in parallel, so the application crashes when neovim's activation is in progress.

https://github.com/akiyosi/gonvim/blob/master/editor/workspace.go#L204

I'm sorry for my application implementation problem. I appreciate your appropriate comment.