Bug 160480
Summary: | Apache gives Segmentation fault (11) when PHP script trys to unset session | ||||||||||||
---|---|---|---|---|---|---|---|---|---|---|---|---|---|
Product: | [Fedora] Fedora | Reporter: | Michael <misha> | ||||||||||
Component: | php | Assignee: | Joe Orton <jorton> | ||||||||||
Status: | CLOSED CANTFIX | QA Contact: | David Lawrence <dkl> | ||||||||||
Severity: | medium | Docs Contact: | |||||||||||
Priority: | medium | ||||||||||||
Version: | 4 | CC: | atontti+rh, dermdaly, mlinford | ||||||||||
Target Milestone: | --- | ||||||||||||
Target Release: | --- | ||||||||||||
Hardware: | i386 | ||||||||||||
OS: | Linux | ||||||||||||
Whiteboard: | |||||||||||||
Fixed In Version: | Doc Type: | Bug Fix | |||||||||||
Doc Text: | Story Points: | --- | |||||||||||
Clone Of: | Environment: | ||||||||||||
Last Closed: | 2007-03-10 18:45:24 UTC | Type: | --- | ||||||||||
Regression: | --- | Mount Type: | --- | ||||||||||
Documentation: | --- | CRM: | |||||||||||
Verified Versions: | Category: | --- | |||||||||||
oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |||||||||||
Cloudforms Team: | --- | Target Upstream Version: | |||||||||||
Embargoed: | |||||||||||||
Attachments: |
|
Description
Michael
2005-06-15 13:16:15 UTC
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. |