Note: This is a beta release of Red Hat Bugzilla 5.0. The data contained within is a snapshot of the live data so any changes you make will not be reflected in the production Bugzilla. Also email is disabled so feel free to test any aspect of the site that you want. File any problems you find or give feedback here.
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
Keywords:
Status: CLOSED CANTFIX
Alias: None
Product: Fedora
Classification: Fedora
Component: php
Version: 4
Hardware: i386
OS: Linux
medium
medium
Target Milestone: ---
Assignee: Joe Orton
QA Contact: David Lawrence
URL:
Whiteboard:
Depends On:
Blocks:
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:
Environment:
Last Closed: 2007-03-10 18:45:24 UTC


Attachments (Terms of Use)
Here session is started (deleted)
2005-06-15 14:43 UTC, Michael
no flags Details
Here session is unset (deleted)
2005-06-15 14:45 UTC, Michael
no flags Details
Core file produced by Apache on segfault (deleted)
2005-06-24 09:39 UTC, Dermot Daly
no flags Details
Patch for sugarcrm to get around the corruption bug in PHP (deleted)
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):
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:

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
configuration.

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:

https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=160691



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):

php-5.0.4-10
httpd-2.0.54-10

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,
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.

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
code?

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
jeff@phatgeeks.com

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.