PHP stream未能及时清理现场导致Core的bug

 

  同事发现一个在使用set_error_handler的时候, 能100%重现的core, 提炼后的重现代码如下(环境必须不能访问internet):

 

  <?php

  function err_handler(){

  exit;

  return true;

  }

  set_error_handler('err_handler');

  $client = file_get_contents("http://www.laruence.com/ServiceNoWse.asmx?WSDL");

 

  这段代码, 放在webServer中, 第一次访问不会有事, 第二第三次的时候就会出core.

  gdb跟踪以后发现, core出在php_stream_display_wrapper_errors函数中, 对err_stack中的错误信息字符串做处理的时刻, core的堆栈如下:

 

  #0 0x000000302af6ff20 in strlen () from /lib64/tls/libc.so.6

  #1 0x0000002a989d97c1 in php_stream_display_wrapper_errors (wrapper=0x2a98e884a0, path=Variable "path" is not available.

  ) at /home/huixc/package/php-5.2.14/main/streams/streams.c:151

  #2 0x0000002a989dca22 in _php_stream_open_wrapper_ex (path=0x76e7c8 "http://www.laruence.com/ServiceNoWse.asmx?WSDL", mode=0x2a98ae3087 "rb", options=8, opened_path=0x0,

  context=0x76e808) at /home/huixc/package/php-5.2.14/main/streams/streams.c:1893

  #3 0x0000002a98966541 in zif_file_get_contents (ht=-1729541984, return_value=0x76e738, return_value_ptr=Variable "return_value_ptr" is not available.

  ) at /home/huixc/package/php-5.2.14/ext/standard/file.c:541

  #4 0x0000002a98a2c05e in zend_do_fcall_common_helper_SPEC (execute_data=0x7fbfffca30) at /home/huixc/package/php-5.2.14/Zend/zend_vm_execute.h:200

  #5 0x0000002a98a2b671 in execute (op_array=0x769890) at /home/huixc/package/php-5.2.14/Zend/zend_vm_execute.h:92

  #6 0x0000002a98a0c734 in zend_execute_scripts (type=8, retval=0x0, file_count=3) at /home/huixc/package/php-5.2.14/Zend/zend.c:1134

  #7 0x0000002a989c965d in php_execute_script (primary_file=0x7fbfffef00) at /home/huixc/package/php-5.2.14/main/main.c:2036

  #8 0x0000002a98a9bd36 in php_handler (r=0x8f1ba8) at /home/huixc/package/php-5.2.14/sapi/apache2handler/sapi_apache2.c:639

 

  经过半个多小时的跟踪, 终于找到原因

  是因为, 在PHP中, 对于exit, 其实是借助了set/longjmp来实现用户脚本退出以后, 到达收尾工作, 而对于出错代码出是根据wrapper的err_count计数来确定有多少错误信息要输出.

  并且, 在输出完错误信息以后, 清空wrap的错误信息, 置零错误计数.

 

  void php_stream_tidy_wrapper_error_log(php_stream_wrapper *wrapper TSRMLS_DC)

  {

  if (wrapper) {

  /* tidy up the error stack */

  int i;

  for (i = 0; i < wrapper->err_count; i++) {

  efree(wrapper->err_stack[i]);

  }

  if (wrapper->err_stack) {

  efree(wrapper->err_stack);

  }

  wrapper->err_stack = NULL;

  wrapper->err_count = 0;

  }

  }

 

  而, 因为在现实错误信息之后, 会紧接着触发php_error_docref1, 继而触发代码中设置的error_handler, 而在handler中, 却调用了exit, 最终longjmp到了soap处理时刻设置的跳转点, 造成跳过了对 php_stream_tidy_wrapper_error_log 的调用, 所以导致第二次再来请求的时候, err_count并没有正确的被初始化为零, 还是保持着上次请求的错误数.

  于是, 在输出错误信息的时候,

 

  ......

  for (i = 0, l = 0; i < wrapper->err_count; i++) {

  l += strlen(wrapper->err_stack[i]); //出core了

  if (i < wrapper->err_count - 1) {

  l += brlen;

  }

  }

 

  暂时来说, 解决这个办法, 可以在streams的php_stream_display_wrapper_errors函数调用php_error_docref1之前掉后用php_stream_tidy_wrapper_error_log;

时间: 2024-07-31 22:07:24

PHP stream未能及时清理现场导致Core的bug的相关文章

外接程序VMDebugger未能加载或导致了异常

  故障现象:打开Visual Studio 2010后弹出错误框,外接程序VMDebugger未能加载或导致了异常,是否希望移除该外接程序,错误号:80004005.系统版本:WIN8.1 64位企业版,安装了Resharper8.1,破解. 解决办法:修改下注册表文件解决. HKEY_LOCAL_MACHINESOFTWAREWow6432NodeMicrosoftVisualStudio10.0AddInsVMDebugger.Connect LoadBehavior项改为0 然后打开vs

怎么解决外接程序VMDebugger未能加载或导致了异常?

  外接程序 VMDebugger 未能加载或导致了异常 修复 1.单击进入 是 visual studio 2.在 VMWARE 菜单栏上 单击 右键,出现如图,然后选择 自定义(C)... 3.打开 自定义 工具栏 里 选中 VMware 然后单击 删除 按钮 ,然后 关闭对话框 4.重启 visual studio,错误不再出现,进入后 如图,VMware图标工具栏重新出现

Java应用中使用ShutdownHook友好地清理现场(转)

在线上Java程序中经常遇到进程程挂掉,一些状态没有正确的保存下来,这时候就需要在JVM关掉的时候执行一些清理现场的代码.Java中得ShutdownHook提供了比较好的方案. JDK在1.3之后提供了Java Runtime.addShutdownHook(Thread hook)方法,可以注册一个JVM关闭的钩子,这个钩子可以在以下几种场景被调用: 1)程序正常退出 2)使用System.exit() 3)终端使用Ctrl+C触发的中断 4)系统关闭 5)使用Kill pid命令干掉进程

110女接线员目睹男友分尸帮其清理现场

男友以承揽工程为名骗取他人18万元,购买汽车.吃喝玩乐,暴露后约见对方痛下杀手.而作为公安机关工作人员的女友为情所困,竟然在男友肢解对方尸体时无动于衷,还帮助男友清理现场血迹和抛尸.日前,淮南市公安局指挥中心接线员李梅被检察机关以帮助毁灭证据罪提起公诉,男友张春平被检察机关以诈骗罪.故意杀人罪提起公诉.记者昨日获悉,该案已被起诉到合肥市中级人民法院,近期将开庭审理. 高速路下惊现尸块 去年12月17日早上8点多,长丰警方接到报警,称合淮阜高速公路义井乡龙王村路段西侧水塘边发现尸块.警方赶到现场,

php内核bug:动态链接方式编译的扩展,扩展全局空间dtor导致core dump

注册扩展的全局空间代码如下: #ifdef ZTS    ts_allocate_id(&sample_globals_id, sizeof(zend_sample_globals), (ts_allocate_ctor)ZEND_MODULE_GLOBALS_CTOR_N(sample), (ts_allocate_dtor)ZEND_MODULE_GLOBALS_DTOR_N(sample));#else    sample_globals_ctor(&sample_globals T

由drop datafile导致的oracle bug

今天碰到了一个dataguard在10gR2的bug,不管怎么样确实是在特定的时间做了特定的操作结果碰到了特定的问题. 这个问题是在10gR2的版本10.2.0.4.0的一个库中出现的,在做巡检的时候发现表空间使用率已经很高了,就准备加一些数据文件把这个问题给修复了,按理说这也是一个常规操作,没有什么可圈圈点点的地方. 但是添加完数据文件之后,过了一会,就收到报警说备库出了点问题,自己还纳闷到底是什么原因导致的,带着疑问使用dgmgrl来查看了一下. DGMGRL> show configura

泛函编程(37)-泛函Stream IO:通用的IO处理过程-Free Process

  在上两篇讨论中我们介绍了IO Process:Process[I,O],它的工作原理.函数组合等.很容易想象,一个完整的IO程序是由 数据源+处理过程+数据终点: Source->Process->Sink所组成的.我们发现:Process[I,O]本身是无法兼顾Source和Sink的功能.而独立附加的Source和Sink又无法有效地与Process[I,O]进行函数组合(functional composition).   实际上Process[I,O]是一种固定单一输入类型(sin

泛函编程(36)-泛函Stream IO:IO数据源-IO Source &amp; Sink

 上期我们讨论了IO处理过程:Process[I,O].我们说Process就像电视信号盒子一样有输入端和输出端两头.Process之间可以用一个Process的输出端与另一个Process的输入端连接起来形成一串具备多项数据处理功能的完整IO过程.但合成的IO过程两头输入端则需要接到一个数据源,而另外一端则可能会接到一个数据接收设备如文件.显示屏等.我们在这篇简单地先介绍一下IO数据源Source和IO数据接收端Sink. 我们先用一个独立的数据类型来代表数据源Source进行简单的示范说明,

数据库内核月报 - 2015 / 08-PgSQL · 答疑解惑 · 归档进程cp命令的core文件追查

问题现象 最近我们的几个非生产实例中,均出现了由archiver进程产生的core dump文件,让人如临大敌:是不是遇到了PG的大BUG导致了crash? 先来看看这些core文件.由于我们在/proc/sys/kernel/core_pattern指定了存放core文件的目录,所以可以在这个目录里面找到这些core文件.幸运的是,这些core文件都不大,一般几百KB,没有对文件系统的存储空间造成压力: $du -sh * 248K core.170254 248K core.242719 2