ID: 28839 Comment by: kameshj at fastmail dot fm Reported By: [EMAIL PROTECTED] Status: Verified Bug Type: CGI related Operating System: * PHP Version: 5CVS-2005-03-06 New Comment:
Patch is available at. http://puggy.symonds.net/~kameshj/zend_execute_API.c.5.1.head.patch http://puggy.symonds.net/~kameshj/zend_execute_API.c.patch.5.0.x Previous Comments: ------------------------------------------------------------------------ [2005-03-18 11:41:23] kameshj at fastmail dot fm In case of interactive mode the for ZEND_JMP op1.u.jmp_addr is not evaluated, it still has the relative diff from the current opcode. for ZEND_JMP, ZEND_JMPNZ, ZEND_JMPZ_EX, ZEND_JMPNZ_EX op2.u.jmp_addr is not evaluated, it still has the relative diff from the current opcode. This normally happens from pass_two. I am attaching the patch which does this jmp_addr evaluation. This patch is against php-5.0.4-dev-RC[2]. http://puggy.symonds.net/~kameshj/zend_execute_API.c.patch ------------------------------------------------------------------------ [2005-03-09 00:43:55] [EMAIL PROTECTED] See also bug #32229 and bug #30513 ------------------------------------------------------------------------ [2004-12-18 23:17:24] samalone at llamagraphics dot com I think I've tracked this bug down to a logic error in the function pass_two() in zend_opcode.c, but I'm not familiar enough with the code to know the correct fix. My particular case is with PHP 5.0.3 under FreeBSD 4.7. The bug is that pass_two() is not adjusting op_array->start_op after calling erealloc on op_array->opcodes. If erealloc returns a pointer to a different chunk of memory, op_array->start_op is left pointing into the old memory block which has just been freed. Later code attempts to execute the opcodes starting at op_array->start_op. Of course, whether this bug results in a crash or not depends on the behavior of the memory allocator. I'm uncertain whether op_array->start_op should be set to NULL in this function, or set to the same relative location in the opcodes array. I'm guessing the latter, since this would mimic the behavior on systems where erealloc simply returns the same chunk of memory. ------------------------------------------------------------------------ [2004-06-18 23:23:13] [EMAIL PROTECTED] Description: ------------ This problem only occurs when php is ran in in interactive mode, it works perfectly fine from a script. Reproduce code: --------------- php -a <?php $k = 1 || 2; Expected result: ---------------- no crash Actual result: -------------- run -a <?php $k = 1 or 2; Program received signal SIGSEGV, Segmentation fault. 0x0826aa87 in execute (op_array=0x83c2c6c) <?php $k = 1||2; Program received signal SIGSEGV, Segmentation fault. 0x0826aa97 in execute (op_array=0x83c2c6c) at /xxx/cvs/php/php-src/Zend/zend_execute.c:1389 1389 if (EX(opline)->handler(&execute_data, EX(opline), op_array TSRMLS_CC)) { (gdb) bt #0 0x0826aa97 in execute (op_array=0x83c2c6c) at /xxx/cvs/php/php-src/Zend/zend_execute.c:1389 #1 0x0823ba64 in execute_new_code () at /xxx/cvs/php/php-src/Zend/zend_execute_API.c:1069 #2 0x08220598 in zendparse () at /xxx/cvs/php/php-src/Zend/zend_language_parser.y:153 #3 0x082246e2 in compile_file (file_handle=0xbfbfe5c0, type=2) at /xxx/cvs/php/php-src/Zend/zend_language_scanner.l:374 #4 0x082472b0 in zend_execute_scripts (type=8, retval=0x0, file_count=3) at /xxx/cvs/php/php-src/Zend/zend.c:1057 #5 0x0820172b in php_execute_script (primary_file=0xbfbfe5c0) at /xxx/cvs/php/php-src/main/main.c:1627 #6 0x08277fb1 in main (argc=2, argv=0xbfbfe630) at /xxx/cvs/php/php-src/sapi/cli/php_cli.c:943 #7 0x08084632 in _start () ------------------------------------------------------------------------ -- Edit this bug report at http://bugs.php.net/?id=28839&edit=1
