Edit report at https://bugs.php.net/bug.php?id=64297&edit=1
ID: 64297
User updated by: jille at hexon dot cx
Reported by: jille at hexon dot cx
Summary: Segfault after allowed memory exhausted
Status: Open
Type: Bug
Package: Reproducible crash
Operating System: Linux
PHP Version: 5.4.12
Block user comment: N
Private report: N
New Comment:
Yes. Exactly the same.
Previous Comments:
------------------------------------------------------------------------
[2013-03-01 09:38:53] laruence@php.net
nothing serious,
so the segufalt backtrace is the same as before?
------------------------------------------------------------------------
[2013-03-01 08:15:56] jille at hexon dot cx
==30922== Memcheck, a memory error detector
==30922== Copyright (C) 2002-2011, and GNU GPL'd, by Julian Seward et al.
==30922== Using Valgrind-3.7.0 and LibVEX; rerun with -h for copyright info
==30922== Command: ./sapi/cli/php -d auto_prepend_file=auto_prepend_prepend.lib
/data/www/htdocs/wheeler/daemons/daemon_wrapper 1023 live memcrash.php
==30922==
==30922== Invalid read of size 8
==30922== at 0x77954D: _zend_mm_free_int (zend_alloc.c:2071)
==30922== by 0x795D61: destroy_op_array (zend_opcode.c:356)
==30922== by 0x7AD657: zend_hash_destroy (zend_hash.c:560)
==30922== by 0x79F860: zend_shutdown (zend.c:822)
==30922== by 0x741019: php_module_shutdown (main.c:2365)
==30922== by 0x433BE6: main (php_cli.c:1379)
==30922== Address 0x4ca5d948 is not stack'd, malloc'd or (recently) free'd
==30922==
==30922==
==30922== Process terminating with default action of signal 11 (SIGSEGV)
==30922== Access not within mapped region at address 0x4CA5D948
==30922== at 0x77954D: _zend_mm_free_int (zend_alloc.c:2071)
==30922== by 0x795D61: destroy_op_array (zend_opcode.c:356)
==30922== by 0x7AD657: zend_hash_destroy (zend_hash.c:560)
==30922== by 0x79F860: zend_shutdown (zend.c:822)
==30922== by 0x741019: php_module_shutdown (main.c:2365)
==30922== by 0x433BE6: main (php_cli.c:1379)
==30922== If you believe this happened as a result of a stack
==30922== overflow in your program's main thread (unlikely but
==30922== possible), you can try to increase the size of the
==30922== main thread stack using the --main-stacksize= flag.
==30922== The main thread stack size used in this run was 8388608.
==30922==
==30922== HEAP SUMMARY:
==30922== in use at exit: 7,553,441 bytes in 20,136 blocks
==30922== total heap usage: 2,020,750 allocs, 2,000,614 frees, 1,564,536,722 bytes allocated
==30922==
==30922== LEAK SUMMARY:
==30922== definitely lost: 203,536 bytes in 3,635 blocks
==30922== indirectly lost: 4,029,186 bytes in 2,979 blocks
==30922== possibly lost: 70,648 bytes in 43 blocks
==30922== still reachable: 3,250,071 bytes in 13,479 blocks
==30922== suppressed: 0 bytes in 0 blocks
==30922== Rerun with --leak-check=full to see details of leaked memory
==30922==
==30922== For counts of detected and suppressed errors, rerun with: -v
==30922== ERROR SUMMARY: 1 errors from 1 contexts (suppressed: 2 from 2)
Segmentation fault
------------------------------------------------------------------------
[2013-03-01 03:12:22] laruence@php.net
do you get the new valgrind log?
thanks
------------------------------------------------------------------------
[2013-02-25 15:51:09] jille at hexon dot cx
Removing the memcache extension doesn't help. (gdb output seems the same, do you want the new
valgrind output? (Takes a while))
------------------------------------------------------------------------
[2013-02-25 14:56:49] laruence@php.net
please remove the memcache extension then test it again.
------------------------------------------------------------------------
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
https://bugs.php.net/bug.php?id=64297
--
Edit this bug report at https://bugs.php.net/bug.php?id=64297&edit=1