Thank you for this bug report. To properly diagnose the problem, we
need a backtrace to see what is happening behind the scenes. To
find out how to generate a backtrace, please read
http://bugs.php.net/bugs-generating-backtrace.php

Once you have generated a backtrace, please submit it to this bug
report and change the status back to "Open". Thank you for helping
us make PHP better.

Backtrace for Apache 1.3.27 and PHP 4.3.0RC2:

Program received signal SIGSEGV, Segmentation fault.
0x42073d65 in _int_malloc () from /lib/i686/libc.so.6
(gdb) where
#0  0x42073d65 in _int_malloc () from /lib/i686/libc.so.6
#1  0x42073155 in malloc () from /lib/i686/libc.so.6
#2  0x402bda44 in pqResultAlloc () from /usr/lib/libpq.so.2
#3  0x402be3d5 in getRowDescriptions () from /usr/lib/libpq.so.2
#4  0x402be2f1 in parseInput () from /usr/lib/libpq.so.2
#5  0x402be970 in PQgetResult () from /usr/lib/libpq.so.2
#6  0x402bea78 in PQexec () from /usr/lib/libpq.so.2
#7  0x40251626 in zif_pg_query (ht=135421720, return_value=0x812593c, 
    this_ptr=0x0, return_value_used=1)
    at /home/dfs/canit-3rdparty-builds/php-4.3.0RC2/ext/pgsql/pgsql.c:931
#8  0x40201692 in execute (op_array=0x80f1e54)
    at /home/dfs/canit-3rdparty-builds/php-4.3.0RC2/Zend/zend_execute.c:1596
#9  0x40201433 in execute (op_array=0x80f3a84)
    at /home/dfs/canit-3rdparty-builds/php-4.3.0RC2/Zend/zend_execute.c:1640
#10 0x40201433 in execute (op_array=0x80b0d40)
    at /home/dfs/canit-3rdparty-builds/php-4.3.0RC2/Zend/zend_execute.c:1640
#11 0x40201433 in execute (op_array=0x80a36a0)
    at /home/dfs/canit-3rdparty-builds/php-4.3.0RC2/Zend/zend_execute.c:1640
#12 0x40201433 in execute (op_array=0x80a8a24)
    at /home/dfs/canit-3rdparty-builds/php-4.3.0RC2/Zend/zend_execute.c:1640
#13 0x401f4fdd in zend_execute_scripts (type=8, retval=0x0, file_count=3)
    at /home/dfs/canit-3rdparty-builds/php-4.3.0RC2/Zend/zend.c:864
#14 0x401d09d4 in php_execute_script (primary_file=0xbffff530)
---Type <return> to continue, or q <return> to quit--- 
    at /home/dfs/canit-3rdparty-builds/php-4.3.0RC2/main/main.c:1549
#15 0x4020525e in apache_php_module_main (r=0x8099974, display_source_mode=0)
    at /home/dfs/canit-3rdparty-builds/php-4.3.0RC2/sapi/apache/sapi_apache.c:55
#16 0x40205c25 in send_php (r=0x8099974, display_source_mode=0, filename=0x0)
    at /home/dfs/canit-3rdparty-builds/php-4.3.0RC2/sapi/apache/mod_php4.c:556
#17 0x40205dba in send_parsed_php (r=0x8099974)
    at /home/dfs/canit-3rdparty-builds/php-4.3.0RC2/sapi/apache/mod_php4.c:571
#18 0x40022174 in ap_invoke_handler (r=0x8099974) at http_config.c:518
#19 0x40038477 in hypot () at http_request.c:1308
#20 0x400384e9 in ap_process_request (r=0x8099974) at http_request.c:1324
#21 0x4002ee39 in child_main (child_num_arg=0) at http_main.c:4603
#22 0x4002eff8 in make_child (s=0x804b7bc, slot=0, now=1039610873)
    at http_main.c:4718
#23 0x4002f182 in startup_children (number_to_start=5) at http_main.c:4800
#24 0x4002f838 in standalone_main (argc=2, argv=0xbffff9b4) at http_main.c:5108
#25 0x40030100 in ap_main (argc=2, argv=0xbffff9b4) at http_main.c:5456
#26 0x080485b3 in ?? ()
#27 0x420158d4 in __libc_start_main () from /lib/i686/libc.so.6

Sorry, but your problem does not imply a bug in PHP itself.  For a
list of more appropriate places to ask for help using PHP, please
visit http://www.php.net/support.php as this bug system is not the
appropriate forum for asking support questions. 

Thank you for your interest in PHP.

The crash is the fault of PostgreSQL and not that of PHP.

I disagree.  The bug *IS* in PHP, not libpq.  The reason I assert this is as follows:

- I tried Apache 1.3.27, 2.0.40 and 2.0.43 with libraries from PostgreSQL 7.2.2, 7.2.3 and 7.3, and PHP 4.2.2, 4.2.3 and PHP 4.3.0RC2.  ALL combinations crashed reliably.

With PHP 4.1.2, I am *unable* to get a crash.  Something in PHP is corrupting memory, and later on, malloc() is failing.  I use the same libpq library with Perl and Tcl, and have never yet had a segfault.

For more info, here's a stack trace for Red Hat 8.0 with Red Hat's version of Apache (2.0.40) and Red Hat's PHP (4.2.2).

Program received signal SIGSEGV, Segmentation fault.
[Switching to Thread 8192 (LWP 3305)]
0x42073d65 in _int_malloc () from /lib/i686/libc.so.6
(gdb) bt
#0  0x42073d65 in _int_malloc () from /lib/i686/libc.so.6
#1  0x42073155 in malloc () from /lib/i686/libc.so.6
#2  0x4051881b in completed.1 () from /etc/httpd/modules/libphp4.so
#3  0x405c5cb1 in completed.1 () from /etc/httpd/modules/libphp4.so
#4  0x405c5fe1 in completed.1 () from /etc/httpd/modules/libphp4.so
#5  0x405c615e in completed.1 () from /etc/httpd/modules/libphp4.so
#6  0x40522efc in completed.1 () from /etc/httpd/modules/libphp4.so
#7  0x40522c6d in completed.1 () from /etc/httpd/modules/libphp4.so
#8  0x40522c6d in completed.1 () from /etc/httpd/modules/libphp4.so
#9  0x40522c6d in completed.1 () from /etc/httpd/modules/libphp4.so
#10 0x4052f6b6 in completed.1 () from /etc/httpd/modules/libphp4.so
#11 0x4053df7a in completed.1 () from /etc/httpd/modules/libphp4.so
#12 0x4053a7bd in completed.1 () from /etc/httpd/modules/libphp4.so
#13 0x0807169c in ap_pass_brigade ()
#14 0x08078e27 in default_handler ()
#15 0x08065bf5 in ap_run_handler ()
#16 0x0806620d in ap_invoke_handler ()
#17 0x080629c6 in ap_process_request ()
#18 0x0805e0ac in ap_process_http_connection ()
#19 0x0806f0d5 in ap_run_process_connection ()
#20 0x08064238 in child_main ()
#21 0x0806445a in make_child ()
#22 0x080644b6 in startup_children ()
#23 0x08064cdf in ap_mpm_run ()
#24 0x0806ac5f in main ()
#25 0x420158d4 in __libc_start_main () from /lib/i686/libc.so.6

It crashs with PHP 4.2.2 because it runs in Apache 2.

The PSQL lib ist most probably not thread safe.

Then how do you explain the crash in Apache 1.3.27?  It is a PHP bug for sure, because changing PHP versions is the only thing which makes it go away.

Uhmm I should read better...

What versions of libpq do you use with 4.1.2 and 4.2.x?

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.

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.)

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.

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

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.)

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

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

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.

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.

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.

I still can't get it to crash here though, even with your configure line and scripts. Valgrind doesn't report anything either. 

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.

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

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.

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");
}

?>

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

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.