Description of problem: See https://openshift.redhat.com/community/forums/express/php-error-child-pid-xxx-exit-signal-segmentation-fault-11#comment-27995 @madewild has an app that triggers a segfault in the php-5.3 cartridge as opposed to the Zend cartridge (where the app works). "it's segfaulting while trying to call json_encode(), so the problem is with the PHP json extension..."
@madewild, could you please provide us with a reproducer? We can't access your gear in any way. It'd be very helpful if you could debug your app yourself: 1. SSH into your gear 2. Run the following command (to start the gdb debugger) $ gdb --pid `ps -ef|grep httpd|tail -n1|gawk '{print $2}'` --eval-command=c 3. ....wait for the crash (gdb should detach from the program and print something like "child pid XXXXX exit signal Segmentation fault (11)") 4. Enter "bt" command in gdb (to print the backtrace) 5. Copy+paste the backtrace into this bugzilla
Hi, I tried the command above but I get the following: [ca13-mastic.rhcloud.com ~]\> gdb --pid `ps -ef|grep httpd|tail -n1|gawk '{print $2}'` --eval-command=c [...] Attaching to process 14219 ptrace: No such process. The program is not being run.
(In reply to comment #4) > Hi, > > I tried the command above but I get the following: > > [ca13-mastic.rhcloud.com ~]\> gdb --pid `ps -ef|grep httpd|tail -n1|gawk > '{print $2}'` --eval-command=c > [...] > Attaching to process 14219 > ptrace: No such process. > The program is not being run. Weird. What you need to do is basically attaching the gdb to the CHILD process of the Apache: $ ps -ef|grep httpd ..gives you list of the Apache processes with it's PIDs. You need to grab PID of the child process (should have the other process listed as parent) and use it as parameter to the gdb: $ gdb --pid <PID-OF-CHILD> --eval-command=c Than you should be able to see the crash and get the backtrace. Could you please try again? Or do you have any reproducer so I can debug it myself?
It works when I run the two commands successively (maybe something was wrong with the simple quotes), but the output ends with "Continuing." and then hangs: [...] Reading symbols from /usr/lib64/php/modules/zip.so...error: cannot open Packages database in error: cannot open Packages database in error: cannot open Packages database in error: cannot open Packages database in Missing separate debuginfo for /usr/lib64/php/modules/zip.so Try: yum --disablerepo='*' --enablerepo='*-debug*' install /usr/lib/debug/.build-id/de/9183f5fd7d6a22f29a1428556dbad0bd4dff27.debug (no debugging symbols found)...done. Loaded symbols for /usr/lib64/php/modules/zip.so 0x00007fe5dd3fd830 in __accept_nocancel () from /lib64/libpthread.so.0 Continuing.
If I quit and run the bt I get: #0 0x00007fe5dd3fd830 in __accept_nocancel () from /lib64/libpthread.so.0 #1 0x00007fe5dd629cf5 in apr_socket_accept () from /usr/lib64/libapr-1.so.0 #2 0x00007fe5deb60be1 in unixd_accept () #3 0x00007fe5deb5f913 in ?? () #4 0x00007fe5deb5fc8a in ?? () #5 0x00007fe5deb6090c in ap_mpm_run () #6 0x00007fe5deb37900 in main ()
(In reply to comment #6) > It works when I run the two commands successively (maybe something was wrong > with the simple quotes), but the output ends with "Continuing." and then > hangs: > > [...] > Reading symbols from /usr/lib64/php/modules/zip.so...error: cannot open > Packages database in > error: cannot open Packages database in > error: cannot open Packages database in > error: cannot open Packages database in > Missing separate debuginfo for /usr/lib64/php/modules/zip.so > Try: yum --disablerepo='*' --enablerepo='*-debug*' install > /usr/lib/debug/.build-id/de/9183f5fd7d6a22f29a1428556dbad0bd4dff27.debug > (no debugging symbols found)...done. > Loaded symbols for /usr/lib64/php/modules/zip.so > 0x00007fe5dd3fd830 in __accept_nocancel () from /lib64/libpthread.so.0 > Continuing. This is correct. When gdb "hangs", you just need to run that PHP application which causes the crash. Then it will show the output of the crash straight after the "Continuing." line..
Oh sorry for my ignorance. Here's the backtrace at last: Program received signal SIGSEGV, Segmentation fault. 0x00007f41e41d8960 in zend_hash_find () from /var/lib/openshift/62e9e663f1c64ca0a0cb1ceeec1c081c/php-5.3/modules/libphp5.so (gdb) bt #0 0x00007f41e41d8960 in zend_hash_find () from /var/lib/openshift/62e9e663f1c64ca0a0cb1ceeec1c081c/php-5.3/modules/libphp5.so #1 0x00007f41dbd9a81a in xdebug_execute () from /usr/lib64/php/modules/xdebug.so #2 0x00007f41e41c14c5 in zend_call_function () from /var/lib/openshift/62e9e663f1c64ca0a0cb1ceeec1c081c/php-5.3/modules/libphp5.so #3 0x00007f41e41e1637 in zend_call_method () from /var/lib/openshift/62e9e663f1c64ca0a0cb1ceeec1c081c/php-5.3/modules/libphp5.so #4 0x00007f41e41e9fa6 in zend_objects_destroy_object () from /var/lib/openshift/62e9e663f1c64ca0a0cb1ceeec1c081c/php-5.3/modules/libphp5.so #5 0x00007f41e41eda93 in zend_objects_store_del_ref_by_handle_ex () from /var/lib/openshift/62e9e663f1c64ca0a0cb1ceeec1c081c/php-5.3/modules/libphp5.so #6 0x00007f41e41edad3 in zend_objects_store_del_ref () from /var/lib/openshift/62e9e663f1c64ca0a0cb1ceeec1c081c/php-5.3/modules/libphp5.so #7 0x00007f41e41bf0da in _zval_ptr_dtor () from /var/lib/openshift/62e9e663f1c64ca0a0cb1ceeec1c081c/php-5.3/modules/libphp5.so #8 0x00007f41e41d73a5 in ?? () from /var/lib/openshift/62e9e663f1c64ca0a0cb1ceeec1c081c/php-5.3/modules/libphp5.so #9 0x00007f41e41d7628 in zend_hash_graceful_reverse_destroy () from /var/lib/openshift/62e9e663f1c64ca0a0cb1ceeec1c081c/php-5.3/modules/libphp5.so #10 0x00007f41e41bf69e in ?? () from /var/lib/openshift/62e9e663f1c64ca0a0cb1ceeec1c081c/php-5.3/modules/libphp5.so #11 0x00007f41e41cb792 in ?? () from /var/lib/openshift/62e9e663f1c64ca0a0cb1ceeec1c081c/php-5.3/modules/libphp5.so #12 0x00007f41e41798e5 in php_request_shutdown () from /var/lib/openshift/62e9e663f1c64ca0a0cb1ceeec1c081c/php-5.3/modules/libphp5.so #13 0x00007f41e4253bd7 in ?? () from /var/lib/openshift/62e9e663f1c64ca0a0cb1ceeec1c081c/php-5.3/modules/libphp5.so #14 0x00007f41ea956bb0 in ap_run_handler () #15 0x00007f41ea95a46e in ap_invoke_handler () #16 0x00007f41ea965b30 in ap_process_request () #17 0x00007f41ea9629a8 in ?? () #18 0x00007f41ea95e6b8 in ap_run_process_connection () #19 0x00007f41ea96a977 in ?? () #20 0x00007f41ea96ac8a in ?? () #21 0x00007f41ea96b90c in ap_mpm_run () #22 0x00007f41ea942900 in main ()
So this is exact same backtrace as in bug 911542. This bug is not related to the OpenShift or the APC extension but to the PHP-5.3 core itself. *** This bug has been marked as a duplicate of bug 911542 ***
This could be actually triggered by any enabled PHP extension, hitting the zend_hash SIGSEGV in PHP core.. I will try to find a workaround for you.