GDB Stacktrace:

#0  zend_mm_remove_from_free_list (heap=0x88da8d8, mm_block=0xb7fc5308)
    at /home/nikic/dev/php-src-git/Zend/zend_alloc.c:805
#1  0x083ad608 in _zend_mm_free_int (heap=0x88da8d8, p=0xb7fc52f0)
    at /home/nikic/dev/php-src-git/Zend/zend_alloc.c:2101
#2  0x083cd657 in destroy_op_array (op_array=0x8a5d4c8, tsrm_ls=0x88d9050)
    at /home/nikic/dev/php-src-git/Zend/zend_opcode.c:380
#3  0x083cd777 in zend_function_dtor (function=0x8a5d4c8)
    at /home/nikic/dev/php-src-git/Zend/zend_opcode.c:124
#4  0x083e49ae in zend_hash_apply_deleter (ht=0x88dae70, p=0x8a5d498)
    at /home/nikic/dev/php-src-git/Zend/zend_hash.c:650
#5  0x083e63b1 in zend_hash_reverse_apply (ht=0x88dae70, 
    apply_func=0x83c7310 <clean_non_persistent_function>, tsrm_ls=0x88d9050)
    at /home/nikic/dev/php-src-git/Zend/zend_hash.c:804
#6  0x083c7ecb in shutdown_executor (tsrm_ls=0x88d9050)
    at /home/nikic/dev/php-src-git/Zend/zend_execute_API.c:304
#7  0x083d7c11 in zend_deactivate (tsrm_ls=0x88d9050)
    at /home/nikic/dev/php-src-git/Zend/zend.c:934
#8  0x0836be33 in php_request_shutdown (dummy=0x0)
    at /home/nikic/dev/php-src-git/main/main.c:1782
#9  0x0848d723 in do_cli (argc=4, argv=0xbffff3b4, tsrm_ls=0x88d9050)
    at /home/nikic/dev/php-src-git/sapi/cli/php_cli.c:1169
#10 0x0806eaa3 in main (argc=4, argv=0xbffff3b4)
    at /home/nikic/dev/php-src-git/sapi/cli/php_cli.c:1356

What I can say :

- I dont reproduce on 5.3.10
- For 5.4, disabling ZendMM with USE_ZEND_ALLOC=0 makes the segfault disappear
- For 5.4, changing the ZendMM segment size with ZEND_MM_SEG_SIZE={val} makes the 
segfault disappear, I havent tested all the possible values for SEG_SIZE.
As a reminder, ZendMM default SEG_SIZE is set to 256k

Notice that I only reproduce with memory_limit set to accurate 512k , not 500k as 
in bug text, nor even 511k

Same here. Reproducable on 64-bit Linux with memory_limit set to "512k".

The segfault is here:

zend_mm_remove_from_free_list (heap=0xf71730, mm_block=0x7ffff7fae1c8) at 
/home/rasmus/php-src/branches/PHP_5_4/Zend/zend_alloc.c:805
805				ZEND_MM_CHECK_TREE(mm_block);

(gdb) p *mm_block
$2 = {info = {_size = 16400, _prev = 57}, prev_free_block = 0x7ffff7fae1c8, 
next_free_block = 0x7ffff7fae1c8, parent = 0x0, child = {0x0, 0x0}}

Note that parent is NULL there and ZEND_MM_CHECK_TREE tries to dereference 
*parent

Description:
------------
Same here, reproducable, but with memory limit set to 128M (note that i am not using the provided test script, it crached randomly)

Test script:
-------------
-

System information :
OS : Fedora 17 Linux nask0 3.6.10-2.fc17.x86_64 #1 SMP Tue Dec 11 18:07:34 UTC 2012 x86_64
PHP version 5.4.9 :
PHP API : 20100412
PHP Extension : 20100525
Zend Extension : 220100525
Zend Extension Build : API220100525,NTS
PHP Extension Build : API20100525,NTS
Thread Safety: disabled
Zend Signal Handling: disabled
Zend Memory Manager: enabled 
Apache Version: Apache/2.2.22 (Fedora) DAV/2 PHP/5.4.9
Apache API Version : 20051115 


GDB backtrace : 
---------------
Program received signal SIGSEGV, Segmentation fault.
zend_mm_remove_from_free_list (heap=0x7f75283c10d0, mm_block=0x7f752a24b3f8) at /usr/src/debug/php-5.4.9/Zend/zend_alloc.c:833
833			if (UNEXPECTED(prev->next_free_block != mm_block) || UNEXPECTED(next->prev_free_block != mm_block)) {
(gdb) continue 
Continuing.

Program terminated with signal SIGSEGV, Segmentation fault.
The program no longer exists.

quick fix attached, could you please verify it?

another way to fix this is promote the ht point assignment in ctor(list blow), 
but there is still a chance that alloc failed when try to alloc memory for ht.

so I still think the fix I attached is the better one.

diff --git a/Zend/zend_variables.c b/Zend/zend_variables.c
index 25a66a1..bb6927a 100644
--- a/Zend/zend_variables.c
+++ b/Zend/zend_variables.c
@@ -134,9 +134,9 @@ ZEND_API void _zval_copy_ctor_func(zval *zvalue 
ZEND_FILE_LINE_DC)
 					return; /* do nothing */
 				}
 				ALLOC_HASHTABLE_REL(tmp_ht);
+				zvalue->value.ht = tmp_ht;
 				zend_hash_init(tmp_ht, 
zend_hash_num_elements(original_ht), NULL, ZVAL_PTR_DTOR, 0);
 				zend_hash_copy(tmp_ht, original_ht, 
(copy_ctor_func_t) zval_add_ref, (void *) &tmp, sizeof(zval *));
-				zvalue->value.ht = tmp_ht;
 			}
 			break;
 		case IS_OBJECT:

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 "Open". Thank you.

The bug is reproducable on
PHP version 5.4.23, 5.3.28
OS: FreeBSD 9.2 amd64
memory_limit=32M

function byRef(&$ref) {}

$array = array_fill(0, 200000, '*');
$ref = $array;

byRef($array);

The patch https://bugs.php.net/patch-display.php?bug=61046&patch=bug61046.patch&revision=1356016047 makes the segfault disappear.

Hi. I have the same problem with a custom CLI PHP script. The test script posted returns PHP Fatal error:  Allowed memory size of 512000 bytes exhausted (tried to allocate 72 bytes) in /tmp/test.php on line 7 instead of segmentation fault like my script.

Since this is the latest stable PHP version for Debian Wheezy, I think this bug is not solved yet.

As a side node, USE_ZEND_ALLOC=0 or ZEND_MM_SEG_SIZE= set to anything else than default 256k solves the problem.

php -i |grep memory_limit
memory_limit => -1 => -1

PHP Version => 5.4.36-0+deb7u1
System => Linux srv 3.2.0-4-amd64 #1 SMP Debian 3.2.63-2+deb7u1 x86_64
Build Date => Dec 31 2014 07:30:15
HP API => 20100412
PHP Extension => 20100525
Zend Extension => 220100525
Zend Extension Build => API220100525,NTS
PHP Extension Build => API20100525,NTS
Debug Build => no
Thread Safety => disabled
Zend Signal Handling => disabled
Zend Memory Manager => enabled
Zend Multibyte Support => provided by mbstring
IPv6 Support => enabled
DTrace Support => disabled

(gdb) bt
#0  zend_mm_remove_from_free_list (heap=0x1e08290, mm_block=0x7f86af142388)
    at /tmp/buildd/php5-5.4.36/Zend/zend_alloc.c:818
#1  0x0000000000680200 in _zend_mm_free_int (heap=0x1e08290, p=0x7f86af142368)
    at /tmp/buildd/php5-5.4.36/Zend/zend_alloc.c:2101
#2  0x00000000006b4f18 in zend_hash_destroy (ht=0x7f86aefd2f70) at /tmp/buildd/php5-5.4.36/Zend/zend_hash.c:560
#3  0x000000000069ce78 in destroy_zend_class (pce=0x1e08290) at /tmp/buildd/php5-5.4.36/Zend/zend_opcode.c:297
#4  0x00000000006b38e5 in zend_hash_apply_deleter () at /tmp/buildd/php5-5.4.36/Zend/zend_hash.c:650
#5  0x00000000006b5421 in zend_hash_reverse_apply (ht=0x1e08bf0, apply_func=0x697a80 <clean_non_persistent_class>)
    at /tmp/buildd/php5-5.4.36/Zend/zend_hash.c:804
#6  0x0000000000698187 in shutdown_executor () at /tmp/buildd/php5-5.4.36/Zend/zend_execute_API.c:303
#7  0x00000000006a6ba5 in zend_deactivate () at /tmp/buildd/php5-5.4.36/Zend/zend.c:948
#8  0x0000000000646a4a in php_request_shutdown (dummy=0x1e08290) at /tmp/buildd/php5-5.4.36/main/main.c:1808
#9  0x0000000000751768 in do_cli (argc=0, argv=0x7fff3583cf1d) at /tmp/buildd/php5-5.4.36/sapi/cli/php_cli.c:1172
#10 0x0000000000431b6f in main (argc=32767, argv=0x1e081f0) at /tmp/buildd/php5-5.4.36/sapi/cli/php_cli.c:1365

Thank you!