#26666 [Opn]: crash in zend_mm_alloc

2004-01-16 Thread jan at horde dot org 
 ID:   2
 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 hope this link doesn't wrap:
http://cvs.horde.org/co.php/framework/MIME/MIME/Part.php?sa=1&r=1.159&p=1


Previous Comments:


[2004-01-16 12:54:20] jan at horde dot org

Oops, sorry. Damn include_path! ;-)

http://cvsweb.horde.org/co.php/framework/MIME/MIME/Part.php?sa=1&r=1.159&p=1

Sorry about the big scripts, but whenever I tried to strip it down, the
crash went away.



[2004-01-16 11:12:08] [EMAIL PROTECTED]

The provided test package is not complete..it misses at least
Horde/MIME/Part.php 

(you really ought to cut down the stuff a lot :)




[2003-12-31 08:15:03] jan at horde dot org

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.



[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?




The remainder of the comments for this report are too long. To view
the rest of the comments, please view the bug report online at
http://bugs.php.net/2

-- 
Edit this bug report at http://bugs.php.net/?id=2&edit=1

#26666 [Opn]: crash in zend_mm_alloc

2003-12-31 Thread jan at horde dot org 
 ID:   2
 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=2&edit=1