Skip to content
New issue

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

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

Already on GitHub? # 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.

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

No branches or pull requests

5 participants