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

ID: 28006 User updated by: per at computer dot org Reported By: per at computer dot org -Status: Feedback +Status: Open Bug Type: Reproducible crash Operating System: linux, kernel 2.4.24 PHP Version: 4.3.4 New Comment: Here's the backtrace when doing the same thing with php4-STABLE-200404151030 (gdb) run -X -f /etc/httpd/httpd.conf Starting program: /usr/bin/httpd -X -f /etc/httpd/ httpd.conf [New Thread 16384 (LWP 18823)] [Thu Apr 15 16:35:42 2004] [warn] module php4_module is already loaded, skipping Program received signal SIGSEGV, Segmentation fault. [Switching to Thread 16384 (LWP 18823)] 0x40578b32 in zend_get_executed_lineno () at /usr/src/ packages/SOURCES/php4-STABLE-200404151030/Zend/ zend_execute_API.c:271 271 return active_opline->lineno; (gdb) bt #0 0x40578b32 in zend_get_executed_lineno () at /usr/src/ packages/SOURCES/php4-STABLE-200404151030/Zend/ zend_execute_API.c:271 #1 0x405811bd in zend_error (type=8, format=0x40709bff "Undefined index: %s") at /usr/src/packages/SOURCES/ php4-STABLE-200404151030/Zend/zend.c:733 #2 0x40593a80 in zend_fetch_dimension_address_inner (ht=0x81d2d2c, op2=0x8226540, Ts=0xbfffaa7c, type=0) at / usr/src/packages/SOURCES/php4-STABLE-200404151030/Zend/ zend_execute.c:645 #3 0x4058cba0 in zend_fetch_dimension_address (result=0x8226520, op1=0x82061bc, op2=0x8226540, Ts=0xbfffaa7c, type=0) at /usr/src/packages/SOURCES/ php4-STABLE-200404151030/Zend/zend_execute.c:801 #4 0x40591dbe in execute (op_array=0x81e932c) at /usr/src/ packages/SOURCES/php4-STABLE-200404151030/Zend/ zend_execute.c:1297 #5 0x4058130b in zend_execute_scripts (type=8, retval=0x0, file_count=3) at /usr/src/packages/SOURCES/ php4-STABLE-200404151030/Zend/zend.c:886 #6 0x40554fcf in php_execute_script (primary_file=0xbffff3f0) at /usr/src/packages/SOURCES/ php4-STABLE-200404151030/main/main.c:1731 #7 0x40594ae4 in php_handler (r=0x81c17e8) at /usr/src/ packages/SOURCES/php4-STABLE-200404151030/sapi/ apache2handler/sapi_apache2.c:561 #8 0x08092d85 in ap_run_handler (r=0x81c17e8) at config.c:151 #9 0x08093390 in ap_invoke_handler (r=0x81c17e8) at config.c:358 #10 0x08076edb in ap_process_request (r=0x81c17e8) at http_request.c:246 #11 0x0807239d in ap_process_http_connection (c=0x81b4fd8) at http_core.c:250 #12 0x0809de25 in ap_run_process_connection (c=0x81b4fd8) at connection.c:42 #13 0x08091384 in child_main (child_num_arg=148) 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=0xbffff764) at main.c:617 Previous Comments: ------------------------------------------------------------------------ [2004-04-15 07:44:25] nlopess@php.net Please try using this CVS snapshot: http://snaps.php.net/php4-STABLE-latest.tar.gz For Windows: http://snaps.php.net/win32/php4-win32-STABLE-latest.zip ------------------------------------------------------------------------ [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