ID:               20927
 User 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:

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);
?>


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

[2002-12-11 13:31:49] [EMAIL PROTECTED]

The word wrap parameters are in the tar file on my Web site.  I do not
know how you will duplicate the problem unless you have PostgreSQL.

Anyway, the script which segfaults:

$str = htmlentities(wordwrap($str, 20, "CANITBREAKFOO", 1));

The one which works OK:

$str = htmlentities(wordwrap($str, 21, "CANITBREAKFOO", 1));

In both cases, the original value of $str is as follows:

"ADV:CLAIM YOUR FORTUNE NOW !!MAKE xxxxxxxxxxHUNDREDS OF
THOUSANDSxxxxxxxxxxxx"

On one line (total 77 characters in length.)

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

[2002-12-11 13:24:41] [EMAIL PROTECTED]

It would really help me if you could give me the parameters to wordwrap
on which you get this error, I dont have postgres here so I can't try
your script.

Derick

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

[2002-12-11 12:57:43] [EMAIL PROTECTED]

More insight, and something very useful:  The bug is in the "wordwrap"
function.

Please see http://www.roaringpenguin.com/segfault2.tar.bz2
There are two PHP scripts:  One crashes PHP when run from the command
line, and the other works fine.  The only difference between the two is
a change in the argument to wordwrap().

Also, I ran valgrind on the standalone PHP executable, and here is its
report.

Hope all of this helps!

Regards,

David.


==7690== ERROR SUMMARY: 138 errors from 5 contexts (suppressed: 38 from
1)
==7690== 
==7690== 1 errors in context 1 of 5:
==7690== Invalid write of size 1
==7690==    at 0x80FF654: zif_wordwrap (in /usr/bin/php)
==7690==    by 0x8152F6C: execute (in /usr/bin/php)
==7690==    by 0x8152CDD: execute (in /usr/bin/php)
==7690==    by 0x8152CDD: execute (in /usr/bin/php)
==7690==    Address 0x44DA1882 is 2 bytes after a block of size 148
alloc'd
==7690==    at 0x4003BA4E: malloc (vg_clientfuncs.c:100)
==7690==    by 0x812A9AB: _emalloc (in /usr/bin/php)
==7690==    by 0x80FF585: zif_wordwrap (in /usr/bin/php)
==7690==    by 0x8152F6C: execute (in /usr/bin/php)
==7690== 
==7690== 1 errors in context 2 of 5:
==7690== Invalid write of size 1
==7690==    at 0x4003C395: memcpy (vg_clientfuncs.c:503)
==7690==    by 0x80FF64E: zif_wordwrap (in /usr/bin/php)
==7690==    by 0x8152F6C: execute (in /usr/bin/php)
==7690==    by 0x8152CDD: execute (in /usr/bin/php)
==7690==    Address 0x44DA1881 is 1 bytes after a block of size 148
alloc'd
==7690==    at 0x4003BA4E: malloc (vg_clientfuncs.c:100)
==7690==    by 0x812A9AB: _emalloc (in /usr/bin/php)
==7690==    by 0x80FF585: zif_wordwrap (in /usr/bin/php)
==7690==    by 0x8152F6C: execute (in /usr/bin/php)
==7690== 
==7690== 1 errors in context 3 of 5:
==7690== Invalid write of size 1
==7690==    at 0x4003C36F: memcpy (vg_clientfuncs.c:496)
==7690==    by 0x80FF711: zif_wordwrap (in /usr/bin/php)
==7690==    by 0x8152F6C: execute (in /usr/bin/php)
==7690==    by 0x8152CDD: execute (in /usr/bin/php)
==7690==    Address 0x44DA1880 is 0 bytes after a block of size 148
alloc'd
==7690==    at 0x4003BA4E: malloc (vg_clientfuncs.c:100)
==7690==    by 0x812A9AB: _emalloc (in /usr/bin/php)
==7690==    by 0x80FF585: zif_wordwrap (in /usr/bin/php)
==7690==    by 0x8152F6C: execute (in /usr/bin/php)
==7690== 
==7690== 2 errors in context 4 of 5:
==7690== Invalid read of size 1
==7690==    at 0x80EE4ED: get_next_char (in /usr/bin/php)
==7690==    by 0x80EDDAE: php_escape_html_entities (in /usr/bin/php)
==7690==    by 0x80EE081: php_html_entities (in /usr/bin/php)
==7690==    by 0x80EE1FE: zif_htmlentities (in /usr/bin/php)
==7690==    Address 0x44DA1880 is 0 bytes after a block of size 148
alloc'd
==7690==    at 0x4003BA4E: malloc (vg_clientfuncs.c:100)
==7690==    by 0x812A9AB: _emalloc (in /usr/bin/php)
==7690==    by 0x80FF585: zif_wordwrap (in /usr/bin/php)
==7690==    by 0x8152F6C: execute (in /usr/bin/php)
==7690== 
==7690== 133 errors in context 5 of 5:
==7690== Conditional jump or move depends on uninitialised value(s)
==7690==    at 0x420BD30B: (within /lib/i686/libc-2.2.93.so)
==7690==    by 0x420C2DF5: (within /lib/i686/libc-2.2.93.so)
==7690==    by 0x80FCD16: php_reg_replace (in /usr/bin/php)
==7690==    by 0x80FD1A8: php_ereg_replace (in /usr/bin/php)
--7690-- 
--7690-- supp:   38 elf_dynamic_do_rela.8/_dl_relocate_object_internal
==7690== 
==7690== IN SUMMARY: 138 errors from 5 contexts (suppressed: 38 from
1)
==7690== 
==7690== malloc/free: in use at exit: 161328 bytes in 4866 blocks.
==7690== malloc/free: 31375 allocs, 26509 frees, 3488507 bytes
allocated.
==7690== For a detailed leak analysis,  rerun with: --leak-check=yes
==7690== 
--7690--       lru: 502 epochs, 0 clearings.
--7690-- translate: new 18262 (318370 -> 3436773), discard 3318 (51606
-> 539831).
--7690--  dispatch: 25100000 basic blocks, 504/89826 sched events,
32379 tt_fast misses.
--7690-- reg-alloc: 5534 t-req-spill, 642096+38688 orig+spill uis,
91926 total-reg-r.
--7690--    sanity: 505 cheap, 21 expensive checks.

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

[2002-12-11 12:38:06] [EMAIL PROTECTED]

More info:

Under Solaris 8 on SPARC, Apache 1.3.27 and PHP 4.2.3, it works fine. 
Probably, Solaris's libc has different malloc strategy so the bug is
not triggered.

I recompiled Apache, PHP and libpq so everything was statically linked
in a single http executable.  Segfaulted.  Ran it under valgrind
(http://developer.kde.org/~sewardj/) and it worked perfectly. :-(

Next, converted the script to a CGI, and installed stand-alone versions
of php-4.2.3 and php-4.1.2.  The cgi crashed with php-4.2.3, but worked
fine with php-4.1.2.  (Same Apache server in each case.)

Therefore, I believe this is a hard-to-find memory corruption bug. :-(

(To do the CGI test, copy showtrap.php to showtrap.cgi and add the
appropriate #! line at the beginning, fix permissions, etc.)

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

[2002-12-11 10:36:28] [EMAIL PROTECTED]

Hi,

I've tried the following versions of libpq:

7.2.2
7.2.3
7.3.0

They all exhibit the same behaviour.  The default version that comes
with RH8.0 is 7.2.2.

Thanks,

David.

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

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