ID: 26666
User updated by: jan at horde dot org
Reported By: jan at horde dot org
Status: Open
Bug Type: Zend Engine 2 problem
Operating System: Linux
PHP Version: 5CVS-2003-12-19 (dev)
New Comment:
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.
Previous Comments:
------------------------------------------------------------------------
[2003-12-21 08:01:43] jan at horde dot org
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.
------------------------------------------------------------------------
[2003-12-19 08:07:57] [EMAIL PROTECTED]
And did this start happening recently or was this old problem?
------------------------------------------------------------------------
[2003-12-19 08:07:20] [EMAIL PROTECTED]
Does valgrind have anything to say about it..?
------------------------------------------------------------------------
[2003-12-19 05:49:47] jan at horde dot org
Description:
------------
When I try to call a really complex script, PHP crashes with this
backtrace:
#0 0x40237422 in grow_heap () from /lib/libc.so.6
#1 0x40238a52 in sYSMALLOc () from /lib/libc.so.6
#2 0x4023918c in malloc () from /lib/libc.so.6
#3 0x406f40f8 in zend_mm_add_memory_block (heap=0x409010f8,
block_size=1515870884) at /home/jan/cvs/php5/Zend/zend_mm.c:223
#4 0x406f43a1 in zend_mm_alloc (heap=0x409010f8, size=1515870856)
at /home/jan/cvs/php5/Zend/zend_mm.c:321
#5 0x406f43c8 in zend_mm_alloc (heap=0x409010f8, size=1515870856)
at /home/jan/cvs/php5/Zend/zend_mm.c:325
#6 0x406f43c8 in zend_mm_alloc (heap=0x409010f8, size=1515870856)
at /home/jan/cvs/php5/Zend/zend_mm.c:325
#7 0x406f43c8 in zend_mm_alloc (heap=0x409010f8, size=1515870856)
at /home/jan/cvs/php5/Zend/zend_mm.c:325
#8 0x406f43c8 in zend_mm_alloc (heap=0x409010f8, size=1515870856)
at /home/jan/cvs/php5/Zend/zend_mm.c:325
#9 0x406f43c8 in zend_mm_alloc (heap=0x409010f8, size=1515870856)
at /home/jan/cvs/php5/Zend/zend_mm.c:325
#10 0x406f43c8 in zend_mm_alloc (heap=0x409010f8, size=1515870856)
at /home/jan/cvs/php5/Zend/zend_mm.c:325
This continues endlessly, I stopped around frame #1000, so I don't know
where it actually was called from.
No, I don't have a simple script to reproduce this, but perhaps someone
already has an idea from looking at this bt.
------------------------------------------------------------------------
--
Edit this bug report at http://bugs.php.net/?id=26666&edit=1
