|  support |  documentation |  report a bug |  advanced search |  search howto |  statistics |  random bug |  login
Bug #65416 output buffering autostart setting php.ini
Submitted: 2013-08-07 19:47 UTC Modified: 2013-10-15 18:25 UTC
From: jwestbrook at gmail dot com Assigned:
Status: Not a bug Package: Output Control
PHP Version: 5.4.17 OS: linux 64bit AWS ami
Private report: No CVE-ID: None
 [2013-08-07 19:47 UTC] jwestbrook at gmail dot com
We recently upgraded from php 5.3 to php 5.4 and when the php.ini output_buffering 
setting is set to ON or anything greater than zero the output buffering does not 
always reliably start.

This is a problem for some scripts that have a shebang as the first line to make 
the script easily executable. But if you send a header or anything else after that 
first line it will fail.

based on the script attached the contents of the error log are

buffer statues : Array\n(\n)\n

Test script:

$buffer_length = ob_get_length();
if($buffer_length != 15)
    error_log('buffer statues : '.print_r(ob_get_status(TRUE),1));

//this header call will not always be successful
header("Content-type: application/pdf");



Add a Patch

Pull Requests

Add a Pull Request


AllCommentsChangesGit/SVN commitsRelated reports
 [2013-08-18 06:52 UTC]
-Status: Open +Status: Not a bug
 [2013-08-18 06:52 UTC]
"#!" does not have special meaning for Web server SAPI.

I think you are sending data larger than output buffer size. Then this is the 
way supposed to be.

output_buffering=On or 1 is special. It enables unlimited buffering. Anything 
other values set buffer chunk size and PHP tries to send data larger than chunk 

Check your buffer size (i.e. output_buffering setting of php.ini file)
I guess you have very small output_buffering. Old output buffer increases size 
automatically, IIRC. New output buffer does not increase buffer size.
 [2013-08-19 22:07 UTC] jwestbrook at gmail dot com
I also tried the settings of On and 1.

I also understand that #!/usr/bin/php means nothing to output buffering but is output that 
I want to capture if the php file is being run from a browser and discard.

From what I understand that is not how the output buffering works. The way I understand it 
the output buffer fills then dumps everything when it is full. In this instance before the 
output buffer fills I want to discard the first 15 characters because it will corrupt any 
binary files that the browser is trying to download.

Based on the test script attached ob_get_length() should ALWAYS return 15 characters - 
however at least 12 times a day PHP fails to start the output buffer and I get the error 
 [2013-08-19 22:19 UTC]
Looks like when this is logged, there actually is no output buffer active, so 
ob_get_length() returns false.
 [2013-08-26 21:35 UTC] jwestbrook at gmail dot com
@mike at Yes that is the bug I'm reporting - the php.ini setting does not 
start the output buffer on every request.
 [2013-08-26 22:45 UTC]
-Status: Not a bug +Status: Feedback
 [2013-08-26 22:45 UTC]
I guess there is some kind of memory problem.
What modules are loaded in your web server and SAPI?

var_dump(get_loaded_extensions(), php_sapi_name());                                                               

or paste phpinfo() output.

> at least 12 times a day PHP fails to start the output buffer and I get the 
error shown.

How many requests a day you have?
 [2013-08-27 00:42 UTC] jwestbrook at gmail dot com
-Status: Feedback +Status: Open
 [2013-08-27 00:42 UTC] jwestbrook at gmail dot com

  string(4) "Core"
  string(4) "date"
  string(4) "ereg"
  string(6) "libxml"
  string(7) "openssl"
  string(4) "pcre"
  string(4) "zlib"
  string(3) "bz2"
  string(8) "calendar"
  string(5) "ctype"
  string(4) "hash"
  string(6) "filter"
  string(3) "ftp"
  string(7) "gettext"
  string(3) "gmp"
  string(3) "SPL"
  string(5) "iconv"
  string(10) "Reflection"
  string(7) "session"
  string(8) "standard"
  string(5) "shmop"
  string(9) "SimpleXML"
  string(7) "sockets"
  string(8) "mbstring"
  string(9) "tokenizer"
  string(3) "xml"
  string(14) "apache2handler"
  string(7) "gearman"
  string(4) "http"
  string(4) "ssh2"
  string(4) "curl"
  string(3) "dom"
  string(8) "fileinfo"
  string(2) "gd"
  string(8) "igbinary"
  string(4) "json"
  string(4) "exif"
  string(6) "mcrypt"
  string(9) "memcached"
  string(7) "mysqlnd"
  string(5) "mysql"
  string(6) "mysqli"
  string(8) "newrelic"
  string(3) "PDO"
  string(9) "pdo_mysql"
  string(10) "pdo_sqlite"
  string(4) "Phar"
  string(5) "posix"
  string(4) "snmp"
  string(4) "soap"
  string(7) "sqlite3"
  string(7) "sysvmsg"
  string(7) "sysvsem"
  string(7) "sysvshm"
  string(4) "wddx"
  string(9) "xmlreader"
  string(9) "xmlwriter"
  string(3) "xsl"
  string(3) "zip"
  string(5) "mhash"
  string(12) "Zend OPcache"
string(14) "apache2handler"

12 requests where I was able to note that the output buffer failed out of 142 
requests to that specific script.

As a whole I average 150,000 PHP requests per day
 [2013-09-26 14:30 UTC]
-Status: Open +Status: Feedback
 [2013-09-26 14:30 UTC]
Not enough information was provided for us to be able
to handle this bug. Please re-read the instructions at

If you can provide more information, feel free to add it
to this bug and change the status back to "Open".

Thank you for your interest in PHP.

 [2013-10-15 11:54 UTC] php-bugs at lists dot php dot net
No feedback was provided. The bug is being suspended because
we assume that you are no longer experiencing the problem.
If this is not the case and you are able to provide the
information that was requested earlier, please do so and
change the status of the bug back to "Re-Opened". Thank you.
 [2013-10-15 18:08 UTC] jwestbrook at gmail dot com
-Status: No Feedback +Status: Closed
 [2013-10-15 18:08 UTC] jwestbrook at gmail dot com
This was resolved when the php agent from New Relic was updated the end of August.
 [2013-10-15 18:25 UTC]
-Status: Closed +Status: Not a bug
PHP Copyright © 2001-2024 The PHP Group
All rights reserved.
Last updated: Thu May 30 20:01:30 2024 UTC