ID:               20927
 Updated by:       [EMAIL PROTECTED]
 Reported By:      [EMAIL PROTECTED]
-Status:           Assigned
+Status:           Closed
 Bug Type:         Strings related
 Operating System: Red Hat Linux 8.0 on Intel
 PHP Version:      4.3.0RC3
 Assigned To:      derick
 New Comment:

This bug has been fixed in CVS.

In case this was a PHP problem, 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/.
 
In case this was a documentation problem, the fix will show up soon at
http://www.php.net/manual/.

In case this was a PHP.net website problem, the change will show
up on the PHP.net site and on the mirror sites in short time.
 
Thank you for the report, and for helping us make PHP better.




Previous Comments:
------------------------------------------------------------------------

[2002-12-12 00:24:30] [EMAIL PROTECTED]

Okay, now I could verify this (with 4.3.0RC3). Going to fix this
soonish.

------------------------------------------------------------------------

[2002-12-11 20:15:23] [EMAIL PROTECTED]

A more dramatic example:  The following script, under PHP 4.1.2,
prints:

Length of original string:  130
Length of break string:     11264
Length of wrapped string:   214127
Size allocated by 4.3.0RC2: 173596
BUFFER OVERFLOW by 40531 bytes!

With 4.3.0RC2, it segfaults.

--
David.

<?php
$part = "1234567890 X ";
$string = "";
for ($i=0; $i<10; $i++) {
    $string .= $part;
}

$break = "a-very-long-break-string-to-clobber-the-heap";
for ($i=0; $i<8; $i++) {
    $break .= $break;
}

$linelength = 10;
$wrapped = wordwrap($string, $linelength, $break, 1);

$textlen = strlen($string);
print("Length of original string:  $textlen\n");
$breakcharlen = strlen($break);
print("Length of break string:     $breakcharlen\n");
$newtextlen = strlen($wrapped);
print("Length of wrapped string:   $newtextlen\n");

$buffer = $textlen +
          intval(($textlen/$linelength + 1) * $breakcharlen * 1.1) +
1;

print("Size allocated by 4.3.0RC2: $buffer\n");
$overflow = $newtextlen - $buffer;
if ($overflow > 0) {
    print ("BUFFER OVERFLOW by $overflow bytes!\n");
}

?>

------------------------------------------------------------------------

[2002-12-11 15:01:15] [EMAIL PROTECTED]

Ah, the bug might not show up on Red Hat 7.1, probably because of glibc
differences.  Anyway, here's my system:

$ gcc -v
Reading specs from /usr/lib/gcc-lib/i386-redhat-linux/3.2/specs
Configured with: ../configure --prefix=/usr --mandir=/usr/share/man
--infodir=/usr/share/info --enable-shared --enable-threads=posix
--disable-checking --host=i386-redhat-linux --with-system-zlib
--enable-__cxa_atexit
Thread model: posix
gcc version 3.2 20020903 (Red Hat Linux 8.0 3.2-7)

$ ldd /usr/local/bin/php
        libcrypt.so.1 => /lib/libcrypt.so.1 (0x4002f000)
        libresolv.so.2 => /lib/libresolv.so.2 (0x4005d000)
        libm.so.6 => /lib/i686/libm.so.6 (0x4006f000)
        libdl.so.2 => /lib/libdl.so.2 (0x40091000)
        libnsl.so.1 => /lib/libnsl.so.1 (0x40094000)
        libc.so.6 => /lib/i686/libc.so.6 (0x42000000)
        /lib/ld-linux.so.2 => /lib/ld-linux.so.2 (0x40000000)

$ rpm -q glibc
glibc-2.2.93-5

Regards,

David.

------------------------------------------------------------------------

[2002-12-11 14:52:13] [EMAIL PROTECTED]

I'm running RedHat 7.1, and the last script still doesn't crash for me,
and no output from valgrind at all...

gcc = 2.96 (stock redhat 7.1)

What is your gcc version?

Derick

------------------------------------------------------------------------

[2002-12-11 14:43:18] [EMAIL PROTECTED]

Are you running on Red Hat 8.0?

I consistently get a crash.  It's also obvious that the buffer
allocated is 135 bytes, and the length of the wrapped string is 138. 
So if you're not getting a crash, it's just luck.  Try this script
instead:

<?php
$x = "ADV:CLAIM YOUR FORTUNE NOW !!MAKE";
$x .= " xxxxxxxxxxHUNDREDS OF THOUSANDSxxxxxxxxxxxx";
$b = "CANITBREAKFOO";
for ($i=0; $i<1000; $i++) {
  $y = wordwrap($x, 20, $b, 1);
}
?>

That should exercise malloc() a lot more.

------------------------------------------------------------------------

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

Reply via email to