您的位置 首页 golang

Go1.13 标准库的 http 包爆出重大 bug,你的项目中招了吗?

概述

2019 年 11 月 21 日,golang 的官方 github 仓库提交了一个 ,该 issue 指出如果初始化 http. Server 结构体时指定了一个非空的 ConnContext 成员函数,且如果在该函数内使用了 context.Value 方法写入数据到上下文并返回,则 Context 将会以链表的方式泄漏。

这是一个很恐怖的 bug,因为一方面 http.Server 是几乎所有市面上流行 web 框架如 gin,beego 的底层依赖,一旦发生问题则全部中招,一个都跑不了;另一方面则 ConnContext 函数在每一个请求初始化时都会被调用,这意味着如果一旦发生泄漏,则服务端程序几乎一定会溢出。

据官方开发人员表示,该 bug 于 1.13 版本引进,目前已经在 1.13.5 修复。

影响范围

所有 1.13~1.13.4 版本,使用原生 http.Server 指定了 ConnContext 成员函数,且在该函数中使用 With*方法写入数据并返回新 Context;或者使用了上层框架的相应功能。

现象

内存根据访问量持续上升,且 pprof 分析发现 cpu 大量耗费在 Context 的底层方法上。

故障原理

问题出在 Server.Serve 方法,该方法是 http.Server 启动的底层唯一入口,负责循环 Accept 连接以及为每个新连接开启 goroutine 做下一步处理。

来看看出问题的代码,为了简洁这里略去不必要代码:

 type Server struct {
    ...
// ConnContext optionally specifies a function that modifies
// the context used for a new connection c. The provided ctx
// is derived from the base context and has a ServerContextKey
// value.
ConnContext func(ctx context.Context, c net.Conn) context.Context
    ...
}

func (srv *Server) Serve(l net.Listener) error {
        ...
baseCtx := context.Background()
        ...
ctx := context.WithValue(baseCtx, ServerContextKey, srv)
for {
rw, e := l.A cc ept()
        ...
if cc := srv.ConnContext; cc !=  nil  {
ctx = cc(ctx, rw)
if ctx == nil {
panic("ConnContext returned nil")
}
}
                ...
go c.serve(ctx)
}
}
  

我们知道 Context 是一个反向链表结构,从最初的 Background 通过各种 With 方法推入表头节点,而 With 方法返回的则是新的表头节点。

从上边的代码中我们看到,如果 srv.ConnContext 不为空,则每次 Accept 连接后都会调用此函数并传入 ctx,然后将返回的结果存入 ctx 中,这意味着如果在此函数中使用 With 函数写入节点并返回,则该节点将被缓存到全局的 ctx,从而造成泄漏。

复现

这个 bug 非常容易复现,下面我们复现一下:

 // go version:1.13.4

func main() {
var count int32 = 0
server := &http.Server{
Addr: ":4444",
Handler: http.HandlerFunc(func(rw http.ResponseWriter, req *http.Request) {
rw.Header().Set("Connection", "close")
}),
ConnContext: func(ctx context.Context, c net.Conn) context.Context {
atomic.AddInt32(&count, 1)
if c2 := ctx.Value("count"); c2 != nil {
fmt.Printf("发现了遗留数据: %d\n", c2.(int32))
}
fmt.Printf("本次数据: %d\n", count)
return context.WithValue(ctx, "count", count)
},
}
go func() {
panic(server.ListenAndServe())
}()

var err error

fmt.Println("第一次请求")
_, err = http.Get("#34;)
if err != nil {
panic(err)
}
fmt.Println("\n第二次请求")

_, err = http.Get("#34;)
if err != nil {
panic(err)
}
}
  

结果:

 第一次请求
本次数据: 1

第二次请求
发现了遗留数据: 1
本次数据: 2
  

可以看到,第二个从请求的 Context 中能读取到第一个请求的 Context 中写入的数据,确实发生了泄漏。

修复

我们首先要理解 ConnContext 这个函数的作用,按照设计它应该是为每个请求的 Context 做一些初始化处理,然后将这个处理后的 Context 链传入go c.serve(ctx),而不应该缓存到全局;下一个请求过来后应该将原始的 Context 传入 ConnContext 进行处理,从而得到新的 Context 链。

明白了目的,再看看问题代码,我们发现罪魁祸首在这里

 ctx = cc(ctx, rw)
  

这一行错误地将 cc 方法生成的新链缓存到了全局,导致泄漏(ps:实在是搞不懂 google 的大神居然会犯这么低级且致命的错误…)。

修复后的代码如下:

 func (srv *Server) Serve(l net.Listener) error {
...
baseCtx := context.Background()
...
ctx := context.WithValue(baseCtx, ServerContextKey, srv)
for {
rw, e := l.Accept()
...
connCtx = ctx
if cc := srv.ConnContext; cc != nil {
connCtx = cc(connCtx, rw)
if connCtx == nil {
panic("ConnContext returned nil")
}
}
...
go c.serve(connCtx)
}
}
  

文章来源:智云一二三科技

文章标题:Go1.13 标准库的 http 包爆出重大 bug,你的项目中招了吗?

文章地址:https://www.zhihuclub.com/86438.shtml

关于作者: 智云科技

热门文章

网站地图