php.net |  support |  documentation |  report a bug |  advanced search |  search howto |  statistics |  random bug |  login
Bug #65367 Segmentation fault when mixing =& and =
Submitted: 2013-07-31 11:10 UTC Modified: 2013-09-19 06:34 UTC
From: mbeccati@php.net Assigned: laruence (profile)
Status: Closed Package: Reproducible crash
PHP Version: 5.5.1 OS: Any
Private report: No CVE-ID: None
View Add Comment Developer Edit
Anyone can comment on a bug. Have a simpler test case? Does it work for you on a different platform? Let us know!
Just going to say 'Me too!'? Don't clutter the database with that please !
Your email address:
MUST BE VALID
Solve the problem:
22 + 2 = ?
Subscribe to this entry?

 
 [2013-07-31 11:10 UTC] mbeccati@php.net
Description:
------------
While updating an old open source application to work with PHP 5.4 and 5.5, I somehow managed to trigger a segmentation fault when removing an =& assignment. I've been able to write a small reproduce script, which however still requires MDB2 from PEAR (tested only with the pgsql driver).

Changing back a specific assignment to =& prevents the shutdown segfault from happening.

The code works fine with 5.3 and crashes on 5.4+. Tested on Windows and Linux.

Test script:
---------------
<?php

require './usr/share/php/MDB2.php';

class A {
        static function singleton()
        {
                $db = MDB2::connect('pgsql://postgres:password@localhost/postgres');
                $db->loadModule('Datatype');

                $GLOBALS['DB'] = $db; // Using =& $db doesn't crash

                return $GLOBALS['DB'];
        }
}

class B {
        function __construct()
        {
                $this->db =& $this->getDb();
        }

        function &getDB()
        {
                return A::singleton();
        }
}

$b = new B();


Expected result:
----------------
PHP Notice:  Only variable references should be returned by reference in foobar.php on line 25


Actual result:
--------------
#0  0x0000000000812979 in gc_zval_possible_root (zv=0x7fffeef256e0) at /root/compile/php-5.5.1/Zend/zend_gc.c:143
No locals.
#1  0x0000000000801268 in zend_hash_destroy (ht=0x7fffeef2b4a0) at /root/compile/php-5.5.1/Zend/zend_hash.c:560
        p = 0x7fffeef2b860
        q = 0x7fffeef2b7b0
#2  0x00000000007f206b in _zval_dtor_func (zvalue=0x7fffeef2b470) at /root/compile/php-5.5.1/Zend/zend_variables.c:45
No locals.
#3  0x00000000007e3178 in _zval_dtor (zvalue=0x7fffeef2b470) at /root/compile/php-5.5.1/Zend/zend_variables.h:35
No locals.
#4  i_zval_ptr_dtor (zval_ptr=0x7fffeef2b470) at /root/compile/php-5.5.1/Zend/zend_execute.h:81
No locals.
#5  _zval_ptr_dtor (zval_ptr=<optimized out>) at /root/compile/php-5.5.1/Zend/zend_execute_API.c:426
No locals.
#6  0x0000000000801268 in zend_hash_destroy (ht=0x7fffeef28b10) at /root/compile/php-5.5.1/Zend/zend_hash.c:560
        p = 0x7fffeef2bfd0
        q = 0x7fffeef2ba80
#7  0x00000000007f206b in _zval_dtor_func (zvalue=0x7fffeef28778) at /root/compile/php-5.5.1/Zend/zend_variables.c:45
No locals.
#8  0x00000000007e3178 in _zval_dtor (zvalue=0x7fffeef28778) at /root/compile/php-5.5.1/Zend/zend_variables.h:35
No locals.
#9  i_zval_ptr_dtor (zval_ptr=0x7fffeef28778) at /root/compile/php-5.5.1/Zend/zend_execute.h:81
No locals.
#10 _zval_ptr_dtor (zval_ptr=<optimized out>) at /root/compile/php-5.5.1/Zend/zend_execute_API.c:426
No locals.
#11 0x0000000000801268 in zend_hash_destroy (ht=0x7fffeef2cbb8) at /root/compile/php-5.5.1/Zend/zend_hash.c:560
        p = 0x7fffeef2ce78
        q = 0x7fffeef2ce20
#12 0x000000000081579c in zend_object_std_dtor (object=0x7fffeef27cb0) at /root/compile/php-5.5.1/Zend/zend_objects.c:44
No locals.
#13 0x0000000000815829 in zend_objects_free_object_storage (object=0x7fffeef27cb0) at /root/compile/php-5.5.1/Zend/zend_objects.c:137
No locals.
#14 0x000000000081b476 in zend_objects_store_free_object_storage (objects=0x1085120)
    at /root/compile/php-5.5.1/Zend/zend_objects_API.c:92
        obj = <optimized out>
        i = <optimized out>
#15 0x00000000007e37e3 in shutdown_executor () at /root/compile/php-5.5.1/Zend/zend_execute_API.c:293
        __orig_bailout = 0x7fffffffe460
        __bailout = {{__jmpbuf = {17321344, -8869895244590628792, 0, 0, 0, 17333536, 8869894737283235912, -8869895235585851320},
            __mask_was_saved = 0, __saved_mask = {__val = {9576849035021516823, 0, 8402366, 17291648, 17319392, 140737353913872,
                140737353912280, 140737353913920, 140737353912280, 0, 17321080, 1, 0, 0, 8330270, 17320992}}}}
#16 0x00000000007f3075 in zend_deactivate () at /root/compile/php-5.5.1/Zend/zend.c:939
No locals.
#17 0x0000000000791637 in php_request_shutdown (dummy=<optimized out>) at /root/compile/php-5.5.1/main/main.c:1803
        report_memleaks = 1 '\001'
<snip>

Patches

Add a Patch

Pull Requests

Add a Pull Request

History

AllCommentsChangesGit/SVN commitsRelated reports
 [2013-07-31 11:13 UTC] mbeccati@php.net
I forgot to mention that you can easily install the necessary PEAR libraries in the current dir without polluting the global PEAR installation with:

pear install -R . MDB2 MDB2#pgsql
 [2013-07-31 11:40 UTC] mbeccati@php.net
-Summary: Segmentation fault when returning onjects by reference +Summary: Segmentation fault when mixing =& and =
 [2013-08-02 01:11 UTC] laruence@php.net
Seems similar to #65372
 [2013-08-02 02:00 UTC] laruence@php.net
-Status: Open +Status: Feedback
 [2013-08-02 02:00 UTC] laruence@php.net
could you please verify the fix I attached at #65372?
thanks
 [2013-08-02 07:29 UTC] mbeccati@php.net
Yes, the patch fixes the issue as far as I can tell. Well done!
 [2013-08-02 07:30 UTC] mbeccati@php.net
-Status: Feedback +Status: Open
 [2013-08-02 16:24 UTC] laruence@php.net
-Status: Open +Status: Closed -Assigned To: +Assigned To: laruence
 [2013-08-02 16:24 UTC] laruence@php.net
fixed in http://git.php.net/?p=php-
src.git;a=commitdiff;h=ce9169e360701ea3b1ab2366171c24d4de5e78e3
 [2013-08-05 14:50 UTC] mbeccati@php.net
-Status: Closed +Status: Re-Opened
 [2013-08-05 14:50 UTC] mbeccati@php.net
I have upgraded PHP 5.4 to latest-git on a new machine. With the patch applied I now see many test runs consistently fail with a segafult. Reverting to 5.4.17 fixes the segfault.

Backtrace is:

#0  0x00000000009beb33 in zend_std_object_get_class (object=0x7fffef535cd0) at /root/compile/php-src/Zend/zend_object_handlers.c:1500
        zobj = 0x7fff00000021
#1  0x000000000098dd98 in zend_get_class_entry (zobject=0x7fffef535cd0) at /root/compile/php-src/Zend/zend_API.c:238
No locals.
#2  0x0000000000a17121 in ZEND_INIT_METHOD_CALL_SPEC_CV_CONST_HANDLER (execute_data=0x7ffff7fa1ea0)
    at /root/compile/php-src/Zend/zend_vm_execute.h:29282
        opline = 0x7ffff0a34228
        function_name = 0x7ffff0a35058
        function_name_strval = 0x7ffff7f97d50 "setFileNameProtection"
        function_name_strlen = 21
#3  0x00000000009c6513 in execute (op_array=0x1446f00) at /root/compile/php-src/Zend/zend_vm_execute.h:410
        ret = 0
        execute_data = 0x7ffff7fa1ea0
        nested = 1 '\001'
        original_in_execution = 0 '\000'
#4  0x000000000098ca9f in zend_execute_scripts (type=8, retval=0x0, file_count=3) at /root/compile/php-src/Zend/zend.c:1315
        files = {{gp_offset = 40, fp_offset = 48, overflow_arg_area = 0x7fffffffae40, reg_save_area = 0x7fffffffad80}}
        i = 1
        file_handle = 0x7fffffffd1e0
        orig_op_array = 0x0
        orig_retval_ptr_ptr = 0x0
        orig_interactive = 0
#5  0x0000000000902ff4 in php_execute_script (primary_file=0x7fffffffd1e0) at /root/compile/php-src/main/main.c:2497
        realfile = "/home/atlassian/bamboo/xml-data/build-dir/AP-RET-P53P/tests/run.php\000\000\000\000\000\021", '\000' <repeats 15 times>, "P\301\377\377\377\177\000\000\336U\225\000\000\000\000\000\234\066\336\367\377\177\000\000\000\020$\001\000\000\000\000\016\000\000\000\000\000\000\000\260\302\377\377\377\177\000\000-\000\000\000\000\000\000\000fII\"\000\000\000\000\240>\336\367\377\177\000\000\000\000\000\000\000\000\000\000&\000\000\000\000\000\000\000%%\211\000\000\000\000\000\030\255\231\365\377\177\000\000\214\236\231\365\377\177\000\000"...
        __orig_bailout = 0x7fffffffd2f0
        __bailout = {{__jmpbuf = {0, -263622604701000067, 4380576, 140737488348720, 0, 0, -263622602725482883, 263621642691976829},
            __mask_was_saved = 0, __saved_mask = {__val = {0, 0, 140737314399616, 140737488343184, 0, 140737488343200, 4380576, 140737488348720, 0, 0,
                9431409, 140737488344000, 140737488349319, 19186208, 287762808856, 21253568}}}}
        prepend_file_p = 0x0
        append_file_p = 0x0
        prepend_file = {type = ZEND_HANDLE_FILENAME, filename = 0x0, opened_path = 0x0, handle = {fd = 0, fp = 0x0, stream = {handle = 0x0,
              isatty = 0, mmap = {len = 0, pos = 0, map = 0x0, buf = 0x0, old_handle = 0x0, old_closer = 0x0}, reader = 0x0, fsizer = 0x0,
              closer = 0x0}}, free_filename = 0 '\000'}
        append_file = {type = ZEND_HANDLE_FILENAME, filename = 0x0, opened_path = 0x0, handle = {fd = 0, fp = 0x0, stream = {handle = 0x0, isatty = 0,
              mmap = {len = 0, pos = 0, map = 0x0, buf = 0x0, old_handle = 0x0, old_closer = 0x0}, reader = 0x0, fsizer = 0x0, closer = 0x0}},
          free_filename = 0 '\000'}
        old_cwd = 0x7fffffffae60 ""
        use_heap = 0 '\000'
        retval = 0
 [2013-08-06 03:02 UTC] laruence@php.net
did you built it frome a fresh work dir?
 [2013-08-06 05:53 UTC] mbeccati@php.net
Yes, I've used a fresh git clone.
 [2013-08-06 07:45 UTC] laruence@php.net
-Status: Re-Opened +Status: Closed
 [2013-08-06 07:45 UTC] laruence@php.net
thanks for the ssh access, it is helpful.

fixed in: http://git.php.net/?p=php-
src.git;a=commit;h=a831499b4a1029118dc45375e62af42043110ade
 [2013-09-18 17:28 UTC] jbozza at mindsites dot com
This bug has been listed as closed and fixed in git, but the problem still remains in 5.4.19. Looking at the diff for both files fixed, the 5.4.19 source code is still missing the changed lines.

According to the changelogs, 5.5.2 received the fixes on August 15, 2013, but 5.4.18 (released the same day) did not receive the fixes.

Can this be applied to 5.4.x? Comment at 2013-08-05 14:50 UTC, by mbeccati@php.net even mentions 5.4.
 [2013-09-19 06:34 UTC] mbeccati@php.net
Yes, this didn't make it into PHP 5.4.19 as it was branched off of 5.4.18. Hopefully 5.4.20 will contain the fix (like 5.5.2 does).
 
PHP Copyright © 2001-2024 The PHP Group
All rights reserved.
Last updated: Tue Apr 16 09:01:28 2024 UTC