better title

Part of valgrind output from PHP 5.5 :

==2715== Invalid read of size 8
==2715==    at 0x8DC6A8: _efree (zend_alloc.c:2436)
==2715==    by 0x91120F: destroy_op_array (zend_opcode.c:361)
==2715==    by 0x9104AF: destroy_zend_function (zend_opcode.c:116)
==2715==    by 0x9104E6: zend_function_dtor (zend_opcode.c:128)
==2715==    by 0x935A80: zend_hash_destroy (zend_hash.c:560)
==2715==    by 0x91F04B: compiler_globals_dtor (zend.c:539)
==2715==    by 0x858B1C: tsrm_shutdown (TSRM.c:180)
==2715==    by 0x9E4B7B: main (php_cli.c:1399)
==2715==  Address 0xd1a3060 is 0 bytes inside a block of size 8 free'd
==2715==    at 0x4C2BDEC: free (in /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so)
==2715==    by 0x858B3B: tsrm_shutdown (TSRM.c:182)
==2715==    by 0x9E4B7B: main (php_cli.c:1399)
==2715== 
==2715== Invalid read of size 4
==2715==    at 0x8DC6AB: _efree (zend_alloc.c:2436)
==2715==    by 0x91120F: destroy_op_array (zend_opcode.c:361)
==2715==    by 0x9104AF: destroy_zend_function (zend_opcode.c:116)
==2715==    by 0x9104E6: zend_function_dtor (zend_opcode.c:128)
==2715==    by 0x935A80: zend_hash_destroy (zend_hash.c:560)
==2715==    by 0x91F04B: compiler_globals_dtor (zend.c:539)
==2715==    by 0x858B1C: tsrm_shutdown (TSRM.c:180)
==2715==    by 0x9E4B7B: main (php_cli.c:1399)
==2715==  Address 0xd1a3100 is 0 bytes inside a block of size 2,224 free'd
==2715==    at 0x4C2BDEC: free (in /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so)
==2715==    by 0x8D9DD6: zend_mm_shutdown (zend_alloc.c:1688)
==2715==    by 0x8DCF40: shutdown_memory_manager (zend_alloc.c:2718)
==2715==    by 0x8DD028: alloc_globals_dtor (zend_alloc.c:2740)
==2715==    by 0x858B1C: tsrm_shutdown (TSRM.c:180)
==2715==    by 0x9E4B7B: main (php_cli.c:1399)
==2715== 
==2715== Invalid read of size 8
==2715==    at 0x8DC708: _efree (zend_alloc.c:2440)
==2715==    by 0x91120F: destroy_op_array (zend_opcode.c:361)
==2715==    by 0x9104AF: destroy_zend_function (zend_opcode.c:116)
==2715==    by 0x9104E6: zend_function_dtor (zend_opcode.c:128)
==2715==    by 0x935A80: zend_hash_destroy (zend_hash.c:560)
==2715==    by 0x91F04B: compiler_globals_dtor (zend.c:539)
==2715==    by 0x858B1C: tsrm_shutdown (TSRM.c:180)
==2715==    by 0x9E4B7B: main (php_cli.c:1399)
==2715==  Address 0xd1a3060 is 0 bytes inside a block of size 8 free'd
==2715==    at 0x4C2BDEC: free (in /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so)
==2715==    by 0x858B3B: tsrm_shutdown (TSRM.c:182)
==2715==    by 0x9E4B7B: main (php_cli.c:1399)
==2715== 
==2715== Invalid read of size 8
==2715==    at 0x8D91C5: zend_mm_check_ptr (zend_alloc.c:1374)
==2715==    by 0x8DB02F: _zend_mm_free_int (zend_alloc.c:2068)
==2715==    by 0x8DC72B: _efree (zend_alloc.c:2440)
==2715==    by 0x91120F: destroy_op_array (zend_opcode.c:361)
==2715==    by 0x9104AF: destroy_zend_function (zend_opcode.c:116)
==2715==    by 0x9104E6: zend_function_dtor (zend_opcode.c:128)
==2715==    by 0x935A80: zend_hash_destroy (zend_hash.c:560)
==2715==    by 0x91F04B: compiler_globals_dtor (zend.c:539)
==2715==    by 0x858B1C: tsrm_shutdown (TSRM.c:180)
==2715==    by 0x9E4B7B: main (php_cli.c:1399)
==2715==  Address 0xd1e27c8 is 257,496 bytes inside a block of size 262,144 free'd
==2715==    at 0x4C2BDEC: free (in /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so)
==2715==    by 0x8D79AA: zend_mm_mem_malloc_free (zend_alloc.c:297)
==2715==    by 0x8D9D99: zend_mm_shutdown (zend_alloc.c:1683)
==2715==    by 0x8DCF40: shutdown_memory_manager (zend_alloc.c:2718)
==2715==    by 0x8DD028: alloc_globals_dtor (zend_alloc.c:2740)
==2715==    by 0x858B1C: tsrm_shutdown (TSRM.c:180)
==2715==    by 0x9E4B7B: main (php_cli.c:1399)

[...]

==2715== Invalid read of size 8
==2715==    at 0x861009: php_message_handler_for_zend (main.c:1458)
==2715==    by 0x920750: zend_message_dispatcher (zend.c:973)
==2715==    by 0x8D90D6: zend_mm_check_ptr (zend_alloc.c:1352)
==2715==    by 0x8D92F0: zend_mm_check_ptr (zend_alloc.c:1389)
==2715==    by 0x8DB02F: _zend_mm_free_int (zend_alloc.c:2068)
==2715==    by 0x8DC72B: _efree (zend_alloc.c:2440)
==2715==    by 0x935B72: zend_hash_destroy (zend_hash.c:568)
==2715==    by 0x910EE8: destroy_zend_class (zend_opcode.c:298)
==2715==    by 0x935A80: zend_hash_destroy (zend_hash.c:560)
==2715==    by 0x91F088: compiler_globals_dtor (zend.c:543)
==2715==    by 0x858B1C: tsrm_shutdown (TSRM.c:180)
==2715==    by 0x9E4B7B: main (php_cli.c:1399)
==2715==  Address 0x40 is not stack'd, malloc'd or (recently) free'd
==2715== 
==2715== 
==2715== Process terminating with default action of signal 11 (SIGSEGV)
==2715==  Access not within mapped region at address 0x40
==2715==    at 0x861009: php_message_handler_for_zend (main.c:1458)
==2715==    by 0x920750: zend_message_dispatcher (zend.c:973)
==2715==    by 0x8D90D6: zend_mm_check_ptr (zend_alloc.c:1352)
==2715==    by 0x8D92F0: zend_mm_check_ptr (zend_alloc.c:1389)
==2715==    by 0x8DB02F: _zend_mm_free_int (zend_alloc.c:2068)
==2715==    by 0x8DC72B: _efree (zend_alloc.c:2440)
==2715==    by 0x935B72: zend_hash_destroy (zend_hash.c:568)
==2715==    by 0x910EE8: destroy_zend_class (zend_opcode.c:298)
==2715==    by 0x935A80: zend_hash_destroy (zend_hash.c:560)
==2715==    by 0x91F088: compiler_globals_dtor (zend.c:543)
==2715==    by 0x858B1C: tsrm_shutdown (TSRM.c:180)
==2715==    by 0x9E4B7B: main (php_cli.c:1399)
==2715==  If you believe this happened as a result of a stack
==2715==  overflow in your program's main thread (unlikely but
==2715==  possible), you can try to increase the size of the
==2715==  main thread stack using the --main-stacksize= flag.
==2715==  The main thread stack size used in this run was 8388608.
==2715== 
==2715== HEAP SUMMARY:
==2715==     in use at exit: 636,155 bytes in 5,094 blocks
==2715==   total heap usage: 28,246 allocs, 23,152 frees, 6,173,404 bytes allocated
==2715== 
==2715== LEAK SUMMARY:
==2715==    definitely lost: 0 bytes in 0 blocks
==2715==    indirectly lost: 0 bytes in 0 blocks
==2715==      possibly lost: 0 bytes in 0 blocks
==2715==    still reachable: 636,155 bytes in 5,094 blocks
==2715==         suppressed: 0 bytes in 0 blocks
==2715== Rerun with --leak-check=full to see details of leaked memory
==2715== 
==2715== For counts of detected and suppressed errors, rerun with: -v
==2715== ERROR SUMMARY: 5974 errors from 288 contexts (suppressed: 0 from 0)

This may not be a output control bug..
Could you try 5.5 also?

5.5.13 crashes as well

If I slightly modify the script to run the asynchronous_write function inside a register_shutdown_function instead of ob_start, it doesn't crash anymore :

<?php
use PhpAmqpLib\Connection\AMQPConnection;

class queue {
	private static $instance = null;
	private $connection = null;
	private $channel = null;

	public static function instance() {
		if (self::$instance == null) {
			self::$instance = new self();
		}
		return self::$instance;
	}

	private function __construct() {
		require_once __DIR__.'/libs/php-amqplib-2.4.0/vendor/autoload.php';
		$this->connection = new AMQPConnection('localhost', '5672', 'guest', 'guest', '/');
	}

	public function asynchronous_write() {
		if (!$this->connection) return;
		if ($this->channel == null) {
			$this->channel = $this->connection->channel();
		}
	}
}

register_shutdown_function('async');
ob_start('foo');
echo 'bar';

function async() {
	queue::instance()->asynchronous_write();
}

function foo($content, $mode = 5) {
	return $content;
}
exit;

Hi,

Any progress on this issue ?
Using register_shutdown_function() + ob_start() as a workaround doesn't work for all the cases. Indeed, I are have cases where ob_start() is called before register_shutdown_function(), even with the PHP_OUTPUT_HANDLER_REMOVABLE flag in ob_start().

Thanks,

It would help a lot if there was a reproducing case that does not require running rabbitmq server. You say you have different cases reproducing it, can any of them be cut down so that actual amqp server is not needed to reproduce?

I've just modified the code on https://github.com/jocel1/php5.4-crash to not require a working AMQP server.

Looking at the library, I see that it runs a lot of code from __destruct function which is called on shutdown. This is usually not the best idea as the services the object needs to run his code may be already partially shut down. I'll still see if it can be handled better, but I'm not sure if this code will actually work properly in this way.

BTW, if you add a flush at the end of the script, this also fixes the issue.

Ok, so the register_shutdown + ob_start approach is the best way to do this, as long as we are sure register_shutdown is called before ob_start (which should always be the case).
I cannot use ob_flush() because my lib is loaded on auto_prepend_file.

had to revert the fix, breaks tests. Will look more into it.

Is this still an issue with any of the actively supported PHP
versions[1]?

[1] <https://www.php.net/supported-versions.php>

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.