Bug #68294 [Fbk->NoF]: file_exists SIGSEGV for FPM
Edit report at https://bugs.php.net/bug.php?id=68294&edit=1
ID: 68294
Updated by: php-bugs@lists.php.net
Reported by: sillyxone at gmail dot com
Summary: file_exists SIGSEGV for FPM
-Status: Feedback
+Status: No Feedback
Type: Bug
Package: Reproducible crash
Operating System: Linux
PHP Version: 5.5.18
Private report: N
New Comment:
No feedback was provided. The bug is being suspended because
we assume that you are no longer experiencing the problem.
If this is not the case and you are able to provide the
information that was requested earlier, please do so and
change the status of the bug back to "Re-Opened". Thank you.
Previous Comments:
------------------------------------------------------------------------
[2014-12-16 17:30:18] sillyxone at gmail dot com
I've narrowed it down to AWS SDK version 1.5.10. Upgrading to AWS SDK version 1.6.2 solved the
problem (PHP-FPM 5.5.19). I don't have the need to fix this bug anymore (at least for now), as
it's too complicated to reproduce (involving AWS SDK 1.5.10, and Drupal's modules). Let me
know if you want me to continue to hunt it down when I have a chance.
thanks
------------------------------------------------------------------------
[2014-11-11 08:54:09] laruence@php.net
Thank you for this bug report. To properly diagnose the problem, we
need a short but complete example script to be able to reproduce
this bug ourselves.
A proper reproducing script starts with <?php and ends with ?>,
is max. 10-20 lines long and does not require any external
resources such as databases, etc. If the script requires a
database to demonstrate the issue, please make sure it creates
all necessary tables, stored procedures etc.
Please avoid embedding huge scripts into the report.
------------------------------------------------------------------------
[2014-10-28 14:10:57] sillyxone at gmail dot com
I haven't done any core dump/stack-tracing for years, and must have done it incorrectly. Can
you provide detailed instructions?
Last time, the dump files were named "core-apache2.xxxxx", and I ran "gdb apache2
core-apache2.xxxxx". Today I tried again and it resulted in "core-php5-fpm.xxxxx"
files, and I can run "gdb php5-fpm core-php5-fpm.xxxxx". So, perhaps it's correct
this time? Sorry for being so dump :-(
First few lines of stack trace (including some lines from gdb so that you can spot what I did
wrong):
---------------
Reading symbols from php5-fpm...Reading symbols from
/usr/lib/debug/.build-id/df/d91fbdc1d94ca651f436aa9d66ef4a24d89c2b.debug...done.
done.
[New LWP 24255]
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib/i386-linux-gnu/libthread_db.so.1".
Core was generated by `php-fpm: pool www
'.
Program terminated with signal SIGSEGV, Segmentation fault.
#0 0x0836ebfb in zend_std_cast_object_tostring (readobj=readobj@entry=0x91fe384,
writeobj=writeobj@entry=0xbf2c20c0, type=type@entry=6)
at /build/buildd/php5-5.5.18+dfsg/Zend/zend_object_handlers.c:1525
1525 /build/buildd/php5-5.5.18+dfsg/Zend/zend_object_handlers.c: No such file or directory.
(gdb) bt
#0 0x0836ebfb in zend_std_cast_object_tostring (readobj=readobj@entry=0x91fe384,
writeobj=writeobj@entry=0xbf2c20c0, type=type@entry=6)
at /build/buildd/php5-5.5.18+dfsg/Zend/zend_object_handlers.c:1525
#1 0x0834a1c4 in zend_make_printable_zval (expr=expr@entry=0x91fe384,
expr_copy=expr_copy@entry=0xbf2c20c0, use_copy=use_copy@entry=0xbf2c20bc)
at /build/buildd/php5-5.5.18+dfsg/Zend/zend.c:258
#2 0x083b16ac in ZEND_CAST_SPEC_CV_HANDLER (execute_data=0x94951f0) at
/build/buildd/php5-5.5.18+dfsg/Zend/zend_vm_execute.h:30840
#3 0x08375cb7 in execute_ex (execute_data=execute_data@entry=0x94951f0) at
/build/buildd/php5-5.5.18+dfsg/Zend/zend_vm_execute.h:363
#4 0x0833878d in dtrace_execute_ex (execute_data=0x94951f0) at
/build/buildd/php5-5.5.18+dfsg/Zend/zend_dtrace.c:73
#5 0x08400535 in zend_execute (op_array=0x931bca8) at
/build/buildd/php5-5.5.18+dfsg/Zend/zend_vm_execute.h:388
#6 0x08402aed in zend_do_fcall_common_helper_SPEC (execute_data=0x949517c) at
/build/buildd/php5-5.5.18+dfsg/Zend/zend_vm_execute.h:584
#7 0x08375cb7 in execute_ex (execute_data=execute_data@entry=0x949517c) at
/build/buildd/php5-5.5.18+dfsg/Zend/zend_vm_execute.h:363
#8 0x0833878d in dtrace_execute_ex (execute_data=0x949517c) at
/build/buildd/php5-5.5.18+dfsg/Zend/zend_dtrace.c:73
#9 0x08400535 in zend_execute (op_array=0x931ba38) at
/build/buildd/php5-5.5.18+dfsg/Zend/zend_vm_execute.h:388
#10 0x0833adf4 in zend_call_function (fci=fci@entry=0xbf2c248c,
fci_cache=fci_cache@entry=0xbf2c2478) at /build/buildd/php5-5.5.18+dfsg/Zend/zend_execute_API.c:937
------------------------------------------------------------------------
[2014-10-28 03:35:26] laruence@php.net
hmmm;
ZEND_API void execute_ex(zend_execute_data *execute_data TSRMLS_DC)
{
DCL_OPLINE
zend_bool original_in_execution;
344: original_in_execution = EG(in_execution);
----------------------------------------
the 344th line of zend_vm_execute.h is listed above, I can not image of how it segs
------------------------------------------------------------------------
[2014-10-24 13:49:09] sillyxone at gmail dot com
I spoke too early. After experimenting some more:
- the same call to file_exists() crashes even when run PHP as Apache Handler (version 5.5.18,
5.4.33)
- doesn't crash for PHP version 5.3.29 (either as Apache Handler or FPM). I'm sticking to
PHP 5.3.29 FPM + Nginx for now.
I can only perform core dump on my Ubuntu development machine, thus can only debug 5.5.18. The test
server running AMI is now stable with PHP 5.3.29 so I won't play with it.
------------------------------------------------------------------------
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=68294
--
Edit this bug report at https://bugs.php.net/bug.php?id=68294&edit=1
Thread (7 messages)