php.net |  support |  documentation |  report a bug |  advanced search |  search howto |  statistics |  random bug |  login
Bug #28839 SIGSEGV in interactive mode (php -a)
Submitted: 2004-06-18 23:23 UTC Modified: 2005-03-26 03:44 UTC
Votes:3
Avg. Score:3.0 ± 0.8
Reproduced:3 of 3 (100.0%)
Same Version:0 (0.0%)
Same OS:1 (33.3%)
From: curt@php.net Assigned:
Status: Closed Package: CGI/CLI related
PHP Version: 5CVS-2005-03-06 OS: *
Private report: No CVE-ID: None
 [2004-06-18 23:23 UTC] curt@php.net
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 ()



Patches

Pull Requests

History

AllCommentsChangesGit/SVN commitsRelated reports
 [2004-12-18 23:17 UTC] 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.
 [2005-03-09 00:43 UTC] sniper@php.net
See also bug #32229 and bug #30513
 [2005-03-18 11:41 UTC] 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-26 03:44 UTC] sniper@php.net
This bug has been fixed in CVS.

Snapshots of the sources are packaged every three hours; this change
will be in the next snapshot. You can grab the snapshot at
http://snaps.php.net/.
 
Thank you for the report, and for helping us make PHP better.


 
PHP Copyright © 2001-2024 The PHP Group
All rights reserved.
Last updated: Mon Dec 30 14:01:28 2024 UTC