Edit report at https://bugs.php.net/bug.php?id=70392&edit=1
ID: 70392
Comment by: pegasus at vaultwiki dot org
Reported by: pegasus at vaultwiki dot org
Summary: SIGSEGV during PHP shutdown
Status: Feedback
Type: Bug
Package: *General Issues
Operating System: Centos 7 64-bit
PHP Version: 7.0Git-2015-08-30 (Git)
Assigned To: dmitry
Block user comment: N
Private report: N
New Comment:
How would I output the value?
Previous Comments:
------------------------------------------------------------------------
[2015-08-31 16:30:35] dmitry@php.net
The crash on line "if (dbg->size != 0)" is possible only when "dbg" is
invalid.
The crash occured on processing 25-th element of 510-th page.
We allocate 512 pages at once. So I assume "dbg" somehow points into page after 512.
I don't see how this may happen yet.
Can you show the values of "dbg" and "bin_num"?
------------------------------------------------------------------------
[2015-08-31 13:55:31] laruence@php.net
Dmitry, can you see anything useful here?
------------------------------------------------------------------------
[2015-08-31 13:43:36] laruence@php.net
hmm, we can not do something useful here if you don't have a way to reproduce it :<
------------------------------------------------------------------------
[2015-08-30 17:09:34] pegasus at vaultwiki dot org
Description:
------------
I have noticed in my logs for several months that PHP has been throwing SIGSEGV at random times that
do not seem to correspond to any scripts when comparing against timestamps in the web server's
access logs. It would be incredibly useful if PHP's error logs would include the
REQUEST_URI+QUERY_STRING that led to a segfault. I ran a backtrace on the coredump a while back and
was disheartened because there was no execute frame that might suggest what PHP code or script
causes this error.
I was hoping you guys would magically find the problem before release, but we're in RC now and
I still get the errors in my logs. From what I remember, if I don't have --enable-debug in my
configure and this error occurs, the FPM shuts down and must be restarted manually. Since it can do
this in the middle of the night when no staff is awake, it can be a serious problem.
Here is the backtrace:
####
#0 0x0000000000946aa0 in zend_mm_find_leaks_small (p=0x7f0499600000, i=510,
j=25, leak=0x7fff54486290)
at /home/***/php-src-c68fa93/Zend/zend_alloc.c:1957
#1 0x0000000000946c0d in zend_mm_find_leaks (heap=0x7f04d9e00040,
p=0x7f0499600000, i=510, leak=0x7fff54486290)
at /home/***/php-src-c68fa93/Zend/zend_alloc.c:1985
#2 0x0000000000947006 in zend_mm_check_leaks (heap=0x7f04d9e00040)
at /home/***/php-src-c68fa93/Zend/zend_alloc.c:2070
#3 0x00000000009472c6 in zend_mm_shutdown (heap=0x7f04d9e00040, full=0,
silent=0) at /home/robotnik/php-src-c68fa93/Zend/zend_alloc.c:2135
#4 0x0000000000948159 in shutdown_memory_manager (silent=0, full_shutdown=0)
at /home/***/php-src-c68fa93/Zend/zend_alloc.c:2578
#5 0x00000000008eac78 in php_request_shutdown (dummy=0x0)
at /home/***/php-src-c68fa93/main/main.c:1837
#6 0x0000000000a47245 in main (argc=8, argv=0x7fff54486a78)
at /home/***/php-src-c68fa93/sapi/fpm/fpm/fpm_main.c:1969
####
If you can give me some idea how to help you solve this issue faster, please let me know. As there
is no execute frame, I cannot debug this in the normal way.
According to frame 0, this is the line in zend_alloc.c that causes the segfault:
####
if (dbg->size != 0) {
####
------------------------------------------------------------------------
--
Edit this bug report at https://bugs.php.net/bug.php?id=70392&edit=1