为什么在 macOS 上，exec.Command.Start() 函数可能会出现挂起的情况？

本篇文章主要是结合我之前面试的各种经历和实战开发中遇到的问题解决经验整理的，希望这篇《为什么在 macOS 上，exec.Command.Start() 函数可能会出现挂起的情况？》对你有很大帮助！欢迎收藏，分享给更多的需要的朋友学习~

我在运行程序的特定开发版本时偶尔会挂起，而使用官方版本时似乎不会挂起。开发版本的主要不同之处在于它引入了更多的 go std 库，但（大部分）它不使用这些库；因此可执行文件更大，并且完成了 static-var 和 init() 初始化，这可能会增加遇到某些竞争条件的可能性。

git bisect run 将（golang）罪魁祸首识别为 6becb033341602f2df9d7c55cc23e64b925bbee2：

author: ian lance taylor <[email protected]>
date:   thu apr 11 16:53:11 2019 -0700

[...]

    runtime: switch to using new timer code

diff --git a/src/runtime/time.go b/src/runtime/time.go
index fea5d6871c..db48a932d4 100644
--- a/src/runtime/time.go
+++ b/src/runtime/time.go
@@ -14,7 +14,7 @@ import (
 )

 // temporary scaffolding while the new timer code is added.
-const oldtimers = true
+const oldtimers = false

 // package time knows the layout of this structure.
 // if this struct changes, adjust ../time/sleep.go:/runtimetimer.

浏览了这个小变化带来的差异后，我强烈倾向于在这个“新计时器代码”和/或其启用的代码中存在一些竞争条件。

无论是通过 ctrl-\ (sigquit) 还是 delve attach，罪魁祸首似乎始终是此处的 cmd.start() 调用：

func sh(dir string, stdin io.reader, stdout io.writer, stderr io.writer, name string, args []string) object {
cmd := exec.command(name, args...)
cmd.dir = dir
cmd.stdin = stdin

var stdoutbuffer, stderrbuffer bytes.buffer
if stdout != nil {
    cmd.stdout = stdout
} else {
    cmd.stdout = &stdoutbuffer
}
if stderr != nil {
    cmd.stderr = stderr
} else {
    cmd.stderr = &stderrbuffer
}

err := cmd.start()
paniconerr(err)

从那里开始的堆栈跟踪看起来非常相似，直到到达 syscall/exec_unix.go （在 go 源代码树中）。然后，在 delve 中，forkandexecinchild() 调用似乎挂起，而 ctrl-\ 将 readlen() 调用显示为挂起：

// Kick off child.
pid, err1 = forkAndExecInChild(argv0p, argvp, envvp, chroot, dir, attr, sys, p[1])
if err1 != 0 {
    err = Errno(err1)
    goto error
}
ForkLock.Unlock()

// Read child error status from pipe.
Close(p[1])
n, err = readlen(p[0], (*byte)(unsafe.Pointer(&err1)), int(unsafe.Sizeof(err1)))
Close(p[0])
if err != nil || n != 0 {

forkandexecinchild() 代码似乎挂在 exec_darwin.go:206 处，这是循环内对 libc_dup2_trampoline 的系统调用。假设这只是对 dup2() 的调用，我想不出它挂起的任何原因；但我已经通过 delve 在那里（而不是其他地方）“捕获”了至少两次挂起的测试运行，尽管这可能只是使用 delve attach ... 与 ctrl-\ (sigquit强>)?

多年来（好吧，几十年）我已经调试并修复了围绕此类活动的各种问题，但我对 go 生态系统相对较新，并且在对发生的情况有一定了解之前不想提交错误报告上。

特别是，cmd.start() 的记录如下：

start 启动指定的命令，但不等待它完成。

因此，从表面上看，即使不是完全有问题，这些挂起似乎都表明该调用是罪魁祸首，这似乎很奇怪。 ie。如果不等待，为什么会挂起？也许看起来像直接操作系统调用的东西实际上在底层操作系统调用之前或之后检查了 go 线程机制，并且挂在那里。

运行测试套件时会出现问题，通常需要大约 12 秒才能运行。我已经循环运行了大约 5 个小时来执行 git bisect run;虽然它通常会在 15 分钟内触发，但我发现它需要 3 个多小时才能触发。

如果有人想更深入地研究（哈！）并尝试重现它，我正在开发的程序是“joker”，这是开发版本（我的分支）：

https://github.com/jcburley/joker/（请参阅分支 gostd；通过 ./run.sh 构建。）

在 os x 上运行 ./all-tests.sh 时（偶尔）会出现此问题。到目前为止，只有当该脚本运行 ./flag-tests.sh 或 ./linter-tests.sh 时才会发生挂起，而 ./eval-tests.sh 还没有发生挂起（这似乎也很奇怪，因为总是这样）由于字母顺序，首先运行）。

同一个测试套件在我的 ubuntu linux (ryzen 3) 开发机上循环运行超过 24 小时，没有挂起。 windows 7 循环也已经持续了几个小时，到目前为止没有挂起。

重现更新：

• 从 6a569f243e028f823a9f20bfd9da7bdfab8699a4 开始的主版本复制（到目前为止相当快）
• git bisect run 确定（golang）罪魁祸首为 6becb033341602f2df9d7c55cc23e64b925bbee2；仔细检查了该提交和之前的提交（通过运行后者的五个实例几个小时），看起来是一个可靠的结果
• 在 ubuntu linux ryzen 3 (amd64-linux) 和 windows 7（amd64-windows、2011-era i7 box）上运行多个小时后仍无法重现
• 在针对官方 joker 进行 os x 测试数小时后未重现
• 1.13.10 没有重现（几个小时后）

与官方（主/发布）版本相比，开发版本的 joker 可执行文件要大得多；虽然这个小测试套件没有执行大部分额外的代码，但由于引入了额外的 go std 库（包），可能会运行一些 init() 或 static-var-init 代码，可能会做出更多贡献（如果不是完全） ）而不是通过启动额外的 go 和/或操作系统线程、增加争用等来解决纯粹的大小和与大小相关的问题。

解决方案

这是 Go for MacOS 上的一个错误，已在 https://go-review.googlesource.com/c/go/+/372798/ 中修复

对于修复之前受影响的 Go 版本，解决方法是将 -Wl,-bind_at_load 传递给链接器，这可以通过使用 -ldflags="-extldflags=-Wl,-bind_at_load" 调用 go 来完成

今天关于《为什么在 macOS 上，exec.Command.Start() 函数可能会出现挂起的情况？》的内容介绍就到此结束，如果有什么疑问或者建议，可以在golang学习网公众号下多多回复交流；文中若有不正之处，也希望回复留言以告知！