|  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
Avg. Score:3.0 ± 0.8
Reproduced:3 of 3 (100.0%)
Same Version:0 (0.0%)
Same OS:1 (33.3%)
From: 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]
This problem only occurs when php is ran in in interactive mode, it works perfectly fine from a script.

Reproduce code:
php -a
$k = 1 || 2;

Expected result:
no crash

Actual result:
run -a
$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 ()


Add a Patch

Pull Requests

Add a Pull Request


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]
See also bug #32229 and bug #30513
 [2005-03-18 11:41 UTC] kameshj at fastmail dot fm
In case of interactive mode the 
op1.u.jmp_addr is not evaluated, it still has the relative diff from the current opcode.

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].
 [2005-03-26 03:44 UTC]
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
Thank you for the report, and for helping us make PHP better.

PHP Copyright © 2001-2022 The PHP Group
All rights reserved.
Last updated: Tue Jul 05 06:05:45 2022 UTC