Bugzilla (bugzilla.redhat.com) will be under maintenance for infrastructure upgrades and will not be available on July 31st between 12:30 AM - 05:30 AM UTC. We appreciate your understanding and patience. You can follow status.redhat.com for details.
Bug 160480 - Apache gives Segmentation fault (11) when PHP script trys to unset session
Summary: Apache gives Segmentation fault (11) when PHP script trys to unset session
Alias: None
Product: Fedora
Classification: Fedora
Component: php
Version: 4
Hardware: i386
OS: Linux
Target Milestone: ---
Assignee: Joe Orton
QA Contact: David Lawrence
Depends On:
TreeView+ depends on / blocked
Reported: 2005-06-15 13:16 UTC by Michael
Modified: 2007-11-30 22:11 UTC (History)
3 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Last Closed: 2007-03-10 18:45:24 UTC
Type: ---

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

Description Michael 2005-06-15 13:16:15 UTC
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 13:25:08 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

Comment 2 Michael 2005-06-15 14:43:32 UTC
Created attachment 115482 [details]
Here session is started

Comment 3 Michael 2005-06-15 14:45:42 UTC
Created attachment 115483 [details]
Here session is unset 

When session is unset (unset_session) apache is crached.

Comment 4 Michael 2005-06-15 14:51:29 UTC
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 14:33:54 UTC
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 17:40:38 UTC
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 09:37:25 UTC
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 09:39:32 UTC
Created attachment 115920 [details]
Core file produced by Apache on segfault

Packages installed (from FC4 disks):


Comment 9 Joe Orton 2005-06-24 09:45:54 UTC
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 15:38:46 UTC
Does anyone have a workaround for this problem? I'm seeing this as well 
(Apache, SugarCRM etc etc.)

Comment 11 JM 2005-07-06 09:17:47 UTC
So do I. It only works properly on first login after app (SugarCRM) reinstallation.

Comment 12 Asko Tontti 2005-07-11 20:26:44 UTC
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 04:34:10 UTC
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 19:00:39 UTC
The patch worked here too. Thank you very much.

Comment 15 Ben Carner 2005-10-11 21:48:43 UTC
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 18:06:19 UTC
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 18:45:24 UTC
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.