Edit report at https://bugs.php.net/bug.php?id=68453&edit=1
ID: 68453
Comment by: pegasus at vaultwiki dot org
Reported by: pegasus at vaultwiki dot org
Summary: FPM Process hangs in no-debug only
Status: Open
Type: Bug
Package: Reproducible crash
Operating System: Centos 6 64-bit
PHP Version: master-Git-2014-11-19 (Git)
Block user comment: N
Private report: N
New Comment:
Finally narrowed it down to a single commit.
This was the breaking change: http://git.php.net/?p=php-src.git;a=commitdiff;h=76019b86c0ede959e000c164b02ed8b1d8bb29e1
I'm not sure why that matters, but I think that change needs to be rolled back, or it at least
needs to be investigated why it causes returns of object instances stored as local static array
entries to sometimes hang.
Previous Comments:
------------------------------------------------------------------------
[2014-11-19 22:42:58] pegasus at vaultwiki dot org
By testing with various old commits, I have determined that the breaking change occurred somewhere
between the following:
- 54fa42475120f3ab61f50732fa2d68c3af07f259 (works)
- 96220027e12d72b295808081136dee66bc3a9d61 (does not work)
The commits between the two look relatively innocuous, so I'm at a bit of a loss regarding how
to narrow it down further.
------------------------------------------------------------------------
[2014-11-19 18:33:00] pegasus at vaultwiki dot org
Well I tried for a few hours but cannot create a simple test that duplicates the results. Although
my results varied and the same code blocks did not consistently hang from test to test, the total
script would always hang.
Before giving up when it seemed the behavior changed, I thought this was related to:
Caching object instances as array entries of static arrays declared inside a getObject method,
inside other objects that were cached in the same way in higher level objects (depth of 3 or
higher), then starting from the highest-level object, trying to retrieve the deep objects. But I
cannot be sure because the simple test succeeds, and it seemed like the original script would hang
on the return statements, which makes it nearly impossible to debug further from within PHP.
As I said, this worked properly in previous commits, but the last commit I tried before today is
dated 11/6/2014, so I am not sure when the breaking change occurred. I will try to at least narrow
it down to the last date with a working commit and report back.
------------------------------------------------------------------------
[2014-11-19 17:06:41] pegasus at vaultwiki dot org
Description:
------------
On certain PHP scripts, the process hangs indefinitely. This is new behavior that I did not
experience several days ago on an earlier build. I have not yet been able to determine what code
block is related, but I am working on that now.
As far as I can tell, there is no SIGSEV or other logged crash; the process just eventually times
out.
This behavior exists in both no-debug-non-zts and no-debug-zts builds.
It does not occur in debug-non-zts (I have not tested debug-zts).
Therefore, it suggests that one of the debug symbols that is removed in no-debug builds is actually
needed for execution somewhere or that the removal of debug symbols might damage non-debug code in
some way.
The behavior persists if opcache is disabled.
Here is the configure line, if it helps:
./configure --enable-bcmath --enable-libxml --enable-mbstring --enable-sockets --enable-fpm
--enable-opcache --prefix=/home/php --with-curl --with-freetype-dir=/usr --with-gd
--enable-gd-native-ttf --with-jpeg-dir=/usr --with-libdir=/lib64 --with-libxml-dir=/usr/lib64/
--with-mcrypt --with-mysql --with-mysqli --with-openssl=/usr --with-pic --with-png-dir=/usr
--with-xpm-dir=/usr --with-xsl --with-zlib --with-zlib-dir=/usr --with-fpm-user --with-fpm-group
Expected result:
----------------
Normal execution
------------------------------------------------------------------------
--
Edit this bug report at https://bugs.php.net/bug.php?id=68453&edit=1