php.net |  support |  documentation |  report a bug |  advanced search |  search howto |  statistics |  random bug |  login
Bug #47818 Segfault due to bound callback param
Submitted: 2009-03-28 04:04 UTC Modified: 2009-04-02 15:55 UTC
From: galaxy dot mipt at gmail dot com Assigned: felipe (profile)
Status: Closed Package: XMLRPC-EPI related
PHP Version: 5.2.9 OS: Linux 2.6.18 x86
Private report: No CVE-ID: None
 [2009-03-28 04:04 UTC] galaxy dot mipt at gmail dot com
Description:
------------
In my particular case when the callback for xmlrpc_server_register_method() is a class method attempt to save some of the parameters passed to that callback during xmlrpc_server_call_method() call results in segfault.

Well, I cannot provide short code that would reproduce the segfault I get in my application - it's sort of unstable. But the code below at least show that something is really wrong here.

I believe that $method_name just gets garbage-collected no matter that it is bound with $this->method. Decoupling them, for example like this, helps:
$this->method = (string)$method_name;


Reproduce code:
---------------
class MyXmlRpc {

    private $s;

    private $method;

    function impl($method_name, $params, $user_data){
        $this->method = $method_name;
        print "Inside impl(): {$this->method}\n";
        return array_sum($params);
    }

    function __construct() {
        $this->s = xmlrpc_server_create();
        xmlrpc_server_register_method($this->s,'add', array($this, 'impl'));
    }

    function call($req) {
        return xmlrpc_server_call_method($this->s, $req, null);
    }

    function getMethod() {return $this->method;}

}

$x = new MyXmlRpc;
$resp = $x->call(xmlrpc_encode_request('add',array(1,2,3)));

$method = $x->getMethod();

print "Global scope: $method\n";



Expected result:
----------------
Inside impl(): add
Global scope: add

Actual result:
--------------
Inside impl(): add
Global scope:

Patches

Add a Patch

Pull Requests

Add a Pull Request

History

AllCommentsChangesGit/SVN commitsRelated reports
 [2009-03-31 07:12 UTC] jani@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.


 [2009-04-01 02:04 UTC] galaxy dot mipt at gmail dot com
Okay, here's the backtrace from my app (not sure if this is helpful as it does not contain references to XML-RPC extension):

#0  0x0078c0ec in memcpy () from /lib/tls/libc.so.6
#1  0x012a4fc2 in php_var_serialize_intern (buf=0xbfa05560, struc=Variable "struc" is not available.
) at /home/local/php-5.2.9/ext/standard/var.c:536
#2  0x012a4b12 in php_var_serialize_intern (buf=0xbfa05560, struc=0x914d4f8, var_hash=0xbfa05570) at /home/local/php-5.2.9/ext/standard/var.c:824
#3  0x012a4b12 in php_var_serialize_intern (buf=0xbfa05560, struc=0xb7f3b114, var_hash=0xbfa05570) at /home/local/php-5.2.9/ext/standard/var.c:824
#4  0x012a4b12 in php_var_serialize_intern (buf=0xbfa05560, struc=0xb7f3b2ec, var_hash=0xbfa05570) at /home/local/php-5.2.9/ext/standard/var.c:824
#5  0x012a7ae5 in php_var_serialize (buf=0xbfa05560, struc=0x9216500, var_hash=0xbfa05570) at /home/local/php-5.2.9/ext/standard/var.c:842
#6  0x012a7b71 in zif_serialize (ht=1, return_value=0xb7f3e694, return_value_ptr=0x0, this_ptr=0x0, return_value_used=1) at /home/local/php-5.2.9/ext/standard/var.c:865
#7  0x0132c009 in zend_do_fcall_common_helper_SPEC (execute_data=0xbfa05b90) at /home/local/php-5.2.9/Zend/zend_vm_execute.h:200
#8  0x0132b7b5 in execute (op_array=0x8fa87e0) at /home/local/php-5.2.9/Zend/zend_vm_execute.h:92
#9  0x0132ba01 in zend_do_fcall_common_helper_SPEC (execute_data=0xbfa05fd0) at /home/local/php-5.2.9/Zend/zend_vm_execute.h:234
#10 0x0132b7b5 in execute (op_array=0x8f9a988) at /home/local/php-5.2.9/Zend/zend_vm_execute.h:92
#11 0x0132ba01 in zend_do_fcall_common_helper_SPEC (execute_data=0xbfa06280) at /home/local/php-5.2.9/Zend/zend_vm_execute.h:234
#12 0x0132b7b5 in execute (op_array=0x8f8342c) at /home/local/php-5.2.9/Zend/zend_vm_execute.h:92
#13 0x01312029 in zend_execute_scripts (type=8, retval=0x0, file_count=3) at /home/local/php-5.2.9/Zend/zend.c:1134
#14 0x012d96dd in php_execute_script (primary_file=0xbfa08560) at /home/local/php-5.2.9/main/main.c:2023
#15 0x0138d2b6 in apache_php_module_main (r=0x8f71984, display_source_mode=0) at /home/local/php-5.2.9/sapi/apache/sapi_apache.c:53
#16 0x0138dc48 in send_php (r=0x8f71984, display_source_mode=0, filename=0x0) at /home/local/php-5.2.9/sapi/apache/mod_php5.c:664
#17 0x0138de3e in send_parsed_php (r=0x8f71984) at /home/local/php-5.2.9/sapi/apache/mod_php5.c:679
#18 0x0809e808 in ap_invoke_handler ()
#19 0x080b3eca in process_request_internal ()
#20 0x080b4323 in ap_internal_redirect ()
#21 0x0806d3c7 in handler_redirect ()
#22 0x0809e808 in ap_invoke_handler ()
#23 0x080b3eca in process_request_internal ()
#24 0x080b3f29 in ap_process_request ()
#25 0x080aad2b in child_main ()
#26 0x080ab014 in make_child ()
#27 0x080ab34d in perform_idle_server_maintenance ()
#28 0x080ab95a in standalone_main ()
#29 0x080abf7d in main ()


As I mentioned earlier the crash is not very stable, I caught this on PHP compiled without --enable-debug because I could not make it crash otherwise after reasonable effort. With debug enabled though it reports memory leaks:

[Wed Apr  1 01:31:18 2009]  Script:  '/home/local/public_html/site/index.php'
/home/local/php-5.2.9/Zend/zend_variables.h(45) :  Freeing 0xB7E9DC64 (1 bytes), script=/home/local/public_html/site/index.php
/home/local/php-5.2.9/Zend/zend_variables.c(120) : Actual location (location was relayed)
[Wed Apr  1 01:31:18 2009]  Script:  '/home/local/public_html/site/index.php'
/home/local/php-5.2.9/ext/xmlrpc/xmlrpc-epi-php.c(362) :  Freeing 0x0939CEA8 (21 bytes), script=/home/local/public_html/site/index.php
=== Total 2 memory leaks detected ===


Up in backtrace it crashed at serialize step but it tends to occasinally crash at any access attempts to the variable that stores the unfortunate XML-RPC method name.
 [2009-04-01 02:44 UTC] galaxy dot mipt at gmail dot com
xmlrpc-epi-php.c, line 1115 (xmlrpc_server_call_method):

            /* cleanup after ourselves.  what a sty! */
            zval_dtor(data.xmlrpc_method);
            FREE_ZVAL(data.xmlrpc_method);
            zval_dtor(data.return_data);
            FREE_ZVAL(data.return_data);

If I get it right data.xmlrpc_method is completely destructed after method call. What if it has more than 1 reference like in reproduce code?
 [2009-04-02 15:55 UTC] felipe@php.net
This bug has been fixed in CVS.

Snapshots of the sources are packaged every three hours; this change
will be in the next snapshot. You can grab the snapshot at
http://snaps.php.net/.
 
Thank you for the report, and for helping us make PHP better.

Fixed in 5.2, 5.3 and HEAD.

Thanks.
 
PHP Copyright © 2001-2024 The PHP Group
All rights reserved.
Last updated: Tue Mar 19 11:01:28 2024 UTC