GO语言(二十九):模糊测试(下)-

Python017

GO语言(二十九):模糊测试(下)-,第1张

语料库文件以特殊格式编码。这是种子语料库和生成语料库的相同格式。

下面是一个语料库文件的例子:

第一行用于通知模糊引擎文件的编码版本。虽然目前没有计划未来版本的编码格式,但设计必须支持这种可能性。

下面的每一行都是构成语料库条目的值,如果需要,可以直接复制到 Go 代码中。

在上面的示例中,我们在 a []byte后跟一个int64。这些类型必须按顺序与模糊测试参数完全匹配。这些类型的模糊目标如下所示:

指定您自己的种子语料库值的最简单方法是使用该 (*testing.F).Add方法。在上面的示例中,它看起来像这样:

但是,您可能有较大的二进制文件,您不希望将其作为代码复制到您的测试中,而是作为单独的种子语料库条目保留在 testdata/fuzz/{FuzzTestName} 目录中。golang.org/x/tools/cmd/file2fuzz 上的file2fuzz工具可用于将这些二进制文件转换为为[]byte.

要使用此工具:

语料库条目:语料库 中的一个输入,可以在模糊测试时使用。这可以是特殊格式的文件,也可以是对 (*testing.F).Add。

覆盖指导: 一种模糊测试方法,它使用代码覆盖范围的扩展来确定哪些语料库条目值得保留以备将来使用。

失败的输入:失败的输入是一个语料库条目,当针对 模糊目标运行时会导致错误或恐慌。

fuzz target: 模糊测试的目标功能,在模糊测试时对语料库条目和生成的值执行。它通过将函数传递给 (*testing.F).Fuzz实现。

fuzz test: 测试文件中的一个被命名为func FuzzXxx(*testing.F)的函数,可用于模糊测试。

fuzzing: 一种自动化测试,它不断地操纵程序的输入,以发现代码可能容易受到的错误或漏洞等问题。

fuzzing arguments: 将传递给 模糊测试目标的参数,并由mutator进行变异。

fuzzing engine: 一个管理fuzzing的工具,包括维护语料库、调用mutator、识别新的覆盖率和报告失败。

生成的语料库: 由模糊引擎随时间维护的语料库,同时模糊测试以跟踪进度。它存储在$GOCACHE/fuzz 中。这些条目仅在模糊测试时使用。

mutator: 一种在模糊测试时使用的工具,它在将语料库条目传递给模糊目标之前随机操作它们。

package: 同一目录下编译在一起的源文件的集合。

种子语料库: 用户提供的用于模糊测试的语料库,可用于指导模糊引擎。它由 f.Add 在模糊测试中调用提供的语料库条目以及包内 testdata/fuzz/{FuzzTestName} 目录中的文件组成。这些条目默认使用go test运行,无论是否进行模糊测试。

测试文件: 格式为 xxx_test.go 的文件,可能包含测试、基准、示例和模糊测试。

漏洞: 代码中的安全敏感漏洞,可以被攻击者利用。

Go语言自亮相以来并没有展示一个明确的方向,Google员工将Go语言称为一个“试验性语言”,称其试图融合Python等动态语言的开发速度和C或C++等编译语言的性能和安全。一位Go语言的支持者概括而言Go语言如下:简单、快速、安全、并发、快乐编程、开源;但Go语言缺乏方向以及其“集大成者”的尝试很容易会导致其学猫不成学狗也不成,沦为四不像。尽管如此,编者仍然觉得Go语言有相当大的潜力:很多开发者对它感兴趣——不仅它的最初设计者阵容强大,而且在参与修改源代码的人群中也不乏大牛级人物。这很有可能帮助Go语言找到适合自己的方向,开拓系统编程的新方向。

sync.Map是1.9才推荐的并发安全的map,除了互斥量以外,还运用了原子操作,所以在这之前,有必要了解下 Go语言——原子操作

go1.10\src\sync\map.go

entry分为三种情况:

从read中读取key,如果key存在就tryStore。

注意这里开始需要加锁,因为需要操作dirty。

条目在read中,首先取消标记,然后将条目保存到dirty里。(因为标记的数据不在dirty里)

最后原子保存value到条目里面,这里注意read和dirty都有条目。

总结一下Store:

这里可以看到dirty保存了数据的修改,除非可以直接原子更新read,继续保持read clean。

有了之前的经验,可以猜测下load流程:

与猜测的 区别

由于数据保存两份,所以删除考虑:

先看第二种情况。加锁直接删除dirty数据。思考下貌似没什么问题,本身就是脏数据。

第一种和第三种情况唯一的区别就是条目是否被标记。标记代表删除,所以直接返回。否则CAS操作置为nil。这里总感觉少点什么,因为条目其实还是存在的,虽然指针nil。

看了一圈貌似没找到标记的逻辑,因为删除只是将他变成nil。

之前以为这个逻辑就是简单的将为标记的条目拷贝给dirty,现在看来大有文章。

p == nil,说明条目已经被delete了,CAS将他置为标记删除。然后这个条目就不会保存在dirty里面。

这里其实就跟miss逻辑串起来了,因为miss达到阈值之后,dirty会全量变成read,也就是说标记删除在这一步最终删除。这个还是很巧妙的。

真正的删除逻辑:

很绕。。。。