Github | Tony Bai

标签 github 下的文章

Go 1.18新特性前瞻：原生支持Fuzzing测试

十二月 1, 2021
0 条评论

本文永久链接 – https://tonybai.com/2021/12/01/first-class-fuzzing-in-go-1-18

今年6月初，Go官博发表了一篇名为《Fuzzing is Beta Ready》的文章，文中称gotip版本已经原生支持Fuzzing并开始了公测。这意味着Fuzzing将以一等公民(first-class citizen)的身份正式加入到即将于2022年2月发布的Go 1.18版本中：

图：关于add fuzz test的issue已经关闭并放入Go1.18里程碑

有了对Fuzzing技术的原生支持后，我相信会有更多代码经过Fuzzing测试，未来不久Go社区的Go代码的安全水平将会得到整体提升。本文我们就来简单聊聊Fuzzing这个Go 1.18版本的新特性。

注意：在Go 1.18版本Beta版发布前要想体验Fuzzing特性，需要自行安装gotip版本，安装方法如下：

$go install golang.org/dl/gotip@latest // go 1.17版本及以后使用go install。go 1.16及之前的版本用go get
$gotip download
$gotip version // 验证安装是否ok

为什么Go要支持Fuzzing

无论是在过去的单机时代，还是在今天的云计算时代，亦或是已经出现苗头的人工智能时代，安全都是程序员在构建软件过程中必不可少且日益重要的考量因素。

同时，安全也是Go语言设计者们在语言设计伊始就为Go设定的一个重要目标。在语言层面，Go提供了很多“安全保障”特性，比如：

显式类型转换，不允许隐式转换；
针对数组、切片的下标越界访问的检查；
不安全代码隔离到unsafe包中，并提供安全使用unsafe包的几条rules；
go module构建模式内置包hash校验，放置恶意包对程序的攻击；
雇佣安全专家，提供高质量且及时更新的crypto包，尽量防止使用第三方加解密包带来的不安全性；
支持纯静态编译，避免动态连接到恶意动态库；
原生提供方便测试的工具链，并支持测试覆盖率统计。
… …

进入云原生时代后，Go语言成为了云原生基础设施与云原生服务的头部语言，由Go语言建造的基础设施、中间件以及应用服务支撑着这个世界的很多重要系统的运行，这些系统对安全性的要求不言而喻。尤其是在“输入”方面，这些系统都会被要求：无论用户使用什么本文数据、二进制数据，无论用户如何构造协议包、无论用户提供的文件包含何种内容，系统都应该是安全健壮的，不会因为用户的故意攻击而出现处理异常、被操控，甚至崩溃。

这就需要我们的系统面对任何输入的情况下都能正确处理，但传统的代码review、静态分析、人工测试和自动化的单元测试无法穷尽所有输入组合，尤其是难于模拟一些无效的、意料之外的、随机的、边缘的输入数据。

于是，Go社区的一些安全方面的专家就尝试将业界在解决这方面问题的优秀实践引入Go，Fuzzing技术就是其中最重要的一个。

什么是Fuzzing？

说了这么半天，啥是Fuzzing？

Fuzzing，又叫fuzz testing，中文叫做模糊测试或随机测试。其本质上是一种自动化测试技术，更具体一点，它是一种基于随机输入的自动化测试技术，常被用于发现处理用户输入的代码中存在的bug和问题。

在具体实现上，Fuzzing不需要像单元测试那样使用预先定义好的数据集作为程序输入，而是会通过数据构造引擎自行构造或基于开发人员提供的初始数据构造一些随机数据，并作为输入提供给我们的程序，然后监测程序是否出现panic、断言失败、无限循环等。这些构造出来的随机数据被称为语料(corpus)。另外Fuzz testing不是一次性执行的测试，如果不限制执行次数和执行时间，Fuzz testing会一直执行下去，因此它也是一种持续测试的技术。

Fuzzing技术形态最初的出现可追溯到以打孔卡承载的数据作为计算机输入的时代。那个时候开发人员经常从废纸篓里随便拿出几张打孔卡输入到自己的程序中来验证程序是否可以正确处理这些“随机”的输入。但Fuzzing测试作为一门技术理论走进广大开发者视野是始于1988年的Barton Miller教授的研究成果，

当时任教于威斯康星大学的Barton Miller教授在高级操作系统研究生班（CS736）上的一个秋季项目中运用了随机测试技术，他通过fuzzing对一个UNIX工具进行测试，为该工具自动生成随机输入和命令行参数。该项目旨在通过快速连续执行大量的随机输入来测试UNIX命令行程序的可靠性，直到它们崩溃。当时Miller团队能够使他们所测试的实用程序中的25%至33%崩溃。然后，他们对每个崩溃的程序进行调试，以确定原因，并对每个检测到的故障进行分类。1990年，Miller团队对外发表了这一成果。自那以后，Fuzzing技术便确定了自己独立的研究分支，并逐渐发展演化到今天。在过去的十多年中，Fuzzing测试的技术水平有了很大的提高，以AFL(american fuzzy lop)、AFL++、libFuzzer、go-fuzz、syzkaller等开源项目为代表的Fuzzing项目已经被各种编程语言的开发人员应用于实践，并且取得了不错的“战绩”。

Fuzzing是对其他形式的测试、代码审查和静态分析的补充，它通过生成一个有趣的输入语料库，而这些输入几乎不可能用手去想去写出来，因此极易被传统类型的测试所遗漏。Fuzzing可以帮助开发人员发现难以发现的稳定性、逻辑性甚至是安全性方面的错误，特别是当被测系统变得更加复杂时。

更为关键的，也是Fuzzing技术能够流行开来的原因是构建一个Fuzzing测试足够简单。有了上述Fuzzing相关开源工具和开源库的支持，Fuzzing test不再是需要专业知识才能成功使用的技术，并且现代Fuzzing引擎可以更有策略的、更快的、更有效地找到有用的输入语料。

Go对Fuzzing技术支持的简要回顾

说过将Fuzzing技术引入Go，我们不能不提到一个人，它就是Go goroutine调度器的作者、前Intel Black Belt级工程师，现Google工程师的Dmitry Vyukov，它也是Go语言首个fuzzing工具go-fuzz的作者。

2015年的GopherCon大会上，Dmitry Vyukov在其名为“[Go Dynamic Tools]”的presentation中就介绍了go-fuzz。我个人的gocmpp项目就是使用go-fuzz搭建的Fuzz test。

之后，Dmitry Vyukov发现虽然通过第三方的fuzzing工具可以解决Go开发者关于Fuzzing的部分需求，但有很多功能特性是通过第三方工具无法实现的。2016年，Dmitry Vyukov在Go官方issue列表中创建“cmd/compile: coverage instrumentation for fuzzing”的issue归纳说明了这些问题，也是从那时开始，Dmitry Vyukov极力推进Fuzzing进入Go原生工具链的。

2017年，Dmitry Vyukov首次提出希望在Go工具链中原生支持Fuzzing的Proposal，并给出了为什么我们需要在Go工具链的支持下使Fuzzing成为Go开发的标准做法的原因。

之后，Dmitry还开源了一个名为syzkaller的项目，该项目用Go语言实现了一个针对操作系统内核的Fuzzing引擎。

Dmitry虽然是goroutine调度器的开发者，也是Google员工，但他却不是Go语言团队的一员，也许正是因为这样，又或是Go核心团队对新特性保持的一贯的谨慎态度，该Dmitry的提议一直处理讨论与反馈的状态，直到2020年中旬，Go安全团队的Katie Hockman才正式发布了在Go中原生支持Fuzzing的新提案。

新提案与Dmitry的提案的目标是相同的，都是期望在Go工具链中加入对Fuzzing的原生支持。不同的是，新提案中的API稍微复杂一些，新提案允许以编程方式设置初始语料库的种子语料，并支持字节字符串以外的输入类型，包括原生的基本数据类型(整型、浮点、字符串等)、复合数据类型(数组、map、结构体等)以及实现了BinaryMarshaler/BinaryUnmarshaler或TextMarshaler/TextUnmarshaler接口的自定义类型。

不过Go fuzzing没有如预期加入到Go 1.17版本中，再继续打磨了半年后，Go 1.18版本正式接受了原生支持Fuzzing这个特性，Fuzzing成为Go的“一等公民”。

如何使用成为Go“一等公民”的Fuzzing

作为普通Go开发人员，我们无需关心Fuzzing引擎是如何实现的，我们只需根据Go提供的Fuzzing API使用就好了。前面也提到过了，Fuzzing技术之所以可以流行到现在，更多也是因为其使用起来十分简单。

Go 1.18将fuzz testing纳入了go test工具链，与单元测试、性能基准测试等一起成为了Go原生测试工具链中的重要成员。

go fuzzing test的测试用例与普通的测试用例(TestXxx)、性能基准测试(BenchmarkXxx)等一样放在xx_test.go中，只不过用例对应的函数名样式换为了FuzzXxx了。一个简单的Fuzzing test用例如下：

func FuzzXxx(f *testing.F) {
    // 设置种子语料(可选)

    // 执行Fuzzing
    f.Fuzz(func(t *testing.T, b []byte) {
        //... ...
    })
}

我们通过go test -fuzz命令即可执行所有xx_test.go中以Fuzz为前缀的Fuzz testing用例。不过这里要注意的是go test -fuzz会先进行普通TestXxx的用例执行，之后才会执行FuzzXxx。

我们看到：每个FuzzXxx函数的参数列表是固定的，fuzzing在testing包中新增了一个F结构体类型，其与testing.T、testing.B是类似的，用于表示一次Fuzzing test的执行，结构体变量中存储了此次fuzzing test执行的上下文信息。

FuzzXxx函数的最主要只能就是调用testing.F的Fuzz方法对目标函数/方法执行测试。testing.F的Fuzz方法接受一个函数类型的参数，按照fuzzing提案的说明，该函数的第一个参数必须是*testing.T，后面可以是多个输入参数，且输入参数的类型不局限于传统的byte切片，还可以是上面提到过的原生的基本数据类型(整型、浮点、字符串等)、复合数据类型(数组、map、结构体等)以及实现了BinaryMarshaler/BinaryUnmarshaler或TextMarshaler/TextUnmarshaler接口的自定义类型。

Fuzz方法会根据目标所需的输入参数类型生成fuzzing后的数据，并将这些数据作为输入参数传给其参数代表的函数。

Go开发人员也可以通过testing.F的Add方法为fuzzing过程提供初始的种子语料(seed corpus)，后续fuzzing test会基于这些种子语料进行fuzzing，虽然这不是必须的，但提供与目标处理逻辑相关的种子语料，可能会加速被测目标中问题的暴露。

当然我们也可以不通过testing.F的Add方法来提供种子语料，go fuzzing还允许你通过文件的形式为每个FuzzXxx函数提供种子语料，以FuzzXxx为例，我们可以在testdata/fuzz/FuzzXxx目录下以文件的形式放置其初始语料，比如：

// testdata/fuzz/FuzzXxx/corpus1
go test fuzz v1
[]byte("ABC\xa8\x8c\xb3G\xfc")

在这个种子语料文件中，第一行go test fuzz v1是go fuzzing要求的文件头，用于标识这是一个种子语料文件，并且使用的编解码器的版本为v1。而下面的一行则是种子语料，其实这行就是一个go代码的片段，fuzzing工具会将其解码后直接作为输入赋值给被测目标。后续的fuzzing过程也是基于这个种子语料的。注意：种子语料可以有很多个，不同语料单独放置在一行中即可。目前，这个种子语料文件需要手工编辑，后续go团队可能会提供相关工具以方便对种子语料文件的编辑，尤其是针对一些二进制数据的种子语料。

下面我们用一个例子来看看如何使用go原生fuzzing。我这里还以我的gocmpp项目为例，对项目中的Submit消息的Unpack方法进行fuzz testing。

我们先来看不提供初始种子语料的情况。

不提供初始种子语料

虽说FuzzXxx测试用例可以与普通用例TestXxx放在一个xxx_test.go文件中，但例子中为了着重强调我们是在写Fuzz testing用例，我们将FuzzXxxx函数放在submit_fuzz_test.go中，下面是不显式提供初始种子语料的FuzzSubmit：

// submit_fuzz_test.go

//go:build go1.18
// +build go1.18

package cmpp_test

import (
    "testing"

    cmpp "github.com/bigwhite/gocmpp"
)

func FuzzSubmit(f *testing.F) {
    f.Fuzz(func(t *testing.T, data []byte) {
        p := &cmpp.Cmpp2SubmitReqPkt{}
        _ = p.Unpack(data)
    })
}

我们看到，为了兼容go 1.18之前的版本，我们使用build指示符来告诉编译器这个文件只在go 1.18及后续版本才参与编译，这样go 1.17及之前的版本会ignore这个源文件。

使用下面命令我们来运行一下这个fuzz test：

$gotip test -v -fuzz  .
=== RUN   TestTypeString
--- PASS: TestTypeString (0.00s)
... ...
=== RUN   TestCmppTerminateRspPktPack
--- PASS: TestCmppTerminateRspPktPack (0.00s)
=== RUN   TestCmppTerminateRspUnpack
--- PASS: TestCmppTerminateRspUnpack (0.00s)
=== FUZZ  FuzzSubmit
fuzz: elapsed: 0s, gathering baseline coverage: 0/38 completed
fuzz: elapsed: 0s, gathering baseline coverage: 38/38 completed, now fuzzing with 8 workers
fuzz: elapsed: 3s, execs: 403378 (134408/sec), new interesting: 0 (total: 38)
fuzz: elapsed: 6s, execs: 800451 (132348/sec), new interesting: 0 (total: 38)
fuzz: elapsed: 9s, execs: 1104435 (101366/sec), new interesting: 0 (total: 38)
fuzz: elapsed: 12s, execs: 1346809 (80789/sec), new interesting: 0 (total: 38)
fuzz: elapsed: 15s, execs: 1718297 (123747/sec), new interesting: 1 (total: 39)
^Cfuzz: elapsed: 16s, execs: 1771361 (92170/sec), new interesting: 1 (total: 39)
--- PASS: FuzzSubmit (15.59s)
PASS
ok      github.com/bigwhite/gocmpp  15.607s

通过上面的执行我们得到几点信息；

gotip test -fuzz会先进行普通TestXxx的用例执行，之后才会执行FuzzXxx。
fuzz testing默认会一直执行下去，直到遇到crash。如果要限制fuzz testing的执行时间，可以使用-fuzztime，比如下面的命令允许fuzz testing只执行10s：

$gotip test -v  -fuzztime 10s -fuzz .

覆盖率引导的fuzzing

我们看到：测试输出内容中包含“gathering baseline coverage字样”，这里要告诉大家的是，go fuzzing使用的是一种名为“覆盖率引导的fuzzing(coverage-guided fuzzing)”。我们知道Fuzzing测试使用的是随机生成的随机数据对被测目标进行测试，如果仅仅是用凭空随机的方式生成的输入很难有效找到边缘情况，当今大多数现代的fuzzing工具都是用了coverage-guided fuzzing的引擎来驱动测试，它可以确定新生成的语料是否能覆盖到新的代码路径。Dmitry在“Fuzzing support for Go”一文中曾经对coverage-guided fuzzing的引擎的工作逻辑做过如下描述：

从一些（可能是空的）输入的语料库开始
for {
    从语料库中随机选择一个输入
    对输入进行变异(mutate)
    执行变异后的输入并收集代码覆盖率
    如果该输入给出了新的覆盖率，则将其添加到语料库中
}

收集代码覆盖率数据和检测一个输入”给出新的覆盖率”并非易事，这也是为什么很多第三方fuzzing工具难于实现的原因，而加入到go原生工具链中，这些特性可借助Go编译器以及已有的设施来完成。

缓存新加入的语料

在上面go test -fuzz执行过程中，新生成的可以覆盖新代码路径的语料放置在哪里了呢？Go fuzzing会将其缓存在cache路径下，我在本机的gocache路径下发现如下与fuzz有关的内容：

//GOCACHE="/Users/tonybai/Library/Caches/go-build"

$ls /Users/tonybai/Library/Caches/go-build/fuzz/github.com/bigwhite/gocmpp/FuzzSubmit
01e40385855b3d317d42bf7ba4a9118702d867492fe2cd52bc84e554769480e5
06ba4bdb19de593e669c642987e270fe2488d4d58ecd712db136a3e011071253
086eabebec22d361087ce571571d86b1cbe1ad3e713f981473275f2c8fa64f09
... ...

go fuzzing会为每个FuzzXxx函数建立对应的语料缓存。目前fuzz cache的默认路径为$GOCACHE/fuzz/包路径/FuzzXxx，后续可能会提供环境变量或cmd option，以允许开发人员自定义fuzzing语料的缓存路径。

前面我们说过，fuzzing test默认会一直执行下去，如果不限制执行次数和执行时间，执行Fuzzing test的机器要有足够的存储才行。而要想清理过多的fuzz缓存，用gotip clean -cache是不行的，需要为clean加上-fuzzcache才可以清除fuzz的cache。

使用Add方法提供种子语料

下面是通过testing.F的Add方法为fuzzing test提供种子语料的例子：

//go:build go1.18
// +build go1.18

package cmpp_test

import (
    "testing"

    cmpp "github.com/bigwhite/gocmpp"
)

func FuzzSubmit(f *testing.F) {
    data := []byte{
        0x00, 0x00, 0x00, 0xbd, 0x00, 0x00, 0x00, 0x04, 0x00, 0x00, 0x00, 0x17, 0x00, 0x00, 0x00, 0x00,
        0x00, 0x00, 0x00, 0x00, 0x01, 0x01, 0x01, 0x01, 0x74, 0x65, 0x73, 0x74, 0x00, 0x00, 0x00, 0x00,
        0x00, 0x00, 0x02, 0x31, 0x33, 0x35, 0x30, 0x30, 0x30, 0x30, 0x32, 0x36, 0x39, 0x36, 0x00, 0x00,
        0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x08, 0x39, 0x30, 0x30, 0x30, 0x30,
        0x31, 0x30, 0x32, 0x31, 0x30, 0x00, 0x00, 0x00, 0x00, 0x31, 0x35, 0x31, 0x31, 0x30, 0x35, 0x31,
        0x33, 0x31, 0x35, 0x35, 0x35, 0x31, 0x30, 0x31, 0x2b, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00,
        0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x39, 0x30, 0x30, 0x30, 0x30,
        0x31, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00,
        0x01, 0x31, 0x33, 0x35, 0x30, 0x30, 0x30, 0x30, 0x32, 0x36, 0x39, 0x36, 0x00, 0x00, 0x00, 0x00,
        0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x1e, 0x6d, 0x4b, 0x8b, 0xd5, 0x00, 0x67, 0x00, 0x6f, 0x00,
        0x63, 0x00, 0x6d, 0x00, 0x70, 0x00, 0x70, 0x00, 0x20, 0x00, 0x73, 0x00, 0x75, 0x00, 0x62, 0x00,
        0x6d, 0x00, 0x69, 0x00, 0x74, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00,
    }
    f.Add(data[8:])
    f.Fuzz(func(t *testing.T, data []byte) {
        p := &cmpp.Cmpp2SubmitReqPkt{}
        _ = p.Unpack(data)
    })
}

在上面代码中，我们使用了一个正确的cmpp2 submit消息包的数据作为种子语料，后续fuzzing会基于该语料做mutate，生成其他语料对Submit的Unpack方法进行测试。执行该fuzz test的输出与不设置种子语料的输出差别不大：

$gotip test -fuzz .
fuzz: elapsed: 0s, gathering baseline coverage: 0/1 completed
fuzz: elapsed: 0s, gathering baseline coverage: 1/1 completed, now fuzzing with 8 workers
fuzz: elapsed: 3s, execs: 395490 (131760/sec), new interesting: 20 (total: 20)
fuzz: elapsed: 6s, execs: 795164 (133251/sec), new interesting: 22 (total: 22)
fuzz: elapsed: 9s, execs: 1106761 (103875/sec), new interesting: 22 (total: 22)
^Cfuzz: elapsed: 11s, execs: 1281577 (92654/sec), new interesting: 22 (total: 22)
PASS
ok      github.com/bigwhite/gocmpp  10.917s

使用testdata/fuzz/FuzzXxx目录提供种子语料

除了通过Add方法添加种子语料外，我们还可以在项目的testdata/fuzz/FuzzXxx目录下为FuzzXxx用例提供种子语料：

$tree testdata
testdata
└── fuzz
    └── FuzzSubmit
        └── corpus1

$cat testdata/fuzz/FuzzSubmit/corpus1
go test fuzz v1
[]byte("ABC\xa8\x8c\xb3G\xfc")

我们把FuzzSubmit代码恢复为不带有Add的形式：

func FuzzSubmit(f *testing.F) {
    f.Fuzz(func(t *testing.T, data []byte) {
        p := &cmpp.Cmpp2SubmitReqPkt{}
        _ = p.Unpack(data)
    })
}

执行这一用例，输出入下结果：

$gotip test -fuzz .
fuzz: elapsed: 0s, gathering baseline coverage: 0/23 completed
fuzz: elapsed: 0s, gathering baseline coverage: 23/23 completed, now fuzzing with 8 workers
fuzz: elapsed: 3s, execs: 355689 (118485/sec), new interesting: 3 (total: 25)
fuzz: elapsed: 6s, execs: 623934 (89390/sec), new interesting: 5 (total: 27)
fuzz: elapsed: 9s, execs: 756400 (44154/sec), new interesting: 5 (total: 27)
^Cfuzz: elapsed: 10s, execs: 771910 (28387/sec), new interesting: 5 (total: 27)
PASS
ok      github.com/bigwhite/gocmpp  9.564s

模拟crash

Fuzzing技术作为其他测试的一种补充，可以用于发现代码中潜在的不易被发现的问题，但这一过程有时候也是很漫长的。因此在这里我们模拟一个crash的产生来看看：当fuzzing test过程中发现代码bug时，fuzzing都做了那些事情。

我们在被测方法Unpack中故意放置了一个panic语句：

// submit.go
func (p *Cmpp2SubmitReqPkt) Unpack(data []byte) error {
    ... ...
    panic("panic for fuzz demo")
    ... ...
}

这样，当fuzzing test执行到这里时Unpack方法就会panic，而fuzzing会生成crash报告并终止fuzz testing执行。

但要注意的是：go test -fuzz是先运行TestXxx，然后再运行FuzzXxx的，如果在TestXxx中发生了panic，那么go fuzzing是不会生成crash报告的。另外还有一点要格外注意：go fuzzing将种子语料作为输入时出现的panic也是不会生成crash报告的，因为，此时对数据的fuzzing还没有真正开始。因此，这里我们使用上面那个不带有种子语料的FuzzSubmit。

好了，我们执行一下fuzzing test：

$gotip test -fuzz .
fuzz: elapsed: 0s, gathering baseline coverage: 0/27 completed
fuzz: minimizing 148-byte crash file
fuzz: elapsed: 0s, gathering baseline coverage: 0/27 completed
--- FAIL: FuzzSubmit (0.03s)
    --- FAIL: FuzzSubmit (0.00s)
        testing.go:1319: panic: panic for fuzz demo
            goroutine 49 [running]:
            runtime/debug.Stack()
                /Users/tonybai/sdk/gotip/src/runtime/debug/stack.go:24 +0x90
            testing.tRunner.func1()
                /Users/tonybai/sdk/gotip/src/testing/testing.go:1319 +0x1f2
            panic({0x11ca860, 0x1241148})
                /Users/tonybai/sdk/gotip/src/runtime/panic.go:838 +0x207
            github.com/bigwhite/gocmpp.(*Cmpp2SubmitReqPkt).Unpack(0xc00025a5a0, {0xc000024400, 0x1, 0x80})
                /Users/tonybai/Go/src/github.com/bigwhite/gocmpp/submit.go:262 +0x625
            github.com/bigwhite/gocmpp_test.FuzzSubmit.func1(0x0?, {0xc000024400, 0x1, 0x80})
                /Users/tonybai/Go/src/github.com/bigwhite/gocmpp/submit_fuzz_test.go:32 +0x45
            reflect.Value.call({0x11ccf40?, 0x12111c8?, 0x13?}, {0x1200df5, 0x4}, {0xc000217080, 0x2, 0x2?})
                /Users/tonybai/sdk/gotip/src/reflect/value.go:543 +0x814
            reflect.Value.Call({0x11ccf40?, 0x12111c8?, 0x10f9980?}, {0xc000217080, 0x2, 0x2})
                /Users/tonybai/sdk/gotip/src/reflect/value.go:339 +0xbf
            testing.(*F).Fuzz.func1.1(0x0?)
                /Users/tonybai/sdk/gotip/src/testing/fuzz.go:327 +0x20b
            testing.tRunner(0xc000201860, 0xc0003a0900)
                /Users/tonybai/sdk/gotip/src/testing/testing.go:1409 +0x102
            created by testing.(*F).Fuzz.func1
                /Users/tonybai/sdk/gotip/src/testing/fuzz.go:316 +0x5b8

    Crash written to testdata/fuzz/FuzzSubmit/582528ddfad69eb57775199a43e0f9fd5c94bba343ce7bb6724d4ebafe311ed4
    To re-run:
    go test github.com/bigwhite/gocmpp -run=FuzzSubmit/582528ddfad69eb57775199a43e0f9fd5c94bba343ce7bb6724d4ebafe311ed4
FAIL
exit status 1
FAIL    github.com/bigwhite/gocmpp  0.037s

我们看到go fuzzing在执行第一个测试时就发生了crash，fuzzing将crash输出了crash报告，并将引发这一crash的语料放入了testdata/fuzz/FuzzSubmit目录下：

$tree testdata
testdata
└── fuzz
    └── FuzzSubmit
        └── 582528ddfad69eb57775199a43e0f9fd5c94bba343ce7bb6724d4ebafe311ed4

查看一下引发crash的语料：

$cat testdata/fuzz/FuzzSubmit/582528ddfad69eb57775199a43e0f9fd5c94bba343ce7bb6724d4ebafe311ed4
go test fuzz v1
[]byte("0")

如果是真实的fuzz测试引发了crash，我们可以将该语料提取出来，建立针对它的TestXxx或为现有TestXxx添加一条测试数据来验证目标方法是否真实存在缺陷，如果的确存在缺陷，我们就需要修复它，并在修复后再次运行TestXxx，以保证我们的修复是有效的。

小结

在即将到来的Go 1.18中，Go fuzzing将正式成为Go的“一等公民”，Go将原生支持Fuzzing。不过Go fuzzing刚刚加入，可能还存在各种问题，根据以往经验，在2-3个版本后，go fuzzing必将成熟稳定起来，到那时，Gopher们就又拥有了一柄挖掘潜在bug和安全问题的利器了。

参考资料

《Fuzzing in Go》 – https://lwn.net/Articles/829242/
《Fuzzing is Beta Ready》 – https://go.dev/blog/fuzz-beta
《Design Draft: First Class Fuzzing》 – https://golang.org/s/draft-fuzzing-design
issue: testing: add fuzz test support – https://github.com/golang/go/issues/44551
Fuzz testing doc – https://pkg.go.dev/testing@master#hdr-Fuzzing
《Go语言随机测试工具go-fuzz》 – http://tonybai.com/2015/12/08/go-fuzz-intro/
维基百科Fuzzing – https://en.wikipedia.org/wiki/Fuzzing
Fuzzing introduction by OWASP – https://owasp.org/www-community/Fuzzing
Fuzzing support for Go – https://docs.google.com/document/u/1/d/1zXR-TFL3BfnceEAWytV8bnzB2Tfp6EPFinWVJ5V4QC8/pub
Go播客：深入研究Fuzzing及Go官方Fuzzing提案 – https://changelog.com/gotime/145

“Gopher部落”知识星球正式转正（从试运营星球变成了正式星球）！“gopher部落”旨在打造一个精品Go学习和进阶社群！高品质首发Go技术文章，“三天”首发阅读权，每年两期Go语言发展现状分析，每天提前1小时阅读到新鲜的Gopher日报，网课、技术专栏、图书内容前瞻，六小时内必答保证等满足你关于Go语言生态的所有需求！部落目前虽小，但持续力很强，欢迎大家加入！

img{512x368}

我爱发短信：企业级短信平台定制开发专家 https://tonybai.com/。smspush : 可部署在企业内部的定制化短信平台，三网覆盖，不惧大并发接入，可定制扩展；短信内容你来定，不再受约束, 接口丰富，支持长短信，签名可选。2020年4月8日，中国三大电信运营商联合发布《5G消息白皮书》，51短信平台也会全新升级到“51商用消息平台”，全面支持5G RCS消息。

著名云主机服务厂商DigitalOcean发布最新的主机计划，入门级Droplet配置升级为：1 core CPU、1G内存、25G高速SSD，价格5$/月。有使用DigitalOcean需求的朋友，可以打开这个链接地址：https://m.do.co/c/bff6eed92687 开启你的DO主机之路。

Gopher Daily(Gopher每日新闻)归档仓库 – https://github.com/bigwhite/gopherdaily

我的联系方式：

微博：https://weibo.com/bigwhite20xx
微信公众号：iamtonybai
博客：tonybai.com
github: https://github.com/bigwhite
“Gopher部落”知识星球：https://public.zsxq.com/groups/51284458844544

微信赞赏：
img{512x368}

商务合作方式：撰稿、出书、培训、在线课程、合伙创业、咨询、广告合作。

ants：在Submit中再调用当前Pool的Submit可能导致阻塞

十一月 27, 2021
1 条评论

本文永久链接 – https://tonybai.com/2021/11/27/ants-call-submit-in-submit-may-cause-blocking

1. goroutine pool的必要性

Go在并发程序方面的一个小创新就是支持轻量级用户线程goroutine，不过虽然goroutine很轻，但并不是免费的，尤其是Go程序中存在大量goroutine反复启停时(比如采用每连接一个goroutine的处理http短连接的http server，在大并发的情况下就是如此)，Go运行时启停和调度goroutine的开销还是蛮大的。这个时候我们对goroutine pool的需求就诞生了。

goroutine pool减小开销的主要思路就是复用：即创建出的goroutine在做完一个task后不退出，而是等待下一个task，这样来减少goroutine反复创建和销毁带来的开销。除此之外，由于goroutine已经被创建，当任务到达时，可以不需要等待goroutine创建就能立即执行，提高响应速度。并且通过goroutine pool，我们还可以严格控制启动的goroutine的数量，避免因外部条件变化带来的goroutine数量的暴涨与暴跌。

在Go社区中，优秀的goroutine pool的实现有不少，Andy Pan开源的ants就是其中之一。根据ants在github上的当前状态来看，它在Go社区范围的应用很广泛，Andy Pan对issue的响应也是十分快的。这也是我们在项目中引入ants的原因。

这篇文章要写的就是我们在使用ants过程中遇到的问题，以及对问题的简单分析与解决过程，这里分享出来的目的也是希望大家能避免遇到同类问题。

2. 问题描述

我们在对系统进行压测时，发现系统出现了“死锁”。经过查找，我们将问题锁定在对ants包的使用上面了。我们的工程师使用ants时，在传给Pool.Submit方法的task函数中又调用了同一个Pool的Submit方法。之后他便用下面代码复现了这个问题：

package main

import (
    "fmt"
    "time"

    "github.com/panjf2000/ants/v2"
)

func main() {
    p, _ := ants.NewPool(100)

    for {
        p.Submit(func() {
            for i := 0; i < 3; i++ {
                p.Submit(func() {
                    fmt.Println(time.Now().Unix())
                })
            }
        })
    }
}

这个代码使用了ants 2.4.6版本，我们在ubuntu 20.04上使用Go 1.17运行这个程序，很快程序就锁住了。

3. 原因分析

ants代码不多，原理上也不复杂，我们直接来看看Submit的代码：

// https://github.com/panjf2000/ants/blob/master/pool.go (commit fdb318c1d7cef8e448f1bc2bbb03519ff69939da)
func (p *Pool) Submit(task func()) error {
    if p.IsClosed() {
        return ErrPoolClosed
    }
    var w *goWorker
    if w = p.retrieveWorker(); w == nil {
        return ErrPoolOverload
    }
    w.task <- task
    return nil
}

我们看到，Submit方法的主要逻辑就是从Pool中获取一个worker，然后将传入的task写入worker的task channel中。再来看看retrieveWorker方法：

// https://github.com/panjf2000/ants/blob/master/pool.go(commit fdb318c1d7cef8e448f1bc2bbb03519ff69939da)

225 func (p *Pool) retrieveWorker() (w *goWorker) {
226     spawnWorker := func() {
227         w = p.workerCache.Get().(*goWorker)
228         w.run()
229     }
230
231     p.lock.Lock()
232
233     w = p.workers.detach()
234     if w != nil { // first try to fetch the worker from the queue
235         p.lock.Unlock()
236     } else if capacity := p.Cap(); capacity == -1 || capacity > p.Running() {
237         // if the worker queue is empty and we don't run out of the pool capacity,
238         // then just spawn a new worker goroutine.
239         p.lock.Unlock()
240         spawnWorker()
241     } else { // otherwise, we'll have to keep them blocked and wait for at least one worker to be put back into pool.
242         if p.options.Nonblocking {
243             p.lock.Unlock()
244             return
245         }
246     retry:
247         if p.options.MaxBlockingTasks != 0 && p.blockingNum >= p.options.MaxBlockingTasks {
248             p.lock.Unlock()
249             return
250         }
251         p.blockingNum++
252         p.cond.Wait() // block and wait for an available worker
253         p.blockingNum--
254         var nw int
255         if nw = p.Running(); nw == 0 { // awakened by the scavenger
256             p.lock.Unlock()
257             if !p.IsClosed() {
258                 spawnWorker()
259             }
260             return
261         }
262         if w = p.workers.detach(); w == nil {
263             if nw < capacity {
264                 p.lock.Unlock()
265                 spawnWorker()
266                 return
267             }
268             goto retry
269         }
270
271         p.lock.Unlock()
272     }
273     return
274 }

retrieveWorker方法负责从Pool中取出一个空闲worker。

retrieveWorker先加锁(line 231)，然后尝试从worker queue中获取空闲worker(line 233)，如果成功获得，那么解锁返回(line 234~235)；

如果队列为空，且池子容量(capacity)还没有满，那就创建一个新worker(line 236~240)；

如果队列为空，且池子容量(capacity)也满了(line 241)，那么判断一下p.options.Nonblocking是否为true，如果为true，说明不想阻塞，那么retrieveWorker返回nil(line 247~250)。retrieveWorker返回nil，那么Submit返回ErrPoolOverload错误。

如果用户没有将p.options.Nonblocking设置为true(p.options.Nonblocking默认为false)，retrieveWorker判断p.options.MaxBlockingTasks这个option，但p.options.MaxBlockingTasks这个option默认为0，所以不满足条件。代码进入p.cond.Wait()，问题就出在这里！

我们简化一下复现的步骤，假设我们的pool的容量是1，初始我们调用1次Submit获得了worker，这个worker开始执行task，而这个被执行的task又调用了同一个Pool的Submit，之后进入retrieveWorker方法，由于没有设置p.options.Nonblocking=true，cap容量也满了，由于此时没有空闲worker了，于是该worker进入p.cond.Wait。此时程序便进入死锁状态。将这个示例整理为代码，如下：

package main

import (
    "fmt"
    "time"

    "github.com/panjf2000/ants/v2"
)

func main() {
    p, _ := ants.NewPool(1)

    p.Submit(func() {
        p.Submit(func() {
            fmt.Println(time.Now().Unix())
        })
    })

    time.Sleep(1000 *time.Second)
}

大家可以执行一下这段代码，死锁必然马上出现。

如果我们修改一下ants的pool.go中的代码，在p.cond.Wait()前后加入一些打印语句，就像下面这样：

p.blockingNum++
fmt.Println("==== cond wait ...===")
p.cond.Wait() // block and wait for an available worker
fmt.Println("==== cond wait return ===")
p.blockingNum--

然后，我们通过replace将demo对ants的依赖改为本地依赖，运行demo后，我们将看到下面输出：

==== cond wait ...===

demo将一直停在上面这行输出的地方不再向下执行了。

4. 官方策略

我将这个问题提交到ants的issue列表中，Andy Pan很快给了响应。按照Andy的说法，目前ants并不禁止Submit()里再调用同一个Pool的Submit()，只是需要设置一下Pool无可用worker时不阻塞即可，就像下面代码这样：

p, _ := ants.NewPool(1, ants.WithNonblocking(true))

我个人又考虑了一下这个问题，设置WithNonblocking为true，Submit方法会返回ErrPoolOverload错误，那么调用者需要考虑如何处理这个错误，最大的可能就是反复重试。

另外如果不设置ants.WithNonblocking(true)，我就是要让代码去等，正常情况下，这种阻塞应该是可以解开的，当task执行完毕后，自然可以空闲出一个goroutine来接新task。但问题就在于：如果我在Submit()里再调用同一个Pool的Submit()，一旦所有task都是这种情况，这个阻塞可能是无法解开的。所以我建议Andy在文档中说明一下这种情况。Andy也接受了这个建议，在最新的commit中在Submit和Invoke方法的注释中增加了对这种情况的说明。

5. 解决方法

那么如果我就是要在Submit中调用Submit该如何处理呢？一种很直接的思路就是使用两个Pool！比如将上面的demo改成下面这样就可以正常运行了：

func main() {
    p1, _ := ants.NewPool(1)
    p2, _ := ants.NewPool(1)

    p1.Submit(func() {
        p2.Submit(func() {
            fmt.Println(time.Now().Unix())
        })
    })

    time.Sleep(10*time.Second)
}

6. 补充一个因上述ants阻塞问题导致的其他问题

我们的系统在生产场景中会有大量并发连接，针对每个连接都会有定时器处理会话相关的过期、删除等。考虑到定时器太多，我们选择了维护定时器开销更小的时间轮算法的定时器实现。在github上，RussellLuo/timingwheel是目前star最多的，但美中不足的是其作者Russelluo似乎对这一项目不是很热心了，issue响应也很少了。我们抱着先使用再自主改进的态度引入了RussellLuo/timingwheel。

考虑到RussellLuo/timingwheel每执行一个fired的timer对应的task时，都启动一个新goroutine去执行，我们将下面代码做了修改：

func (tw *TimingWheel) addOrRun(t *Timer) {
    if !tw.add(t) {
        // Already expired

        // Like the standard time.AfterFunc (https://golang.org/pkg/time/#AfterFunc),
        // always execute the timer's task in its own goroutine.
        go t.task()
    }
}

改为：

func (tw *TimingWheel) addOrRun(t *Timer) {
    if !tw.add(t) {
        // Already expired

        // Like the standard time.AfterFunc (https://golang.org/pkg/time/#AfterFunc),
        // always execute the timer's task in its own goroutine.
        tw.workerPool.Submit(func() {
            t.task()
        })
    }
}

我们用一个ants pool(pool size默认为1024)来减少goroutine频繁创建销毁带来的开销。

在开发与功能测试阶段，改造后的RussellLuo/timingwheel表现不错，一切都还ok。进入到压测阶段，我们发现，在大量连接一起断连后，大部分新启动的用于清除会话的定时器都无法工作，时间到了后，timer也不fire，导致我们的连接断连逻辑无法执行。我用下面的例子复现了这个问题(为了方便复现现象，我们把ants的Pool size改为1)：

package main

import (
    "fmt"
    "sync"
    "time"

    "github.com/RussellLuo/timingwheel"
)

var tw *timingwheel.TimingWheel

type tickScheduler struct {
    interval time.Duration
}

func (s *tickScheduler) Next(prev time.Time) time.Time {
    next := prev.Add(s.interval)
    return next
}

type Timer struct {
    timer *timingwheel.Timer
}

func (t *Timer) Stop() bool {
    return t.timer.Stop()
}

func TickFunc(d time.Duration, f func()) *Timer {
    s := &tickScheduler{
        interval: d,
    }
    t := tw.ScheduleFunc(s, f)
    return &Timer{t}
}

func main() {
    tw = timingwheel.NewTimingWheel(10*time.Millisecond, 60)
    tw.Start()
    defer tw.Stop()

    var c = make(chan string)
    var wg sync.WaitGroup
    wg.Add(10)

    for i := 0; i < 10; i++ {
        go func() {
            timer := TickFunc(time.Millisecond*10, func() {
                c <- "timer fired"
            })
            defer timer.Stop()

            time.Sleep(time.Second)

            for i := 0; i < 10; i++ {
                s := <-c
                if s != "timer fired" {
                    fmt.Errorf("%d: want [timer fired], got [%s]\n", i+1, s)
                } else {
                    fmt.Printf("%d: timer fired\n", i+1)
                }
            }
            wg.Done()
        }()
    }

    wg.Wait()
}

运行这个程序，程序也很快锁住：

$ go run main.go
1: timer fired
1: timer fired
1: timer fired
1: timer fired
1: timer fired
2: timer fired
2: timer fired
2: timer fired
2: timer fired
//锁住

这个问题与本文开始的问题一样，也是在Submit中调用同pool的Submit，调用Submit的两处位置，我在下面的代码中用注释标记了出来。

func (tw *TimingWheel) ScheduleFunc(s Scheduler, f func()) (t *Timer) {
    expiration := s.Next(time.Now().UTC())
    if expiration.IsZero() {
        // No time is scheduled, return nil.
        return
    }   

    t = &Timer{
        expiration: timeToMs(expiration),
        task: func() {
            // Schedule the task to execute at the next time if possible.
            expiration := s.Next(msToTime(t.expiration))
            if !expiration.IsZero() {
                t.expiration = timeToMs(expiration)
                tw.addOrRun(t)  // 如果timer已经fire，那么就调用pool.Submit
            }   

            // Actually execute the task.
            f()
        },
    }
    tw.addOrRun(t) // 如果timer已经fire，那么就调用pool.Submit

    return
}

btw，关于时间轮算法是否在资源占用，维护timer开销方面胜过Go标准库timer，这里其实并没有细致比对过。Go标准库的timer性能一直在完善，后续有时间需要认真对比一下。

img{512x368}

Gopher Daily(Gopher每日新闻)归档仓库 – https://github.com/bigwhite/gopherdaily

我的联系方式：