websocket连接：错误nil值出现在websocket.(*Conn).beginMessage()

在Golang实战开发的过程中，我们经常会遇到一些这样那样的问题，然后要卡好半天，等问题解决了才发现原来一些细节知识点还是没有掌握好。今天golang学习网就整理分享《websocket连接：错误nil值出现在websocket.(*Conn).beginMessage()》，聊聊，希望可以帮助到正在努力赚钱的你。

使用fiber v2.38.1，后者又使用fasthttp/websocket v1.5.0。

应用程序因以下错误而崩溃：

2022-10-15t04:05:42.983563+00:00 app[web.1]: time="2022-10-15t04:05:42z" level=info msg="close msg received: &{418 close}"
2022-10-15t04:05:42.983564+00:00 app[web.1]: conn is nil: false, msg: &{418 close <nil> conn 0}
2022-10-15t04:05:42.986035+00:00 app[web.1]: panic: runtime error: invalid memory address or nil pointer dereference
2022-10-15t04:05:42.986035+00:00 app[web.1]: [signal sigsegv: segmentation violation code=0x1 addr=0x78 pc=0x8db967]
2022-10-15t04:05:42.986036+00:00 app[web.1]: 
2022-10-15t04:05:42.986037+00:00 app[web.1]: goroutine 86 [running]:
2022-10-15t04:05:42.986037+00:00 app[web.1]: github.com/fasthttp/websocket.(*conn).beginmessage(0x0, 0xc000348f60, 0x1)
2022-10-15t04:05:42.986037+00:00 app[web.1]:    /tmp/codon/tmp/cache/go-path/pkg/mod/github.com/fasthttp/[email protected]/conn.go:479 +0x27
2022-10-15t04:05:42.986038+00:00 app[web.1]: github.com/fasthttp/websocket.(*conn).nextwriter(0x0, 0x1)
2022-10-15t04:05:42.986038+00:00 app[web.1]:    /tmp/codon/tmp/cache/go-path/pkg/mod/github.com/fasthttp/[email protected]/conn.go:520 +0x45
2022-10-15t04:05:42.986039+00:00 app[web.1]: github.com/fasthttp/websocket.(*conn).writejson(0xe79a80?, {0xc143a0, 0xc00041e600})
2022-10-15t04:05:42.986039+00:00 app[web.1]:    /tmp/codon/tmp/cache/go-path/pkg/mod/github.com/fasthttp/[email protected]/json.go:24 +0x45
2022-10-15t04:05:42.986039+00:00 app[web.1]: github.com/kuchaguangjie/go-fit/model.(*wsclient).writemsg(0xc00056a280, 0xc00041e600)
2022-10-15t04:05:42.986040+00:00 app[web.1]:    /tmp/build_0b2fe533/model/ws_model.go:97 +0xf9
2022-10-15t04:05:42.986040+00:00 app[web.1]: github.com/kuchaguangjie/go-fit/controller.(*contentcontroller).ws.func1.2()
2022-10-15t04:05:42.986041+00:00 app[web.1]:    /tmp/build_0b2fe533/controller/content_ctl.go:623 +0x171
2022-10-15t04:05:42.986041+00:00 app[web.1]: created by github.com/kuchaguangjie/go-fit/controller.(*contentcontroller).ws.func1
2022-10-15t04:05:42.986042+00:00 app[web.1]:    /tmp/build_0b2fe533/controller/content_ctl.go:608 +0x10cc
2022-10-15t04:05:43.113930+00:00 heroku[web.1]: process exited with status 2

它在 conn.go:479 崩溃，函数 beginmessage():

if c.writer != nil {

我已经检查过 c 不为零（如日志所示），那么它是如何崩溃的......

顺便说一句，它部署在heroku上，我在heroku上看到以下日志：

2022-10-15t04:59:30.344791+00:00 heroku[路由器]: at=错误代码=h15 desc="空闲连接"

不确定是否相关。

更新：相关代码

• 处理关闭消息的单独 goroutine（content_ctl.go 的一部分）：

// handle close - from a channel,
    // todo: use goroutine pool ?
    go func() {
        if r := recover(); r != nil { // todo: is this proper ?,
            fmt.printf("recover from panic: %v\n", r)
        }

        closemsg := <-(*client).closechan // handle close,
        log.infof("close msg received: %v", closemsg)

        // send close msg,
        closeresp := &model.wsresp{
            status: closemsg.httpcode,
            source: model.respsourceconn,
            msg:    closemsg.msg,
        }

        log.infof("is conn nil: %v, msg: %v\n", client.wsconn == nil, closeresp)
        err = client.writemsg(closeresp)
        if err != nil {
            log.errorf("error - on write close msg: %v", closeresp)
        }

        ctl.cwm.closeandcleanup(client.id) // close & clean up,
    }()

• wsclient 结构体及其方法 writemsg() 的定义（ws_model.go 的一部分）：

// websocket client,
    type wsclient struct {
        wsuser
        contentuuid string          `json:"contentuuid"` // content uuid id,
        wsconn      *websocket.conn `json:"-"`           // websocket connection,
        closechan   chan *closemsg  `json:"-"`           // close channel,
        writelock   *sync.mutex     // write lock, to avoid concurrent write to ws connection, which will cause panic, acquire lock when write or close,
    }

    // write ws msg, with lock,
    func (wsc *wsclient) writemsg(msg *wsresp) error {
        if wsc.wsconn == nil {
            return errutil.errnoconn
        }
        wsc.writelock.lock()
        err := wsc.wsconn.writejson(msg)
        wsc.writelock.unlock()
        return err
    }

• clos​​emsg 结构（ws_model.go 的一部分）：

// close msg sent to close chan,
    type closemsg struct {
        httpcode int    `json:"httpcode"`
        msg      string `json:"msg"`
    }

问题状态：

• 其实，在提问之前我已经通过检查clos​​emsg中的httpcode解决了这个问题，如果是418，那么我就不会发送close消息。
• 虽然问题暂时解决了，但我还是想知道问题的真正原因，所以才提出这个问题。

一些背景：

• 我对 clos​​emsg 的 httpcode 有几个可能的值。
  • 418 是默认值，仅当连接上发生意外 io 问题时才会发生（例如，heroku 由于空闲而终止连接？）。
  • 对于其他情况，例如，如果我想断开连接，那么我将发送其他 http 代码。
• 从日志中，我发现只有当 close msg 的 http 代码为 418 时才会出现问题。
• 顺便说一句，虽然 418 可能不是最好的 http 代码（来自一个笑话），但这不会影响我猜想的问题。
• 而且，在 wsclient 的 writemsg() 方法中，我总是在发送消息之前检查 conn 是否为 nil。

更新 - 来自heroku的更多日志

2022-10-16T05:19:03.088622+00:00 heroku[router]: at=error code=H15 desc="Idle connection" method=GET path="/api/v1/content/ws/RgPx8znal7AJb
2022-10-16T05:19:03.065493+00:00 app[web.1]: time="2022-10-16T05:19:03Z" level=info msg="error - on read:  websocket: close 1006 (abnormal closure): unexpected EOF"
2022-10-16T05:20:57.758379+00:00 app[web.1]: time="2022-10-16T05:20:57Z" level=info msg="cleanup client, id = 'wscid-ee670cc5-4100-49d6-9857-8284d93a6d33'"
2022-10-16T05:20:57.758505+00:00 app[web.1]: time="2022-10-16T05:20:57Z" level=info msg="close msg received: &{418 close}"

如果一段时间内没有消息，heroku 似乎会终止 websocket 连接。这时 418 就会出现。

而且，我问了一个关于heroku杀死websocket连接的问题：heroku继续杀死空闲连接（websocket）

正确答案

这是一个 fasthttp 错误，已在 v1.5.1-rc.8 中修复

参考：https://github.com/fasthttp/websocket/issues/30#issuecomment-1326860975

好了，本文到此结束，带大家了解了《websocket连接：错误nil值出现在websocket.(*Conn).beginMessage()》，希望本文对你有所帮助！关注golang学习网公众号，给大家分享更多Golang知识！