#20927 [NEW]: Crash inside libpq (PQexec) with PHP > 4.1.2
From: [EMAIL PROTECTED] Operating system: Red Hat Linux 8.0 on Intel PHP version: 4.3.0RC2 PHP Bug Type: Reproducible crash Bug description: Crash inside libpq (PQexec) with PHP > 4.1.2 This is difficult (impossible) to reproduce with a short script. Please download and unpack http://www.roaringpenguin.com/segfault.tar.bz2 You need to have PostgreSQL and create a specific database with specific data in it. Here's the README file from the tarball: SUMMARY: PHP segfaults for PHP versions > 4.1.2 --- THE SOURCE FILES IN THIS ARCHIVE ARE PROPRIETARY COMMERCIAL SOFTWARE. PLEASE USE THEM ONLY TO DEBUG PHP PROBLEMS. System: Red Hat Linux 8.0 PostgreSQL: 7.2.2, as supplied with Red Hat Linux 8.0 Apache: 1.3.27, configured as follows: ./configure --with-layout=Apache --enable-shared=max \ --enable-rule=SHARED_CORE PHP: Tried 4.2.2, 4.2.3 and 4.3.0RC2, all configured as follows: ./configure --with-pgsql=shared \ --with-gnu-ld \ --with-apxs=/usr/local/apache/bin/apxs HOW TO REPRODUCE: - 1) Install Apache 1.3.27 and PHP 4.2.2, 4.2.3 or 4.3.0RC2 from source. Configure PostgreSQL 7.2.2 to trust local connections. That is, in /var/lib/pgsql/data/pg_hba.conf, make the local line read thus: local all trust 2) Create and populate the database: createdb -U postgres spam psql -U postgres -d spam < spam-database-dump 3) Copy the PHP files to your document root somewhere convenient. 4) Browse http://your_server/these_php_files/index.php 5) Log in as "admin", password "foo" 6) Click on "Pending Messages" - Apache will segfault. However: Using PHP 4.1.2, configured as above, it works fine. Extensive investigation shows that it's segfaulting inside libpq, inside PQexec, but the function which segfaults is "malloc" which leads me to believe there's memory corruption going on. -- Edit bug report at http://bugs.php.net/?id=20927&edit=1 -- Try a CVS snapshot: http://bugs.php.net/fix.php?id=20927&r=trysnapshot Fixed in CVS: http://bugs.php.net/fix.php?id=20927&r=fixedcvs Fixed in release: http://bugs.php.net/fix.php?id=20927&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=20927&r=needtrace Try newer version: http://bugs.php.net/fix.php?id=20927&r=oldversion Not developer issue:http://bugs.php.net/fix.php?id=20927&r=support Expected behavior: http://bugs.php.net/fix.php?id=20927&r=notwrong Not enough info:http://bugs.php.net/fix.php?id=20927&r=notenoughinfo Submitted twice:http://bugs.php.net/fix.php?id=20927&r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=20927&r=globals PHP 3 support discontinued: http://bugs.php.net/fix.php?id=20927&r=php3 Daylight Savings: http://bugs.php.net/fix.php?id=20927&r=dst IIS Stability: http://bugs.php.net/fix.php?id=20927&r=isapi
#20927 [Fbk->Opn]: Crash inside libpq (PQexec) with PHP > 4.1.2
ID: 20927 User updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] -Status: Feedback +Status: Open Bug Type: PostgreSQL related Operating System: Red Hat Linux 8.0 on Intel PHP Version: 4.3.0RC2 New Comment: 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=0xb530) ---Type to continue, or q 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=0xb9b4) at http_main.c:5108 #25 0x40030100 in ap_main (argc=2, argv=0xb9b4) at http_main.c:5456 #26 0x080485b3 in ?? () #27 0x420158d4 in __libc_start_main () from /lib/i686/libc.so.6 Previous Comments: [2002-12-11 00:59:23] [EMAIL PROTECTED] 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. [2002-12-10 19:42:59] [EMAIL PROTECTED] This is difficult (impossible) to reproduce with a short script. Please download and unpack http://www.roaringpenguin.com/segfault.tar.bz2 You need to have PostgreSQL and create a specific database with specific data in it. Here's the README file from the tarball: SUMMARY: PHP segfaults for PHP versions > 4.1.2 --- THE SOURCE FILES IN THIS ARCHIVE ARE PROPRIETARY COMMERCIAL SOFTWARE. PLEASE USE THEM ONLY TO DEBUG PHP PROBLEMS. System: Red Hat Linux 8.0 PostgreSQL: 7.2.2, as supplied with Red Hat Linux 8.0 Apache: 1.3.27, configured as follows: ./configure --with-layout=Apache --enable-shared=max \ --enable-rule=SHARED_CORE PHP: Tried 4.2.2, 4.2.3 and 4.3.0RC2, all configured as follows: ./configure --with-pgsql=shared \ --with-gnu-ld \ --with-apxs=/usr/local/apache/bin/apxs HOW TO REPRODUCE: - 1) Install Apache 1.3.27 and PHP 4.2.2, 4.2.3 or 4.3.0RC2 from source. Configure PostgreSQL 7.2.2 to trust local connections. That is, in /var/lib/pgsql/data/pg_hba.conf, make the local line read thus: local
#20927 [Bgs->Opn]: Crash inside libpq (PQexec) with PHP > 4.1.2
ID: 20927
User updated by: [EMAIL PROTECTED]
Reported By: [EMAIL PROTECTED]
-Status: Bogus
+Status: Open
Bug Type: PostgreSQL related
Operating System: Red Hat Linux 8.0 on Intel
PHP Version: 4.3.0RC2
New Comment:
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
Previous Comments:
[2002-12-11 09:17:15] [EMAIL PROTECTED]
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.
[2002-12-11 06:50:18] [EMAIL PROTECTED]
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=0xb530)
---Type to continue, or q 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
#20927 [Bgs->Opn]: Crash inside libpq (PQexec) with PHP > 4.1.2
ID: 20927
User updated by: [EMAIL PROTECTED]
Reported By: [EMAIL PROTECTED]
-Status: Bogus
+Status: Open
Bug Type: PostgreSQL related
Operating System: Red Hat Linux 8.0 on Intel
PHP Version: 4.3.0RC2
New Comment:
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.
Previous Comments:
[2002-12-11 10:32:10] [EMAIL PROTECTED]
It crashs with PHP 4.2.2 because it runs in Apache 2.
The PSQL lib ist most probably not thread safe.
[2002-12-11 09:55:43] [EMAIL PROTECTED]
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
[2002-12-11 09:17:15] [EMAIL PROTECTED]
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.
[2002-12-11 06:50:18] [EMAIL PROTECTED]
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)
#20927 [Fbk->Opn]: Crash inside libpq (PQexec) with PHP > 4.1.2
ID: 20927 User updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] -Status: Feedback +Status: Open Bug Type: PostgreSQL related Operating System: Red Hat Linux 8.0 on Intel PHP Version: 4.3.0RC2 New Comment: 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. Previous Comments: [2002-12-11 10:35:04] [EMAIL PROTECTED] Uhmm I should read better... What versions of libpq do you use with 4.1.2 and 4.2.x? [2002-12-11 10:34:38] [EMAIL PROTECTED] 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. [2002-12-11 10:32:10] [EMAIL PROTECTED] It crashs with PHP 4.2.2 because it runs in Apache 2. The PSQL lib ist most probably not thread safe. [2002-12-11 09:55:43] [EMAIL PROTECTED] 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 [2002-12-11 09:17:15] [EMAIL PROTECTED] 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. 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
#20927 [Opn]: Crash inside libpq (PQexec) with PHP > 4.1.2
ID: 20927 User updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] Status: Open Bug Type: PostgreSQL related Operating System: Red Hat Linux 8.0 on Intel PHP Version: 4.3.0RC2 New Comment: 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.) Previous Comments: [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. [2002-12-11 10:35:04] [EMAIL PROTECTED] Uhmm I should read better... What versions of libpq do you use with 4.1.2 and 4.2.x? [2002-12-11 10:34:38] [EMAIL PROTECTED] 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. [2002-12-11 10:32:10] [EMAIL PROTECTED] It crashs with PHP 4.2.2 because it runs in Apache 2. The PSQL lib ist most probably not thread safe. [2002-12-11 09:55:43] [EMAIL PROTECTED] 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 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
#20927 [Opn]: Crash inside libpq (PQexec) with PHP > 4.1.2 (Actually, culprit is wordwrap)
ID: 20927 User updated by: [EMAIL PROTECTED] -Summary: Crash inside libpq (PQexec) with PHP > 4.1.2 Reported By: [EMAIL PROTECTED] Status: Open -Bug Type: PostgreSQL related +Bug Type: Strings related Operating System: Red Hat Linux 8.0 on Intel PHP Version: 4.3.0RC2 New Comment: 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: 2510 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. Previous Comments: [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 scrip
#20927 [Fbk->Opn]: Crash inside libpq (PQexec) with PHP > 4.1.2 (Actually, culprit is wordwrap)
ID: 20927 User updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] -Status: Feedback +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: 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 xxHUNDREDS OF THOUSANDS" On one line (total 77 characters in length.) Previous Comments: [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== --76
#20927 [Opn]: Crash inside libpq (PQexec) with PHP > 4.1.2 (Actually, culprit is wordwrap)
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: This script works just fine: 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 xxHUNDREDS OF THOUSANDS" 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==
#20927 [Csd->Opn]: Crash inside libpq (PQexec) with PHP > 4.1.2 (Actually, culprit is wordwrap)
ID: 20927 User updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] -Status: Closed +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: 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. Previous Comments: [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: This script works just fine: [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 xxHUNDREDS OF THOUSANDS" 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/p
#20927 [Opn]: Crash inside libpq (PQexec) with PHP > 4.1.2 (Actually, culprit is wordwrap)
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: 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 !!MAKECANITBREAKFOOxxHUNDREDSCANITBREAKFOOOFCANITBREAKFOOTHOUSANDSxxxCANITBREAKFOOx 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. Previous Comments: [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: This script works just fine: [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 xxHUNDREDS OF THOUSANDS" 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 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
#20927 [Opn]: Crash inside libpq (PQexec) with PHP > 4.1.2 (Actually, culprit is wordwrap)
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: 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. Previous Comments: [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 !!MAKECANITBREAKFOOxxHUNDREDSCANITBREAKFOOOFCANITBREAKFOOTHOUSANDSxxxCANITBREAKFOOx 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: This script works just fine: [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 xxHUNDREDS OF THOUSANDS" On one line (total 77 characters in length.) 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
#20927 [Opn]: Crash inside libpq (PQexec) with PHP > 4.1.2 (Actually, culprit is wordwrap)
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: 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: That should exercise malloc() a lot more. Previous Comments: [2002-12-11 14:38:23] [EMAIL PROTECTED] I still can't get it to crash here though, even with your configure line and scripts. Valgrind doesn't report anything either. [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 !!MAKECANITBREAKFOOxxHUNDREDSCANITBREAKFOOOFCANITBREAKFOOTHOUSANDSxxxCANITBREAKFOOx 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 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
#20927 [Opn]: Crash inside libpq (PQexec) with PHP > 4.1.2 (Actually, culprit is wordwrap)
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: 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 (0x4200) /lib/ld-linux.so.2 => /lib/ld-linux.so.2 (0x4000) $ rpm -q glibc glibc-2.2.93-5 Regards, David. Previous Comments: [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: That should exercise malloc() a lot more. [2002-12-11 14:38:23] [EMAIL PROTECTED] I still can't get it to crash here though, even with your configure line and scripts. Valgrind doesn't report anything either. [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 !!MAKECANITBREAKFOOxxHUNDREDSCANITBREAKFOOOFCANITBREAKFOOTHOUSANDSxxxCANITBREAKFOOx 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. 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
#20927 [Opn]: Crash inside libpq (PQexec) with PHP > 4.1.2 (Actually, culprit is wordwrap)
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:
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.
0) {
print ("BUFFER OVERFLOW by $overflow bytes!\n");
}
?>
Previous Comments:
[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 (0x4200)
/lib/ld-linux.so.2 => /lib/ld-linux.so.2 (0x4000)
$ 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:
That should exercise malloc() a lot more.
[2002-12-11 14:38:23] [EMAIL PROTECTED]
I still can't get it to crash here though, even with your configure
line and scripts. Valgrind doesn't report anything either.
[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.
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
