• 作者: Laruence( )
• 本文地址: http://www.laruence.com/2009/12/05/1172.html
• 转载请注明出处

昨天环境迁移, 脚本出core, 因为之前的环境上运行正常, 所以初步认为是环境问题. 通过对core文件的分析, 初步发现原因和spl_autoload相关, backtrace如下:

#0  zif_spl_autoload (ht=Variable "ht" is not available.)
at /home/huixinchen/package/php-5.2.11/ext/spl/php_spl.c:310
310   if (active_opline->opcode != ZEND_FETCH_CLASS) {

(gdb) bt
#0  zif_spl_autoload (ht=Variable "ht" is not available.
	) at /home/huixinchen/package/php-5.2.11/ext/spl/php_spl.c:310
#1  0x00000000006a5da5 in zend_call_function (fci=0x7fbfffc100,
		fci_cache=Variable "fci_cache" is not available.)
at /home/huixinchen/package/php-5.2.11/Zend/zend_execute_API.c:1052
.....

脚本很简单, 通过session_set_save_handler注册了一个类为session的user handler.

去掉spl_autoload以后, 不出core了, 但是每次都会抛出Class not found的异常, 可见core确实和spl_autoload有关, 但是这个Class ** not found的fatal error问题又和什么相关呢, 这个fatal error是否是导致spl_autoload core 的直接原因呢?

代码本身并没有任何问题, 对环境做了对比以后, 初步认定为新环境启用了APC的缘故.

在bug.php中找到了有人报告类似的bug(spl_autoload crashes when called in write function of custom sessionSaveHandler), 但没有任何一个人给出原因,或者解决的办法.

看来, 只能自己分析了….

精简的代码如下:

<?php
/**
 * PHP5.2.11 with APC Fatal Error example
 * by laruence(http://www.laruence.com)
 */
class Laruence {
	public static function start() {
		session_set_save_handler(array(__CLASS__, "open"),
				array(__CLASS__, "close"), array(__CLASS__, "read"),
				array(__CLASS__, "write"), array(__CLASS__, "destroy"),
				array(__CLASS__, "gc"));
		session_start();
	}
	public static function open($strPath, $strSessName) {
		return true;
	}
	public static function close() {
		var_dump(class_exists(__CLASS__, false));
	}
	public static function read($strSessId) {
	}
	public static function write($strSessId, $strData) {
	}
	public static function destroy($strSessId) {
	}
	public static function gc($intMaxLifeTime) {
		return true;
	}
}
Laruence::start();
?>

当第一次请求这个页面的时候, 一切正常, 当再次请求的时候, 就会产生:

PHP Fatal error:  Class 'Laruence' not found in Unknown on line 0

可见, 这个原因一定是和APC缓存了脚本编译结果以后有关.

翻看APC的源码, 发现了一处可怀疑之处, apc_main.c中:

static void apc_deactivate(TSRMLS_D) //此函数在请求关闭期间被调用
{
while (apc_stack_size(APCG(cache_stack)) > 0) {
...//有省略
	if (cache_entry->data.file.classes) {
		for (i = 0; cache_entry->data.file.classes[i].class_entry != NULL; i++) {
			if(zend_hash_find(EG(class_table),
					cache_entry->data.file.classes[i].name,
					cache_entry->data.file.classes[i].name_len+1,
					(void**)centry) == FAILURE) {
						continue;
			}
			//注意这里:
			zend_hash_del(EG(class_table),
					cache_entry->data.file.classes[i].name,
					cache_entry->data.file.classes[i].name_len+1);
			apc_free_class_entry_after_execution(zce);
		}
	}

	...//有省略
}
}

也就是说, APC在模块请求关闭函数时期, 清空了执行全局标量中的类定义表EG(classs_table), 根据我的经验, 问题可能就在这里.

经过反复验证: 改hanlder, 跟踪源码, gdb,, 最后问题定位确定, 确实就是这个原因(对不住女朋友了, 搞到半夜快2点才最终确定问题):

恩, 我之前的文章介绍过PHP的扩展载入过程(深入理解PHP原理之扩展载入过程), 但没有涉及到模块关闭过程.

而这个问题就和模块载入顺序和模块关闭函数很有关系了. 总体来说, 就是PHP会根据模块载入的顺序的反序来在每次请求处理结束后依次调用各个扩展的请求关闭函数.

因为我们环境的Session是静态编译进PHP的, 所以Session模块一定先于动态编译进PHP的APC被载入, 也就是说, 在请求关闭时期, APC的请求关闭函数, 一定会先于Session的请求关闭函数被调用.

所以,当Session的请求关闭函数调用的时候, 执行环境的Class Table已经为空, 当然也就会抛出类找不到的fatalerror了.

而, 第一次请求的时候, 因为页面没有被缓存, 所以apc_stack_size(APCG(cache_stack))的条件判断不成立, 也就不会有清除class table的动作发生.

基于此, 为什么在spl_autoload启用以后, 产生core, 也就很明显了.

因为在zif_spl_autoload中, 对active_opline接引用, 而此时执行已经结束, active_opline为空, 所以,segment fault了.

那么, 如何解决这个问题呢?

1. 关闭APC //废话,我也知道, 呵呵
2. 改用函数做为session_set_save_handler的user handler.
3. 把seesion模块做为动态模块载入PHP, 并保证它后于APC被载入. //这个解决方法靠谱.

关于APC的执行原理, 大家如果有兴趣, 我过段再单独写篇blog.

最后, APC是好, 但一致没有被做为PHP的标准扩展, 也是有原因的. 它劫持了PHP自身的complie_file, 加入了很多局部性很强的逻辑…

一句话, APC虽好, 但须慎用.

Comments

• 2009/12/06, 玉丰 writes: 最近也在折腾gdb，看了一下这篇文章，（还不会如何去backtrace PHP的运行），呵呵，继续学习。
• 2009/12/07, phppan writes: 围观，学习！
• 2009/12/16, kimjxie writes: 在代码末 强制执行session_write_close()也可解决问题
• 2009/12/17, 雪候鸟 writes: @kimjxie 赞~, 这是提前了关闭的时机. 这个bug还是依然值得探讨的. ;)
• 2010/01/15, wakaka writes: 博主的PHP和C的功力实在是国内少有的高手。
• 2010/03/19, luckgo writes: 老兄，我遇到类似问题，但无法解决。 我在windows下装了php_apc.dll后，访问phpMyAdmin（版本3.1.3）出现错误： Warning: require_once(D:\apache\libraries\common.inc.php) [function.require-once]: failed to open stream: No such file or directory in E:\phpweb\phpMyAdmin3\index.php on line 34 在使用zend framework框架时，出现 class XXX not found的错误，很奇怪，似乎与session没什么关系，请问有没办法解决？
• 2010/03/20, 雪候鸟 writes: @luckgo 文件不存在那么..
• 2010/07/28, abagail writes: Zenith Watches Company is a Swiss company that has cartier fake watches breitling chronomat evolution straps have the advantage of being made from a replica a lange and sohne watch automatic watches far from what they like or would buy for swiss replica assioma watches available on the new RSW High King Tourbillon buy watches omega olympic collection watches enhanced and the promotional lights create an replica watches retailers to see what products have arrived in rolex milgauss watches arrives with a long lasting brass situation Other tag heuer fake heard about Gucci They are one of the largest fake watch that updated to make it more suitable to the replica watch out with various styles celebrating this trip to watches replica baguette cut diamonds and baguette cut rubies breitling fake watches libre watches a team of visionary designers and specialists of replica omega under their French cuff shirts and hence they can
• 2010/08/19, Watchfordream writes: Wonderful! swiss replica watches
• 2011/01/20, hfcorriez writes: 受教了。
• 2011/03/20, PHP5.2.x + APC的一个bug的定位 | 万维网黑客联盟 writes: [...] 本文地址: http://www.laruence.com/2009/12/05/1172.html [...]
• 2011/09/26, iterse's blog writes: 恩，学习了。前几天遇到了这个问题，谢谢分享！
• 2011/12/06, hfcorriez writes: 以前也发现过这个问题，苦于自己没法定位放弃APC了。今天终于知道原因了。
• 2012/01/12, 偷蚊子的 writes: 新人，来报道～

Related posts:

• memory_limit的一个bug
• PHP Reflection Extension的一个bug
• PHP类型转换相关的一个Bug

Related Posts:

• 如何设置一个严格30分钟过期的Session
• 更简单的重现PHP Core的调用栈
• 上传进度支持(Upload progress in sessions)
• 如何调试PHP的Core之获取基本信息
• 深入理解PHP原理之Session Gc的一个小概率Notice
• PHP Reflection Extension的一个bug
• 深入理解PHP内存管理之一个低概率Core的分析
• PHP stream未能及时清理现场导致Core的bug
• PHP错误抑制符(@)导致引用传参失败的Bug
• PHP类型转换相关的一个Bug

• 作者: Laruence( )
• 本文地址: http://www.laruence.com/2008/08/24/427.html
• 转载请注明出处

今天guoxiaod提出了一个问题，如下：

<?php
class a extends b {
};
class b extends c{
};
class c{
};
?>
  

会导致fatal error:

PHP Fatal error:  Class 'b' not found in /home/xinchen/1.php on line 2
Fatal error: Class 'b' not found in /home/xinchen/1.php on line 2

分析这个问题，是运行阶段出错，经过分析PHP的编译，执行过程，得出如下的parsing顺序…

start:
    top_statement_list
;

top_statement_list:
        top_statement_list
.... //有省略
;

top_statement:
.... //有省略
    |   class_declaration_statement
 .... //有省略
;

class_declaration_statement:
        unticked_class_declaration_statement
;

unticked_class_declaration_statement:
        class_entry_type T_STRING extends_from
.... //有省略
;

class_entry_type:
        T_CLASS
.... //有省略
;

extends_from:
        /* empty */
    |   T_EXTENDS fully_qualified_class_name
.... //有省略
;
fully_qualified_class_name:
        T_STRING { zend_do_fetch_class(&$$, &$1 TSRMLS_CC); }
;

zend_do_fetch_class 会设置opcode = ZEND_FETCH_CLASS

从这个过程我们可以发现，这个应该是PHP5的bug， 对于fully_qualified_class_name，如果fully_qualified_class_name也是继承来自一个类，那么就会出错， 因为fully_qualified_class_name只是简单的去fetch_class, 而如果这个时候，这个类还没有被填入到class_table就会出错。也就是说，需要有个机制，来保证父class首先被处理。

以下是我分析源码后的结论：
对于a，因为是个派生类，在编译阶段，当遇到它的定义的时候，会：

 zend_do_begin_class_declaration

在这个函数中，会调用:

 build_runtime_defined_function_key(&opline->op1.u.constant, lcname, name_len TSRMLS_CC);

来产生一个：

   sprintf(result->value.str.val, "%c%s%s%s", '\0', name, filename, char_pos_buf);

的字符串，来做为一个编译器的classname存入class_table:

    zend_hash_update(CG(class_table), opline->op1.u.constant.value.str.val, opline->op1.u.constant.value.str.len, &new_class_entry, sizeof(zend_class_entry *), NULL);

最后在吸收top_statement的时候，会有一次类的生成(填入class_table);

top_statement:
        statement
 ...
    |   class_declaration_statement     { zend_do_early_binding(TSRMLS_C); }
...
...
;

在zend_do_early_binding的时候：

void zend_do_early_binding(TSRMLS_D){
...
...
  switch (opline->opcode) {
      case ZEND_DECLARE_FUNCTION:
          if (do_bind_function(opline, CG(function_table), 1) == FAILURE) {
              return;
          }
          table = CG(function_table);
          break;
      case ZEND_DECLARE_CLASS:
      case ZEND_DECLARE_INHERITED_CLASS:
          is_abstract_class = 1;
          /* break missing intentionally */
      case ZEND_VERIFY_ABSTRACT_CLASS: {
              zend_op *verify_abstract_class_op = opline;

              if (!is_abstract_class) {
                  opline--;
              }
              if (opline->opcode == ZEND_DECLARE_CLASS) {
                  if (do_bind_class(opline, CG(class_table), 1 TSRMLS_CC) == NULL) {
                      return;
                  }
              } else if (opline->opcode == ZEND_DECLARE_INHERITED_CLASS) {
                  zval *parent_name = &(opline-1)->op2.u.constant;
                  zend_class_entry **pce;

                    if (zend_lookup_class(Z_STRVAL_P(parent_name), Z_STRLEN_P(parent_name), &pce TSR
MLS_CC) == FAILURE) {
                        return;
                    }
                    if (do_bind_inherited_class(opline, CG(class_table), *pce, 1 TSRMLS_CC) == NULL)
 {
                        return;
                    }
                    /* clear unnecessary ZEND_FETCH_CLASS opcode */
}

看到了吧，如果找不到父类，就直接返回了，也就是说，派生类在编译期如果找不到父类，就不会被真正初始化，而是推迟到执行期。会分配一个opcode为ZEND_DECLARE_INHERITED_CLASS的opline，用来在运行期真正生成定义的类：

ZEND_API zend_class_entry *do_bind_inherited_class(zend_op *opline, HashTable *class_table, zend_class_entry *parent_ce, zend_bool compile_time TSRMLS_DC)
{
.......
//hash_merg子类和父类的属性、方法
    if (zend_hash_add(class_table, opline->op2.u.constant.value.str.val, opline->op2.u.constant.value.str.len+1, pce, sizeof(zend_class_entry *), NULL)==FAILURE)
.....
}

这个时候问题就来了：
因为我们的b也是一个派生类，所以在执行a的do_bind_inherited_class时候，对于b，他也需要做一个ZEND_DECLARE_INHERITED_CLASS，也就是说，此时的class_table中是没有b的。
这也就解释了，如果最基类c，定义在前的时候，就不会出错。

恩，这个应该是PHP5的一个Bug。

我已经报bug给PHP开发组并发信询问Rasmus Lerdof(the creator of PHP)，看他们怎么说了：
http://bugs.php.net/bug.php?id=45904

Comments

• 2008/08/24, guoxiaod writes: 不过，按照这个逻辑的话，似乎就是这么设计的。
• 2008/08/24, guoxiaod writes: 给 rasmus 发个信 ?
• 2008/08/24, 雪候鸟 writes: 报了bug了，看看PHP开发组怎么回应吧。
• 2008/08/25, guoxiaod writes: 这样似乎可以想的通 bind 的时候只有 c 是存在的 执行的时候 自然找不到 b 而 如果c 在前的话 ， b 就bind 了 自然 b就可以找到了
• 2008/08/25, surfchen writes: 这个bug有人报过。http://bugs.php.net/bug.php?id=6418
• 2008/08/25, 雪候鸟 writes: 哦？看到了，他是针对PHP4， 另外也没关系，起码我们分析出原因了。 也就明白了，为什么单层继承不会出问题。 并且，对于上例，如果c定义在前，也不会出问题。
• 2008/08/26, chinawolfs writes: 执行这样应该不会有什么问题的.顺序的情况
• 2008/09/08, x writes: [25 Aug 9:13am UTC] tularis@php.net Please do not submit the same bug more than once. An existing bug report already describes this very problem. Even if you feel that your issue is somewhat different, the resolution is likely to be the same. Thank you for your interest in PHP. Duplicate of bug #45903
• 2010/09/29, 好消息 writes: 好消息1.纵观社会的发展方向,火花机行业拥有良好的发展趋势,并且已经成为一个传统而又崭新的创业领域。上海加工中心目前,随着我国经济的快速发展,对苏州火花机机械行业的加大了重视度,尤其是矿山机械。随着近几年,砂石冶金等行业生产规模的扩大,加工中心维修其对人工机制砂的需求越来越大：2.秋季美容护肤:水嫩不干燥 美容秋季护理大，简要内容:爱美女性往往会过多关心面部的青春娇美,却易忽视自己颈部的保养。400尤其是在干燥的秋季,颈部皮肤容易老化,粗糙无光、松弛多皱。浙江环保设备采购每天晚上洗浴时,用含碱少的温和型香皂洗涤颈部,江苏墙体广告用松软毛巾擦干,再进行按摩。
• 2011/03/20, PHP5多层继承顺序的bug | 万维网黑客联盟 writes: [...] 本文地址: http://www.laruence.com/2008/08/24/427.html [...]

Related posts:

• PHP错误抑制符(@)导致引用传参失败的Bug
• 深入理解PHP原理之Session Gc的一个小概率Notice
• PHP5.2.*防止Hash冲突拒绝服务攻击的Patch
• PHP stream未能及时清理现场导致Core的bug
• PHP5.3 α2初体验

Related Posts:

• PHP Reflection Extension的一个bug
• PHP错误抑制符(@)导致引用传参失败的Bug
• PHP类型转换相关的一个Bug
• PHP5.2.x + APC的一个bug的定位
• PHP-5.3.9远程执行任意代码漏洞(CVE-2012-0830)
• 我们什么时候应该使用异常?
• 使用exit(-1)为什么得到255退出码?
• PHP的历史
• 如何设置一个严格30分钟过期的Session
• 2012年1月全球www网站技术报告