一. Panic问题概述

本周收到客户在bugclose上填写的一个issue：添加一个下发通道后，pushd程序panic并退出了！程序panic时输出的stacktrace信息摘录如下：

panic: runtime error: invalid memory address or nil pointer dereference
[signal SIGSEGV: segmentation violation code=0x1 addr=0x0 pc=0x8ca449]

goroutine 266900 [running]:
pkg.tonybai.com/smspush/vendor/github.com/bigwhite/gocmpp.(*Client).Connect(0xc42040c7f0, 0xc4203d29c0, 0x11, 0xc420423256, 0x6, 0xc420423260, 0x8, 0x37e11d600, 0x0, 0x0)
        /root/.go/src/pkg.tonybai.com/smspush/vendor/github.com/bigwhite/gocmpp/client.go:79 +0x239
pkg.tonybai.com/smspush/pkg/pushd/pusher.cmpp2Login(0xc4203d29c0, 0x11, 0xc420423256, 0x6, 0xc420423260, 0x8, 0x37e11d600, 0xc4203d29c0, 0x11, 0x73)
        /root/.go/src/pkg.tonybai.com/smspush/pkg/pushd/pusher/cmpp2_handler.go:25 +0x9a
pkg.tonybai.com/smspush/pkg/pushd/pusher.newCMPP2Loop(0xc42071f800, 0x4, 0xaaecd8)
        /root/.go/src/pkg.tonybai.com/smspush/pkg/pushd/pusher/cmpp2_handler.go:65 +0x226
pkg.tonybai.com/smspush/pkg/pushd/pusher.(*tchanSession).Run(0xc42071f800, 0xaba7c3, 0x17)
        /root/.go/src/pkg.tonybai.com/smspush/pkg/pushd/pusher/session.go:52 +0x98
pkg.tonybai.com/smspush/pkg/pushd/pusher.(*gateway).addSession.func1(0xc4200881a0, 0xc42071f800, 0xc42040c700)
        /root/.go/src/pkg.tonybai.com/smspush/pkg/pushd/pusher/gateway.go:61 +0x11e
created by pkg.tonybai.com/smspush/pkg/pushd/pusher.(*gateway).addSession
        /root/.go/src/pkg.tonybai.com/smspush/pkg/pushd/pusher/gateway.go:58 +0x350

印象中近大半年用Go写的程序，遇到panic情况不多。上一次是因为原生map变量的并发访问导致的panic，那次panic一眼就看到问题所在了。但这次又是因为啥呢？

二. 分析和debug过程

这个问题在印象中似乎出现过，不过由于当初没有复现，客户环境中又没有panic信息提供，那时没能定位和解决，后来问题并没有出现，显然这个问题是有一定“随机属性”。

对于panic，我们首先检查直接导致panic发生的那一行代码：

        /root/.go/src/pkg.tonybai.com/smspush/vendor/github.com/bigwhite/gocmpp/client.go:79 +0x239

下面是client.go 79行周围的代码片段：

也许是疏忽大意，当时瞅了一眼后，就断定这块没有问题（更多从业务协议层面考虑），这也直接导致后面绕了一个大圈子才查到”真凶”。如果您还没看出来问题，那继续往下看。

定式思维让我认为很可能是函数栈中的内存问题，于是我开始调查panic输出的函数调用栈中参数是否正确。

要想知道函数调用栈中参数传递是否有问题，先要知晓panic后输出的栈帧信息都是什么！比如下面panic dump信息中参数中的各种magic number都代表什么！

gocmpp.(*Client).Connect(0xc42040c7f0, 0xc4203d29c0, 0x11, 0xc420423256, 0x6, 0xc420423260, 0x8, 0x37e11d600, 0x0, 0x0)

pusher.cmpp2Login(0xc4203d29c0, 0x11, 0xc420423256, 0x6, 0xc420423260, 0x8, 0x37e11d600, 0xc4203d29c0, 0x11, 0x73)

pusher.newCMPP2Loop(0xc42071f800, 0x4, 0xaaecd8)

在Joe Shaw的《Understanding Go panic output》和William Kennedy的《Stack Traces In Go》中有针对Stack trace输出信息的解析。关于Stack trace输出信息的识别，总体遵循几个要点：

• stack trace中每个函数/方法后面的“参数数值”个数与函数/方法原型的参数个数不是一一对应的；

• stack trace中每个函数/方法后面的“参数数值”是按照函数/方法原型参数列表中从左到右的参数类型的内存布局逐一展开的; 每个数值占用一个word(64位平台下面为8字节)

• 如果是method，则第一个参数是receiver自身。如果reciever是指针类型，则第一个参数数值就是一个指针地址；如果是非指针的实例，则stack trace会按照其内存布局输出；

• 函数/方法返回值放在stack trace的“参数数值”列表的后面；如果有多个返回值，则同样按从左到右顺序，按照返回值类型的内存布局输出；

• 指针类型参数：占用stack trace的“参数数值”列表的1个位置；数值表示指针值，也是指针指向的对象的地址；

• string类型参数：由于string在内存中由两个字(word)表示，第一个字是数据指针，第二个字是string的长度，因此在stack trace的“参数数值”列表中将占用两个位置；

• slice类型参数：由于slice类型在内存中由三个字表示，第一个word是数据指针，第二个word是len，第三个字是cap，因此在stack trace的“参数数值”列表中将占用三个位置；

• 内建整型(int,rune,byte)：由于按word逐个输出，对于类型长度不足一个Word的参数，会做合并处理；比如：一个函数有5个int16类型的参数，那么在stack trace的信息中，这5个参数将占用stack trace的“参数数值”列表中的两个位置；第一个位置是前4个参数的“合体”，第二个位置则是最后那个int16类型的参数值。

• struct类型参数: 会按照struct中字段的内存布局顺序在stack trace中展开。

• interface类型参数：由于interface类型在内存中由两部分组成，一部分是接口类型的参数指针，一部分是接口值的参数指针，因此interface类型参数将用stack trace的“参数数值”列表中的两个位置。

• stack trace输出的信息是在函数调用过程中的“快照”信息，因此一些输出数值看似不合理，但是由于其并不是最终值，所以问题不一定发生在这些参数身上，比如：返回值参数。

结合上面要点、函数/方法原型以及stack trace的输出，我们来“定位”一下stack trace输出的各个“参数”的含义：

cmpp2Login和Connect的原型以及调用关系如下：

func cmpp2Login(dstAddr, user, password string, connectTimeout time.Duration) (*cmpp.Client, error)

func (cli *Client) Connect(servAddr, user, password string, timeout time.Duration) error

func cmpp2Login(dstAddr, user, password string, connectTimeout time.Duration) (*cmpp.Client, error) {
    c := cmpp.NewClient(cmpp.V21)
    return c, c.Connect(dstAddr, user, password, connectTimeout)
}

对照后，我们得出下面对应关系：

pusher.cmpp2Login(
        0xc4203d29c0,  // dstAddr的data pointer
        0x11,                  // dstAddr string的length
        0xc420423256,  // user 的data pointer
        0x6,                    // user string的length
        0xc420423260,  // password的data pointer
        0x8,                    // password string的length
        0x37e11d600,    // connectTimeout
        0xc4203d29c0,  // 返回值：Client的指针
        0x11,                 // 返回值：error接口的type pointer
        0x73)                 // 返回值：error接口的data pointer

gocmpp.(*Client).Connect(
        0xc42040c7f0,   //cli的指针
        0xc4203d29c0,  //servAddr string的data pointer
        0x11,                  //servAddr string的 length
        0xc420423256,  // user string的data pointer
        0x6,                    // user string的length
        0xc420423260,  // password的data pointer
        0x8,                    // password string的length
        0x37e11d600,   // timeout
        0x0,                   // 返回值：error接口的type pointer
        0x0)                   // 返回值：error接口的data pointer

在这里，cmpp2Login的dstAddr、user、password、connectTimeout这些输入参数值都非常正常；看起来不正常的两个返回值在栈帧中的值其实意义不大，因为connect没有返回，所以这些值处于“非最终态”；而Connect执行到第79行panic，因此其返回值error的两个值也是处于“中间状态”。

这样一来，似乎没有参数是错误的！

三. 回到起点，捉住“真凶”

在反复查看代码和对比stack trace的参数列表后，依然没有找到蛛丝马迹。遂决定平复心情，从头再来，回到起点！

        var ok bool
        var status uint8
        if cli.typ == V20 || cli.typ == V21 {
                var rsp *Cmpp2ConnRspPkt
                rsp, ok = p.(*Cmpp2ConnRspPkt)
                status = rsp.Status
        } else {
                var rsp *Cmpp3ConnRspPkt
                rsp, ok = p.(*Cmpp3ConnRspPkt)
                status = uint8(rsp.Status)   <------ 79行
        }

        if !ok {
                err = ErrRespNotMatch
                return err
        }

又反复看了这段代码！程序正常执行时都是经过这段代码的，都是正常的。为何随机爆出panic呢？79行如果要panic，显然是rsp为nil或其他非法地址。但rsp是由p进行type assertion而来的！难道是type assertion失败了！！！

从正常业务流程来看，这里是不会失败的！这也是当初这里没有立即检查ok这个bool值的原因。但是特殊情况下，也就是当tcp连接建立后，conn包发出后，对方未必返回是conn response包，很可能是其他包回来（比如active test），这样就会导致这块的type assertion失败！这也与这个问题随机发生的情况吻合！

而且当初保留了“ok”，而不是用”_”代替，说明设计思路中是存在返回的包不是conn response包的情况。看来是当初coding时逻辑混乱了:(

这就是问题所在了！教训：type assertion后一定要在检查ok这个bool值之后再决定是否使用assertion之后的变量。

四. 其他

借着这个问题的解决过程，再多说一句 stacktrace。在Go 1.11及以后版本中，go compiler做了更深入的优化，很多“简单”的函数或方法会被自动inline(内联)了，函数一旦内联化了，那么在stack trace中我们就无法看到栈帧信息了，就会看到如下在栈帧信息中存在省略号的情况：

 $go run stacktrace.go
panic: panic in foo

goroutine 1 [running]:
main.(*Y).foo(...)
    /Users/tony/test/go/stacktrace/stacktrace2.go:32
main.main()
    /Users/tony/test/go/stacktrace/stacktrace.go:51 +0x39
exit status 2

可以使用-gcflags=”-l”来告诉编译器不要inline。至于是否要这么做，就要看debug和性能之间您是如何权衡的了。

我的网课“Kubernetes实战：高可用集群搭建、配置、运维与应用”在慕课网上线了，感谢小伙伴们学习支持！

我爱发短信：企业级短信平台定制开发专家 https://tonybai.com/
smspush : 可部署在企业内部的定制化短信平台，三网覆盖，不惧大并发接入，可定制扩展； 短信内容你来定，不再受约束, 接口丰富，支持长短信，签名可选。

著名云主机服务厂商DigitalOcean发布最新的主机计划，入门级Droplet配置升级为：1 core CPU、1G内存、25G高速SSD，价格5$/月。有使用DigitalOcean需求的朋友，可以打开这个链接地址：https://m.do.co/c/bff6eed92687 开启你的DO主机之路。

我的联系方式：

微博：https://weibo.com/bigwhite20xx
微信公众号：iamtonybai
博客：tonybai.com
github: https://github.com/bigwhite

微信赞赏：

商务合作方式：撰稿、出书、培训、在线课程、合伙创业、咨询、广告合作。

本文是首发于个人微信公众号的文章“TB一周萃选[第3期]”的归档。

 《岁旦》

　　 宋伯仁 宋代诗人

　　居间无贺客，早起只如常。桃版随人换，梅花隔岁香。
　　春风回笑语，云气卜丰穰。柏酒何劳劝，心平寿自长。

本期萃选是2017年的最后一期，也是迎接2018新年“承前启后”的一期。

对于现代中国人来说，公历新年又称为“元旦”。但稍有些历史常识的朋友都会知道：此“元旦”与中国古时的那个“元旦”有所不同。古代中国人把农历大年初一称为元旦，传说古时“元旦”在距今4000多年前“尧舜禹”的时候就已经有了。1911年辛亥革命成功后，当时孙中山领导的国民政府把农历的大年初一称春节，把公历1月1日称元旦，这就是现在元旦的由来。现代中国的元旦，在世界更广的范围内被更多称为“新年”，是全世界人们的一个共同的节日。在这样的一个节日里，人们家庭团聚，亲友重逢，倾诉过往，憧憬新年，祈求平安。

节日，似乎是群居生物的一种典型的行为表现形式，动物有之（可能是以我们无法理解的形式），人类也在进化的几十万年（又或更长的时间）内设定了大大小小的各种节日。这是作为群居动物的人类的一个重要需求，是进化数十万年后依然保留的最古老的基因所表现出的行为倾向。人类通过“节日”来“蓄力”，以迎接新的挑战！不同的是，古代人类挑战的是凶恶的生存环境，现代人类抗争的是现代生活无形的“生活压力”。

不过，人类从来没有屈服于困难！近期火热的电影《芳华》向我们直观生动地阐释了这一点，让我们更加明白生活的真谛，珍惜与家人、爱人、朋友在一起的时光，享受现在的生活，乐观的面对人生。

一、一周文章精粹

1. Go初学者的类型系统入门

对于Go初学者而言，尤其是对那些从OO语言转到Go的开发者，在他们大脑中根深蒂固的OO type hierachy不见了，这让他们似乎一下子失去了着力点或抓手。原Go core team成员JBD撰文阐述了Go类型系统的特点，诸如：流程优先、嵌入不是继承、多态、没有构造函数、没有范型等。

原文链接：《The Go type system for newcomers》。

2. Go反射详解

Go语言提供了反射(reflect)特性，在标准库中很多常见功能都是用反射实现的，比如：encoding/json、fmt包的Println系列等。但日常编程中，直接使用reflect包的场合并不多。reflect为Go程序员提供了一种在运行时 “陷入” 的机制，使得Go程序具备了直接操作runtime中类型元数据的能力以及在运行时凭空“制造”变量的能力，因此reflect操作是比较“危险”的。

Sidhartha Mani的“Go反射详解”分为两个part，part1主要讲解type与kind的区别、基于reflect包的type和value进行Go原生类型变量的构造和值的析出；part2则是针对复合类型，比如数组、map、struct等类型变量的构造和值的析出进行讲解，思路十分清晰。

原文链接：

《Go Reflection: Creating Objects from Types — Part I (Primitive Types)》
《Go Reflection: Creating Objects from Types — Part II (Composite Types)》

3. 现代网络负载均衡和代理指南

lyft的envoy工程师撰文对高可用分布式网络中的负载均衡和反向代理做了详尽的科普性讲解，内容包含：lb与proxy的区别、L4 lb、L7 lb、lb特性分析、lb的拓扑类型、当前L4-lb技术、L7-lb技术现状的情况、全局lb和集中控制平面等。强烈推荐阅读！

原文链接：《Introduction to modern network load balancing and proxying》

4. Go编译器内幕

这是由国内一位就职于ARM公司的开发者在Go dev group上发的topic，这位开发者将自己学习和整理了Go compiler的原理（主要针对ARM平台）放在了一篇slide中，并在Go core team的反馈下，对他的slide进行了修正和优化。这份资料对于想深入了解Go compiler的朋友可能是大有裨益的。

原文链接：“Golang Compiler Internals for arm64″

5. 年度盘点2017之Service Mesh：群雄逐鹿烽烟起

在Kubecon&CloudNativeCon 2017上大放异彩后，Service Mesh在国内已经渐入火热阶段。Service Mesh的著名Advocator：数人云的架构师敖小剑年终前发了此文，对service mesh的发展历史、来龙去脉、各方开源项目和厂商势力分析以及未来发展做了回顾和展望。如果你还不知道什么是service mesh，那借此文赶紧上车吧:)

原文链接：“年度盘点2017之Service Mesh：群雄逐鹿烽烟起”

二、一周资料分享

1. Microservice’ing like a unicorn with kubernetes, envoy, and istio

随着传播渠道多元化和传播速度的加快，新技术“火”的速度也变得以前所未有。以Service Mesh概念为例（参考了 “年度盘点2017之Service Mesh：群雄逐鹿烽烟起”）：

• 2016 年 9 月 29 日在 SF Microservices 上，“Service Mesh”这个词汇第一次在公开场合被使用。这标志着“Service Mesh”这个词，从 Buoyant 公司走向社区。
• 2017 年 4 月 25 日，William Morgan 发布博文“What’s a service mesh? And why do I need one?”。正式给 Service Mesh 做了一个权威定义。
• 2017 年 5 月 24 日，Istio 0.1 release 版本发布，Google 和 IBM 高调宣讲，社区反响热烈，很多公司在这时就纷纷站队表示支持 Istio。

istio的正式发布，成为了service mesh的一个重要里程碑事件。谁能否认istio不是另一个Google内部技术的开源版本呢，就好比当年Kubernetes的开源。微服务框架走向统一的service mesh似乎成了大势所趋的趋势。无论国内外，对service mesh的研究、开发和试验，甚至是商用都在如火如荼地进行当中。

Redhat架构师Christian Posta近日在自己的博客上放出一份正在构建中的资料：Microservice’ing like a unicorn with kubernetes, envoy, and istio，对envoy和istio的原理与使用进行案例式的详尽说明，同时配有对应的示例源码。对于希望学习service mesh技术的朋友们，这是一份不可多得的资料。

资料分享链接：Microservice’ing like a unicorn with kubernetes, envoy, and istio

三、一周工具推荐

1. mdp

今天给大家推荐一个比较有Geek赶脚的present工具：mdp。

mdp是一款文稿演示工具，与go present工具有些类似，都是以一种类markdown格式的文档作为输入。不同之处，后者是将演示文稿渲染到浏览器中，而mdp工具则是将文稿渲染到terminal中，效果参见下面图示：

mdp支持标准markdown语法，同时也支持通过一些扩展语法实现的特定渲染效果。mdp同时支持一些快捷键控制命令，比如：h,j,k,l组合的翻页控制等。在Mac上可使用brew工具来install mdp，在其他平台可以通过下载源码并自行编译的方式安装。

工具链接：mdp

四、一周图书推荐

笔者认为人类正在构建支撑未来20-30年支撑人类社会发展的IT技术“有机生命体”，包括：

• 能量系统(类比于细胞化学反应，提供计算能量) – IT基础设施(云计算、vm、k8s、container)、Cloud Native技术框架：microservice 、service mesh(服务治理网络) 、serverless等。
• 神经通道 – 基础高速互联网、移动网络、区块链（信用网络）
• 大脑 – 人工智能、数据与智能算法
• 肢体与感知 – 机器人、智能交通工具（比如：无人汽车等）、智能硬件、Iot等。

其中区块链技术作为未来社会信用网络的重要基础，IT技术人员都应该认真学习。本期我就推荐一本有关区块链技术的开源书：yesky的《区块链开发指南》。这是一本关于区块链技术的较为系统的开源书。该书探索了区块链概念的来龙去脉，剥茧抽丝，剖析关键技术原理、典型应用场景、分布式系统核心问题，同时讲解了区块链技术的三大典型应用：比特币、以太坊和Hyperledger超级账本以及相关应用的开发入门。

开源书链接：《区块链开发指南》
商业纸板图书链接：《区块链原理、设计与应用》

我的联系方式：

微博：http://weibo.com/bigwhite20xx
微信公众号：iamtonybai
博客：tonybai.com
github: https://github.com/bigwhite

微信赞赏：

商务合作方式：撰稿、出书、培训、在线课程、合伙创业、咨询、广告合作。