Bug 160480 - Apache gives Segmentation fault (11) when PHP script trys to unset session
Apache gives Segmentation fault (11) when PHP script trys to unset session
Product: Fedora
Classification: Fedora
Component: php (Show other bugs)
i386 Linux
medium Severity medium
: ---
: ---
Assigned To: Joe Orton
David Lawrence
Depends On:
  Show dependency treegraph
Reported: 2005-06-15 09:16 EDT by Michael
Modified: 2007-11-30 17:11 EST (History)
3 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2007-03-10 13:45:24 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)
Here session is started (22.06 KB, application/x-php)
2005-06-15 10:43 EDT, Michael
no flags Details
Here session is unset (5.27 KB, application/x-php)
2005-06-15 10:45 EDT, Michael
no flags Details
Core file produced by Apache on segfault (2.24 MB, application/octet-stream)
2005-06-24 05:39 EDT, Dermot Daly
no flags Details
Patch for sugarcrm to get around the corruption bug in PHP (1.17 KB, patch)
2005-07-11 16:26 EDT, Asko Tontti
no flags Details | Diff

  None (edit)
Description Michael 2005-06-15 09:16:15 EDT
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):

How reproducible:

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

Additional info:
Comment 1 Joe Orton 2005-06-15 09:25:08 EDT
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
Comment 2 Michael 2005-06-15 10:43:32 EDT
Created attachment 115482 [details]
Here session is started
Comment 3 Michael 2005-06-15 10:45:42 EDT
Created attachment 115483 [details]
Here session is unset 

When session is unset (unset_session) apache is crached.
Comment 4 Michael 2005-06-15 10:51:29 EDT
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
Comment 5 Joe Orton 2005-06-16 10:33:54 EDT
If you can't give a self-contained reproduction case, or obtain a backtrace,
there's not much we can do to fix this.
Comment 6 Mark Linford 2005-06-16 13:40:38 EDT
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:


Comment 7 Dermot Daly 2005-06-24 05:37:25 EDT
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
Comment 8 Dermot Daly 2005-06-24 05:39:32 EDT
Created attachment 115920 [details]
Core file produced by Apache on segfault

Packages installed (from FC4 disks):

Comment 9 Joe Orton 2005-06-24 05:45:54 EDT
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,
    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)
    at /usr/src/debug/php-5.0.4/Zend/zend_execute.c:1406
#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)
    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
    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.
Comment 10 Jules Oudmans 2005-06-29 11:38:46 EDT
Does anyone have a workaround for this problem? I'm seeing this as well 
(Apache, SugarCRM etc etc.)
Comment 11 JM 2005-07-06 05:17:47 EDT
So do I. It only works properly on first login after app (SugarCRM) reinstallation.
Comment 12 Asko Tontti 2005-07-11 16:26:44 EDT
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.
Comment 13 Jeff Thompson 2005-08-12 00:34:10 EDT
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
Comment 14 Gravis 2005-09-14 15:00:39 EDT
The patch worked here too. Thank you very much.
Comment 15 Ben Carner 2005-10-11 17:48:43 EDT
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.
Comment 16 Yasir Drabu 2005-12-04 13:06:19 EST
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.
Comment 17 John Thacker 2007-03-10 13:45:24 EST
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.

Note You need to log in before you can comment on or make changes to this bug.