From Bugzilla Helper: User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.8) Gecko/20050524 Fedora/1.0.4-4 Firefox/1.0.4 Description of problem: The problem is when PHP session is starting it creates an empty session file. And when it trys to unset that session apache dies with segmentation fault (11). After removing RPM installation of PHP and building PHP from source (versions are the same - 5.0.4) all work perfect. Version-Release number of selected component (if applicable): php-5.0.4-10.i386.rpm How reproducible: Always Steps to Reproduce: 1. Create PHP session 2. Unset PHP session 3. Actual Results: Apache craches with error "child pid XXXX exit signal Segmentation fault (11)" Expected Results: Continue working Additional info:
Can you give a sample script which triggers this? Alternatively obtain a backtrace: # echo "CoreDumpDirectory /tmp" > /etc/httpd/conf.d/coredump.conf # service httpd reload ... trigger segfault... # gdb /usr/sbin/httpd /tmp/core.<pid> ... (gdb) bt full
Created attachment 115482 [details] Here session is started
Created attachment 115483 [details] Here session is unset When session is unset (unset_session) apache is crached.
I can give you only scripts. I cannot create a backtrace because I already reinstalled PHP from the sources. But I think that problem in PHP RPM because after reinstallation the web application works correctly. So, I didn't change application code or PHP configuration.
If you can't give a self-contained reproduction case, or obtain a backtrace, there's not much we can do to fix this.
FWIW, I just entered a bug that has very similar symptoms (mysql_connect vs. unsetting a session, but same seg-fault behaviour), and attached a backtrace: https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=160691
If this helps, I'm seeing this too. I've found it in a fresh install of FC4. I noticed it when I installed SugarCRM, which causes the segfault when you attempt to log in. I tracked it down to a line of code calling session_unset, however I can't seem to get this to occur in a simple test case. I have a core file produced by Apache, if it helps
Created attachment 115920 [details] Core file produced by Apache on segfault Packages installed (from FC4 disks): php-5.0.4-10 httpd-2.0.54-10
Thanks a lot Dermot. Backtrace is: #0 0x020f4efd in zend_hash_del_key_or_index (ht=0x8ff19bc, arKey=Variable "arKey" is not available. ) at /usr/src/debug/php-5.0.4/Zend/zend_hash.c:462 #1 0x0201ac39 in zif_session_unregister (ht=1, return_value=0x8ff2ebc, this_ptr=0x0, return_value_used=0) at /usr/src/debug/php-5.0.4/ext/session/session.c:1583 #2 0x021108d8 in zend_do_fcall_common_helper (execute_data=0xbff512a0, opline=0x8ff6344, op_array=0x8fdcef4) at /usr/src/debug/php-5.0.4/Zend/zend_execute.c:2727 #3 0x02120e58 in zend_do_fcall_handler (execute_data=0xbff512a0, opline=0x8ff6344, op_array=0x84804800) at /usr/src/debug/php-5.0.4/Zend/zend_execute.c:2859 #4 0x0210dd81 in execute (op_array=0x8fdcef4) at /usr/src/debug/php-5.0.4/Zend/zend_execute.c:1406 #5 0x02124253 in zend_include_or_eval_handler (execute_data=0xbff56600, opline=0xb7dc0cf8, op_array=0x84804800) at /usr/src/debug/php-5.0.4/Zend/zend_execute.c:3581 #6 0x0210dd81 in execute (op_array=0x8c3dbe4) at /usr/src/debug/php-5.0.4/Zend/zend_execute.c:1406 #7 0x020ec699 in zend_execute_scripts (type=8, retval=Variable "retval" is not available. ) at /usr/src/debug/php-5.0.4/Zend/zend.c:1069 #8 0x020b1fd7 in php_execute_script (primary_file=0xbff58940) at /usr/src/debug/php-5.0.4/main/main.c:1632 #9 0x02128012 in php_handler (r=0x8c2de48) at /usr/src/debug/php-5.0.4/sapi/apache2handler/sapi_apache2.c:570 this could be similar to bug 157457; memory corruption in the session table.
Does anyone have a workaround for this problem? I'm seeing this as well (Apache, SugarCRM etc etc.)
So do I. It only works properly on first login after app (SugarCRM) reinstallation.
Created attachment 116621 [details] Patch for sugarcrm to get around the corruption bug in PHP I think there is a bug in PHP and sugarcrm manages to trigger it with using array_merge to $_SESSION superglobal. If I have understand correctly the code of sugarcrm it doesn't really need that array_merge line. Some old leftover code? I hope the patch will help people to find the real corruption problem in PHP and offer an interim solution to sugarcrm users.
You just kept me from commiting suicide. I wish I would have found this post 10 hours ago. I can verify that your patch for SugarCRM works. Thank you! Jeff Thompson jeff
The patch worked here too. Thank you very much.
I found another way around the problem (At least for SugarCRM login) in /etc/php.ini, there's an option register_long_arrays which is set to Off by default. Setting that to On lets me login to SugarCRM.
I had the same problem. I upgraded to FC4 with Php 5 and apache 2.0.54. After restoring the database for SugarCRM 3.0c, I could not login. First I thought that there was a problem in the data. To make sure I turned on the php debugger log in php4log.properties. Identified the prolem was at session_unregister('loginXXX') in the User/Authenticate.php. So I was sure there was some problem with the session management. Initially I thought that apache was unable to write to my php session directory. So I gave apache users the permission to that folder. No luck. Finally I fould this post after wasting quite some time tinkering with the php code. I think it is left over code too, not sure. For now I just changed /etc/php.ini (default location of php config file in fedora core 4) register_long_arrays to On as suggested by Ben in the previous post. Thanks everyone.
Closing because bug has remained in NEEDINFO state without reply for a long period of time. Note that FC3 and FC4 are supported by Fedora Legacy for security fixes only. Please install a still supported version and retest. If it still occurs on FC5 or FC6, please reopen and assign to the correct version. Otherwise, if this a security issue, please change the product to Fedora Legacy. Thanks, and we are sorry that we did not get to this bug earlier. This bug was originally filed against a much earlier version of Fedora Core, and significant changes have taken place since the last version for which this bug is confirmed. Here, it is very likely that a new version of PHP has fixed the problem.