tls conn中的Golang恐慌阅读-仅在Linux上吗？

Question

I'm using golang crypto/tls to process a custom line-oriented message protocol.

This approach works fine on windows:

var fullBuffer string

for {

    // If we're not connected, attempt reconnect
    if this.conn == nil {

        if this.IsSecure() {
            this.conn, err = tls.Dial("tcp", this.GetHostOnly(), nil)
        } else {
            this.conn, err = net.Dial("tcp", this.GetHostOnly())
        }

        if err == nil {
            // log and continue
        }
    }

    // Read from socket into our local buffer (blocking)
    if this.conn != nil {
        readBuff := make([]byte, 4096)
        nbytes, err = this.conn.Read(readBuff)
        if nbytes > 0 {
            fullBuffer += string(readBuff[0:nbytes])
        }
    }

Pretty straightforward - and it works fine on win64.

But when i try to run it on Linux (debian 8 - both i386 and amd64 - both golang 1.5 native and 1.6 crosscompiled from windows) i get the following panic:

panic: runtime error: invalid memory address or nil pointer dereference
[signal 0xb code=0x1 addr=0x0 pc=0x4ec8b4]

goroutine 8 [running]:
panic(0x8237780, 0x18522030)
    C:/Go/src/runtime/panic.go:464 +0x326
crypto/tls.(*Conn).Handshake(0x0, 0x0, 0x0)
    C:/Go/src/crypto/tls/conn.go:1023 +0x198
crypto/tls.(*Conn).Read(0x0, 0x18597000, 0x1000, 0x1000, 0x0, 0x0, 0x0)
    C:/Go/src/crypto/tls/conn.go:922 +0x5e
mylib.(*MyConnection).worker(0x18512480)
    C:/gopath/src/mylib/mylib.go:342 +0x200

The Read call is failing because it's somehow passing nil to the TLS handshake.

What's going wrong here?

And, why is the problem isolated to linux?

Answer 1

OK, linux builds are producing the error x509: certificate signed by unknown authority.

But

• the certificate is valid

  • crypto/x509/root_unix.go looks in /etc/ssl/certs which is world-readable
  • but openssl s_client is hanging on -showcerts -verify, pointing to some issue with my OS network configuration

• for some reason the if block below is being entered regardless of the error

  • but i was storing it as a net.Conn instead of a pointer, so it's not nil-able.

Calling this solved, sorry for the noise. Hopefully this debugging story helps someone else in the future