php.net |  support |  documentation |  report a bug |  advanced search |  search howto |  statistics |  random bug |  login
Bug #28006 referencing an unset global produces a segfault
Submitted: 2004-04-15 07:36 UTC Modified: 2005-04-18 15:18 UTC
Votes:1
Avg. Score:5.0 ± 0.0
Reproduced:1 of 1 (100.0%)
Same Version:0 (0.0%)
Same OS:0 (0.0%)
From: per at computer dot org Assigned:
Status: Closed Package: Reproducible crash
PHP Version: 4CVS-2005-01-10 OS: linux, kernel 2.4.26
Private report: No CVE-ID: None
Welcome back! If you're the original bug submitter, here's where you can edit the bug or add additional notes.
If you forgot your password, you can retrieve your password here.
Password:
Status:
Package:
Bug Type:
Summary:
From: per at computer dot org
New email:
PHP Version: OS:

 

 [2004-04-15 07:36 UTC] per at computer dot org
Description:
------------
Hi, 
 
I've got a situation where a seemingly innocent statement 
produces a 
segfault. I've tried reducing it to a single reproducable 
testcase, but 
without 
success.??The?problem?is?however?solidly?reproducable?in?the 
context in which it occurs.  
I'm certain it is caused by a mistake in my code, but I 
feel it isn't 
exactly appropriate for php to segfault because of a user 
error?  
 
Very briefly, this is an excerpt where the segfault occurs: 
 
<h2><?php print $_SESSION['customers'][$customer]; ?></h2> 
<?php 
 
????????$q="<longish?SELECT?query>"; 
????????$result=mysql_query(?$q?)?or?die("mysql:".mysql_error()); 
 
????????$main_address=mysql_fetch_array(?$result,?MYSQL_ASSOC?); 
 
????????$q="<longish?SELECT?query>"; 
????????$result=mysql_query(?$q?)?or?die(mysql_error()); 
 
????????$billing_address=mysql_fetch_array(?$result,?MYSQL_ASSOC?); 
 
????????$q="<longish?SELECT?query>"; 
????????$result=mysql_query(?$q?)?or?die(mysql_error()); 
 
????????$technical_address=mysql_fetch_array(?$result,?MYSQL_ASSOC?); 
 
????????$editmain=strcasecmp($_REQUEST['contact'],"main")==0; 
????????//
$editbilling=strcasecmp($_REQUEST['contact'],"billing")==0; 
????????//
$edittechnical=strcasecmp($_REQUEST['contact'],"technical")==0; 
 
?> 
 
If I uncomment either of the last 2 commented-out 
statements, I get a segfault. 
I'm using php 4.3.4 and apache 2.0.49 on linux 2.4.24. 
mysql is 4.0.15. 
 
------- 
OK,  
I've now guarded the above with : 
 
if ( isset($_REQUEST['contact']) ) 
{ 
????????$editmain=strcmp($_REQUEST['contact'],"main")==0; 
????????$editbilling=strcmp($_REQUEST['contact'],"billing")==0; 
????????$edittechnical=strcasecmp($_REQUEST['contact'],"technical")==0; 
} 
 
and the segfault is 
gone.??Still,?a?segfault?just?because?I'm?using?an?unset 
global???And?why?only?on?the?2nd?or?later?statement? 

Actual result:
--------------
(gdb) run -X -f /etc/httpd/httpd.conf 
Starting program: /usr/bin/httpd -X -f /etc/httpd/
httpd.conf 
[New Thread 16384 (LWP 9121)] 
 
Program received signal SIGSEGV, Segmentation fault. 
[Switching to Thread 16384 (LWP 9121)] 
0x40576622 in zend_get_executed_lineno () at /usr/src/
packages/SOURCES/php-4.3.4/Zend/zend_execute_API.c:271 
271                     return active_opline->lineno; 
(gdb) bt 
#0  0x40576622 in zend_get_executed_lineno () at /usr/src/
packages/SOURCES/php-4.3.4/Zend/zend_execute_API.c:271 
#1  0x4057ec6d in zend_error (type=8, format=0x40706ea3 
"Undefined index:  %s") at /usr/src/packages/SOURCES/
php-4.3.4/Zend/zend.c:731 
#2  0x405914a0 in zend_fetch_dimension_address_inner 
(ht=0x81d4bf4, op2=0x821ed34, Ts=0xbfffb34c, type=0) at /
usr/src/packages/SOURCES/php-4.3.4/Zend/zend_execute.c:636 
#3  0x4058a5f0 in zend_fetch_dimension_address 
(result=0x821ed14, op1=0x81d4bd4, op2=0x821ed34, 
Ts=0xbfffb34c, type=0) at /usr/src/packages/SOURCES/
php-4.3.4/Zend/zend_execute.c:787 
#4  0x4058f7fe in execute (op_array=0x81d4f2c) at /usr/src/
packages/SOURCES/php-4.3.4/Zend/zend_execute.c:1283 
#5  0x4057edbb in zend_execute_scripts (type=8, retval=0x0, 
file_count=3) at /usr/src/packages/SOURCES/php-4.3.4/Zend/
zend.c:884 
#6  0x40552f3f in php_execute_script 
(primary_file=0xbffff3d0) at /usr/src/packages/SOURCES/
php-4.3.4/main/main.c:1729 
#7  0x405923b8 in php_handler (r=0x81ef8f8) at /usr/src/
packages/SOURCES/php-4.3.4/sapi/apache2handler/
sapi_apache2.c:537 
#8  0x08092d85 in ap_run_handler (r=0x81ef8f8) at 
config.c:151 
#9  0x08093390 in ap_invoke_handler (r=0x81ef8f8) at 
config.c:358 
#10 0x08076edb in ap_process_request (r=0x81ef8f8) at 
http_request.c:246 
#11 0x0807239d in ap_process_http_connection (c=0x81b5000) 
at http_core.c:250 
#12 0x0809de25 in ap_run_process_connection (c=0x81b5000) 
at connection.c:42 
#13 0x08091384 in child_main (child_num_arg=0) at 
prefork.c:609 
#14 0x0809159b in make_child (s=0x0, slot=0) at 
prefork.c:649 
#15 0x080915f8 in startup_children (number_to_start=5) at 
prefork.c:721 
#16 0x08091e6a in ap_mpm_run (_pconf=0x80d6310, 
plog=0x8116410, s=0x80d9dd0) at prefork.c:940 
#17 0x080983bd in main (argc=4, argv=0xbffff744) at 
main.c:617 
 

Patches

Pull Requests

History

AllCommentsChangesGit/SVN commitsRelated reports
 [2004-07-12 13:15 UTC] per at computer dot org
I believe I am now able to reproduce the problem - I can't say for certain that it *is* the same, but I suspect so.
I first saw this with php 434, then 437, and finally php4-STABLE-200407120830, all with apache 2.0.49 on linux 2.4.26.

3 files to reproduce:

k1.phtml.en - http://jessen.ch/php-bug28006/k1.txt
k2.phtml.en - http://jessen.ch/php-bug28006/k2.txt
k3.phtml.en - http://jessen.ch/php-bug28006/k3.txt

Load http://server/k1
 [2004-12-13 00:27 UTC] sniper@php.net
Can't you provide a SINGLE file with a short script in it?
Using virtual() in this kind of place is pretty useless, why don't you use include() ??

 [2004-12-13 09:15 UTC] per at computer dot org
Those 3 files simply reproduce a problem I've seen elsewhere.  They are in no way closely related to the actual code.  What I could or could not use instead is of no importance - the problem is easily reproduced, isn't that what matters?
 [2005-01-10 09:43 UTC] per at computer dot org
php4-STABLE-200501100730:  segfault.  
Let me know if you need any further diagnostics or info.
 [2005-01-10 22:43 UTC] sniper@php.net
A simpler test case would be nice..

 [2005-01-11 07:11 UTC] moriyoshi@php.net
Do you have some kind of optimiser / accelerator such as 
APC installed?

 [2005-01-11 09:31 UTC] per at computer dot org
No, this is a fairly plain vanilla install.  The only not-quite-standard is that I'm building everything with -DHARMUT_0 as I need/want getopt_long() in the cli. See bug#30380. 
With respect to reproducing this problem - I'll try to make it even simpler, but it's really only 17 lines in 2 files.
 [2005-02-11 06:19 UTC] sniper@php.net
Please try using this CVS snapshot:

  http://snaps.php.net/php5-latest.tar.gz
 
For Windows:
 
  http://snaps.php.net/win32/php5-win32-latest.zip


 [2005-02-11 11:51 UTC] per at computer dot org
OK, I tried php4-STABLE-200502110930.tar.gz, and it appears to have been fixed.  I'd be interested to know what really caused it?  Thanks.
 [2005-02-17 06:31 UTC] sniper@php.net
Are you sure it was PHP 4 ? :)
I asked you to try the latest HEAD (PHP 5.1-dev)..
If it really was the PHP 4 snapshot, I must ask you to try again the current one: 
 
  http://snaps.php.net/php4-STABLE-latest.tar.gz

If the bug appears again with this snapshot, I'll have pretty good idea what fixes it.


 [2005-02-17 13:32 UTC] per at computer dot org
Um, well ... :-)
It was php4-STABLE-200502110930, and I've just now tried php4-STABLE-200502170730 - also works fine.  If need be, I can try out 5.1-dev too.
 [2005-04-16 08:30 UTC] per at computer dot org
I've tested this again with 4.3.11 and it appears to have been fixed.  I'd be interested to know what really happened.
 [2005-04-18 15:18 UTC] sniper@php.net
So do we, so do we..:) As long as it works -> closed.

 
PHP Copyright © 2001-2024 The PHP Group
All rights reserved.
Last updated: Thu Oct 17 10:01:28 2024 UTC