一次apache Segmentation fault (11) 崩溃问题定位
这些天出了一个很严重的问题。php接口，或者某个页面，会突然访问不了，查看apache错误日志，发现是不断的apache Segmentation fault (11)，访问就会出现崩溃，之后所有的请求都会失败了。
之后运维重启apache解决，但是之后惨无人道的崩溃大幕开始了，每天晚上十点多的时候，某个站就会跑出来崩溃下。在分析最近更新内容后，发现没有明显能导致崩溃的更新或者写法。于是开发不行运维补，伟大的运维大神在连续几天晚上两三点被叫起来尿尿的情况下，终于想到了一个好办法，监控apache error日志的Segmentation fault (11) ，出现就重启，粗糙猛的办法临时解决了问题。
但是原因还是要找的，万一啥时候监控不准或者忘了加，或者掉了，那就出大事了。在这种找不到具体问题，也没法知道是更新了什么的情况下，只有分析apache的崩溃文件了。于是叫运维大神开启了apache崩溃产生core文件的配置。抓到了一堆core文件，gdb强势插入，bt观察，core文件大致分2种，
第一种崩在
remove_header,而且参数是 content-type ，大概估计是移除这个content-type的时候，崩溃了,看了下php代码，没有手动设置删除content-type,设置content-type倒很多，但都不是新增的，还是无法直接定位到具体的原因。
第二种是：
在销毁op_array的地方，完整堆栈：
注意下12-16层，是curl的调用，curl出了很多bug，于是猜测是新增了什么大量调用curl的功能，但是检查发现没有。
继续看类似几个core文件，发现除了curl，其他core文件还有mysql，file_get_contents等函数出现，然后就崩溃了，难道是阿里云网络最近不稳定，导致涉及网络调用的代码崩溃了？再仔细看看调用：
#7 0x004ea8ed in apr_pool_destroy (pool=0x9cbb920)
at memory/unix/apr_pools.c:814
#8 0x001c06e5 in clean_child_exit (code=0) at prefork.c:218
#9 0x001c073d in just_die (sig=15) at prefork.c:344
#10
just_die (sig=15)应该是收到信号，然后apache退出，在释放资源的时候崩溃了，结合core文件生成的时候，能确定这种是产生Segmentation fault (11)后，监控脚本重启apache，然后apache进程在退出的时候，因为有网络调用的内容在跑，没处理好导致了崩溃，这种崩溃只在重启的时候才会发生，于是略过不管，真正致命的应该是第一种。
继续分析第一种core，完整堆栈信息
(gdb) bt
#0 sapi_remove_header (l=0x85e20e8, name=0xb7fc21a0 "Content-Type", len=12) at /usr/local/src/lamp/php-5.4.15/main/SAPI.c:601
#1 0x01426236 in sapi_header_add_op (op=, sapi_header=0xbff94460, tsrm_ls=0x85e2f60)
at /usr/local/src/lamp/php-5.4.15/main/SAPI.c:650
#2 0x01426e8b in sapi_header_op (op=SAPI_HEADER_REPLACE, arg=0xbff944a0, tsrm_ls=0x85e2f60)
at /usr/local/src/lamp/php-5.4.15/main/SAPI.c:842
#3 0x013b9415 in zif_header (ht=1, return_value=0xb7fc213c, return_value_ptr=0x0, this_ptr=0x0, return_value_used=0, tsrm_ls=0x85e2f60)
at /usr/local/src/lamp/php-5.4.15/ext/standard/head.c:48
#4 0x014b21a4 in zend_do_fcall_common_helper_SPEC (execute_data=0xb7fb210c, tsrm_ls=0x85e2f60)
at /usr/local/src/lamp/php-5.4.15/Zend/zend_vm_execute.h:643
#5 0x014b8d98 in execute (op_array=0xb7fb2070, tsrm_ls=0x85e2f60) at /usr/local/src/lamp/php-5.4.15/Zend/zend_vm_execute.h:410
#6 0x01480c7c in zend_execute_scripts (type=2, tsrm_ls=0x85e2f60, retval=0x0, file_count=1)
at /usr/local/src/lamp/php-5.4.15/Zend/zend.c:1315
#7 0x015364fb in php_handler (r=0x8801058) at /usr/local/src/lamp/php-5.4.15/sapi/apache2handler/sapi_apache2.c:669
#8 0x0808541b in ap_run_handler (r=0x8801058) at config.c:168
#9 0x08088fbb in ap_invoke_handler (r=0x8801058) at config.c:432
#10 0x0809a707 in ap_process_async_request (r=0x8801058) at http_request.c:317
#11 0x0809a83d in ap_process_request (r=0x8801058) at http_request.c:363
#12 0x08097230 in ap_process_http_sync_connection (c=0x87f4b20) at http_core.c:190
#13 ap_process_http_connection (c=0x87f4b20) at http_core.c:231
#14 0x0808f32b in ap_run_process_connection (c=0x87f4b20) at connection.c:41
#15 0x00fb6c59 in child_main (child_num_arg=) at prefork.c:704
#16 0x00fb6ffd in make_child (s=0x8570d48, slot=15) at prefork.c:800
#17 0x00fb7b13 in prefork_run (_pconf=0x854c0a8, plog=0x85729a0, s=0x8570d48) at prefork.c:902
#18 0x0806ddc9 in ap_run_mpm (pconf=0x854c0a8, plog=0x85729a0, s=0x8570d48) at mpm_common.c:96
#19 0x0806886a in main (argc=139763872, argv=0x87f2940) at main.c:777
调用层比较少，说明还没跑什么就崩溃了。
这里有两个地方能看到php信息，第5层的 execute 以及第4层zend_do_fcall_common_helper_SPEC 。看下op_array中的信息：
找到了崩溃的php文件main.php，但是这是一个入口文件。基本所有功能都走这进入，要定位的范围还是很大。
继续看下zend_do_fcall_common_helper_SPEC，在gdb中，可以手动打印出函数的变量，可以查看下源码，看传递进去的变量是什么结构，然后构造个指针查看。
不过php调试有简单方法。php有个gdb调试脚本，可以较快的将php执行信息输出来，不用盯着c的结构体看细节内容，
来执行一下：source /usr/local/src/lamp/php-5.4.15/.gdbinit
然后切到zend_do_fcall_common_helper_SPEC的上下文中，命令是frame 层数 缩写是f，执行f 4
dump_bt类似bt，是php的gdb调试脚本提供的方法，能看到当前执行环境的调用层次，我们这就看到一层，在header设置content-type的时候就崩掉了。
main.php源代码如下：
date_default_timezone_set('Asia/Shanghai');
header('Content-Type: text/html;charset=utf-8');
define('APP_PATH',dirname(__FILE__)."/aae");//tita base dir
define('ROOT_PATH',dirname(__FILE__));
require APP_PATH . '/core/Core.php';//加载框架核心
$app=\core\Tita::App();
$app->run();
根据dump_bt提示，崩在16行设置header的地方，也就是这里的第二行，这比较头痛，刚到入口apache就崩了，应该不是php语句写错了导致的。这样子也不好绕过，继续往上看：
#0 sapi_remove_header (l=0x85e20e8, name=0xb7fc21a0 "Content-Type", len=12) at /usr/local/src/lamp/php-5.4.15/main/SAPI.c:601
#1 0x01426236 in sapi_header_add_op (op=, sapi_header=0xbff94460, tsrm_ls=0x85e2f60)
at /usr/local/src/lamp/php-5.4.15/main/SAPI.c:650
#2 0x01426e8b in sapi_header_op (op=SAPI_HEADER_REPLACE, arg=0xbff944a0, tsrm_ls=0x85e2f60)
at /usr/local/src/lamp/php-5.4.15/main/SAPI.c:842
最终是崩在remove_header,我们是设置header，为什么会remove header呢， 看源码。
sapi.c 601 行
/*
* since zend_llist_del_element only remove one matched item once,
* we should remove them by ourself
*/
static void sapi_remove_header(zend_llist *l, char *name, uint len) {
sapi_header_struct *header;
zend_llist_element *next;
zend_llist_element *current=l->head;
while (current) {
header = (sapi_header_struct *)(current->data);
next = current->next;
if (header->header_len > len && header->header[len] == ':'
&& !strncasecmp(header->header, name, len)) {
if (current->prev) {
current->prev->next = next;
} else {
l->head = next;
}
if (next) {
next->prev = current->prev;
} else {
l->tail = current->prev;
}
sapi_free_header(header);
efree(current);
--l->count;
}
current = next;
}
}
这里对current这个结构体进行操作，l->head是个链表，在next = current->next;崩溃，当时的current是个已经损坏的zend_llist_element结构，导致继续遍历下个节点的时候崩溃了。注意这句：
zend_llist_element *current=l->head;
current最初是从l来的，幸好l还没损坏，
检查下链表指向
查看到第二个节点的时候，就发现异常了0x1d明显不像是个指针，也就是应该只有一个节点，第一个节点的next本来应该为null，这里却是一个不知道啥的值。在->next的时候就崩溃了
至此，大致情况清楚了：
我们的php程序在调用header('Content-Type: text/html;charset=utf-8');的时候，apache进入了sapi_remove_header，然后这个函数里，遍历header列表的时候，使用了一个未初始化或者已经释放或者不知道怎么被损坏的一个header链表。如何解决这个问题呢？既然我们不需要remove_header，那是不是不进入这里就可以了，再看下#1层的函数sapi_header_add_op，这应该是我们要操作的内容，设置header content-type
static void sapi_header_add_op(sapi_header_op_enum op, sapi_header_struct *sapi_header TSRMLS_DC)
{
if (!sapi_module.header_handler ||
(SAPI_HEADER_ADD & sapi_module.header_handler(sapi_header, op, &SG(sapi_headers) TSRMLS_CC))) {
if (op == SAPI_HEADER_REPLACE) {
char *colon_offset = strchr(sapi_header->header, ':');
if (colon_offset) {
char sav = *colon_offset;
*colon_offset = 0;
sapi_remove_header(&SG(sapi_headers).headers, sapi_header->header, strlen(sapi_header->header));
*colon_offset = sav;
}
}
zend_llist_add_element(&SG(sapi_headers).headers, (void *) sapi_header);
} else {
sapi_free_header(sapi_header);
}
}
源代码显示op == SAPI_HEADER_REPLACE时才会进入sapi_remove_header，也就是我们传进来就是replace,看手册：
void header ( string $string [, bool $replace = true [, int $http_response_code ]] )
原来默认设置成replace，这个参数的意思是当有同名header的时候替换较旧设置的那个header，我们这因为是入口，代码保证了这个header是第一个，所以，直接设置成false，来避免进入崩溃的函数sapi_remove_header。改成：header('Content-Type: text/html;charset=utf-8',false);
虽然崩溃问题解决了，但是为啥链表会是个坏的，因为崩溃几率小，压测设置header也不崩溃，所以还无法复现。
