php.net |  support |  documentation |  report a bug |  advanced search |  search howto |  statistics |  random bug |  login
Bug #62437 Strange behavior with global variables (objects) in ob_start() output callback
Submitted: 2012-06-28 11:56 UTC Modified: 2013-07-30 19:24 UTC
Votes:5
Avg. Score:4.8 ± 0.4
Reproduced:5 of 5 (100.0%)
Same Version:1 (20.0%)
Same OS:2 (40.0%)
From: tero dot tasanen at gmail dot com Assigned: mike (profile)
Status: Not a bug Package: Output Control
PHP Version: 5.3.14 OS: Linux 64bit
Private report: No CVE-ID: None
 [2012-06-28 11:56 UTC] tero dot tasanen at gmail dot com
Description:
------------
Global variables in output buffering seem to work in very strange way. don't know 
actually if this has anything to do with output buffering callback but see the 
test case attached to reproduce this. 

And the strangest thing is that if you uncomment the last line the script works 
as expected!

After some searching I found two similar bug reports (#40604, #44840) and the 
comments indicate that this is expected behavior?! Not just that it seem really 
strange that all objects get destroyed before the output callback is called, but 
why does the use of the $test variable in the end of the script change this behavior? This really does not make any sense! 

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

function output($buffer) {
  global $object;
  return $buffer . $object->bar;
}


ob_start('output');
$object = new stdClass();
$object->bar = "bar";

echo "foo ";
// $test = $object;


Expected result:
----------------
foo bar

Actual result:
--------------
PHP Notice:  Trying to get property of non-object in /home/ttasanen/test.php on 
line 5
PHP Stack trace:
PHP   1. output() /home/ttasanen/test.php:0
foo 

Patches

Add a Patch

Pull Requests

Add a Pull Request

History

AllCommentsChangesGit/SVN commitsRelated reports
 [2012-06-30 13:25 UTC] Sjon at hortensius dot net
Contrary to what tony2001 says in #40604, this was actually working fine until it 
was broken in 5.2

http://3v4l.org/SUUkK

The reason that http://3v4l.org/pZ2PP works might be explained to the second 
reference to the same object which could prevent destruction, but that would then 
actually be a bug too (since it indicates a memory-leak).
 [2012-07-02 11:51 UTC] tero dot tasanen at gmail dot com
Yes, I agree that there might be two bugs here. 

Here's another test script that shows that this only affects objects and not 
other data types.

http://3v4l.org/Ip5Sn
<?php

function output($buffer) {
  global $object, $string, $int, $float, $array;

  $ret_val = array($string, $object->bar, $int, sprintf("%.2f", $float), 
$array[0]);
  return implode(" ", $ret_val);
}

ob_start('output');

$object = new stdClass();
$object->bar = "bar";

$string = "foo";
$int = 1;
$float = 2.0;
$array = array('array');

// $test = $object;
?>
 [2013-07-30 19:24 UTC] mike@php.net
-Status: Open +Status: Not a bug -Assigned To: +Assigned To: mike
 [2013-07-30 19:24 UTC] mike@php.net
Thank you for taking the time to write to us, but this is not
a bug. Please double-check the documentation available at
http://www.php.net/manual/ and the instructions on how to report
a bug at http://bugs.php.net/how-to-report.php

So something has to be shut down first, it's kind of a chicken and egg problem.
Object destruction is performed in two stages, objects with e.g. circular 
references are destroyed at the very last (try $object->ref=$object to see the 
difference).
 
PHP Copyright © 2001-2024 The PHP Group
All rights reserved.
Last updated: Fri Apr 19 04:01:28 2024 UTC