#28006 [Opn->Fbk]: referencing an unset global produces a segfault

ID: 28006 Updated by: sniper@php.net Reported By: per at computer dot org -Status: Open +Status: Feedback Bug Type: Reproducible crash Operating System: linux, kernel 2.4.26 PHP Version: 4.3.10RC2 New Comment: 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() ?? Previous Comments: ------------------------------------------------------------------------ [2004-07-12 13:15:32] 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-04-15 07:36:22] 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 ------------------------------------------------------------------------ -- Edit this bug report at http://bugs.php.net/?id=28006&edit=1