php.net |  support |  documentation |  report a bug |  advanced search |  search howto |  statistics |  random bug |  login
Bug #50394 Reference argument converted to value in __call
Submitted: 2009-12-07 01:40 UTC Modified: 2010-09-20 05:14 UTC
Votes:4
Avg. Score:4.8 ± 0.4
Reproduced:3 of 4 (75.0%)
Same Version:3 (100.0%)
Same OS:1 (33.3%)
From: tstarling at wikimedia dot org Assigned: pajoye (profile)
Status: Closed Package: Scripting Engine problem
PHP Version: 5.3.1 OS: Linux
Private report: No CVE-ID: None
 [2009-12-07 01:40 UTC] tstarling at wikimedia dot org
Description:
------------
This is a regression in the PHP 5.3.1 release. When you call a __call() function with a reference parameter, it is silently converted to a value, by the time it reaches the second argument to __call().

This breaks MediaWiki and has no obvious workaround.

Reproduce code:
---------------
function foo( &$x ) {}

class Proxy {
	function __call( $name, $args ) {
		debug_zval_dump( $args );
		call_user_func_array( 'foo', $args );
	}
}

$arg = 1;
$args = array( &$arg );
$proxy = new Proxy;
call_user_func_array( array( &$proxy, 'bar' ), $args );


Expected result:
----------------
PHP 5.3.0 produces:

array(1) refcount(4){
  [0]=>
  &long(1) refcount(5)
}


Actual result:
--------------
array(1) refcount(4){
  [0]=>
  long(1) refcount(3)
}

Warning: Parameter 1 to foo() expected to be a reference, value given in /home/tstarling/src/php/stuff/test-reference-call.php on line 8


Patches

MediaWiki (last revision 2010-09-10 14:51 UTC by produzione at solarisenergy dot it)
chihanglow (last revision 2010-07-09 00:10 UTC by chihanglow at gmail dot com)
Php_Patch (last revision 2010-05-18 08:00 UTC by saschasteffens at gmx dot net)
sedwdfqf (last revision 2010-03-31 16:40 UTC by www dot mhobkirk at shaw dot ca)

Pull Requests

History

AllCommentsChangesGit/SVN commitsRelated reports
 [2009-12-08 04:46 UTC] tstarling at wikimedia dot org
For the record, I've isolated this further, and the annotation suggests it was introduced in r287466 by stas in the course of fixing another bug.
 [2009-12-17 19:15 UTC] stas@php.net
This bug is actually deeper than it appears. The problem seems to be that when __call is used, user function is "simulated" by internal function processing __call. And there is when it gets hairy, since the simulating function does not accept parameters by-ref, so they get separated. 
I'll think about how to fix this situation - there might be a way to carry the reference through... 
 [2009-12-18 19:12 UTC] svn@php.net
Automatic comment from SVN on behalf of stas
Revision: http://svn.php.net/viewvc/?view=revision&revision=292295
Log: fix regression bug #50394: Reference argument converted to value in __call
 [2009-12-18 19:13 UTC] stas@php.net
This bug has been fixed in SVN.

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, thanks
 [2009-12-18 19:20 UTC] svn@php.net
Automatic comment from SVN on behalf of stas
Revision: http://svn.php.net/viewvc/?view=revision&revision=292296
Log: Fixed bug #50394 (Reference argument converted to value in __call)
 [2010-03-21 21:57 UTC] spam dot here at verizon dot net
Mediawiki still reports that the problem still exists.

http://www.mediawiki.org/wiki/Project:Support_desk#PHP_5.3_Problem_Still_Exists

And it is still in their install document.

http://www.mediawiki.org/wiki/Installation

"PHP version 5.1 or later (5.2.x recommended). PHP 5.3.1 is incompatible with MediaWiki due to a bug."
 [2010-03-21 22:01 UTC] tstarling at wikimedia dot org
This bug was fixed in 5.3.2. The problem you reported on mediawiki.org was not a PHP bug.
 [2010-04-07 05:59 UTC] clark4220 at yahoo dot com
PLEASE EXPLAIN THE TRUE NATURE OF THE DISAGREEMENT
 [2010-04-12 22:53 UTC] tog7yt at yahoo dot com
hljlkkga pbugs me
 [2010-06-06 18:12 UTC] PandoraBox2007 at gmail dot com
fuccking PHP 5.3.2-SVN

not working this shit
 [2010-06-06 18:55 UTC] PandoraBox2007 at gmail dot com
install-utils.inc

set comments

	/*
	$test = new PhpRefCallBugTester;
	$test->execute();
	if ( !$test->ok ) {
		echo "PHP 5.3.1 is not compatible with MediaWiki due to a bug involving\n" .
			"reference parameters to __call. Upgrade to PHP 5.3.2 or higher, or \n" .
			"downgrade to PHP 5.3.0 to fix this.\n" .
			"ABORTING (see http://bugs.php.net/bug.php?id=50394 for details)\n";
		die( -1 );
	}
	*/
 [2010-06-06 19:04 UTC] pajoye@php.net
-Assigned To: +Assigned To: pajoye
 [2010-06-06 19:04 UTC] pajoye@php.net
Mediawiki is wrong in their comments. There is a regression which was fixed in 5.3.2, so upgrade to 5.3.2 is the right way to do it.

No need of further comments tho', the issue is fixed.

Thanks for your feedbacks.
 [2010-07-23 01:09 UTC] heis dot turtlemad at gmail dot com
> Mediawiki is wrong in their comments. 

Not quite true.

> There is a regression which was fixed in 5.3.2, 
> so upgrade to 5.3.2 is the right way to do it.

Upgrading to 5.3.2 doesn't solve the issue, running the following softwares:
FreeBSD 8/Nginx/MediaWiki 1.15.4
Any call to a Mediawiki extension fails on the following error:
 <Parameter n to xxx expected to be a reference, value given in yyy>

Downgrading to 5.2 is actually the only way to get rid of this.
 [2010-08-10 09:14 UTC] parktrip at gmail dot com
I have the same problem with mediawiki 1.15.5 and PHP 5.3.2 (lastest version from Zend Server)
So is this a MW problem or PHP ?
 [2010-09-04 01:16 UTC] david at tuxteam dot com
This seems to be an issue for Drupal modules as well.  This is a significant problem for running Drupal on PHP 5.3.
 [2010-09-15 01:16 UTC] jeremy at tuxmachine dot com
See bug 51174.
 [2010-09-15 02:23 UTC] tstarling at wikimedia dot org
Commenters please note: you're receiving an error "parameter expected to be a reference, value given", that does not mean that you are seeing this bug. In fact, if you're using PHP 5.3.2 or later, it is pretty much impossible for it to be this bug. 

Most cases of "parameter expected to be a reference, value given" are due to bugs in the user code, not due to any problem with PHP. The message indicates a mismatch between the reference/value status of arguments to call_user_func_array() and the function declaration, as in:

function foo( &$x ) {}
$x = '';
call_user_func_array( 'foo', array( $x ) );

The correct way to call the function foo() in this case is:

call_user_func_array( 'foo', array( &$x ) );

That is to say, the reference must be explicit in the array on the calling side.
 [2010-09-19 10:54 UTC] heis dot turtlemad at gmail dot com
Please note that the "user code" we are talking about was running as expected  until php5.3 was released; and that downgrading to 5.2 solves the issue.

that means,  that the way to pass arrays as references in function args has 
changed since the 5.3 release ?
 [2010-09-20 05:14 UTC] tstarling at wikimedia dot org
heis: yes, the behaviour changed in 5.3.0. I'm not saying it was a good idea, I'm just saying you should complain on some other bug report, preferably one that I'm not CC'ed on. 

The correct way to pass reference arguments to functions via call_user_func_array() hasn't changed, we've been doing it this way since PHP 4. It's just that the impact of doing it the wrong way has changed. Previously, the argument was silently converted to a value. Now, a warning is shown and the function isn't called.
 [2010-09-21 11:49 UTC] hugoniks at hotmail dot com
wtff
 [2010-10-11 04:18 UTC] master33rd at yahoo dot com
I find it disturbing that the bug has been declared fixed, when it hasn't.

Starting Mediawiki with Xampp (even with the new beta of XAMPP)...the same error occurs.  "PHP 5.3.1 is not compatible with MediaWiki due to a bug involving reference parameters to __call. Upgrade to PHP 5.3.2 or higher, or downgrade to PHP 5.3.0 to fix this. ABORTING (see http://bugs.php.net/bug.php?id=50394 for details)"  Upgrading to PhP 5.3.3 doesn't fix the problem.  

Let's stop passing the buck and fix this.
 [2010-10-22 07:58 UTC] john dot GTD at yahoo dot com
What are the exact steps to reproduce the problem?

I'm running MediaWiki on UniformServer with PHP 5.3.3 and didn't have any problems 
yet.
 [2013-05-08 14:55 UTC] dessander at gmail dot com
Still active bug.

My PHP Version:
PHP 5.4.14 (cli) (built: Apr 11 2013 19:13:00)

Code to reproduce:
<?php

class TestForCall
{
    public static function myFunc($test, &$reference_var)
    {
        var_dump($test);
        $reference_var = 'changed';
    }
}

class Test
{
    public function __call($name, $arguments)
    {
        return call_user_func_array(
            array(
                'TestForCall',
                'myFunc'
            ),
            $arguments
        );
    }
}

(new Test())
    ->notExistsFunction('test', $reference_var)
;

var_dump($reference_var);

Output:
PHP Warning:  Parameter 2 to TestForCall::myFunc() expected to be a reference, value given in /www/godudu.local/test.php on line 22

Warning: Parameter 2 to TestForCall::myFunc() expected to be a reference, value given in /www/godudu.local/test.php on line 22
NULL
 [2013-06-12 11:54 UTC] merzikain at yahoo dot com
Still a bug with 5.4.16 as well.
 [2014-03-10 05:05 UTC] bgardner at noggin dot com dot au
And a test case that shows the weirdness. Run against PHP 5.3.3

<?php

function foo($a,&$b){
	print $a . ' ' . $b . "\n";
}

function fails(){
	$args = func_get_args();
	call_user_func_array('foo',$args);
}

function works(){
	$args = func_get_args();
	$newargs = array();

	foreach (array_keys($args) as $k){
		$newargs[$k] = &$args[$k];
	}

	//Notice here that I do not pass in $newargs, but $args
	call_user_func_array('foo',$args);
}


works('Hello','World');
fails('Hello','World');

?>
 [2014-03-10 05:56 UTC] tstarling@php.net
dessander: that is unrelated
bgardner: that is also unrelated

Both test cases are covered by my comment from 2010-09-15. In bgardner's test case, both the elements of $args and the elements of $newargs are made into references by the reference assignment, so it doesn't matter which one you pass. Putting a space between "=" and "&" is misleading, since "=&" is a binary operator which binds two variables. The "&" is not an address-of operator.

File a separate bug if you want to complain about unrelated behaviour.
 
PHP Copyright © 2001-2024 The PHP Group
All rights reserved.
Last updated: Mon Dec 30 14:01:28 2024 UTC