Closed akiyosi closed 6 years ago
My environment is the following:
OS: macOS High Sierra (10.13.4) golang: go1.10 darwin/amd64
A SEGV is Cmd.Start is likely outside the control of this package. Please provide more information:
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.
It is cause via NewEmbeded() function with arg []
.
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
: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.
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?
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
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.
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
Are there any ideas to avoid this problem?