概述

2019 年 11 月 21 日,golang 的官方 github 仓库提交了一个 https://github.com/golang/go/issues/35750 ,该 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.Accept()
            ...
        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("http://localhost:4444/")
    if err != nil {
        panic(err)
    }
    fmt.Println("\n第二次请求")

    _, err = http.Get("http://localhost:4444/")
    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)
    }
}

timg.jpg


本文由 吾爱 创作,采用 知识共享署名 3.0,可自由转载、引用,但需署名作者且注明文章出处。

还不快抢沙发

添加新评论