php.net |  support |  documentation |  report a bug |  advanced search |  search howto |  statistics |  random bug |  login

go to bug id or search bugs for

Bug #42475 Got seg fault, core dump in php 5.2.3 code in _zend_hash_add_or_update
Submitted: 2007-08-29 18:42 UTC Modified: 2007-09-07 01:00 UTC
Votes:3
Avg. Score:5.0 ± 0.0
Reproduced:3 of 3 (100.0%)
Same Version:0 (0.0%)
Same OS:0 (0.0%)
From: shawn at mbuzzy dot com Assigned:
Status: No Feedback Package: Reproducible crash
PHP Version: 5.2.3 OS: RedHat Enterprise 3
Private report: No CVE-ID: None
View Add Comment Developer Edit
Have you experienced this issue?
Rate the importance of this bug to you:

 [2007-08-29 18:42 UTC] shawn at mbuzzy dot com 
Description:
------------
I am running:

Apache 1.3.31
Php 5.2.3 -- built with following switches:

'./configure' '--prefix=/local/service/php' '--with-apxs=/local/service/apache/bin/apxs' '--with-mysql' '--with-mysqli=/usr/bin/mysql_config' '--with-config-file-path=/local/service/php' '--with-mcrypt' '--with-curl' '--with-pdo-mysql'

APC 3.0.14


We are getting a SEGV/core dump from apache httpd. The
dump is reproducible in the sense that it happens regularly
at about 2-3 hour intervals and the core back-trace is landing in exactly the same spot every time. However, it is not always processing
the same php, so it's difficult to give you a reproducible php script to try yourself.

However I do have a back-trace that might help.
It appears to always be in a state where it is trying to setup the php global hash environment. Specificaly, processing the query args to populate the $_REQUESTS values.

#0  _zend_hash_add_or_update (ht=0x64696f, arKey=0x80eb220 "returnURL", nKeyLength=10, pData=0xbfffd4c4, nDataSize=4, pDest=0xbfffd4c8, flag=1)
    at /local/palermo/redhat.es.3.0.i386/src/php-5.2.3/Zend/zend_hash.c:216
#1  0xb6ee61f0 in zend_symtable_update (ht=0x64696f, arKey=0x80eb220 "returnURL", nKeyLength=10, pData=0xbfffd4c4, nDataSize=4, pDest=0xbfffd4c8) at zend_hash.h:340
#2  0xb6ee4cf8 in php_register_variable_ex (var=0x80eb094 "returnURL", val=0xbfffd500, track_vars_array=0x458ff178) at /local/palermo/redhat.es.3.0.i386/src/php-5.2.3/main/php_variables.c:213
#3  0xb6dabc59 in php_sapi_filter (arg=1, var=0x80eb094 "returnURL", val=0xbfffd580, val_len=21, new_val_len=0xbfffd584) at /local/palermo/redhat.es.3.0.i386/src/php-5.2.3/ext/filter/filter.c:396
#4  0xb6ee50d6 in php_default_treat_data (arg=1, str=0x0, destArray=0x458ff178) at /local/palermo/redhat.es.3.0.i386/src/php-5.2.3/main/php_variables.c:369
#5  0xb6ee5cd7 in php_hash_environment () at /local/palermo/redhat.es.3.0.i386/src/php-5.2.3/main/php_variables.c:677
#6  0xb6edb970 in php_request_startup () at /local/palermo/redhat.es.3.0.i386/src/php-5.2.3/main/main.c:1143
#7  0xb6f67e93 in apache_php_module_main (r=0x809cf70, display_source_mode=0) at /local/palermo/redhat.es.3.0.i386/src/php-5.2.3/sapi/apache/sapi_apache.c:33
#8  0xb6f688ea in send_php (r=0x809cf70, display_source_mode=0, filename=0x0) at /local/palermo/redhat.es.3.0.i386/src/php-5.2.3/sapi/apache/mod_php5.c:663
#9  0xb6f689f7 in send_parsed_php (r=0x809cf70) at /local/palermo/redhat.es.3.0.i386/src/php-5.2.3/sapi/apache/mod_php5.c:678
#10 0x080552bb in ap_invoke_handler ()
#11 0x0806a619 in process_request_internal ()
#12 0x0806a678 in ap_process_request ()
#13 0x08061737 in child_main ()
#14 0x080619bd in make_child ()
#15 0x08061cfb in perform_idle_server_maintenance ()
#16 0x08062332 in standalone_main ()
#17 0x08062952 in main ()

Note that the ht parameter _zend_hash_add_or_update()
is pointing to bad (invalid) memory.

Thanks.

-Shawn

Patches

Add a Patch

Pull Requests

Add a Pull Request

History

AllCommentsChangesGit/SVN commitsRelated reports
 [2007-08-29 20:42 UTC] jani@php.net 
First I need to quote one line from the page you sent this report from:

"Always disable any Zend or other 3rd party extensions (Turck MMCache, ionCube loader, Xdebug, APC) before submitting a *PHP* bug."

Before you start disabling anything, install the latest CVS snapshot from here: http://snaps.php.net/php5.2-latest.tar.gz

And then disable all 3rd party extensions (APC especially..).
 [2007-08-29 23:09 UTC] shawn at mbuzzy dot com 
Hello Jani,

We tried a simple test and ran php5.2.3 "clean", by disabling third party extensions, including APC.

We still got the core dump and the back trace landed in exactly the same place in code.
Now we'll try the other suggestion and build/install 5.2.4RC3 and see if that makes the problem go away.

Thanks,

-Shawn
 [2007-09-07 01:00 UTC] php-bugs at lists dot php dot net 
No feedback was provided for this bug for over a week, so it is
being suspended automatically. If you are able to provide the
information that was originally requested, please do so and change
the status of the bug back to "Open".
 [2009-10-12 20:32 UTC] zach at box dot net 
We are experiencing the same issue. We first noticed the issue under 5.2.9, but have reproduced it under 5.2.11 and a recent snapshot. 200910091830)

We've found that if we set apache's MaxRequestsPerChild to a low number (less than 50) we never experience a segfault. If we set it to a high number (5000 or so) we always experience the segfault. We don't yet have enough data to know how many requests it takes to trigger the segfault.

The only external module we're loading is memcache.so.
 [2014-06-29 08:45 UTC] majo-bugs dot php dot net at pematon dot com 
Related To: Bug #67493
 
PHP Copyright © 2001-2024 The PHP Group
All rights reserved. 		Last updated: Thu Apr 18 06:01:28 2024 UTC