C++的多线程后台服务很容易 coredump 啊

那得看是你接手之前是不是容易 coredump

代码还原，看看初步怎样

初版

是代码菜 还是 你菜。。。

换 java，或者 golang，逃

@linbiaye 一直容易 coredump，我接手前也是每周 core 2 回的样子

@araraloren 毫无疑问是我菜...

根据这个"也"字，意思是接手后解决的 bug 数和衍生的 bug 数持平吗，根据我数年的维护经验，lz 应该是掉进坑里了:doge:

gdb 调试一下

lz 接了一个坑盘

小就重构，大的话…看钱多少

上 supervisor，自动重启，大家假装无事发生，还不是美滋滋

感觉上是没处理好多线程的同步 /临界区的问题，所以。。。。。。我觉得应该把菜加到标题里面

C++表示这锅我不背

写 c/c++我也经常 coredump。。。

还是单线程好，逃

拒绝写
有全局对象的
不封装 channel 或者共享内存的
临界对象自己不带锁的
敢于在构造函数之外的大括号内只放 new/malloc 或者析构以外只放 delete/free 的
c++多线程程序

一般这种不定期 core 又可能与 race 相关，哎想想就头大

我感觉楼主接盘侠了，恭喜恭喜

加 gdb 调呗，多半是临界区问题。。

容易复现的问题都不是问题…

仔细看代码和 core，给关键部分写单元测试，总能看出来是哪儿的问题的。

C++ : 你们菜还赖我？

你菜或老项目写得烂或机器内存不够硬件背锅

C++：反正这锅我不背

因为我菜所以喜欢 Rust 啊……

c++线程同步很是麻烦啊，需要考虑很多，解决方案也不少，锁、消息队列、互斥量、信号量等等，你可以看看 core 文件，段错误段在哪里~

注册 SIGTREM SIGSERV 然后在信号函数中使用 backtrace* 函数将堆栈展开输出到 bug 文件，然后使用 addr2line 去解析问题出在哪里，对于你的这种情况基本可以解决。

我们公司的 sshd 服务器就是 C++ 编写，然后使用了 backtrace 功能，前阵子更新了 libssh 经常出现 结束连接 SIGSERV, 后来找到了是 libssh 的一个 bug。

在信号回调函数中需要严格遵循异步信号安全的原则，不能有锁，否则会死锁，处理完后需要退出进程。（常见的动态内存申请需要加锁，因此不是异步信号安全的）。

不 coredump 的那就不叫 c++

我改造了好多有问题的 c++历史代码...还好他们之前知道使用有锁队列.