Does valgrind have anything to say about it..?

And did this start happening recently or was this old problem?

This is the output from valgrind: 
 
VG_(get_memory_from_mmap): newSuperblock's request for 
1515872256 bytes failed. 
VG_(get_memory_from_mmap): 102113062 bytes already 
allocated. 
 
No wonder that it crashes. The question is, why does this 
only happen in HEAD and why does the memory_limit doesn't 
prevent this. 
 
I can't really say when this started because I don't use 
PHP5 regularly. But it definitely *did* happen before the 
recent crash bugs/fixes.

I managed to create a medium sized test case, unfortunately the bug disappeared as soon as I tried to strip it further down.

Get www.horde.org/~jan/prop_test.tar.gz, unpack it and run ob_vars.php with a current HEAD cli. It segfaults with the last statement, but this seems to only a followup bug. If you look at the test script, the output and the MIME_Message::buildMessage() method, you will easily see wha t is going wrong.

The strange thing is that in production, these UNKNOWN:0 properties happen to only two properties of the object, always the same two and no obvious pattern that I see for those.

http://www.horde.org/~jan/prop_test.tar.gz has been updated to contain all files necessary. I just checked again that this bug still happens with the current PHP 5 from CVS.

This is the backtrace I got:

0x082c1c9d in _zend_is_inconsistent (ht=0x1b, file=0x8403060 "/usr/src/web/php/php5/Zend/zend_hash.c", line=841)
    at /usr/src/web/php/php5/Zend/zend_hash.c:53
53              if (ht->inconsistent==HT_OK) {
(gdb) bt
#0  0x082c1c9d in _zend_is_inconsistent (ht=0x1b, file=0x8403060 "/usr/src/web/php/php5/Zend/zend_hash.c", line=841)
    at /usr/src/web/php/php5/Zend/zend_hash.c:53
#1  0x082c3dcc in zend_hash_find (ht=0x1b, arKey=0x4111999c "__wakeup", nKeyLength=9, pData=0xbfffd088)
    at /usr/src/web/php/php5/Zend/zend_hash.c:841
#2  0x082b2489 in zend_call_function (fci=0xbfffd130, fci_cache=0x0)
    at /usr/src/web/php/php5/Zend/zend_execute_API.c:619
#3  0x082b2033 in call_user_function_ex (function_table=0x8613e08, object_pp=0xbfffd270, function_name=0xbfffd1a0, 
    retval_ptr_ptr=0xbfffd1bc, param_count=0, params=0x0, no_separation=1, symbol_table=0x0)
    at /usr/src/web/php/php5/Zend/zend_execute_API.c:517
#4  0x0825cb91 in object_common2 (rval=0xbfffd270, p=0xbfffd42c, max=0x41117545 "", var_hash=0xbfffd430, elements=20)
    at var_unserializer.re:233
#5  0x0825bc53 in php_var_unserialize (rval=0xbfffd270, p=0xbfffd42c, max=0x41117545 "", var_hash=0xbfffd430)
    at var_unserializer.re:452
#6  0x0825c945 in process_nested_data (rval=0xbfffd320, p=0xbfffd42c, max=0x41117545 "", var_hash=0xbfffd430, 
    ht=0x4111985c, elements=0) at var_unserializer.re:173
#7  0x0825bea1 in php_var_unserialize (rval=0xbfffd320, p=0xbfffd42c, max=0x41117545 "", var_hash=0xbfffd430)
    at var_unserializer.re:361
#8  0x0825c945 in process_nested_data (rval=0xbfffd444, p=0xbfffd42c, max=0x41117545 "", var_hash=0xbfffd430, 
    ht=0x41118918, elements=9) at var_unserializer.re:173
#9  0x0825cb1f in object_common2 (rval=0xbfffd444, p=0xbfffd42c, max=0x41117545 "", var_hash=0xbfffd430, elements=22)
    at var_unserializer.re:226
#10 0x0825bc53 in php_var_unserialize (rval=0xbfffd444, p=0xbfffd42c, max=0x41117545 "", var_hash=0xbfffd430)
    at var_unserializer.re:452
#11 0x0824fb39 in zif_unserialize (ht=1, return_value=0x40e6abdc, this_ptr=0x0, return_value_used=1)
    at /usr/src/web/php/php5/ext/standard/var.c:742
#12 0x082dd628 in zend_do_fcall_common_helper (execute_data=0xbfffd7a0, opline=0x40e42aa0, op_array=0x40e426ac)
    at /usr/src/web/php/php5/Zend/zend_execute.c:2558
#13 0x082ddc5e in zend_do_fcall_handler (execute_data=0xbfffd7a0, opline=0x40e42aa0, op_array=0x40e426ac)
    at /usr/src/web/php/php5/Zend/zend_execute.c:2700
#14 0x082da46c in execute (op_array=0x40e426ac) at /usr/src/web/php/php5/Zend/zend_execute.c:1272
#15 0x082bcaa7 in zend_execute_scripts (type=8, retval=0x0, file_count=3) at /usr/src/web/php/php5/Zend/zend.c:1051
#16 0x08285fd8 in php_execute_script (primary_file=0xbffffba0) at /usr/src/web/php/php5/main/main.c:1641

Can you find out what statement triggers that error from your bt? Perhaps I am able to strip the example down if I know where to start. No promises though.

Here's the backtrace with today's CVS checkout:

#0  0x406d7563 in mmap () from /lib/i686/libc.so.6
#1  0x4066fdac in sYSMALLOc () from /lib/i686/libc.so.6
#2  0x4066c853 in malloc () from /lib/i686/libc.so.6
#3  0x08356954 in zend_mm_add_memory_block (heap=0x864c008, block_size=3031741692)
    at /usr/src/web/php/php5/Zend/zend_mm.c:223
#4  0x08356bfb in zend_mm_alloc (heap=0x864c008, size=3031741664) at /usr/src/web/php/php5/Zend/zend_mm.c:321
#5  0x08356c22 in zend_mm_alloc (heap=0x864c008, size=3031741664) at /usr/src/web/php/php5/Zend/zend_mm.c:325
#6  0x08356c22 in zend_mm_alloc (heap=0x864c008, size=3031741664) at /usr/src/web/php/php5/Zend/zend_mm.c:325
#7  0x08356c22 in zend_mm_alloc (heap=0x864c008, size=3031741664) at /usr/src/web/php/php5/Zend/zend_mm.c:325
#8  0x08356c22 in zend_mm_alloc (heap=0x864c008, size=3031741664) at /usr/src/web/php/php5/Zend/zend_mm.c:325

Since Stanislavs work on zend_mm.c the script doesn't segfault anymore, but produces the error:

PHP Fatal error:  Out of memory: cannot allocate -1263225620 bytes! in /home/jan/prop_test/ob_vars.php on line 20

That's a step forward but still doesn't explain what's happening with the MIME_Message object.

These strange UNKNOWN:0 properties appear after the get_object_vars() call in buildMessage(). Without this call, everything looks fine.

Seems to have been fixed with Andi's recent work on get_object_vars().