php.net |  support |  documentation |  report a bug |  advanced search |  search howto |  statistics |  random bug |  login
Bug #64168 Segmentation fault when a Closure ends up in the session data
Submitted: 2013-02-07 09:29 UTC Modified: 2014-04-14 02:05 UTC
Votes:3
Avg. Score:3.3 ± 0.5
Reproduced:3 of 3 (100.0%)
Same Version:1 (33.3%)
Same OS:0 (0.0%)
From: rosier at interstroom dot nl Assigned:
Status: Not a bug Package: Xdebug (PECL)
PHP Version: Irrelevant OS:
Private report: No CVE-ID: None
 [2013-02-07 09:29 UTC] rosier at interstroom dot nl
Description:
------------
I can reproduces the segfault with PHP 5.3.21 and PHP 5.4.11

Test script:
---------------
session_start();

$_SESSION['test'] = function($name) { return strtoupper($name); };

Expected result:
----------------
No crash and a error message like "PHP Fatal error: 'Closure' in session data is not allowed"

Actual result:
--------------
Blank screen in the browser and the following apache logs:
[Wed Feb 06 12:51:50 2013] [error] [client 192.168.0.xx] PHP Fatal error:  Uncaught exception 'Exception' with message 'Serialization of 'Closure' is not allowed' in [no active file]:0\nStack trace:\n#0 {main}\n  thrown in [no active file] on line 0
[Wed Feb 06 12:51:51 2013] [notice] child pid 7316 exit signal Segmentation fault (11)

Patches

Add a Patch

Pull Requests

Pull requests:

Add a Pull Request

History

AllCommentsChangesGit/SVN commitsRelated reports
 [2013-02-07 16:00 UTC] laruence@php.net
Thank you for this bug report. To properly diagnose the problem, we
need a backtrace to see what is happening behind the scenes. To
find out how to generate a backtrace, please read
http://bugs.php.net/bugs-generating-backtrace.php for *NIX and
http://bugs.php.net/bugs-generating-backtrace-win32.php for Win32

Once you have generated a backtrace, please submit it to this bug
report and change the status back to "Open". Thank you for helping
us make PHP better.

I can not reproduce this with 5.4.*  , could you please paste the backtrace out?
 [2013-02-07 16:00 UTC] laruence@php.net
-Status: Open +Status: Feedback
 [2013-02-07 18:28 UTC] rosier at interstroom dot nl
I did some more tests and it looks like the segfault is related to Xdebug.


Without xdebug
(gdb) run test.php
Starting program: /opt/local/bin/php54 test.php
Reading symbols for shared libraries .+++++++++. done
Reading symbols for shared libraries . done
Reading symbols for shared libraries ............ done
Reading symbols for shared libraries .... done
Reading symbols for shared libraries . done
Reading symbols for shared libraries .......................................................................... done
Reading symbols for shared libraries ..... done
Reading symbols for shared libraries . done
Reading symbols for shared libraries .. done
Reading symbols for shared libraries . done
Reading symbols for shared libraries . done
Reading symbols for shared libraries . done
Reading symbols for shared libraries . done
Reading symbols for shared libraries . done
Reading symbols for shared libraries .. done
Reading symbols for shared libraries . done
Reading symbols for shared libraries . done
PHP Fatal error:  Uncaught exception 'Exception' with message 'Serialization of 'Closure' is not allowed' in [no active file]:0
Stack trace:
#0 {main}
  thrown in [no active file] on line 0

Fatal error: Uncaught exception 'Exception' with message 'Serialization of 'Closure' is not allowed' in [no active file]:0
Stack trace:
#0 {main}
  thrown in [no active file] on line 0

Program exited with code 0377.
(gdb) bt
No stack.


With xdebug
(gdb) run test.php
Starting program: /opt/local/bin/php54 test.php
Reading symbols for shared libraries . done
Reading symbols for shared libraries . done
Reading symbols for shared libraries ...... done
Reading symbols for shared libraries .... done
Reading symbols for shared libraries . done
Reading symbols for shared libraries .................. done
Reading symbols for shared libraries .+++. done
Reading symbols for shared libraries . done
Reading symbols for shared libraries .. done
Reading symbols for shared libraries . done
Reading symbols for shared libraries . done
Reading symbols for shared libraries . done
Reading symbols for shared libraries . done
Reading symbols for shared libraries . done
Reading symbols for shared libraries .. done
Reading symbols for shared libraries . done
Reading symbols for shared libraries . done
PHP Fatal error:  Uncaught exception 'Exception' with message 'Serialization of 'Closure' is not allowed' in [no active file]:0
Stack trace:
#0 {main}
  thrown in [no active file] on line 0

Program received signal EXC_BAD_ACCESS, Could not access memory.
Reason: KERN_INVALID_ADDRESS at address: 0x0000000000000000
0x00007fff8581ec00 in strlen ()
(gdb) bt
#0  0x00007fff8581ec00 in strlen ()
#1  0x0000000100da2bc9 in xdebug_str_add ()
#2  0x0000000100da28d0 in xdebug_error_cb ()
#3  0x0000000100213593 in zend_error_va ()
#4  0x00000001002137ad in zend_exception_error ()
#5  0x0000000100214016 in zend_throw_exception_internal ()
#6  0x000000010021415a in zend_throw_exception ()
#7  0x00000001002142bc in zend_throw_exception_ex ()
#8  0x000000010021295f in zend_class_serialize_deny ()
#9  0x000000010014a11f in php_var_serialize_intern ()
#10 0x000000010014b9b7 in php_var_serialize ()
#11 0x00000001000cfcd8 in ps_srlzr_encode_php ()
#12 0x00000001000ca586 in php_session_encode ()
#13 0x00000001000ca640 in php_session_flush ()
#14 0x00000001000cadac in zm_deactivate_session ()
#15 0x00000001001ffac0 in zend_deactivate_modules ()
#16 0x00000001001973c7 in php_request_shutdown ()
#17 0x00000001002ac3e7 in do_cli ()
#18 0x00000001002ade36 in main ()
 [2013-02-07 18:28 UTC] rosier at interstroom dot nl
-Status: Feedback +Status: Open -Package: Session related +Package: Xdebug
 [2013-03-04 03:17 UTC] payden at paydensutherland dot com
I've looked into this a bit and I'm unsure whether this would be classified as an xdebug problem or PHP problem, but essentially this segfault 
is going to happen anytime there is an exception thrown without a stack frame and xdebug is enabled, (I think).  In Zend/zend_exceptions.c 
line 110 zend_exception_error calls zend_error_va which calls zend_error_cb which is xdebug_error_cb with xdebug enabled.  xdebug_error_cb 
calls xdebug_str_add with XG(last_exception_trace) = NULL which eventually causes a strlen(NULL).  XG(last_exception_trace) gets set in 
xdebug_throw_exception_hook which is never called in the case of an exception without a stack.  Trivial solution is to check for NULL in 
xdebug_str_add which I've submitted a pull request to do this to xdebug.  I think it should probably check for NULL anyway.  It's not like 
it's expensive?  Maybe, I'm mistaken there though.  IMHO it seems that xdebug should handle the case of xdebug_error_cb being called with 
last_exception_trace = NULL or PHP should ensure zend_throw_exception_hook is called before zend_error_cb?  I've tried putting the 
zend_throw_exception_hook call ahead of the zend_error_cb in zend_exceptions.c and xdebug seems to handle that okay.  I get the following in 
that case:

Fatal error: Uncaught exception 'Exception' with message 'Serialization of 'Closure' is not allowed' in [no active file] on line 0

Exception: Serialization of 'Closure' is not allowed in [no active file] on line 0

This is similar to what I get when I have a script just throw an uncaught exception except there is no stack trace from xdebug.  (Obviously)

I'm still a PHP internals newbie though, so I'm not sure if that is the "right" thing to do.

Backtrace:

PHP-5.4.12/xdebug-2.2.1

(gdb) bt
#0  __strlen_sse2_bsf () at ../sysdeps/i386/i686/multiarch/strlen-sse2-bsf.S:51
#1  0xb6d13b0e in xdebug_str_add (xs=xs@entry=0xbfffdd88, str=0x0, f=f@entry=0) at /home/payden/payden-xdebug/xdebug_str.c:33
#2  0xb6d13320 in xdebug_error_cb (type=1, error_filename=0xb706f2c8 "[no active file]", error_lineno=0, format=0x88c867d "Uncaught %s\n  
thrown", 
    args=0xbfffde00 "\020\002\a\267,\336\377\277") at /home/payden/payden-xdebug/xdebug_stack.c:639
#3  0x083ff040 in zend_error_va (type=type@entry=1, file=0xb706f2c8 "[no active file]", lineno=0, format=format@entry=0x88c867d "Uncaught %s\n  
thrown")
    at /home/payden/.src/php-5.4.12/Zend/zend_exceptions.c:791
#4  0x0840116a in zend_exception_error (exception=0xb706ec54, severity=severity@entry=1) at /home/payden/.src/php-
5.4.12/Zend/zend_exceptions.c:831
#5  0x08401339 in zend_throw_exception_internal (exception=0xb706ec54) at /home/payden/.src/php-5.4.12/Zend/zend_exceptions.c:110
#6  zend_throw_exception_internal (exception=0xb706ec54) at /home/payden/.src/php-5.4.12/Zend/zend_exceptions.c:84
#7  0x08401412 in zend_throw_exception (exception_ce=0x89caff8, exception_ce@entry=0x0, message=0xb706f124 "Serialization of 'Closure' is not 
allowed", 
    code=code@entry=0) at /home/payden/.src/php-5.4.12/Zend/zend_exceptions.c:758
#8  0x08401505 in zend_throw_exception_ex (exception_ce=exception_ce@entry=0x0, code=code@entry=0, 
    format=format@entry=0x88c82ac "Serialization of '%s' is not allowed") at /home/payden/.src/php-5.4.12/Zend/zend_exceptions.c:772
#9  0x083fe722 in zend_class_serialize_deny (object=0xb706ec8c, buffer=0xbfffdf64, buf_len=0xbfffdf68, data=0xb706fea0)
    at /home/payden/.src/php-5.4.12/Zend/zend_interfaces.c:487
#10 0x0832ab5d in php_var_serialize_intern (buf=buf@entry=0xbfffe024, struc=0xb706ec8c, var_hash=0xb706fea0)
    at /home/payden/.src/php-5.4.12/ext/standard/var.c:777
#11 0x0833092b in php_var_serialize (buf=buf@entry=0xbfffe024, struc=0xb706f450, var_hash=var_hash@entry=0xbfffe010)
    at /home/payden/.src/php-5.4.12/ext/standard/var.c:899
#12 0x0826e654 in ps_srlzr_encode_php (newstr=0xbfffe06c, newlen=0xbfffe0ac) at /home/payden/.src/php-5.4.12/ext/session/session.c:857
#13 0x0826a4e8 in php_session_encode (newlen=newlen@entry=0xbfffe0ac) at /home/payden/.src/php-5.4.12/ext/session/session.c:203
#14 0x0826a5a3 in php_session_save_current_state () at /home/payden/.src/php-5.4.12/ext/session/session.c:487
#15 php_session_flush () at /home/payden/.src/php-5.4.12/ext/session/session.c:1453
#16 0x0826b405 in zm_deactivate_session (type=1, module_number=32) at /home/payden/.src/php-5.4.12/ext/session/session.c:2144
#17 0x083eea0c in zend_deactivate_modules () at /home/payden/.src/php-5.4.12/Zend/zend_API.c:2335
#18 0x0838a445 in php_request_shutdown (dummy=dummy@entry=0x0) at /home/payden/.src/php-5.4.12/main/main.c:1769
#19 0x08487e6f in do_cli (argc=0, argc@entry=2, argv=0x7) at /home/payden/.src/php-5.4.12/sapi/cli/php_cli.c:1171
#20 0x08070047 in main (argc=2, argv=0xbffff764) at /home/payden/.src/php-5.4.12/sapi/cli/php_cli.c:1364
(gdb) f 5
#5  0x08401339 in zend_throw_exception_internal (exception=0xb706ec54) at /home/payden/.src/php-5.4.12/Zend/zend_exceptions.c:110
110				zend_exception_error(EG(exception), E_ERROR TSRMLS_CC);
(gdb) print executor_globals.current_execute_data
$3 = (struct _zend_execute_data *) 0x0
 [2013-06-06 11:40 UTC] arjen at react dot com
Similar issues @ the xdebug bugtracker: http://bugs.xdebug.org/view.php?id=921
 [2014-04-14 02:05 UTC] stas@php.net
-Status: Open +Status: Not a bug
 [2014-04-14 02:05 UTC] stas@php.net
Thank you for taking the time to report a problem with PHP.
Unfortunately you are not using a current version of PHP -- 
the problem might already be fixed. Please download a new
PHP version from http://www.php.net/downloads.php

If you are able to reproduce the bug with one of the latest
versions of PHP, please change the PHP version on this bug report
to the version you tested and change the status back to "Open".
Again, thank you for your continued support of PHP.

Looks like xdebug already fixed it.
 
PHP Copyright © 2001-2019 The PHP Group
All rights reserved.
Last updated: Sun Sep 15 05:01:26 2019 UTC