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):
Steps to Reproduce:
1. Create PHP session
2. Unset PHP session
Actual Results: Apache craches with error "child pid XXXX exit signal Segmentation fault (11)"
Expected Results: Continue working
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
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:
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):
Thanks a lot Dermot. Backtrace is:
#0 0x020f4efd in zend_hash_del_key_or_index (ht=0x8ff19bc, arKey=Variable
"arKey" is not available.
#1 0x0201ac39 in zif_session_unregister (ht=1, return_value=0x8ff2ebc,
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,
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)
#5 0x02124253 in zend_include_or_eval_handler (execute_data=0xbff56600,
op_array=0x84804800) at /usr/src/debug/php-5.0.4/Zend/zend_execute.c:3581
#6 0x0210dd81 in execute (op_array=0x8c3dbe4)
#7 0x020ec699 in zend_execute_scripts (type=8, retval=Variable "retval" is not
#8 0x020b1fd7 in php_execute_script (primary_file=0xbff58940)
#9 0x02128012 in php_handler (r=0x8c2de48)
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
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
I can verify that your patch for SugarCRM works.
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.
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.