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.

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

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

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.

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

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.