ID: 20927
Updated by: [EMAIL PROTECTED]
Reported By: [EMAIL PROTECTED]
Status: Open
Bug Type: Strings related
Operating System: Red Hat Linux 8.0 on Intel
PHP Version: 4.3.0RC2
Assigned To: derick
New Comment:
I still can't get it to crash here though, even with your configure
line and scripts. Valgrind doesn't report anything either.
Previous Comments:
------------------------------------------------------------------------
[2002-12-11 14:37:12] [EMAIL PROTECTED]
One more thing and then I'll shut up. :-)
Rather than allocating space to begin with, why not use something like
Tcl's Dynamic Strings, which let you grow the buffer as required? Then
you can just call dstring_append and not worry about space.
Regards,
David.
------------------------------------------------------------------------
[2002-12-11 14:35:20] [EMAIL PROTECTED]
4.3.0RC2 still crashes; the "10-percent-extra-space" hack fails. :-)
Stepping through the code, by line 674 of string.c, we have:
textlen = 77
linelength = 20
breakcharlen = 13
docut = 1
and line 674 computes newtextlen as 135. Unfortunately, under PHP
4.1.2, which works correctly, the length of the final string is 138
characters long, and you have a buffer overflow. :-) Test it if you
don't believe me.
The problem seems to be that the break string itself is being counted
to determine whether or not to break the line.
Here's the output from 4.1.2 (hard to see clearly...)
ADV:CLAIM YOURCANITBREAKFOOFORTUNE NOW
!!MAKECANITBREAKFOOxxxxxxxxxxHUNDREDSCANITBREAKFOOOFCANITBREAKFOOTHOUSANDSxxxxxxxxxxxCANITBREAKFOOx
Note the two breaks very close together around the word "OF"? This
yielded 5 breaks instead of the maximum 4 which the code assumes, and
the break string was long enough to frustrate the "10% overhead"
method.
You really need to be extremely conservative when allocating space;
assume that there can be as many breaks added as there are characters
in the original string. For most cases, with short break strings, this
won't lead to too much over-allocation, and it will fix the problem.
--
David.
------------------------------------------------------------------------
[2002-12-11 14:15:54] [EMAIL PROTECTED]
It DOES crash with 4.30RC2:
I built 4.30RC2 with this configuration:
./configure --with-pgsql=shared \
--with-gnu-ld \
--with-apxs=/usr/local/apache/bin/apxs
I then installed it and ran the command-line version:
$ /usr/local/bin/php -v
PHP 4.3.0RC2 (cli) (built: Dec 10 2002 19:58:29)
Copyright (c) 1997-2002 The PHP Group
Zend Engine v1.4.0, Copyright (c) 1998-2002 Zend Technologies
$ /usr/local/bin/php test-wrap.php
Segmentation fault
$ /usr/local/bin/php test-wrap2.php
(no output, but no segfault)
Please don't accuse me of wasting your time without reading ALL of my
comments... I said that 4.2.2, 4.2.3 and 4.3.0RC2 behave the same.
--
David.
------------------------------------------------------------------------
[2002-12-11 14:06:24] [EMAIL PROTECTED]
ARGH!
Why did you fill in 4.3.0RC2 as version number if you're talking about
PHP 4.2.2? You just wasted my time trying to hunt down a bug that's
already fixed. Indeed, this crashes with PHP 4.2.2 but not with
4.3.0RC2 and RC3.
Derick
------------------------------------------------------------------------
[2002-12-11 13:58:46] [EMAIL PROTECTED]
Scripts which duplicate the problem without PostgreSQL:
This script crashes PHP 4.2.2 from Red Hat:
<?php
$x = "ADV:CLAIM YOUR FORTUNE NOW !!MAKE";
$x .= " xxxxxxxxxxHUNDREDS OF THOUSANDSxxxxxxxxxxxx";
$b = "CANITBREAKFOO";
$x = wordwrap($x, 20, $b, 1);
$x = wordwrap($x, 20, $b, 1);
?>
This script works just fine:
<?php
$x = "ADV:CLAIM YOUR FORTUNE NOW !!MAKE";
$x .= " xxxxxxxxxxHUNDREDS OF THOUSANDSxxxxxxxxxxxx";
$b = "CANITBREAKFOO";
$x = wordwrap($x, 21, $b, 1);
$x = wordwrap($x, 21, $b, 1);
?>
------------------------------------------------------------------------
The remainder of the comments for this report are too long. To view
the rest of the comments, please view the bug report online at
http://bugs.php.net/20927
--
Edit this bug report at http://bugs.php.net/?id=20927&edit=1
