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.26 PHP Version: 4.3.10RC2 New Comment:
php4-STABLE-200501100730: segfault. Let me know if you need any further diagnostics or info. Previous Comments: ------------------------------------------------------------------------ [2005-01-10 01:52:36] [EMAIL PROTECTED] 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-12-13 09:15:15] 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? ------------------------------------------------------------------------ [2004-12-13 00:27:03] [EMAIL PROTECTED] 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-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
