#39115 [Com]: PDO Crashes Apache with null value in Postgres prepared statement
ID: 39115
Comment by: ruben at lingo dot com dot mx
Reported By: opensource at videinfra dot com
Status: No Feedback
Bug Type: PDO related
Operating System: MAC OS X
PHP Version: 5.1.6
New Comment:
I'm getting the same behavior. When PDO->prepare the thread disconnects
from postgresql.
SQLite works fine.
Mac OS X tiger 10.4.11
PHP 5.2.3 compiled from source
Postgresql 8.1.3
I have syck loaded from PECL and some PEAR stuff.
Previous Comments:
[2006-10-18 01:00:00] php-bugs at lists dot php dot net
No feedback was provided for this bug for over a week, so it is
being suspended automatically. If you are able to provide the
information that was originally requested, please do so and change
the status of the bug back to "Open".
[2006-10-10 13:43:35] [EMAIL PROTECTED]
Please try using this CVS snapshot:
http://snaps.php.net/php5.2-latest.tar.gz
For Windows:
http://snaps.php.net/win32/php5.2-win32-latest.zip
[2006-10-10 13:30:45] opensource at videinfra dot com
Description:
Apache2 crashes when call is made to execute prepared
statement with null parameters.
Usign PDO-PostgreSQL
Apache 2.0
PostgreSql 8.1
PHP 5,1.6
Reproduce code:
---
$dbh=new PDO("pgsql:yourdb");
$sth = $dbh->prepare('SELECT * from "table" WHERE "field1"= ? AND
"field2"= ?');
$sth->execute(array(null,null));
Actual result:
--
Crash reporter output:
Thread 7 Crashed:
0 libpq.4.dylib 0x007b161e parseInput + 6
1 libpq.4.dylib 0x007b1eb6 PQgetResult + 31
2 libpq.4.dylib 0x007b2229 PQexecStart + 50
3 libpq.4.dylib 0x007b242d PQexec + 21
4 libphp5.so 0x020f18ab pgsql_stmt_dtor + 111
5 libphp5.so 0x020ed125 free_statement + 214
6 libphp5.so 0x022ebc06
zend_objects_store_free_object_storage + 58
7 libphp5.so 0x022bddce shutdown_executor + 947
8 libphp5.so 0x022cc63d zend_deactivate + 226
9 libphp5.so 0x0227d4db php_request_shutdown +
848
10 libphp5.so 0x0236cbcc php_handler + 2003
11 apache2 0x0001e430 ap_run_handler + 59
(config.c:152)
12 apache2 0x0001e833 ap_invoke_handler + 87
(config.c:366)
13 apache2 0xcb86 ap_process_request + 375
(http_request.c:249)
14 apache2 0x6e1d
ap_process_http_connection + 297 (http_core.c:253)
15 apache2 0x0002ab62 ap_run_process_connection
+ 59 (connection.c:43)
16 apache2 0x0002ae80 ap_process_connection +
69 (connection.c:178)
17 apache2 0x0001b509 worker_thread + 545
(threadpool.c:683)
18 libapr-0.0.dylib0x00715f51 dummy_worker + 22
(thread.c:106)
19 libSystem.B.dylib 0x90023d87 _pthread_body + 84
--
Edit this bug report at http://bugs.php.net/?id=39115&edit=1
#29149 [Com]: CURL extension can't be compiled as shared
ID: 29149 Comment by: ruben at lingo dot com dot mx Reported By: fdsoft at pganet dot com Status: No Feedback Bug Type: Compile Failure Operating System: Mac OS X 10.3.4 PHP Version: 5.0.0 New Comment: Issue still exists. Curl can be compiled into the executable, but --with-curl=shared has no effect. php-5.1.2 Red Hat Enterprise Linux WS release 4 (Nahant) curl-devel-7.12.1-8.rhel4 This is the configuration: ./configure --enable-fastcgi --enable-discard-path --enable-force-redirect --with-gd=shared --with-pgsql=shared --with-mysql=shared --enable-exif=shared --with-zlib-dir=/usr/lib --with-readline=shared --enable-soap=shared --enable-sqlite-utf8 --with-imap=shared --with-kerberos --with-imap-ssl --with-curl=shared Cheers Previous Comments: [2004-12-29 01:00:08] php-bugs at lists dot php dot net No feedback was provided for this bug for over a week, so it is being suspended automatically. If you are able to provide the information that was originally requested, please do so and change the status of the bug back to "Open". [2004-12-21 07:47:13] [EMAIL PROTECTED] Please try using this CVS snapshot: http://snaps.php.net/php5-STABLE-latest.tar.gz For Windows: http://snaps.php.net/win32/php5.0-win32-latest.zip [2004-07-14 15:42:05] fdsoft at pganet dot com Description: I'm running Mac OS X 10.3.4 with curl 7.12.0 installed in /usr/local. PHP 4.3.8's version of the curl extension still compiles OK (as shared). Trying to compile the curl extension *as a shared module* for PHP 5.0.0 results in the following error message: gcc -flat_namespace -undefined suppress -o .libs/curl -bundle .libs/interface.o .libs/multi.o .libs/streams.o -L/usr/local/lib /usr/local/lib/libcurl.dylib -lssl -lcrypto -lz ld: multiple definitions of symbol _le_curl .libs/interface.o definition of _le_curl in section (__DATA,__common) .libs/multi.o definition of _le_curl in section (__DATA,__common) ld: multiple definitions of symbol _le_curl_multi_handle .libs/interface.o definition of _le_curl_multi_handle in section (__DATA,__common) .libs/multi.o definition of _le_curl_multi_handle in section (__DATA,__common) .libs/streams.o definition of _le_curl in section (__DATA,__common) .libs/streams.o definition of _le_curl_multi_handle in section (__DATA,__common) make: *** [curl.la] Error 1 Configure parameter used was --with-curl=shared,/usr/ local Again, it doesn't occur if the CURL extension is built in statically, so it's no biggie. -- Edit this bug report at http://bugs.php.net/?id=29149&edit=1
