挖井

类库大魔王的挖井日记

挖一口属于自己的井


程序被Google Breakpad挂住了

很长一段时间来,一直偶尔有发现进程在收到SIGTERM或SIGKILL后,仍然不能完全退出。之前总以为是sighandler写得有问题,还怀疑过是SIGTERM不够强力,需要用SIGKILL,事实证明其实都没关系。

前段时间还在网上看到Apache httpd server在让子进程退出时的做法,因为貌似它也有偶尔不能完全退出的情况,于是他们就先发个SIGTERM,过1秒钟如果发现进程还在,再发一个SIGTERM,如果再过3秒钟进程还在,就最后发一个SIGKILL强制退出。于是我也照这个样子做,但是现在看来仍然会有退不出的情况。用htop看那个残留的进程从n个线程变成1个线程了,用gdb attach上去看一下那个线程的callstack,发现这样的东西:

(gdb) bt
#0  0x00000000004c6650 in sys_read (this=0x2370920) at ./src/third_party/lss/linux_syscall_support.h:2838
#1  google_breakpad::ExceptionHandler::WaitForContinueSignal (this=0x2370920) at src/client/linux/handler/exception_handler.cc:519
#2  0x00000000004c670d in google_breakpad::ExceptionHandler::ThreadEntry (arg=<value optimized out>) at src/client/linux/handler/exception_handler.cc:379
#3  0x00000000004c6a4a in sys_clone (this=0x0, context=<value optimized out>) at ./src/third_party/lss/linux_syscall_support.h:2010
#4  google_breakpad::ExceptionHandler::GenerateDump (this=0x0, context=<value optimized out>) at src/client/linux/handler/exception_handler.cc:474
#5  0x0000000000000000 in ?? ()
(gdb) info thread
* 1 process 6804  0x00000000004c6650 in sys_read (this=0x2370920) at ./src/third_party/lss/linux_syscall_support.h:2838

可以看到程序是被Google Breakpad的某个方法google_breakpad::ExceptionHandler::WaitForContinueSignal挂住了。在网上搜了一下,也没发现什么有用的信息,在Stackoverflow上看到一个问题,也提到进程被这个方法挂住了,但他出现的场景跟我完全不一样,而且还没下文了。

目前我也没头绪怎么可以比较完美地解决这个问题,实在不行就只好在发布版本中不带breakpad了,毕竟现在在生产环境中程序几乎不会意外crash了。

本文地址:

https://minidump.info/blog/2015/01/be-hung-by-google-breakpad/

上一篇

现在做事越来越没意思了

以前吧,虽然经常被骂,还被气得肝疼,但那都是人际方面的问题,还可以安慰自己至少做的事情还是比较有兴趣的。现在嘛,被骂得少了很多,倒是做的事情越来越没意思了。TL有个很不好的毛病:喜欢揽活,当保姆。明明就应该别的人别的组做的事,揽过来,用很丑的方法做一遍。比如要跟某些service交互,我们组因...…

Job 全文阅读
下一篇

Blog开启https支持并强制使用

上周在cloudflare又新建了个账号,记得很多年前我有个账号的,不过忘了密码也忘了注册邮箱,只好再新建个。然后用free plan加了两个域名,其中一个就是现在blog在用的minidump.info,cloudflare除了CDN,还能提供SSL,这点非常赞,于是就加上了。昨天晚上看到有...…

Life 全文阅读