Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Install go1.10.2 failed with errno 38 (netpoll failed) #3194

Closed
zhengxiaoyao0716 opened this issue May 15, 2018 · 3 comments
Closed

Install go1.10.2 failed with errno 38 (netpoll failed) #3194

zhengxiaoyao0716 opened this issue May 15, 2018 · 3 comments

Comments

@zhengxiaoyao0716
Copy link

zhengxiaoyao0716 commented May 15, 2018

  • Your Windows build number: (Type ver at a Windows Command Prompt)

Microsoft Windows [版本 10.0.14393]

  • What you're doing and what's happening: (Copy&paste specific commands and their output, or include screen shots)

I installed the go1.10.2 followed the golang official guide, but got some error. I have already report it to golang, but it seems not a Go bug.
image

  • What's wrong / what should be happening instead:

Go tools works well.

  • Strace of the failing command, if applicable: (If some_command is failing, then run strace -o some_command.strace -f some_command some_args, and link the contents of some_command.strace in a gist here)

go env go run xxx.go and such on.

runtime: epollwait on fd 4 failed with 38
fatal error: runtime: netpoll failed

runtime stack:
runtime.throw(0x8b4137, 0x17)
        /usr/local/go/src/runtime/panic.go:616 +0x81
runtime.netpoll(0x9e71e90f00, 0x7fec00000000)
        /usr/local/go/src/runtime/netpoll_epoll.go:75 +0x216
runtime.sysmon()
        /usr/local/go/src/runtime/proc.go:4265 +0x424
runtime.mstart1(0x0)
        /usr/local/go/src/runtime/proc.go:1227 +0xe7
runtime.mstart()
        /usr/local/go/src/runtime/proc.go:1193 +0x76

goroutine 1 [runnable]:
os.newFile(0x5, 0x8a9f6f, 0x2, 0x2, 0x0)
        /usr/local/go/src/os/file_unix.go:94 +0x1d1
os.Pipe(0x9, 0x8, 0x8, 0xc4201e20b8)
        /usr/local/go/src/os/pipe_linux.go:32 +0xb7
os/exec.(*Cmd).writerDescriptor(0xc4202106e0, 0x910960, 0xc420224150, 0x7fecd8647bc0, 0xc4201e20b8, 0x7fecd86a0d90)
        /usr/local/go/src/os/exec/exec.go:267 +0x63
os/exec.(*Cmd).stdout(0xc4202106e0, 0x0, 0x0, 0x0)
        /usr/local/go/src/os/exec/exec.go:243 +0x3d
os/exec.(*Cmd).Start(0xc4202106e0, 0x1, 0xc420224150)
        /usr/local/go/src/os/exec/exec.go:368 +0x10c
os/exec.(*Cmd).Run(0xc4202106e0, 0xc420224150, 0xc4201bb450)
        /usr/local/go/src/os/exec/exec.go:302 +0x2b
os/exec.(*Cmd).CombinedOutput(0xc4202106e0, 0x1, 0x1, 0xc420217340, 0x1c, 0x1c)
        /usr/local/go/src/os/exec/exec.go:521 +0x106
cmd/go/internal/work.(*Builder).gccSupportsFlag(0xc420222000, 0xc4201da140, 0x1, 0x1, 0x8b444c, 0x18, 0x0)
        /usr/local/go/src/cmd/go/internal/work/exec.go:1889 +0x53c
cmd/go/internal/work.(*Builder).compilerCmd(0xc420222000, 0xc4201da140, 0x1, 0x1, 0x8a9d5d, 0x1, 0x0, 0x0, 0xc4201e0240, 0xc4201e01e0, ...)
        /usr/local/go/src/cmd/go/internal/work/exec.go:1833 +0x712
cmd/go/internal/work.(*Builder).GccCmd(0xc420222000, 0x8a9d5d, 0x1, 0x0, 0x0, 0xc4201e01e0, 0x2, 0x2)
        /usr/local/go/src/cmd/go/internal/work/exec.go:1742 +0x6b
cmd/go/internal/envcmd.ExtraEnvVars(0xc42006e260, 0x406f4e, 0x401650)
        /usr/local/go/src/cmd/go/internal/envcmd/env.go:122 +0x255
cmd/go/internal/envcmd.runEnv(0xafec80, 0xc42000c090, 0x0, 0x0)
        /usr/local/go/src/cmd/go/internal/envcmd/env.go:158 +0x8fa
main.main()
        /usr/local/go/src/cmd/go/main.go:140 +0x7e1

goroutine 5 [syscall]:
os/signal.signal_recv(0x0)
        /usr/local/go/src/runtime/sigqueue.go:139 +0xa6
os/signal.loop()
        /usr/local/go/src/os/signal/signal_unix.go:22 +0x22
created by os/signal.init.0
        /usr/local/go/src/os/signal/signal_unix.go:28 +0x41
@ianlancetaylor
Copy link

The problem is almost certainly that with Go 1.10.1 we changed from calling the epoll_wait system call to calling the epoll_pwait system call. I bet that WSL implements the former but not the latter. epoll_pwait has been in the Linux kernel since 2.6.19.

@therealkenc
Copy link
Collaborator

My kingdom for people to fill out the issue template. In which case the ENOSYS wouldn't be a speculative bet but instead show up in the requested strace log.

@Brian-Perkins
Copy link

Build 14393 lacks many features, including epoll_pwait. When you are able to update I think you will be happy with how much better things work.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

5 participants