这种 coredump 真的是很难遇见

[xuelang]

最近在项目中遇到了一个奇怪的 coredump 问题，排查过程并不顺利。经过不断分析，找到了一个复现的步骤，经过合理猜测和谨慎验证，最终才定位到原因。

复盘下来，发现这类 coredump 问题确实比较罕见，排查起来也不是很容易。只有项目代码编译依赖管理不是很合理的时候，才可能出现。另外，在复盘过程中，对这里的 coredump 以及 C++ 对象内存分布也有了更多理解。于是整理一篇文章，如有错误，欢迎指正。

某次变更，在服务 A 的 service.proto 文件中，对某个 rpc 请求参数增加了一个字段(比如下面的 age)：

service Greeter {
  rpc SayHello (HelloRequest) returns (HelloReply) {}
}
message HelloRequest {
  string name = 1;
  string age = 2;   // 增加了参数
}
message HelloReply {
  string message = 1;
}

然后增加了这个字段的相关逻辑，随后编译上线了该模块。我们知道在微服务架构中，经常有多个服务共用同一个 proto 对象。如果要修改 proto 的话，一般都是增加字段，这样对调用方和被调用方都是兼容的。这里服务 A 上线后，用新的 proto ，其他用到这个 proto 的服务在重新编译前都会用老的版本，这样不会有问题。其实严格来说这样也是可能有问题的，之前踩过坑，主要是 Merge 的兼容问题，可以参考我之前的文章 Protobuf 序列化消息引起的存储失败问题分析。

正常来说，如果其他服务想更新 proto ，只需要重新编译就能用到新的 proto ，肯定不会有问题。不过这次就出问题了，服务 A 的 proto 增加字段上线后，其他通过 client 调用 A 的服务，只要重新编译上线，就会 coredump。

---

完整文章在： Bazel 依赖缺失导致的 C++ 进程 coredump 问题分析

[root71370]

proto 是不是很常用？我还没接触过

[xuelang]

@root71370 很常用的

[liberize]

大部分情况都没必要用 pb ，用 json 性能足够了，用 pb 徒增运维调试难度。

[xuelang]

@liberize pb 数据序列化和反序列化还是很重要的，能省不少网络带宽

[iceheart]

改动公用的接口方法的参数？
那崩溃就是最好的结果。

[xuelang]

@iceheart ?? rpc 的接口参数改动很正常呀。。