• 作者: 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/2009/11/27/1164.html
• 转载请注明出处

PHP 5.2x中, 由于错误的选用了zend_atoi, 导致memory_limit不能设置为超过4G的值.

今天同事分享给我一个问题(thans to yanmi), 一段代码(PHP 5.2.11 Linux/X86_64),设置memory_limit为4096M会导致内存耗尽, 而设置4095M就不会. 奇怪的问题呵.

那是怎么回事呢?

问题的原因也很简单, 在PHPSRC/main.c中定义的memory_limit设置项的处理器OnChangeMemoryLimit中, 并没有检测当前的机器字长, 而统一使用了zend_atoi来做为字符串数字化, 这个问题在PHP5.3的版本中已经修正(换成了zend_atol):

static PHP_INI_MH(OnChangeMemoryLimit)
{
    if (new_value) {
        PG(memory_limit) = zend_atoi(new_value, new_value_length);
    } else {
        PG(memory_limit) = 1<<30;       /* effectively, no limit */
    }
    return zend_set_memory_limit(PG(memory_limit));
}

而, 顾名思义么, atoi是转成整形, 4096M是2的32次方, 发生溢出, 继而环绕成结果为0, zend_atoi代码如下:

ZEND_API int zend_atoi(const char *str, int str_len)
{
    int retval;

    if (!str_len) {
        str_len = strlen(str);
    }
    retval = strtol(str, NULL, 0);
    if (str_len>0) {
        switch (str[str_len-1]) {
            case 'g':
            case 'G':
                retval *= 1024;
                /* break intentionally missing */
            case 'm':
            case 'M':
                retval *= 1024;
                /* break intentionally missing */
            case 'k':
            case 'K':
                retval *= 1024;
                break;
        }
    }
    return retval;
}

最后在zend_set_memory_limit的时候, 会错误的设置memory_limit为mm_heap的blok_size, 那结果就肯定远远小与你所预期的4096M了

....
 AG(mm_heap)->limit = (memory_limit >= AG(mm_heap)->block_size) ? memory_limit : AG(mm_heap)->block_size;
...

最后, 如果是32位的机器, 那确实不算bug, 但现在的机器很多都64了, 最大内存也不再是4GB了, PHP也要与时俱进啊.

PS, 多看别人的代码是有好处的, 今天有学会了intentionally这个单词, ^_^.

Comments

• 2009/11/27, Anders writes: 真的使用了4G内存？ 那我们这些开发机只有512M内存的人怎么活啊?
• 2009/11/27, 雪候鸟 writes: @Anders 呵呵, 现在的服务器都不止4G的内存了..., 不过这个bug确实影响不大..
• 2009/11/27, fortruth writes: 果然， 今天我也学到了 intentionally 这个单词。 :)
• 2009/11/27, kevin writes: 4个G内存消耗确实不常见，但有时需要遍历一些数据库操作大数据集的时候还是比较容易碰到的。 分析的不错！另：1<<30是多大？
• 2009/11/27, kevin writes: 另：1<<30是多大？ -------------------------- 应该是pow(2,30)吧,2的30次方。
• 2009/11/29, 星空泪 writes: 占用 4G 内存的程序大概需要优化了……
• 2009/12/02, Anonymous writes: 脚本语言估计是不会 要 4G 内存的了。
• 2009/12/02, laruence writes: @Anonymous 恩, 这个只是就问题而说问题, 再说,设置成4096,不代表就要用4096么, ;_)

Related posts:

• ini_set memory_limit在safe_mode下不可用
• PHP Reflection Extension的一个bug
• PHP类型转换相关的一个Bug
• PHP5.2.x + APC的一个bug的定位

Related Posts:

• 深入理解PHP内存管理之谁动了我的内存
• PHP类型转换相关的一个Bug
• Nginx + PHP CGI的一个可能的安全漏洞
• 深入理解PHP原理之对象(一)
• PHP5.2.x + APC的一个bug的定位
• 提升PHP性能之改变Zend引擎分发方式
• PHP文件上传源码分析(RFC1867)
• 深入理解PHP原理之错误抑制与内嵌HTML
• PHP-5.3.9远程执行任意代码漏洞(CVE-2012-0830)
• 我们什么时候应该使用异常?