#39835 [Com]: Configure script fails with expr: syntax error
ID: 39835 Comment by: bill at bt-systems dot com Reported By: cheetah at tanabi dot org Status: No Feedback Bug Type: *Compile Issues Operating System: Solaris 10 PHP Version: 5.2.0 New Comment: I encountered this problem on Solaris 10 x86 as well. My path specified /usr/ucb before /usr/bin. Apparently the version of expr in /usr/ucb is not compatible with PHP's configure script. Simply removing /usr/ucb from my path fixed the problem. Previous Comments: [2007-08-29 19:38:02] jd at cpanel dot net the expr info page suggests the expr tests in configure should be quoted with a leading space to avoid being interpreted as flags and remain as portable as possible: diff -Nur php-5.2.3.orig/acinclude.m4 php-5.2.3/acinclude.m4 --- php-5.2.3.orig/acinclude.m4 2007-05-24 16:40:41.0 -0500 +++ php-5.2.3/acinclude.m4 2007-08-29 14:30:40.0 -0500 @@ -2504,20 +2504,20 @@ done echo "'[$]0' \\" >> $1 - if test `expr -- [$]0 : "'.*"` = 0; then + if test `expr " [$]0" : " '.*"` = 0; then CONFIGURE_COMMAND="$CONFIGURE_COMMAND '[$]0'" else CONFIGURE_COMMAND="$CONFIGURE_COMMAND [$]0" fi for arg in $ac_configure_args; do - if test `expr -- $arg : "'.*"` = 0; then -if test `expr -- $arg : "--.*"` = 0; then + if test `expr " $arg" : " '.*"` = 0; then +if test `expr " $arg" : " --.*"` = 0; then break; fi echo "'[$]arg' \\" >> $1 CONFIGURE_COMMAND="$CONFIGURE_COMMAND '[$]arg'" else -if test `expr -- $arg : "'--.*"` = 0; then +if test `expr " $arg" : " '--.*"` = 0; then break; fi echo "[$]arg \\" >> $1 [2007-08-29 19:11:51] jd at cpanel dot net Passing -- to mark the end of flags for expr doesn't work everywhere. # expr --version | head -1 expr (GNU coreutils) 5.2.1 # expr -- hello hello # expr --version | head -1 expr (GNU sh-utils) 2.0 # expr -- hello expr: syntax error [2007-06-12 09:49:56] aklx at ee dot cuhk dot edu dot hk I had similar problem with php5.2.3 and php4.4.7. I was building php for my horde package and the following was observed when running configure(Sun Sparc Solaris 2.9): # ./configure --prefix=/usr/local/php.5.23 > --with-apxs=/usr/apache2/bin/apxs \ > > >> --with-gettext --with-dom \ > >> --with-iconv --enable-mbstring=all --enable-mbregex \ > >> --with-mysql=/usr/local/mysql > >> > creating cache ./config.cache > checking for Cygwin environment... no > checking for mingw32 environment... no checking for egrep... egrep > checking for a sed that does not truncate output... /usr/local/bin/sed > expr: syntax error > ../configure: test: argument expected I used gnu sed when I had the problem when using the Solairs sed. [2007-03-13 15:23:11] v2 at petrov dot ks dot ua Have same error when try to compile php-4.4.6 # ./configure loading cache ./config.cache checking for egrep... grep -E checking for a sed that does not truncate output... /bin/sed expr: syntax error ./configure: test: =: unary operator expected ... OS Red Hat 7.3 # bash --version GNU bash, version 2.05a.0(1)-release (i686-pc-linux-gnu) Copyright 2001 Free Software Foundation, Inc. # expr --version expr (GNU sh-utils) 2.0.11 Written by Mike Parker. [2006-12-23 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 "O
#43454 [Opn->Fbk]: xsl:include / xslt_based_dir
ID: 43454
Updated by: [EMAIL PROTECTED]
Reported By: emmanuel dot de-peretti at cinqas dot fr
-Status: Open
+Status: Feedback
Bug Type: XSLT related
Operating System: windows
PHP Version: 5.2
New Comment:
Thank you for this bug report. To properly diagnose the problem, we
need a short but complete example script to be able to reproduce
this bug ourselves.
A proper reproducing script starts with ,
is max. 10-20 lines long and does not require any external
resources such as databases, etc. If the script requires a
database to demonstrate the issue, please make sure it creates
all necessary tables, stored procedures etc.
Please avoid embedding huge scripts into the report.
Previous Comments:
[2007-11-29 17:18:03] [EMAIL PROTECTED]
Not a php.net website problem, reclassified.
[2007-11-29 16:52:20] emmanuel dot de-peretti at cinqas dot fr
Description:
Hi,
Since 5.2.x, the commande
setParameter('sablotron','xslt_base_dir',$file) seems doesnt't work if
you have setParameter('sablotron','xslt_base_dir',$chemin);
a bug is report only since php 5.2x before, it's good
--
Edit this bug report at http://bugs.php.net/?id=43454&edit=1
#43387 [Opn]: Segmentation fault during shutdown in _zend_mm_free_int()
ID: 43387 Updated by: [EMAIL PROTECTED] Reported By: matteo at beccati dot com Status: Open Bug Type: Reproducible crash Operating System: GNU/Linux 2.6.18 x86_64 PHP Version: 5.2.5 New Comment: Note for developers: See bug #43459 (crash in same place) Previous Comments: [2007-11-25 17:55:44] matteo at beccati dot com If I was able to understand what is causing the issue, I would happily create a short reproduce script. Unfortunately the bug only shows randomly during shutdown after a very complex script. The best I could do is to give you access to my machine in case the crash happens again, but I'm afraid I can't do much more right now. [2007-11-25 17:31:26] [EMAIL PROTECTED] Thank you for this bug report. To properly diagnose the problem, we need a short but complete example script to be able to reproduce this bug ourselves. A proper reproducing script starts with , is max. 10-20 lines long and does not require any external resources such as databases, etc. If the script requires a database to demonstrate the issue, please make sure it creates all necessary tables, stored procedures etc. Please avoid embedding huge scripts into the report. [2007-11-24 15:20:57] matteo at beccati dot com FreeBSD, PHP 5.2.4: ./configure --with-apxs2=/usr/local/sbin/apxs --with-mysql=/usr/local --with-pgsql=/usr/local/pgsql --with-zlib --with-iconv=/usr/local --enable-bcmath --enable-ftp --enable-mbstring --with-mcrypt=/usr/local --with-mhash=/usr/local --with-curl=/usr/local --with-xml --with-xmlrpc --with-gettext --with-gd --enable-gd-native-ttf --with-png --with-png-dir=/usr/local --with-jpeg --with-jpeg-dir=/usr/local --with-freetype-dir=/usr/local --with-ttf=/usr/local --enable-pcntl --enable-sockets --enable-sigchild --enable-shmop --enable-sysvmsg --enable-sysvsem --enable-sysvshm No extensions loaded in php.ini. Nothing has changed, but I'm unable to reproduce it ATM. Linux, PHP 5.2.5: ./configure --prefix=/usr/local/php-5.2.5 --with-apxs2=/usr/local/apache2/bin/apxs --with-mysql=/usr/local/mysql-5.0 --with-pgsql=/usr/local/pgsql-8.2 --enable-mbstring --with-gd --enable-gd-native-ttf --with-freetype-dir --with-jpeg-dir --with-png-dir --with-curl --with-openssl --with-zlib --enable-pcntl No extensions loaded in php.ini. Another CriuseControl build failed for that very reason the last night. [2007-11-24 12:14:54] [EMAIL PROTECTED] What configure line was used when building PHP? Are you loading some extensions in php.ini? Did you disable all zend extensions (like caches, optimizers..etc.) ? [2007-11-23 10:57:32] matteo at beccati dot com Description: PHP 5.2.5 sometimes crashes with a segmentation fault after running a specific unit test suite. Unfortunately the issue isn't easily replicable and seems to happen randomly. We have CruiseControl running dozens of builds with different PHP versions back to 4.3 and it just happens that sometimes one of the builds using PHP 5.2.5 fails on a particular test. So far it happened when running tests with PostgreSQL 8.0, 8.1 and MySQL 5.0. I've just tried to replicate the issue on another server and I finally did it. It crashes also on FreeBSD 6.2/amd64 using PHP 5.2.4 and MySQL 5.1. Surprisingly a similarily compiled 5.2.5 doesn't crash on this server. Reproduce code: --- svn export -r12748 https://svn.openads.org/openads/trunk OA-trunk cd OA-trunk cp etc/test.conf var/ ; edit var/test.conf.php and set the db parameters cd tests php run.php --type=unit --level=file --layer=dal --folder=lib/OA/Dal/Delivery --file=DeliveryDB.dal.test.php --format=text --host=test Expected result: UNIT: Data Abstraction Layer (DB): lib/OA/Dal/Delivery/DeliveryDB.dal.test.php OK Test cases run: 1/1, Passes: 302, Failures: 0, Exceptions: 0 Actual result: -- UNIT: Data Abstraction Layer (DB): lib/OA/Dal/Delivery/DeliveryDB.dal.test.php OK Test cases run: 1/1, Passes: 302, Failures: 0, Exceptions: 0 Segmentation fault: 11 (core dumped) gdb output on Linux / PHP 5.2.5 === GNU gdb Red Hat Linux (6.5-16.el5rh) Copyright (C) 2006 Free Software Foundation, Inc. GDB is free software, covered by the GNU General Public License, and you are welcome to change it and/or distribute copies of it under certain conditions. Type "show copying" to see the conditions. There is absolutely no warranty for GDB. Type "show warranty" for details. This GDB was configured as "x86_64-redhat-linux-gnu"...Using host libthread_db library "/lib64/libthread_db.so.1". Reading symbols from /lib6
#43459 [Opn]: Segfault on graceful restart?
ID: 43459
Updated by: [EMAIL PROTECTED]
Reported By: ch at westend dot com
Status: Open
Bug Type: Reproducible crash
Operating System: Debian 4.0 'etch' Linux
PHP Version: 5.2.5
New Comment:
Note for developers: See bug #43387 (crash in same place)
Previous Comments:
[2007-11-29 21:15:31] ch at westend dot com
Description:
I have lots of segfaults in the error.log of a new apache installation
using a Debian shipped Apache2 with prefork mpm and the very latest
PHP5. Below is the backtrace.
Reproduce code:
---
I guess it comes sometimes from graceful restarts or from idle threads
that apache kills himself.
PHP was compiled using:
./configure \
--with-apxs2=/usr/bin/apxs2 \
--prefix=/usr/local/php5 \
\
--enable-shared \
--enable-exif \
--enable-ftp \
--enable-gd-native-ttf \
--enable-mbstring \
--enable-simplexml \
--enable-soap \
--enable-pdo \
--enable-spl \
--enable-zip \
--with-bz2 \
--with-curl \
--with-curl=/usr \
--with-freetype-dir=/usr \
--with-gd=shared \
--with-gettext \
--with-iconv \
--with-mime-magic \
--with-mysql=shared,/usr \
--with-mysql-sock=/var/run/mysqld/mysqld.sock \
--with-pdo-mysql=/usr \
--with-t1lib \
--with-jpeg-dir=/usr \
--with-ttf=/usr \
--with-zlib=/usr \
--with-xsl=/usr \
Expected result:
-
Actual result:
--
$ gdb /usr/sbin/apache2 core
...
Core was generated by `/usr/sbin/apache2 -k start'.
Program terminated with signal 11, Segmentation fault.
#0 _zend_mm_free_int (heap=0x744dd0, p=0x2ab8a7c272a0) at
/usr/local/src/php5/php-5.2.5/Zend/zend_alloc.c:1944
1944if (ZEND_MM_IS_FREE_BLOCK(next_block)) {
(gdb) bt
#0 _zend_mm_free_int (heap=0x744dd0, p=0x2ab8a7c272a0) at
/usr/local/src/php5/php-5.2.5/Zend/zend_alloc.c:1944
#1 0x2ab89d7e3735 in destroy_op_array (op_array=0x2ab8abe89260) at
/usr/local/src/php5/php-5.2.5/Zend/zend_opcode.c:232
#2 0x2ab89d7f6cb8 in zend_hash_destroy (ht=0x2ab8abe84760) at
/usr/local/src/php5/php-5.2.5/Zend/zend_hash.c:526
#3 0x2ab89d7e3465 in destroy_zend_class (pce=) at /usr/local/src/php5/php-5.2.5/Zend/zend_opcode.c:184
#4 0x2ab89d7f69a2 in zend_hash_apply_deleter (ht=0x745710,
p=0x9dbba0) at /usr/local/src/php5/php-5.2.5/Zend/zend_hash.c:611
#5 0x2ab89d7f6aa9 in zend_hash_reverse_apply (ht=0x745710,
apply_func=0x2ab89d7dee70 )
at /usr/local/src/php5/php-5.2.5/Zend/zend_hash.c:760
#6 0x2ab89d7dfe96 in shutdown_executor () at
/usr/local/src/php5/php-5.2.5/Zend/zend_execute_API.c:291
#7 0x2ab89d7ec232 in zend_deactivate () at
/usr/local/src/php5/php-5.2.5/Zend/zend.c:860
#8 0x2ab89d7aa9be in php_request_shutdown (dummy=) at /usr/local/src/php5/php-5.2.5/main/main.c:1485
#9 0x2ab89d86b08e in php_handler (r=0x968488) at
/usr/local/src/php5/php-5.2.5/sapi/apache2handler/sapi_apache2.c:471
#10 0x00432c89 in ap_run_handler ()
#11 0x00435e02 in ap_invoke_handler ()
#12 0x00441ed8 in ap_process_request ()
#13 0x0043f3bc in ap_register_input_filter ()
#14 0x004397e1 in ap_run_process_connection ()
#15 0x00445851 in ap_graceful_stop_signalled ()
#16 0x00445ac4 in ap_graceful_stop_signalled ()
#17 0x00446366 in ap_mpm_run ()
#18 0x00420e00 in main ()
--
Edit this bug report at http://bugs.php.net/?id=43459&edit=1
#43341 [Fbk->Opn]: no libphp5.so or php cli binary created
ID: 43341 User updated by: jay3ld at yahoo dot com Reported By: jay3ld at yahoo dot com -Status: Feedback +Status: Open Bug Type: Compile Failure Operating System: Mac os X 10.5 Leopard PHP Version: 5.3CVS-2007-11-20 (snap) New Comment: I can say for fact I am no longer using the built in apache 2.0 or php. I have custom built apache 2.2 and it even shows under my phpinfo.php page I am using apache 2.2.6 (It is how I pulled this information up originally). I renamed the apachectl file in /usr/sbin to apachectl.old and made symlink to the new one in my /home directory so startup commands still use apachectl correctly. My httpd.conf specifically points at php directories as I run php 5.2 and php 6.0 at the moment and wanted to add 5.3 as another option to ensure my sites will operate in the future correctly when and if I upgrade to 5.3 Previous Comments: [2007-11-29 01:05:12] [EMAIL PROTECTED] There seems to be some problem with the Apache that comes with Leopard. Here are some instructions how to do this: http://gorn.ch/archive/2007/11/01/leopard-native-apache-with-custom-64bit-php.html 5.2 propably works because it comes with the system, and you're most likely just loading that instead.. [2007-11-28 23:07:02] geoffrey dot hughes at otago dot ac dot nz I'm getting this same problem on version 5.2.5 under leopard. The apache module does install and activate and phpinfo via a web page returns the correct version but the php and pear CLIs are not being installed and as such still report the previous version I had (5.2.4). [2007-11-28 17:41:18] jay3ld at yahoo dot com Empty file as well with plain options. [2007-11-25 17:34:31] [EMAIL PROTECTED] How about if you used plain 'diff -u' without any fancy options? Do you get any diff? [2007-11-25 01:20:37] jay3ld at yahoo dot com I receive a blank file. I used: diff -urx Packages /home/php52/lib/php/build/Makefile.global /home/php53/lib/php/build/Makefile.global > test.patch The php 5.2 was not a cv but the 5.2.5 release 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/43341 -- Edit this bug report at http://bugs.php.net/?id=43341&edit=1
#43457 [Opn]: prepared statement with incorrect parms doens't throw exception
ID: 43457
User updated by: pookey at pookey dot co dot uk
Reported By: pookey at pookey dot co dot uk
Status: Open
-Bug Type: PostgreSQL related
+Bug Type: PDO related
Operating System: linux
PHP Version: 5.2CVS-2007-11-29 (CVS)
New Comment:
moving to PDO related from Postgres related.
Previous Comments:
[2007-11-29 17:41:05] pookey at pookey dot co dot uk
Description:
no exception is thrown when using named params to a prepared statement,
when you pass invalid names.
Interestingly, is that count of the params doesnt' match, an exception
is thrown.
Using the code below, but using sqlite instead..
$pdo = new PDO('sqlite::memory:');
then you do get an exception
# php ./test.php
PDOException: SQLSTATE[HY000]: General error: 25 bind or column index
out of range in /tmp/test.php on line 16
Call Stack:
0.0002 103296 1. {main}() /tmp/test.php:0
0.0014 106912 2. PDOStatement->execute() /tmp/test.php:16
I've not tested with other DBMSs.
Reproduce code:
---
$ cat ./test.php
setAttribute(PDO::ATTR_ERRMODE, PDO::ERRMODE_EXCEPTION);
$pdo->exec('CREATE TABLE test ( field1 varchar, field2 varchar)');
$stmt2 = $pdo->prepare('INSERT INTO test (field1, field2) VALUES
(:param1, :param2)');
$pdo->beginTransaction();
$ret = $stmt2->execute( array(
':param1' => 'wibble',
':nonsense' => 1,
));
var_dump($ret);
var_dump($stmt2->errorInfo());
Expected result:
exception thrown
Actual result:
--
$ ~pookey/src/php5/sapi/cli/php ./test.php
bool(false)
array(3) {
[0]=>
string(5) "HY093"
[1]=>
int(7)
[2]=>
string(0) ""
}
--
Edit this bug report at http://bugs.php.net/?id=43457&edit=1
#43450 [Opn]: Memory leak on some functions with implicit object __toString() call
ID: 43450
Updated by: [EMAIL PROTECTED]
Reported By: [EMAIL PROTECTED]
Status: Open
Bug Type: Scripting Engine problem
Operating System: Any
PHP Version: 5.2.5
New Comment:
I'm still not sure if this has anything to do with the new Zend parsing
API, but I've tested the md5 function with the zend_get_parameters_ex
(the old API) and the leak didn't occur. See the two version for a
comparison.
currently
PHP_NAMED_FUNCTION(php_if_md5)
{
char *arg;
int arg_len;
zend_bool raw_output = 0;
char md5str[33];
PHP_MD5_CTX context;
unsigned char digest[16];
if (zend_parse_parameters(ZEND_NUM_ARGS() TSRMLS_CC,
"s|b", &arg, &arg_len, &raw_output) == FAILURE) {
return;
}
md5str[0] = '\0';
PHP_MD5Init(&context);
PHP_MD5Update(&context, arg, arg_len);
PHP_MD5Final(digest, &context);
if (raw_output) {
RETURN_STRINGL(digest, 16, 1);
} else {
make_digest_ex(md5str, digest, 16);
RETVAL_STRING(md5str, 1);
}
}
--- hacked rewrite
PHP_NAMED_FUNCTION(php_if_md5)
{
zval **zarg;
zend_bool raw_output = 0;
char md5str[33];
PHP_MD5_CTX context;
unsigned char digest[16];
if (ZEND_NUM_ARGS() != 1 ||
zend_get_parameters_ex(1, &zarg) == FAILURE) {
WRONG_PARAM_COUNT;
}
convert_to_string_ex(zarg);
md5str[0] = '\0';
PHP_MD5Init(&context);
PHP_MD5Update(&context, Z_STRVAL_PP(zarg), Z_STRLEN_PP(zarg));
PHP_MD5Final(digest, &context);
if (raw_output) {
RETURN_STRINGL(digest, 16, 1);
} else {
make_digest_ex(md5str, digest, 16);
RETVAL_STRING(md5str, 1);
}
}
Previous Comments:
[2007-11-29 14:59:48] [EMAIL PROTECTED]
Description:
Under certain circumenstances, the implicit call to __toString() on an
object may lead to memory leaks.
In the reproducable example, the following line leaks ($o is a simply
object):
md5($o);
But this line doesn't:
md5($o->__toString());
This only applies to certain functions, I've identifier md5, sha1 and
crc32.
If I try other examples like strstr or strlen, there's no leak at all.
A wild guess is that this maybe has to do whether the function
internally uses zend_parse_parameters() or zend_get_parameters_ex().
The function which leak use zend_parse_parameters(), the others don't.
But this may completely accidental.
It seems very related to bug#38591. However I don't see how bug#38604
is related to this issue (mentioned in bug#38591).
This leak was most notable found in an application which is supposed to
run for a long time, even hours. So usually within web application this
is not an issue.
Reproduce code:
---
__toString());
# does not leak either way
# strstr($o, 'f');
#strstr($o->__toString(), 'f');
if ($i % 1e3 == 0) {
printf("%u: %1.2f KB\n",
$i, memory_get_usage(true) / 1024);
}
}
Expected result:
Constant memory usage.
Actual result:
--
Memory grows and grows.
--
Edit this bug report at http://bugs.php.net/?id=43450&edit=1
#43458 [Opn->Bgs]: works in PHP4, but not PHP5
ID: 43458 Updated by: [EMAIL PROTECTED] Reported By: andrew at sundale dot net -Status: Open +Status: Bogus Bug Type: Scripting Engine problem Operating System: Linux PHP Version: 5.2.5 New Comment: Thank you for taking the time to write to us, but this is not a bug. Please double-check the documentation available at http://www.php.net/manual/ and the instructions on how to report a bug at http://bugs.php.net/how-to-report.php This is expected. Previous Comments: [2007-11-29 20:27:20] andrew at sundale dot net Description: works in PHP4, but not PHP5 I have encountered a legacy code, there were used these comments. Surprisingly, it works in PHP4. Reproduce code: --- Expected result: Nothing Actual result: -- Error in PHP5 -- Edit this bug report at http://bugs.php.net/?id=43458&edit=1
#41941 [Asn]: oci8 extension not lib64 savvy
ID: 41941
Updated by: [EMAIL PROTECTED]
Reported By: wdierkes at 5dollarwhitebox dot org
Status: Assigned
Bug Type: OCI8 related
Operating System: Redhat Enterprise Linux
PHP Version: 5.2.3
Assigned To: sixd
New Comment:
We're not going to add support for any unofficial Instant Client rpms
(there is enough hassle with the official ones, so please don't add even
more).
The support for official 64bit OIC rpms is currently being tested.
Previous Comments:
[2007-11-29 21:28:09] [EMAIL PROTECTED]
Update: Oracle has released Instant Client x86_64 RPMs on the OTN
website. OCI8 should use the directory structure in these official
RPMs.
[2007-07-23 18:03:17] [EMAIL PROTECTED]
Status update: I'm pushing for official Oracle 64 bit RPMs to be
released and am waiting to see what directory structure they will have.
[2007-07-09 23:14:12] wdierkes at 5dollarwhitebox dot org
I built, and maintain the RPMS (internally) based off of a FedoraCore
SPEC with minimal changes (I believe they dropped the package though as
it was hard to find). The 'lib' directory is based off of the
'%{_libdir}' RPM macro (as it should be) placing the library data in
'/usr/lib64' on an x86_64 box (as it should as well).
This issue is not with the RPM... rather the fact that '/usr/lib' is
hardcoded in the config.m4 line (as described above) that determines the
'/usr/include...' path for oci.h.
[2007-07-09 23:03:28] [EMAIL PROTECTED]
Oracle doesn't distribute x64 RPMs for Instant Client, though there has
been some discussion about it. Who created the RPMs you are using?
[2007-07-09 17:29:16] wdierkes at 5dollarwhitebox dot org
Description:
Related to Bug 35471 - could not open/comment on that bug report.
Oracle InstantClient 10.2.0.3 (RPM)
Redhat Enterprise Linux 3/4 x86_64
configure
--with-oci8=shared,instantclient,/usr/lib64/oracle/10.2.0.3/client/lib
When compiling php-5.2.3 on x86_64, configure fails with the
following:
...
checking Oracle Instant Client directory...
/usr/lib64/oracle/10.2.0.3/client/lib
checking Oracle Instant Client SDK header directory... configure:
error: Oracle Instant Client SDK header files not found
The issue is at the following line (around line 345-350) in
php-5.2.3/ext/oci8/config.m4:
OCISDKRPMINC=`echo "$PHP_OCI8_INSTANT_CLIENT" | $PHP_OCI8_SED -e
's!^/usr/lib/oracle/\(.*\)/client/lib[/]*$!/usr/include/oracle/\1/client!'`
Obviously, $OCISDKRPMINC is hardcoded to sed up the line based on
'/usr/lib'. This should be 32bit/64bit savvy, or can just as easily be
done differently. The following patch resolved the issue:
http://devel.5dollarwhitebox.org/patches/php-5.2.3-oci8-lib64.patch
--- php-5.2.3/ext/oci8/config.m4.oci8 2007-05-04 06:30:37.0
-0500
+++ php-5.2.3/ext/oci8/config.m42007-07-09 11:49:26.0
-0500
@@ -345,7 +345,8 @@
AC_MSG_CHECKING([Oracle Instant Client SDK header directory])
dnl Header directory for Instant Client SDK RPM install
- OCISDKRPMINC=`echo "$PHP_OCI8_INSTANT_CLIENT" | $PHP_OCI8_SED -e
's!^/usr/lib/oracle/\(.*\)/client/lib[/]*$!/usr/include/oracle/\1/client!'`
+ INSTANT_CLIENT_VERSION=`echo "$PHP_OCI8_INSTANT_CLIENT" | awk -F /
{' print $5 '}`
+ OCISDKRPMINC="/usr/include/oracle/${INSTANT_CLIENT_VERSION}/client"
dnl Header directory for Instant Client SDK zip file install
OCISDKZIPINC=$PHP_OCI8_INSTANT_CLIENT/sdk/include
A cleaner and more flexible solution would be to add a '--oci8-include'
option along with the standard '--with-oci8' option. Basically... the
directory passed to '--with-oci8' directs configure to the path where
the library files are The rest of the code is assuming that the
header files are in a set location
'/usr/include/oracle//client'... there should be an option to
override this location of oci.h.
Reproduce code:
---
configure
--with-oci8=shared,instantclient,/usr/lib64/oracle/10.2.0.3/client/lib
Expected result:
configure properly finds oci.h in the default include dir for oracle.
Actual result:
--
checking Oracle Instant Client directory...
/usr/lib64/oracle/10.2.0.3/client/lib
checking Oracle Instant Client SDK header directory... configure:
error: Oracle Instant Client SDK header files not found
--
Edit this bug report at http://bugs.php.net/?id=41941&edit=1
#41941 [Asn]: oci8 extension not lib64 savvy
ID: 41941
Updated by: [EMAIL PROTECTED]
Reported By: wdierkes at 5dollarwhitebox dot org
Status: Assigned
Bug Type: OCI8 related
Operating System: Redhat Enterprise Linux
PHP Version: 5.2.3
Assigned To: sixd
New Comment:
Update: Oracle has released Instant Client x86_64 RPMs on the OTN
website. OCI8 should use the directory structure in these official
RPMs.
Previous Comments:
[2007-07-23 18:03:17] [EMAIL PROTECTED]
Status update: I'm pushing for official Oracle 64 bit RPMs to be
released and am waiting to see what directory structure they will have.
[2007-07-09 23:14:12] wdierkes at 5dollarwhitebox dot org
I built, and maintain the RPMS (internally) based off of a FedoraCore
SPEC with minimal changes (I believe they dropped the package though as
it was hard to find). The 'lib' directory is based off of the
'%{_libdir}' RPM macro (as it should be) placing the library data in
'/usr/lib64' on an x86_64 box (as it should as well).
This issue is not with the RPM... rather the fact that '/usr/lib' is
hardcoded in the config.m4 line (as described above) that determines the
'/usr/include...' path for oci.h.
[2007-07-09 23:03:28] [EMAIL PROTECTED]
Oracle doesn't distribute x64 RPMs for Instant Client, though there has
been some discussion about it. Who created the RPMs you are using?
[2007-07-09 17:29:16] wdierkes at 5dollarwhitebox dot org
Description:
Related to Bug 35471 - could not open/comment on that bug report.
Oracle InstantClient 10.2.0.3 (RPM)
Redhat Enterprise Linux 3/4 x86_64
configure
--with-oci8=shared,instantclient,/usr/lib64/oracle/10.2.0.3/client/lib
When compiling php-5.2.3 on x86_64, configure fails with the
following:
...
checking Oracle Instant Client directory...
/usr/lib64/oracle/10.2.0.3/client/lib
checking Oracle Instant Client SDK header directory... configure:
error: Oracle Instant Client SDK header files not found
The issue is at the following line (around line 345-350) in
php-5.2.3/ext/oci8/config.m4:
OCISDKRPMINC=`echo "$PHP_OCI8_INSTANT_CLIENT" | $PHP_OCI8_SED -e
's!^/usr/lib/oracle/\(.*\)/client/lib[/]*$!/usr/include/oracle/\1/client!'`
Obviously, $OCISDKRPMINC is hardcoded to sed up the line based on
'/usr/lib'. This should be 32bit/64bit savvy, or can just as easily be
done differently. The following patch resolved the issue:
http://devel.5dollarwhitebox.org/patches/php-5.2.3-oci8-lib64.patch
--- php-5.2.3/ext/oci8/config.m4.oci8 2007-05-04 06:30:37.0
-0500
+++ php-5.2.3/ext/oci8/config.m42007-07-09 11:49:26.0
-0500
@@ -345,7 +345,8 @@
AC_MSG_CHECKING([Oracle Instant Client SDK header directory])
dnl Header directory for Instant Client SDK RPM install
- OCISDKRPMINC=`echo "$PHP_OCI8_INSTANT_CLIENT" | $PHP_OCI8_SED -e
's!^/usr/lib/oracle/\(.*\)/client/lib[/]*$!/usr/include/oracle/\1/client!'`
+ INSTANT_CLIENT_VERSION=`echo "$PHP_OCI8_INSTANT_CLIENT" | awk -F /
{' print $5 '}`
+ OCISDKRPMINC="/usr/include/oracle/${INSTANT_CLIENT_VERSION}/client"
dnl Header directory for Instant Client SDK zip file install
OCISDKZIPINC=$PHP_OCI8_INSTANT_CLIENT/sdk/include
A cleaner and more flexible solution would be to add a '--oci8-include'
option along with the standard '--with-oci8' option. Basically... the
directory passed to '--with-oci8' directs configure to the path where
the library files are The rest of the code is assuming that the
header files are in a set location
'/usr/include/oracle//client'... there should be an option to
override this location of oci.h.
Reproduce code:
---
configure
--with-oci8=shared,instantclient,/usr/lib64/oracle/10.2.0.3/client/lib
Expected result:
configure properly finds oci.h in the default include dir for oracle.
Actual result:
--
checking Oracle Instant Client directory...
/usr/lib64/oracle/10.2.0.3/client/lib
checking Oracle Instant Client SDK header directory... configure:
error: Oracle Instant Client SDK header files not found
--
Edit this bug report at http://bugs.php.net/?id=41941&edit=1
#43459 [NEW]: Segfault on graceful restart?
From: ch at westend dot com
Operating system: Debian 4.0 'etch' Linux
PHP version: 5.2.5
PHP Bug Type: Reproducible crash
Bug description: Segfault on graceful restart?
Description:
I have lots of segfaults in the error.log of a new apache installation
using a Debian shipped Apache2 with prefork mpm and the very latest PHP5.
Below is the backtrace.
Reproduce code:
---
I guess it comes sometimes from graceful restarts or from idle threads
that apache kills himself.
PHP was compiled using:
./configure \
--with-apxs2=/usr/bin/apxs2 \
--prefix=/usr/local/php5 \
\
--enable-shared \
--enable-exif \
--enable-ftp \
--enable-gd-native-ttf \
--enable-mbstring \
--enable-simplexml \
--enable-soap \
--enable-pdo \
--enable-spl \
--enable-zip \
--with-bz2 \
--with-curl \
--with-curl=/usr \
--with-freetype-dir=/usr \
--with-gd=shared \
--with-gettext \
--with-iconv \
--with-mime-magic \
--with-mysql=shared,/usr \
--with-mysql-sock=/var/run/mysqld/mysqld.sock \
--with-pdo-mysql=/usr \
--with-t1lib \
--with-jpeg-dir=/usr \
--with-ttf=/usr \
--with-zlib=/usr \
--with-xsl=/usr \
Expected result:
-
Actual result:
--
$ gdb /usr/sbin/apache2 core
...
Core was generated by `/usr/sbin/apache2 -k start'.
Program terminated with signal 11, Segmentation fault.
#0 _zend_mm_free_int (heap=0x744dd0, p=0x2ab8a7c272a0) at
/usr/local/src/php5/php-5.2.5/Zend/zend_alloc.c:1944
1944if (ZEND_MM_IS_FREE_BLOCK(next_block)) {
(gdb) bt
#0 _zend_mm_free_int (heap=0x744dd0, p=0x2ab8a7c272a0) at
/usr/local/src/php5/php-5.2.5/Zend/zend_alloc.c:1944
#1 0x2ab89d7e3735 in destroy_op_array (op_array=0x2ab8abe89260) at
/usr/local/src/php5/php-5.2.5/Zend/zend_opcode.c:232
#2 0x2ab89d7f6cb8 in zend_hash_destroy (ht=0x2ab8abe84760) at
/usr/local/src/php5/php-5.2.5/Zend/zend_hash.c:526
#3 0x2ab89d7e3465 in destroy_zend_class (pce=)
at /usr/local/src/php5/php-5.2.5/Zend/zend_opcode.c:184
#4 0x2ab89d7f69a2 in zend_hash_apply_deleter (ht=0x745710,
p=0x9dbba0) at /usr/local/src/php5/php-5.2.5/Zend/zend_hash.c:611
#5 0x2ab89d7f6aa9 in zend_hash_reverse_apply (ht=0x745710,
apply_func=0x2ab89d7dee70 )
at /usr/local/src/php5/php-5.2.5/Zend/zend_hash.c:760
#6 0x2ab89d7dfe96 in shutdown_executor () at
/usr/local/src/php5/php-5.2.5/Zend/zend_execute_API.c:291
#7 0x2ab89d7ec232 in zend_deactivate () at
/usr/local/src/php5/php-5.2.5/Zend/zend.c:860
#8 0x2ab89d7aa9be in php_request_shutdown (dummy=) at /usr/local/src/php5/php-5.2.5/main/main.c:1485
#9 0x2ab89d86b08e in php_handler (r=0x968488) at
/usr/local/src/php5/php-5.2.5/sapi/apache2handler/sapi_apache2.c:471
#10 0x00432c89 in ap_run_handler ()
#11 0x00435e02 in ap_invoke_handler ()
#12 0x00441ed8 in ap_process_request ()
#13 0x0043f3bc in ap_register_input_filter ()
#14 0x004397e1 in ap_run_process_connection ()
#15 0x00445851 in ap_graceful_stop_signalled ()
#16 0x00445ac4 in ap_graceful_stop_signalled ()
#17 0x00446366 in ap_mpm_run ()
#18 0x00420e00 in main ()
--
Edit bug report at http://bugs.php.net/?id=43459&edit=1
--
Try a CVS snapshot (PHP 4.4):
http://bugs.php.net/fix.php?id=43459&r=trysnapshot44
Try a CVS snapshot (PHP 5.2):
http://bugs.php.net/fix.php?id=43459&r=trysnapshot52
Try a CVS snapshot (PHP 5.3):
http://bugs.php.net/fix.php?id=43459&r=trysnapshot53
Try a CVS snapshot (PHP 6.0):
http://bugs.php.net/fix.php?id=43459&r=trysnapshot60
Fixed in CVS: http://bugs.php.net/fix.php?id=43459&r=fixedcvs
Fixed in release:
http://bugs.php.net/fix.php?id=43459&r=alreadyfixed
Need backtrace: http://bugs.php.net/fix.php?id=43459&r=needtrace
Need Reproduce Script:http://bugs.php.net/fix.php?id=43459&r=needscript
Try newer version:http://bugs.php.net/fix.php?id=43459&r=oldversion
Not developer issue: http://bugs.php.net/fix.php?id=43459&r=support
Expected behavior:http://bugs.php.net/fix.php?id=43459&r=notwrong
Not enough info:
http://bugs.php.net/fix.php?id=43459&r=notenoughinfo
Submitted twice:
http://bugs.php.net/fix.php?id=43459&r=submittedtwice
register_globals: http://bugs.php.net/fix.php?id=43459&r=globals
PHP 3 support discontinued: http://bugs.php.net/fix.php?id=43459&r=php3
Daylight Savings: http://bugs.php.net/fix.php?id=43459&r=dst
IIS Stability:http://bugs.php.net/fix.php?id=43459&r=isapi
Install GNU Sed: http://bugs.php.net/fix.php?id=43459&r=gnused
Floating point limitations: http://bugs.php.net/fix.php?id=43459&r=float
No Zend Extensions: http://bugs.php.net/fix.php?id=43459
#38915 [Com]: Apache: system() (and similar) don't cleanup opened handles of Apache
ID: 38915 Comment by: odeta at hard dot lt Reported By: dimmoborgir at gmail dot com Status: Open Bug Type: Feature/Change Request Operating System: UNIX PHP Version: 5.2.2, 4.4.7 New Comment: Any news? mail() function is suffering from the same problem, and exim is using Apache port then.. Previous Comments: [2007-11-25 19:57:51] olafvdspek at gmail dot com Can't you use FastCGI and avoid issues like these completely? [2007-10-07 09:33:33] Cruz at guerillamail dot com Ran into the same problem. I'm appalled that a bug this big isn't fixed more than a year after it was reported. [2007-07-29 10:48:18] antoine dot bajolet at tdf dot fr Hello, I agree with all contributors : It's a bunch of pain we can't launch a clean process from a PHP web interface. Without any technical consideration, functionally it's a real need to numerous PHP users, and for a long time seeing those bug reports : http://bugs.php.net/bug.php?id=15529 http://bugs.php.net/bug.php?id=15642 http://bugs.php.net/bug.php?id=16548 The only workaround whe found to obtain the result is : - Writing something to a file to tell "hey, there is a process to launch or stop" - Using a cron'ed script to read the file and launch/stop the process if it tells it. And this poor tip is far far from satisfying us. The last response given in 2003 was "Given the nature of PHP's execution architecture this is not possible/practical to implement." But if the Apache API offers a "apr_proc_create()" function, why not using it in mod_php ? There are some other differences between mod_php and php-cli. Regards, Antoine [2007-03-05 21:11:51] oliver at realtsp dot com apart from the security considerations mentioned above the fact that mod_php doesn't free the FDs when forking prevents us from forking cleanly. ie we cannot from a web request to mod_php fork a cli process cleanly because it will inherit all the open FDs (ie typically port 80 & 443) even if you use setsid() (or daemon on FreeBSD) etc.. you can see this when you... fork stop apache netstat -an | grep LISTEN your cli process will be LISTENING to port 80 & 443. this is not only a security risk, but it will prevent apache for restarting: (48)Address already in use: make_sock: could not bind to address [::]:443 no listening sockets available, shutting down I have not found any way to close these sockets as they should be because the resource handles are not available in php. If you could at least make these available then we could at least ensure we close them manually. Regards Oliver [2007-01-04 19:25:26] anomie at users dot sf dot net On 20 Oct 2006 9:48am UTC, [EMAIL PROTECTED] wrote: > The opened file descriptors are opened by Apache. > It is the job of Apache to protect them, not something that > should be reinvented in all apache modules. If that's your position, then as far as I can tell mod_php should be calling apr_proc_create() instead of system()/popen()/etc and apr_pool_cleanup_for_exec() before exec(). Apache adds (or should be adding) all the FDs that should be closed on exec to a list that those functions make use of. If you don't like that, then either explain (in as much detail as is required) why that isn't Apache's method of protecting the FDs, find a non-bogus reason for claiming this issue is not a mod_php bug, or just fix the bug already. "Apache should just use FD_CLOEXEC" isn't a non-bogus reason, BTW, although convincing Apache to do so and making sure FD_CLOEXEC is supported on all platforms mod_php can possibly be used on might be an acceptable bugfix. I've also seen the "MTA ends up listening on port 80" issue after using the php mail functions. 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/38915 -- Edit this bug report at http://bugs.php.net/?id=38915&edit=1
#43458 [NEW]: works in PHP4, but not PHP5
From: andrew at sundale dot net Operating system: Linux PHP version: 5.2.5 PHP Bug Type: Scripting Engine problem Bug description: works in PHP4, but not PHP5 Description: works in PHP4, but not PHP5 I have encountered a legacy code, there were used these comments. Surprisingly, it works in PHP4. Reproduce code: --- Expected result: Nothing Actual result: -- Error in PHP5 -- Edit bug report at http://bugs.php.net/?id=43458&edit=1 -- Try a CVS snapshot (PHP 4.4): http://bugs.php.net/fix.php?id=43458&r=trysnapshot44 Try a CVS snapshot (PHP 5.2): http://bugs.php.net/fix.php?id=43458&r=trysnapshot52 Try a CVS snapshot (PHP 5.3): http://bugs.php.net/fix.php?id=43458&r=trysnapshot53 Try a CVS snapshot (PHP 6.0): http://bugs.php.net/fix.php?id=43458&r=trysnapshot60 Fixed in CVS: http://bugs.php.net/fix.php?id=43458&r=fixedcvs Fixed in release: http://bugs.php.net/fix.php?id=43458&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=43458&r=needtrace Need Reproduce Script:http://bugs.php.net/fix.php?id=43458&r=needscript Try newer version:http://bugs.php.net/fix.php?id=43458&r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=43458&r=support Expected behavior:http://bugs.php.net/fix.php?id=43458&r=notwrong Not enough info: http://bugs.php.net/fix.php?id=43458&r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=43458&r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=43458&r=globals PHP 3 support discontinued: http://bugs.php.net/fix.php?id=43458&r=php3 Daylight Savings: http://bugs.php.net/fix.php?id=43458&r=dst IIS Stability:http://bugs.php.net/fix.php?id=43458&r=isapi Install GNU Sed: http://bugs.php.net/fix.php?id=43458&r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=43458&r=float No Zend Extensions: http://bugs.php.net/fix.php?id=43458&r=nozend MySQL Configuration Error:http://bugs.php.net/fix.php?id=43458&r=mysqlcfg
#43453 [Opn->Bgs]: wrong result if the decimal is not a dot
ID: 43453 Updated by: [EMAIL PROTECTED] Reported By: bammo_merdini at hotmail dot com -Status: Open +Status: Bogus Bug Type: *Math Functions Operating System: Windows XP Pro PHP Version: 5.2.5 New Comment: Thank you for taking the time to write to us, but this is not a bug. Please double-check the documentation available at http://www.php.net/manual/ and the instructions on how to report a bug at http://bugs.php.net/how-to-report.php With comma the value isn't treat as float. Then, when it is converted, the part after ',' is removed. See: $number = number_format(100/1024, 2, ",", ""); var_dump($number); // string(6) "976,56" var_dump((float) $number); // float(976) Previous Comments: [2007-11-29 16:19:18] bammo_merdini at hotmail dot com Description: If I use number_format() with "." as decimal point and then round it with 1 decimal, it'll work fine, but not if the decimal point is ",". I'm using WAMP5 and haven't done any changes at all to php.ini. Reproduce code: --- Expected result: A: 976.56 B: 976,56 Actual result: -- A: 976.56 B: 976 -- Edit this bug report at http://bugs.php.net/?id=43453&edit=1
#42496 [Opn]: cursor is not closed when using 2 clobs in a select query
ID: 42496
Updated by: [EMAIL PROTECTED]
Reported By: iddekingej at lycos dot com
Status: Open
Bug Type: OCI8 related
Operating System: win 2000
PHP Version: 5.2.4
New Comment:
This was reproduced with 5.2.3 on Linux.
Please try this patch AND LET US KNOW THE RESULT - thanks!
In php_oci_define_callback function [oci8_statement.c],
zend_list_addref is called for every lob column of each row. When we
commented out this increment, the statements were destroyed and no
cursor leaks were seen.
case SQLT_RDD:
case SQLT_BLOB:
case SQLT_CLOB:
case SQLT_BFILE: {
...
descr = php_oci_lob_create(outcol->statement->connection, dtype
TSRMLS_CC);
if (!descr) {
return OCI_ERROR;
}
/*zend_list_addref(outcol->statement->id); Commented out
*/
Previous Comments:
[2007-11-29 16:38:45] michael dot virnstein at brodos dot de
I recognized, that when calling oci_free_statement() for every lob
column that is returned by the select, the cursor gets closed
correctly.
So if i have three lob columns in the query, i have to call
oci_free_statment() three times on the statement handle to have it
closed correctly.
[2007-11-22 10:01:34] ghosh at q-one dot com
I'm using OCI8 1.2.4 with Oracle 11g. A previous version doesnt seem to
work, so I cannot test with 1.2.3. It also says so in the changelog for
1.2.4: Add Oracle 11g support. Now, whenever I select (c)lobs (even with
only 1 lob column),, the table v$temporary_lobs keeps filling up and UGA
memory is consumed for each row that's being read until the server
aborts with an out-of-memory error. This does not happen when I run my
statements directly via SQLplus, so it seems to be an OCI8/PHP bug. So,
is this related to this bug or should I file a new one?
[2007-11-15 13:55:42] markus dot knecht at psi dot ch
What i see after upgrading to PHP 5.2.5:
NOT Working: oci8 1.2.4,$Revision: 1.269.2.16.2.38 $
Working: oci8 1.2.3,$Revision: 1.269.2.16.2.29 $
[2007-11-13 21:38:44] iarenuno at eteo dot mondragon dot edu
I can confirm that 1.2.4 has the bug, but 1.2.3 ($Revision:
1.269.2.16.2.30 $) doesn't have it.
Saludos. Iñaki.
[2007-11-09 11:28:26] br at absb dot de
We can reproduce the problem with OCI8 versions before 1.2.4: Version
1.2.3, $Revision: 1.269.2.16.2.32 $
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/42496
--
Edit this bug report at http://bugs.php.net/?id=42496&edit=1
#43455 [Opn->Bgs]: cursor not closed after leaving function when selecting lobs
ID: 43455 Updated by: [EMAIL PROTECTED] Reported By: michael dot virnstein at brodos dot de -Status: Open +Status: Bogus Bug Type:OCI8 related PHP Version: 5.2.5 New Comment: Please do not submit the same bug more than once. An existing bug report already describes this very problem. Even if you feel that your issue is somewhat different, the resolution is likely to be the same. Thank you for your interest in PHP. Appears to be a duplicate of http://bugs.php.net/bug.php?id=42496 Previous Comments: [2007-11-29 16:54:11] michael dot virnstein at brodos dot de Description: PHP 5.2.3 / 5.2.4 / 5.2.5 Apache 2.2.6 Oracle-DB 10.2.0.3.0 Oracle-Client 10.2.0.3 OS Linux Usually, when leaving a function, php closes e.g. statements implicitly. This works as long as a lob is selected. When a lob is selected, i have to call oci_free_statement() explicitly on the statement, otherwise the cursor is kept open and i have a dangling cursor. This issue can cause an "ORA-01000: maximum open cursors exceeded". Our db setting for open_cursors is 300, so every session is allowed to have max 300 cursors open simultaneously. if i run the reproduce code below, i get an ORA-01000 create the following table: create table t_lobdata ( id number not null, data clob ); fill table: insert into t_lobdata select rownum, object_name from sys.all_objects; Reproduce code: --- Expected result: cursor gets closed implicitly when leaving the function Actual result: -- cursor isn't closed, which results in dangling cursors and an ORA-01000 -- Edit this bug report at http://bugs.php.net/?id=43455&edit=1
#43457 [NEW]: prepared statement with incorrect parms doens't throw exception
From: pookey at pookey dot co dot uk
Operating system: linux
PHP version: 5.2CVS-2007-11-29 (CVS)
PHP Bug Type: PostgreSQL related
Bug description: prepared statement with incorrect parms doens't throw
exception
Description:
no exception is thrown when using named params to a prepared statement,
when you pass invalid names.
Interestingly, is that count of the params doesnt' match, an exception is
thrown.
Using the code below, but using sqlite instead..
$pdo = new PDO('sqlite::memory:');
then you do get an exception
# php ./test.php
PDOException: SQLSTATE[HY000]: General error: 25 bind or column index out
of range in /tmp/test.php on line 16
Call Stack:
0.0002 103296 1. {main}() /tmp/test.php:0
0.0014 106912 2. PDOStatement->execute() /tmp/test.php:16
I've not tested with other DBMSs.
Reproduce code:
---
$ cat ./test.php
setAttribute(PDO::ATTR_ERRMODE, PDO::ERRMODE_EXCEPTION);
$pdo->exec('CREATE TABLE test ( field1 varchar, field2 varchar)');
$stmt2 = $pdo->prepare('INSERT INTO test (field1, field2) VALUES
(:param1, :param2)');
$pdo->beginTransaction();
$ret = $stmt2->execute( array(
':param1' => 'wibble',
':nonsense' => 1,
));
var_dump($ret);
var_dump($stmt2->errorInfo());
Expected result:
exception thrown
Actual result:
--
$ ~pookey/src/php5/sapi/cli/php ./test.php
bool(false)
array(3) {
[0]=>
string(5) "HY093"
[1]=>
int(7)
[2]=>
string(0) ""
}
--
Edit bug report at http://bugs.php.net/?id=43457&edit=1
--
Try a CVS snapshot (PHP 4.4):
http://bugs.php.net/fix.php?id=43457&r=trysnapshot44
Try a CVS snapshot (PHP 5.2):
http://bugs.php.net/fix.php?id=43457&r=trysnapshot52
Try a CVS snapshot (PHP 5.3):
http://bugs.php.net/fix.php?id=43457&r=trysnapshot53
Try a CVS snapshot (PHP 6.0):
http://bugs.php.net/fix.php?id=43457&r=trysnapshot60
Fixed in CVS: http://bugs.php.net/fix.php?id=43457&r=fixedcvs
Fixed in release:
http://bugs.php.net/fix.php?id=43457&r=alreadyfixed
Need backtrace: http://bugs.php.net/fix.php?id=43457&r=needtrace
Need Reproduce Script:http://bugs.php.net/fix.php?id=43457&r=needscript
Try newer version:http://bugs.php.net/fix.php?id=43457&r=oldversion
Not developer issue: http://bugs.php.net/fix.php?id=43457&r=support
Expected behavior:http://bugs.php.net/fix.php?id=43457&r=notwrong
Not enough info:
http://bugs.php.net/fix.php?id=43457&r=notenoughinfo
Submitted twice:
http://bugs.php.net/fix.php?id=43457&r=submittedtwice
register_globals: http://bugs.php.net/fix.php?id=43457&r=globals
PHP 3 support discontinued: http://bugs.php.net/fix.php?id=43457&r=php3
Daylight Savings: http://bugs.php.net/fix.php?id=43457&r=dst
IIS Stability:http://bugs.php.net/fix.php?id=43457&r=isapi
Install GNU Sed: http://bugs.php.net/fix.php?id=43457&r=gnused
Floating point limitations: http://bugs.php.net/fix.php?id=43457&r=float
No Zend Extensions: http://bugs.php.net/fix.php?id=43457&r=nozend
MySQL Configuration Error:http://bugs.php.net/fix.php?id=43457&r=mysqlcfg
#37120 [Com]: mod_php5 + apache2 + mail() = hung process
ID: 37120 Comment by: hackish at gmail dot com Reported By: brlcad at mac dot com Status: No Feedback Bug Type: Apache2 related Operating System: FreeBSD 5.2.1 PHP Version: 5.1.2 New Comment: I've got a similar system with the exact same problem. It appears to be related to the way php is communicating with the sendmail process. I'm not yet sure if it is sending an EOF or a simple line with a '.' as that may be the difference between the two. Previous Comments: [2007-10-31 18:22:18] jborges at cybercare dot pt This error still exists My PHP still hangs at the command mail() Any news? [2007-03-02 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". [2007-02-22 10:50:04] [EMAIL PROTECTED] Do not touch the production Apache, setup an Apache instance in your $HOME dir, listening on a different port. [2007-02-22 04:59:45] brlcad at mac dot com Yes, but such a pain in the arse to set up as it's a live production system...where's the magical intuition and devine insight?? :-) I'll see if I can get an updated backtrace. Cheers! [2007-02-21 23:16:17] [EMAIL PROTECTED] >Now with whatever change was made in mail() since 5.2.1, > it crashes the httpd. A gdb backtrace is worth of thousand words. 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/37120 -- Edit this bug report at http://bugs.php.net/?id=37120&edit=1
#43454 [Opn]: xsl:include / xslt_based_dir
ID: 43454
Updated by: [EMAIL PROTECTED]
Reported By: emmanuel dot de-peretti at cinqas dot fr
Status: Open
-Bug Type: Website problem
+Bug Type: XSLT related
Operating System: windows
-PHP Version: Irrelevant
+PHP Version: 5.2
New Comment:
Not a php.net website problem, reclassified.
Previous Comments:
[2007-11-29 16:52:20] emmanuel dot de-peretti at cinqas dot fr
Description:
Hi,
Since 5.2.x, the commande
setParameter('sablotron','xslt_base_dir',$file) seems doesnt't work if
you have setParameter('sablotron','xslt_base_dir',$chemin);
a bug is report only since php 5.2x before, it's good
--
Edit this bug report at http://bugs.php.net/?id=43454&edit=1
#42496 [Com]: cursor is not closed when using 2 clobs in a select query
ID: 42496 Comment by: michael dot virnstein at brodos dot de Reported By: iddekingej at lycos dot com Status: Open Bug Type: OCI8 related Operating System: win 2000 PHP Version: 5.2.4 New Comment: I recognized, that when calling oci_free_statement() for every lob column that is returned by the select, the cursor gets closed correctly. So if i have three lob columns in the query, i have to call oci_free_statment() three times on the statement handle to have it closed correctly. Previous Comments: [2007-11-22 10:01:34] ghosh at q-one dot com I'm using OCI8 1.2.4 with Oracle 11g. A previous version doesnt seem to work, so I cannot test with 1.2.3. It also says so in the changelog for 1.2.4: Add Oracle 11g support. Now, whenever I select (c)lobs (even with only 1 lob column),, the table v$temporary_lobs keeps filling up and UGA memory is consumed for each row that's being read until the server aborts with an out-of-memory error. This does not happen when I run my statements directly via SQLplus, so it seems to be an OCI8/PHP bug. So, is this related to this bug or should I file a new one? [2007-11-15 13:55:42] markus dot knecht at psi dot ch What i see after upgrading to PHP 5.2.5: NOT Working: oci8 1.2.4,$Revision: 1.269.2.16.2.38 $ Working: oci8 1.2.3,$Revision: 1.269.2.16.2.29 $ [2007-11-13 21:38:44] iarenuno at eteo dot mondragon dot edu I can confirm that 1.2.4 has the bug, but 1.2.3 ($Revision: 1.269.2.16.2.30 $) doesn't have it. Saludos. Iñaki. [2007-11-09 11:28:26] br at absb dot de We can reproduce the problem with OCI8 versions before 1.2.4: Version 1.2.3, $Revision: 1.269.2.16.2.32 $ [2007-11-09 03:21:13] martin at catalyst dot net dot nz > Does setting oci8.statement_cache_size = 0 change the behavior? It does not in our tests, unfortunately. 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/42496 -- Edit this bug report at http://bugs.php.net/?id=42496&edit=1
#43456 [NEW]: forcing type of variable in class
From: kjarli at gmail dot com Operating system: PHP version: 5.2.5 PHP Bug Type: Feature/Change Request Bug description: forcing type of variable in class Description: Why not adding something like this in classes: public $array:Array; private $bool:Bool = false; protected $number:Number = 40; var $string:String = 'a text'; This is like forcing a variable into a bool, array, number etc. This should be pure for classes only. Assigning an array value to like a :Number, will cause a notice error. This is usefull for 1. Debugging 2. accessing public values 3. If you are working with more than 1 person, your class won't get messed up. 4. if you use like :Number, and you insert '10', it can force it into a number. -- Edit bug report at http://bugs.php.net/?id=43456&edit=1 -- Try a CVS snapshot (PHP 4.4): http://bugs.php.net/fix.php?id=43456&r=trysnapshot44 Try a CVS snapshot (PHP 5.2): http://bugs.php.net/fix.php?id=43456&r=trysnapshot52 Try a CVS snapshot (PHP 5.3): http://bugs.php.net/fix.php?id=43456&r=trysnapshot53 Try a CVS snapshot (PHP 6.0): http://bugs.php.net/fix.php?id=43456&r=trysnapshot60 Fixed in CVS: http://bugs.php.net/fix.php?id=43456&r=fixedcvs Fixed in release: http://bugs.php.net/fix.php?id=43456&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=43456&r=needtrace Need Reproduce Script:http://bugs.php.net/fix.php?id=43456&r=needscript Try newer version:http://bugs.php.net/fix.php?id=43456&r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=43456&r=support Expected behavior:http://bugs.php.net/fix.php?id=43456&r=notwrong Not enough info: http://bugs.php.net/fix.php?id=43456&r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=43456&r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=43456&r=globals PHP 3 support discontinued: http://bugs.php.net/fix.php?id=43456&r=php3 Daylight Savings: http://bugs.php.net/fix.php?id=43456&r=dst IIS Stability:http://bugs.php.net/fix.php?id=43456&r=isapi Install GNU Sed: http://bugs.php.net/fix.php?id=43456&r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=43456&r=float No Zend Extensions: http://bugs.php.net/fix.php?id=43456&r=nozend MySQL Configuration Error:http://bugs.php.net/fix.php?id=43456&r=mysqlcfg
#43455 [NEW]: cursor not closed after leaving function when selecting lobs
From: michael dot virnstein at brodos dot de Operating system: PHP version: 5.2.5 PHP Bug Type: OCI8 related Bug description: cursor not closed after leaving function when selecting lobs Description: PHP 5.2.3 / 5.2.4 / 5.2.5 Apache 2.2.6 Oracle-DB 10.2.0.3.0 Oracle-Client 10.2.0.3 OS Linux Usually, when leaving a function, php closes e.g. statements implicitly. This works as long as a lob is selected. When a lob is selected, i have to call oci_free_statement() explicitly on the statement, otherwise the cursor is kept open and i have a dangling cursor. This issue can cause an "ORA-01000: maximum open cursors exceeded". Our db setting for open_cursors is 300, so every session is allowed to have max 300 cursors open simultaneously. if i run the reproduce code below, i get an ORA-01000 create the following table: create table t_lobdata ( id number not null, data clob ); fill table: insert into t_lobdata select rownum, object_name from sys.all_objects; Reproduce code: --- Expected result: cursor gets closed implicitly when leaving the function Actual result: -- cursor isn't closed, which results in dangling cursors and an ORA-01000 -- Edit bug report at http://bugs.php.net/?id=43455&edit=1 -- Try a CVS snapshot (PHP 4.4): http://bugs.php.net/fix.php?id=43455&r=trysnapshot44 Try a CVS snapshot (PHP 5.2): http://bugs.php.net/fix.php?id=43455&r=trysnapshot52 Try a CVS snapshot (PHP 5.3): http://bugs.php.net/fix.php?id=43455&r=trysnapshot53 Try a CVS snapshot (PHP 6.0): http://bugs.php.net/fix.php?id=43455&r=trysnapshot60 Fixed in CVS: http://bugs.php.net/fix.php?id=43455&r=fixedcvs Fixed in release: http://bugs.php.net/fix.php?id=43455&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=43455&r=needtrace Need Reproduce Script:http://bugs.php.net/fix.php?id=43455&r=needscript Try newer version:http://bugs.php.net/fix.php?id=43455&r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=43455&r=support Expected behavior:http://bugs.php.net/fix.php?id=43455&r=notwrong Not enough info: http://bugs.php.net/fix.php?id=43455&r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=43455&r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=43455&r=globals PHP 3 support discontinued: http://bugs.php.net/fix.php?id=43455&r=php3 Daylight Savings: http://bugs.php.net/fix.php?id=43455&r=dst IIS Stability:http://bugs.php.net/fix.php?id=43455&r=isapi Install GNU Sed: http://bugs.php.net/fix.php?id=43455&r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=43455&r=float No Zend Extensions: http://bugs.php.net/fix.php?id=43455&r=nozend MySQL Configuration Error:http://bugs.php.net/fix.php?id=43455&r=mysqlcfg
#28711 [Com]: $QUERY_STRING is define with null instead of stay undefine when no query string
ID: 28711 Comment by: schindler dot kimberly at yahoo dot com Reported By: sikachu at beezone dot net Status: No Feedback Bug Type: Unknown/Other Function Operating System: Windows 2000 PHP Version: 5.0.0RC3 New Comment: the truth Previous Comments: [2005-01-22 01:00:10] 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". [2005-01-15 00:10:43] [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-06-18 15:04:28] sikachu at beezone dot net Looks like nobody else got a same problem and also no staff come to this topic regarding this bug. I'm fine right now with using empty() instead isset(). So, I may close this one after a while. I really want somebody to have a same environment (PHP5 ISAPI + IIS5) and test with me. I want to see that we got the same result or not [2004-06-11 01:24:59] imprestavel at gameguru dot com dot br Sorry... I meant i tested with both (4.3.7 and 5RC3) *CGI versions* with register_globals On and Off (under Apache2) [2004-06-11 01:20:18] imprestavel at gameguru dot com dot br Tested with both (4.3.7 and 5RC3) with register_globals On and Off (on both) and they all had the same behavior Maybe its some weird thing between php and the server... Your 4.3.7 server is running IIS5, right? Maybe it only passes query string to cgi if its not empty... In that case, the only reason why your script works(while it shouldnt), is because IIS works how it shouldnt hehe Anyway, i think you should change isset to empty for cases like the one you described But lets wait for someone from the staff to reply... 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/28711 -- Edit this bug report at http://bugs.php.net/?id=28711&edit=1
#43453 [NEW]: wrong result if the decimal is not a dot
From: bammo_merdini at hotmail dot com Operating system: Windows XP Pro PHP version: 5.2.5 PHP Bug Type: *Math Functions Bug description: wrong result if the decimal is not a dot Description: If I use number_format() with "." as decimal point and then round it with 1 decimal, it'll work fine, but not if the decimal point is ",". I'm using WAMP5 and haven't done any changes at all to php.ini. Reproduce code: --- Expected result: A: 976.56 B: 976,56 Actual result: -- A: 976.56 B: 976 -- Edit bug report at http://bugs.php.net/?id=43453&edit=1 -- Try a CVS snapshot (PHP 4.4): http://bugs.php.net/fix.php?id=43453&r=trysnapshot44 Try a CVS snapshot (PHP 5.2): http://bugs.php.net/fix.php?id=43453&r=trysnapshot52 Try a CVS snapshot (PHP 5.3): http://bugs.php.net/fix.php?id=43453&r=trysnapshot53 Try a CVS snapshot (PHP 6.0): http://bugs.php.net/fix.php?id=43453&r=trysnapshot60 Fixed in CVS: http://bugs.php.net/fix.php?id=43453&r=fixedcvs Fixed in release: http://bugs.php.net/fix.php?id=43453&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=43453&r=needtrace Need Reproduce Script:http://bugs.php.net/fix.php?id=43453&r=needscript Try newer version:http://bugs.php.net/fix.php?id=43453&r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=43453&r=support Expected behavior:http://bugs.php.net/fix.php?id=43453&r=notwrong Not enough info: http://bugs.php.net/fix.php?id=43453&r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=43453&r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=43453&r=globals PHP 3 support discontinued: http://bugs.php.net/fix.php?id=43453&r=php3 Daylight Savings: http://bugs.php.net/fix.php?id=43453&r=dst IIS Stability:http://bugs.php.net/fix.php?id=43453&r=isapi Install GNU Sed: http://bugs.php.net/fix.php?id=43453&r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=43453&r=float No Zend Extensions: http://bugs.php.net/fix.php?id=43453&r=nozend MySQL Configuration Error:http://bugs.php.net/fix.php?id=43453&r=mysqlcfg
#43105 [Com]: PHP seems to fail to close open files.
ID: 43105 Comment by: marcus dot mueller at grintsch dot com Reported By: ian at onlineloop dot com Status: Assigned Bug Type: Apache2 related Operating System: Solaris 10 PHP Version: 5.2.5RC2-dev Assigned To: ab5602 New Comment: As I stated above we have this issue on two Linux boxes with self-compiled PHP binaries. These were compiled using gcc! Previous Comments: [2007-11-28 16:36:24] ian at onlineloop dot com Coming back to the bug report here now. In the meantime some private emails were exchanged, including a pfiles output from Solaris showing that PHP had over 210,000 open files after 24 hours running on our servers. Within 48 hours (we let it go this far onyl once), apache/php eats around 12Gb of RAM and has between 170 and 220 child processes with over 230,000 open files. Under 5.1.6 the usage is more around 1.5-2Gb ram, and 30-70 child processes, with rarely more than 100 open files (only when we are really under load do we get to more than about 800 open files at any one time). A small patch was sent to me to try, however this has changed nothing. I was also asked to compile with gcc if possible, however this is not feasible as too many other things would have to be recompiled. Besides, we specifically went away from gcc because everything we had that was compiled with gcc was seg faulting all the time, however with the Sun Studio compiler suite, everything is stable. I seriously doubt this is an apache bug, why were things working with previous versions of PHP, and not this one? [2007-11-28 15:02:11] grknight at iwon dot com I am also experiencing this issue. We are running Apache 2.2.3 on Redhat EL 3 and recently tried to update to 5.2.5 from 5.2.3 to fix the security issues. The moment 5.2.5 was activated, connections failed to close in apache and resulted in hung processes. I also tried 5.2.4 with the same results. No configurations were changed nor PHP scripts. Something changed in the PHP processes that prevents the apxs2handler from exiting between 5.2.3 and 5.2.4. Configs available on request. [2007-11-26 14:08:48] marcus dot mueller at grintsch dot com I doubt this is an Apache issue since we're experiencing the same symptons as hwallenstone at gmx dot here on two debian linux boxes, one using the 64bit version of Apache's httpd 2.2.4, the other using the 32bit version of httpd 2.0.59. httpd processes seem to hang i.e. they don't close the connection (telling from /server-status) resulting in the issues mentioned above. I first noticed this behaviour when switching from PHP 5.2.3 to PHP 5.2.4, both self-compiled using the same configure options. PHP 5.2.3, unlike 5.2.4 and 5.2.5, does not expose this behaviour. I hope this info might narrow down your search path a little bit. [2007-11-25 14:21:58] hwallenstone at gmx dot de I think we have the same problem here. I have updated one server of a cluster of busy servers from a patched 5.2.1 to 5.2.5 . The number of apache processes is growing and as a consequence of this, the number of open files increases. We have about 50 processes running on average machines; on the 5.2.5-one the number constantly grows until it reaches my MaxClients Limit. Trying to stop apache, I get hundreds of entries like [Sun Nov 25 14:14:55 2007] [error] could not make child process 28546 exit, attempting to continue anyway This problem **definitely** has come with the upgrade from 5.2.1 to 5.2.5. Nothing else was changed. So it doesn't look like this is a old apache bug. [2007-11-20 09:40:33] [EMAIL PROTECTED] IIRC, this is actually an Apache bug. PHP is not the only module which suffers as 3rd party of it.. 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/43105 -- Edit this bug report at http://bugs.php.net/?id=43105&edit=1
#43452 [NEW]: strtotime returns wrong date when requested day is same as first day of the mon
From: sean dot thorne at gmail dot com
Operating system: Mac OS X 10.4.11
PHP version: 5.2CVS-2007-11-29 (CVS)
PHP Bug Type: Date/time related
Bug description: strtotime returns wrong date when requested day is same as
first day of the mon
Description:
When asking strtotime for the 3rd thursday in a month and the first day of
that month is thursday, it ignores the first thursday. It then begins to
count after that first Thursday and returns the fourth Thursday.
Reproduce code:
---
$day = strtotime("3 Thursday Nov 2007");
echo date("m-d-Y", $day);
Expected result:
11-15-2007
Actual result:
--
11-22-2007
--
Edit bug report at http://bugs.php.net/?id=43452&edit=1
--
Try a CVS snapshot (PHP 4.4):
http://bugs.php.net/fix.php?id=43452&r=trysnapshot44
Try a CVS snapshot (PHP 5.2):
http://bugs.php.net/fix.php?id=43452&r=trysnapshot52
Try a CVS snapshot (PHP 5.3):
http://bugs.php.net/fix.php?id=43452&r=trysnapshot53
Try a CVS snapshot (PHP 6.0):
http://bugs.php.net/fix.php?id=43452&r=trysnapshot60
Fixed in CVS: http://bugs.php.net/fix.php?id=43452&r=fixedcvs
Fixed in release:
http://bugs.php.net/fix.php?id=43452&r=alreadyfixed
Need backtrace: http://bugs.php.net/fix.php?id=43452&r=needtrace
Need Reproduce Script:http://bugs.php.net/fix.php?id=43452&r=needscript
Try newer version:http://bugs.php.net/fix.php?id=43452&r=oldversion
Not developer issue: http://bugs.php.net/fix.php?id=43452&r=support
Expected behavior:http://bugs.php.net/fix.php?id=43452&r=notwrong
Not enough info:
http://bugs.php.net/fix.php?id=43452&r=notenoughinfo
Submitted twice:
http://bugs.php.net/fix.php?id=43452&r=submittedtwice
register_globals: http://bugs.php.net/fix.php?id=43452&r=globals
PHP 3 support discontinued: http://bugs.php.net/fix.php?id=43452&r=php3
Daylight Savings: http://bugs.php.net/fix.php?id=43452&r=dst
IIS Stability:http://bugs.php.net/fix.php?id=43452&r=isapi
Install GNU Sed: http://bugs.php.net/fix.php?id=43452&r=gnused
Floating point limitations: http://bugs.php.net/fix.php?id=43452&r=float
No Zend Extensions: http://bugs.php.net/fix.php?id=43452&r=nozend
MySQL Configuration Error:http://bugs.php.net/fix.php?id=43452&r=mysqlcfg
#43451 [NEW]: Session data got loaded multiple times for different users
From: mg at memedia dot de Operating system: GNU/Debian 4.0 PHP version: 5.2.5 PHP Bug Type: Session related Bug description: Session data got loaded multiple times for different users Description: A customer was forwarded to me on the phone today, telling me she would see the customer area of another customer on our online-shop. That's was indeed very surprising. The site uses no client side cookies, except the one form the php session management. Anyway, she got on our site by typing in the URL into the address bar, no injections and stuff. Moreover i found out that she was not the only one with the "problem". >From 12:14:28 to 13:57:36 i count about 10 different IP adresses with different browsers in our logs that used ONE session (d28b9616a3013ef6441f8e4383d7e05b). The session must have been loaded multiple times, because we put that data also in our db-based user-tracking. It seems the session was started different times with the same SessionID. There was no session id given by URL or cookie. People came according to the referer from different sites. As i said we use the PHP session managment. There are about 20-30 people most of the time online. Not every one was affected. The file itself (under /var/lib/php5) seems to be ok. We're using the distribution from dotdeb.org on our servers. Any clues where the problem could hang? Is it Apache or PHP? How ist the has for the session file created? I guess i will add an IP-referer and Browser User Agent check first to avoid the problem in future. Reproduce code: --- -- -- Edit bug report at http://bugs.php.net/?id=43451&edit=1 -- Try a CVS snapshot (PHP 4.4): http://bugs.php.net/fix.php?id=43451&r=trysnapshot44 Try a CVS snapshot (PHP 5.2): http://bugs.php.net/fix.php?id=43451&r=trysnapshot52 Try a CVS snapshot (PHP 5.3): http://bugs.php.net/fix.php?id=43451&r=trysnapshot53 Try a CVS snapshot (PHP 6.0): http://bugs.php.net/fix.php?id=43451&r=trysnapshot60 Fixed in CVS: http://bugs.php.net/fix.php?id=43451&r=fixedcvs Fixed in release: http://bugs.php.net/fix.php?id=43451&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=43451&r=needtrace Need Reproduce Script:http://bugs.php.net/fix.php?id=43451&r=needscript Try newer version:http://bugs.php.net/fix.php?id=43451&r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=43451&r=support Expected behavior:http://bugs.php.net/fix.php?id=43451&r=notwrong Not enough info: http://bugs.php.net/fix.php?id=43451&r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=43451&r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=43451&r=globals PHP 3 support discontinued: http://bugs.php.net/fix.php?id=43451&r=php3 Daylight Savings: http://bugs.php.net/fix.php?id=43451&r=dst IIS Stability:http://bugs.php.net/fix.php?id=43451&r=isapi Install GNU Sed: http://bugs.php.net/fix.php?id=43451&r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=43451&r=float No Zend Extensions: http://bugs.php.net/fix.php?id=43451&r=nozend MySQL Configuration Error:http://bugs.php.net/fix.php?id=43451&r=mysqlcfg
#43450 [NEW]: Memory leak on some functions with implicit object __toString() call
From: [EMAIL PROTECTED]
Operating system: Any
PHP version: 5.2.5
PHP Bug Type: Scripting Engine problem
Bug description: Memory leak on some functions with implicit object
__toString() call
Description:
Under certain circumenstances, the implicit call to __toString() on an
object may lead to memory leaks.
In the reproducable example, the following line leaks ($o is a simply
object):
md5($o);
But this line doesn't:
md5($o->__toString());
This only applies to certain functions, I've identifier md5, sha1 and
crc32.
If I try other examples like strstr or strlen, there's no leak at all.
A wild guess is that this maybe has to do whether the function internally
uses zend_parse_parameters() or zend_get_parameters_ex().
The function which leak use zend_parse_parameters(), the others don't.
But this may completely accidental.
It seems very related to bug#38591. However I don't see how bug#38604 is
related to this issue (mentioned in bug#38591).
This leak was most notable found in an application which is supposed to
run for a long time, even hours. So usually within web application this is
not an issue.
Reproduce code:
---
__toString());
# does not leak either way
# strstr($o, 'f');
#strstr($o->__toString(), 'f');
if ($i % 1e3 == 0) {
printf("%u: %1.2f KB\n",
$i, memory_get_usage(true) / 1024);
}
}
Expected result:
Constant memory usage.
Actual result:
--
Memory grows and grows.
--
Edit bug report at http://bugs.php.net/?id=43450&edit=1
--
Try a CVS snapshot (PHP 4.4):
http://bugs.php.net/fix.php?id=43450&r=trysnapshot44
Try a CVS snapshot (PHP 5.2):
http://bugs.php.net/fix.php?id=43450&r=trysnapshot52
Try a CVS snapshot (PHP 5.3):
http://bugs.php.net/fix.php?id=43450&r=trysnapshot53
Try a CVS snapshot (PHP 6.0):
http://bugs.php.net/fix.php?id=43450&r=trysnapshot60
Fixed in CVS: http://bugs.php.net/fix.php?id=43450&r=fixedcvs
Fixed in release:
http://bugs.php.net/fix.php?id=43450&r=alreadyfixed
Need backtrace: http://bugs.php.net/fix.php?id=43450&r=needtrace
Need Reproduce Script:http://bugs.php.net/fix.php?id=43450&r=needscript
Try newer version:http://bugs.php.net/fix.php?id=43450&r=oldversion
Not developer issue: http://bugs.php.net/fix.php?id=43450&r=support
Expected behavior:http://bugs.php.net/fix.php?id=43450&r=notwrong
Not enough info:
http://bugs.php.net/fix.php?id=43450&r=notenoughinfo
Submitted twice:
http://bugs.php.net/fix.php?id=43450&r=submittedtwice
register_globals: http://bugs.php.net/fix.php?id=43450&r=globals
PHP 3 support discontinued: http://bugs.php.net/fix.php?id=43450&r=php3
Daylight Savings: http://bugs.php.net/fix.php?id=43450&r=dst
IIS Stability:http://bugs.php.net/fix.php?id=43450&r=isapi
Install GNU Sed: http://bugs.php.net/fix.php?id=43450&r=gnused
Floating point limitations: http://bugs.php.net/fix.php?id=43450&r=float
No Zend Extensions: http://bugs.php.net/fix.php?id=43450&r=nozend
MySQL Configuration Error:http://bugs.php.net/fix.php?id=43450&r=mysqlcfg
#43449 [NEW]: Segmentation Fault when calling PL/SQL-function wich returns ref cursor
From: michael dot virnstein at brodos dot de Operating system: Linux PHP version: 5.2.5 PHP Bug Type: OCI8 related Bug description: Segmentation Fault when calling PL/SQL-function wich returns ref cursor Description: PHP: since 5.2.4 Apache: 2.2.6 Oracle DB: 10.2.0.3.0 Oracle-Client: 10.2.0.3 OS: Linux When i'm calling a PL/SQL-function, which returns a ref cursor, more than once, php segfaults. When i call the PL/SQL-function only once, everything works. The bug is present since PHP 5.2.4, which introduced OCI 1.2.4 Create the following Oracle-package: create or replace package testpackage is type cursortype is ref Cursor; function testcursor return cursortype; end testpackage; / create or replace package body testpackage is function testcursor return cursortype is retCursor cursorType; begin Open retCursor For 'select * from dual'; return retCursor; end; end testpackage; / Reproduce code: --- Expected result: display var_dump result Actual result: -- apache segmentation fault -- Edit bug report at http://bugs.php.net/?id=43449&edit=1 -- Try a CVS snapshot (PHP 4.4): http://bugs.php.net/fix.php?id=43449&r=trysnapshot44 Try a CVS snapshot (PHP 5.2): http://bugs.php.net/fix.php?id=43449&r=trysnapshot52 Try a CVS snapshot (PHP 5.3): http://bugs.php.net/fix.php?id=43449&r=trysnapshot53 Try a CVS snapshot (PHP 6.0): http://bugs.php.net/fix.php?id=43449&r=trysnapshot60 Fixed in CVS: http://bugs.php.net/fix.php?id=43449&r=fixedcvs Fixed in release: http://bugs.php.net/fix.php?id=43449&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=43449&r=needtrace Need Reproduce Script:http://bugs.php.net/fix.php?id=43449&r=needscript Try newer version:http://bugs.php.net/fix.php?id=43449&r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=43449&r=support Expected behavior:http://bugs.php.net/fix.php?id=43449&r=notwrong Not enough info: http://bugs.php.net/fix.php?id=43449&r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=43449&r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=43449&r=globals PHP 3 support discontinued: http://bugs.php.net/fix.php?id=43449&r=php3 Daylight Savings: http://bugs.php.net/fix.php?id=43449&r=dst IIS Stability:http://bugs.php.net/fix.php?id=43449&r=isapi Install GNU Sed: http://bugs.php.net/fix.php?id=43449&r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=43449&r=float No Zend Extensions: http://bugs.php.net/fix.php?id=43449&r=nozend MySQL Configuration Error:http://bugs.php.net/fix.php?id=43449&r=mysqlcfg
#43445 [Opn]: Segfault when selecting from a "long" column using Odbc with TimesTen driver
ID: 43445
User updated by: akoebel at capgemini dot fr
Reported By: akoebel at capgemini dot fr
Status: Open
Bug Type: PDO related
Operating System: Ubuntu 7.10
-PHP Version: 5.2.5
+PHP Version: 5.2.6 20071127
New Comment:
Tested today with version 5.2.6 from november 27th, 2007
PHP was compiled with debugging enabled and pdo-odbc=unixOdbc
unixOdbc was version 2.2.12
Here's the backtrace:
Program received signal SIGSEGV, Segmentation fault.
[Switching to Thread -1216276816 (LWP 10102)]
0xb72439c5 in extract_sql_error_rec (head=0x8392858,
sqlstate=0xbf8e3a93 "0", rec_number=1,
native_error=0xbf8e3a98,
message_text=0xbf8e3ab8 "ocket_sendto", buffer_length=1023,
text_length=0xbf8e3ab0) at SQLGetDiagRec.c:440
440 as1 = (SQLCHAR*) unicode_to_ansi_alloc( ptr -> msg,
SQL_NTS, __get_connection( head ));
(gdb) bt
#0 0xb72439c5 in extract_sql_error_rec (head=0x8392858,
sqlstate=0xbf8e3a93 "0", rec_number=1,
native_error=0xbf8e3a98,
message_text=0xbf8e3ab8 "ocket_sendto", buffer_length=1023,
text_length=0xbf8e3ab0) at SQLGetDiagRec.c:440
#1 0xb724468d in SQLGetDiagRec (handle_type=3, handle=0x8392430,
rec_number=2, sqlstate=0xbf8e3a93 "0", native=0xbf8e3a98,
message_text=0xbf8e3ab8 "ocket_sendto", buffer_length=1023,
text_length_ptr=0xbf8e3ab0) at SQLGetDiagRec.c:741
#2 0xb746694d in pdo_odbc_error (dbh=0x82e78a4, stmt=0x82e9638,
statement=0x8392430, what=0xb7771b9d "SQLFetchScroll",
file=0xb7771ac8
"/home/sieadmin/php5.2-200711271530/ext/pdo_odbc/odbc_stmt.c", line=375,
tsrm_ls=0x8135388)
at
/home/sieadmin/php5.2-200711271530/ext/pdo_odbc/odbc_driver.c:120
#3 0xb7468a9a in odbc_stmt_fetch (stmt=0x82e9638,
ori=PDO_FETCH_ORI_NEXT,
offset=0, tsrm_ls=0x8135388)
at /home/sieadmin/php5.2-200711271530/ext/pdo_odbc/odbc_stmt.c:375
#4 0xb745e329 in do_fetch_common (stmt=0x82e9638,
ori=PDO_FETCH_ORI_NEXT,
offset=0, do_bind=1, tsrm_ls=0x8135388)
at /home/sieadmin/php5.2-200711271530/ext/pdo/pdo_stmt.c:669
#5 0xb745f764 in do_fetch (stmt=0x82e9638, do_bind=1,
return_value=0x82e9114,
how=PDO_FETCH_BOTH, ori=PDO_FETCH_ORI_NEXT, offset=0,
return_all=0x0,
tsrm_ls=0x8135388)
at /home/sieadmin/php5.2-200711271530/ext/pdo/pdo_stmt.c:903
#6 0xb7461025 in zim_PDOStatement_fetch (ht=0,
return_value=0x82e9114,
return_value_ptr=0x0, this_ptr=0x82e9094, return_value_used=1,
tsrm_ls=0x8135388)
at /home/sieadmin/php5.2-200711271530/ext/pdo/pdo_stmt.c:1342
#7 0xb76a47ea in zend_do_fcall_common_helper_SPEC
(execute_data=0xbf8e4360,
tsrm_ls=0x8135388)
at /home/sieadmin/php5.2-200711271530/Zend/zend_vm_execute.h:200
#8 0xb76a57e3 in ZEND_DO_FCALL_BY_NAME_SPEC_HANDLER
(execute_data=0xbf8e4360,
tsrm_ls=0x8135388)
at /home/sieadmin/php5.2-200711271530/Zend/zend_vm_execute.h:322
#9 0xb76a4284 in execute (op_array=0x82e77e8, tsrm_ls=0x8135388)
at /home/sieadmin/php5.2-200711271530/Zend/zend_vm_execute.h:92
#10 0xb767b7e5 in zend_execute_scripts (type=8, tsrm_ls=0x8135388,
retval=0x0,
file_count=3) at
/home/sieadmin/php5.2-200711271530/Zend/zend.c:1134
#11 0xb761596c in php_execute_script (primary_file=0xbf8e66cc,
tsrm_ls=0x8135388) at
/home/sieadmin/php5.2-200711271530/main/main.c:2004
#12 0xb770438e in php_handler (r=0x831f1c0)
at
/home/sieadmin/php5.2-200711271530/sapi/apache2handler/sapi_apache2.c:631
#13 0x08079259 in ap_run_handler ()
#14 0x0807c5b7 in ap_invoke_handler ()
#15 0x08089998 in ap_process_request ()
#16 0x08086c9b in ?? ()
#17 0x0831f1c0 in ?? ()
#18 0x0004 in ?? ()
#19 0x0831f1c0 in ?? ()
#20 0x in ?? ()
Previous Comments:
[2007-11-29 10:36:53] akoebel at capgemini dot fr
Description:
We're having some difficulties using PDO
in conjunction with Oracle TimesTen 7.03 ODBC driver
and long column datatypes.
Oracle table :
CREATE TABLE TEST (ID NUMBER(10) NOT NULL PRIMARY KEY,DATA LONG NOT
NULL);
INSERT INTO TEST VALUES (1,'sample');
TimesTen :
CREATE READONLY CACHE GROUP FROM TEST (ID NUMBER(10) NOT NULL PRIMARY
KEY, DATA VARCHAR(256000);
Note that timesten doesn't support the long datatype directly.
Odbc.ini :
[myDSN]
Datastore=/home/sieadmin/tt
PermSize=100
TempSize=100
UID=test
OracleId=XE
OraclePwd=test
DatabaseCharacterSet=WE8MSWIN1252
[testClient]
DRIVER = /opt/TimesTen/tt70/lib/libtten.so
DataStore=/home/sieadmin/tt
PermSize=100
PHP File :
PDO
prepare($sql);
$rs->execute();
while ($res=$rs->fetch()) {
print_r($res);
}
$conn=null;
?>
This script was executed on these platforms:
-Ubuntu 7.10 with PHP5.2.3 PDO/unixODBC, TimesTen ODBC Driver
-Ubuntu 7.10 with PHP5.2.3 PDO/unixODBC, Oracle ODBC Driver
-Ubuntu 7.10 with PHP5.2.3 ODBC, TimesTen Driver
-Windows with PHP5.2.3 PDO, TimesTen Driver
-Windows with PHP5.2.5 PDO, TimesTen Driver
On Ubuntu with PDO and the timesten driver, the script segfaults,
un
#43427 [Fbk->Csd]: PHP 5.2.3 don't compile with --with-ldap option
ID: 43427 User updated by: srfrogster at gmail dot com Reported By: srfrogster at gmail dot com -Status: Feedback +Status: Closed Bug Type: Compile Failure Operating System: Solaris 10 PHP Version: 5.2.5 New Comment: I try php without ldap and it worked well. The issue was an ldap installation problem, but now it's solved, and php compiles and builds ok. Thanks anyway. I close the bug Previous Comments: [2007-11-29 00:59:46] [EMAIL PROTECTED] Did you try without loading PHP? Or was that Apache+ldap thing without it? [2007-11-28 16:05:24] srfrogster at gmail dot com I have trying to remove the "--with-ldap-sasl" option, but it still crashes and shows the same message. However, when I remove "--with-ldap" option, it compiles and builds correctly. I figure out it may be an issue belonging to ldap installation or something related (I use iplanet-ldap-sdk), because when I try to start the apache server with ldap compatibility, it fails and shows a message which tells that it can't find neither libc.so.6, libpthread.so.0 nor libdl.so.2. Anyway, I'm not sure at all about this, so is it possible to keep opened till I check deeply my theory? Thanks [2007-11-28 12:48:37] [EMAIL PROTECTED] You're trying to enable SASL support but using Solaris LDAP SDK? That doesn't work, this works only with OpenLDAP so get that and try again. (IIRC, you need to compile openldap with sasl support too..) [2007-11-27 15:05:53] srfrogster at gmail dot com Description: Hello phpeople, I'm having problems while compiling PHP-5.2.3 with ldap support. Here is my configure line: ./configure --prefix=/usr/local/php-5.2.3 --with-mysql=/usr/local/mysql --with-mysqli=/usr/local/mysql/bin/mysql_config --with-apxs2=/usr/local/apache2/bin/apxs --with-ldap=/usr --with-openssl=/usr/local/ssl --with-curl=/usr/local --with-gd=/usr/local --with-jpeg-dir=/usr/local --with-png-dir=/usr/local --with-xpm-dir=/usr/local --with-freetype-dir=/usr/local --with-ldap-sasl=/usr/local And it stops when: checking for LDAP support... yes checking for LDAP Cyrus SASL support... /usr/local checking for 3 arg ldap_set_rebind_proc... yes checking for ldap_parse_result... no checking for ldap_parse_reference... no checking for ldap_start_tls_s... no checking for sasl_version in -lldap... no configure: error: LDAP SASL check failed. Please check config.log for more information. Also, I have trying to compile php-5.2.5 with the same configure line, and it fails in the same step, showing the same output message. Checking the "config.log" file, it shows many undefined symbols, almost all of them, first referenced in libnspr4.so. And just above this list of undefined symbols, it shows: ld: warning: file /export/home/SOFTWARE/LDAP_SDK/lib//libnspr4.so: section .stabstr: malformed string table, initial or final byte ld: warning: global symbol `_GLOBAL_OFFSET_TABLE_' has non-global binding: (file /export/home/SOFTWARE/LDAP_SDK/lib//libnss3.so value=LOCL); ld: warning: file /export/home/SOFTWARE/LDAP_SDK/lib//libssl3.so: section .stabstr: malformed string table, initial or final byte ld: warning: global symbol `_GLOBAL_OFFSET_TABLE_' has non-global binding: (file /export/home/SOFTWARE/LDAP_SDK/lib//libssl3.so value=LOCL); ld: warning: file libdl.so.2: required by /export/home/SOFTWARE/LDAP_SDK/lib//libnspr4.so, not found ld: warning: file libpthread.so.0: required by /export/home/SOFTWARE/LDAP_SDK/lib//libnspr4.so, not f ound ld: warning: file libc.so.6: required by /export/home/SOFTWARE/LDAP_SDK/lib//libnspr4.so, not found I have been trying to get these libraries from outside in order to compile again php, but I haven't found them available for Solaris 10. Can you help me with this? Thanks in advance -- Edit this bug report at http://bugs.php.net/?id=43427&edit=1
#43448 [NEW]: PDO Object comparison failure
From: desarrollo at c17 dot net Operating system: Ubuntu Linux 7.10 PHP version: 5.2.5 PHP Bug Type: Class/Object related Bug description: PDO Object comparison failure Description: When I try to compare a PDO object with itself, it's supposed to be equal, but the '==' operator doesn't seems to work properly. Reproduce code: --- Expected result: bool(true) Actual result: -- bool(false) -- Edit bug report at http://bugs.php.net/?id=43448&edit=1 -- Try a CVS snapshot (PHP 4.4): http://bugs.php.net/fix.php?id=43448&r=trysnapshot44 Try a CVS snapshot (PHP 5.2): http://bugs.php.net/fix.php?id=43448&r=trysnapshot52 Try a CVS snapshot (PHP 5.3): http://bugs.php.net/fix.php?id=43448&r=trysnapshot53 Try a CVS snapshot (PHP 6.0): http://bugs.php.net/fix.php?id=43448&r=trysnapshot60 Fixed in CVS: http://bugs.php.net/fix.php?id=43448&r=fixedcvs Fixed in release: http://bugs.php.net/fix.php?id=43448&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=43448&r=needtrace Need Reproduce Script:http://bugs.php.net/fix.php?id=43448&r=needscript Try newer version:http://bugs.php.net/fix.php?id=43448&r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=43448&r=support Expected behavior:http://bugs.php.net/fix.php?id=43448&r=notwrong Not enough info: http://bugs.php.net/fix.php?id=43448&r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=43448&r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=43448&r=globals PHP 3 support discontinued: http://bugs.php.net/fix.php?id=43448&r=php3 Daylight Savings: http://bugs.php.net/fix.php?id=43448&r=dst IIS Stability:http://bugs.php.net/fix.php?id=43448&r=isapi Install GNU Sed: http://bugs.php.net/fix.php?id=43448&r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=43448&r=float No Zend Extensions: http://bugs.php.net/fix.php?id=43448&r=nozend MySQL Configuration Error:http://bugs.php.net/fix.php?id=43448&r=mysqlcfg
#43447 [Opn->Bgs]: comparison in a for-loop is not exact
ID: 43447 Updated by: [EMAIL PROTECTED] Reported By: jumo at gmx dot de -Status: Open +Status: Bogus Bug Type: *General Issues Operating System: Ubuntu Linux PHP Version: 5.2.5 New Comment: Floating point values have a limited precision. Hence a value might not have the same string representation after any processing. That also includes writing a floating point value in your script and directly printing it without any mathematical operations. If you would like to know more about "floats" and what IEEE 754 is read this: http://docs.sun.com/source/806-3568/ncg_goldberg.html Thank you for your interest in PHP. . Previous Comments: [2007-11-29 12:08:02] jumo at gmx dot de Description: the comparison in a special for-loop is not correct. Reproduce code: --- "; } ?> Expected result: 400.84 400.85 400.86 400.87 Actual result: -- 400.84 400.85 400.86 400.87 400.88 -- Edit this bug report at http://bugs.php.net/?id=43447&edit=1
#43437 [Fbk->Opn]: Second SOAP call causes segfault
ID: 43437
User updated by: denis dot arh at gmail dot com
Reported By: denis dot arh at gmail dot com
-Status: Feedback
+Status: Open
Bug Type: SOAP related
Operating System: CentOS 5
PHP Version: 5.2.5
New Comment:
Tried with the latest PHP (from the link you gave me) - still no luck
#0 0x0021f333 in strlen () from /lib/libc.so.6
#1 0x0817a9b6 in get_http_header_value (headers=0x0, type=0x83b8fec
"HTTP/") at /usr/src/php/php5.2-200711290930/ext/soap/php_http.c:1144
#2 0x0817caef in make_http_soap_request (this_ptr=0x9fd5290,
buf=0xa00c740 "http://snaps.php.net/php5.2-latest.tar.gz
For Windows (zip):
http://snaps.php.net/win32/php5.2-win32-latest.zip
For Windows (installer):
http://snaps.php.net/win32/php5.2-win32-installer-latest.msi
I think it was fixed already, so please try the snapshot to verify.
[2007-11-28 10:10:44] denis dot arh at gmail dot com
Description:
Same problems (segfault) with second call on same client object
(re-opening SoapClient solves this issue)
Similar problems as described here: #35570
Reproduce code:
---
$c = new SoapClient('api_v0.2.wsdl', array(
'encoding' => 'UTF-8',
'trace' => true,
'exceptions' => true,
));
// call 1 --> OK
// call 2 --> segfault
Expected result:
Both calls ok, no segfault
Actual result:
--
PHP Warning:
Warning: SoapClient::__doRequest(): 31 bytes of buffered data lost
during stream conversion!
Segmentation fault
-
#0 0x00b4 in strlen () from /lib/libc.so.6
#1 0x012589c2 in get_http_header_value (headers=0x0, type=0x127c3fb
"HTTP/") at /usr/src/redhat/BUILD/php-5.2.5/ext/soap/php_http.c:1144
#2 0x0125ad3a in make_http_soap_request (this_ptr=0x84d9bd0,
buf=0x850a6a0 "\nhttp://schemas.xmlsoap.org/soap/envelope/\";
xmlns:ns1=\"http://schemas.zejn.si/AvtoPortal/\";>"...,
buf_size=302, location=0x84e49a4
"http://dev.avtooglasnik.lan/api/api_v0.2.php";,
soapaction=0x84e4b00
"http://dev.avtooglasnik.lan/api/php?application=embedded&service=AdCaptureService&method=login";,
soap_version=1, buffer=0x84d9e70, buffer_len=0x84d9e74)
at /usr/src/redhat/BUILD/php-5.2.5/ext/soap/php_http.c:734
#3 0x0123b973 in zim_SoapClient___doRequest (ht=5,
return_value=0x84d9e70, return_value_ptr=0x0, this_ptr=0x84d9bd0,
return_value_used=1)
at /usr/src/redhat/BUILD/php-5.2.5/ext/soap/soap.c:3035
#4 0x0820b4ee in zend_call_function ()
#5 0x0820c4dc in call_user_function_ex ()
#6 0x0820c55b in call_user_function ()
#7 0x01240f19 in do_request (this_ptr=0x84d9bd0, request=, location=0x84e49a4
"http://dev.avtooglasnik.lan/api/api_v0.2.php";,
action=0x84e4b00
"http://dev.avtooglasnik.lan/api/php?application=embedded&service=AdCaptureService&method=login";,
version=1, one_way=0, response=0xbfc75a30)
at /usr/src/redhat/BUILD/php-5.2.5/ext/soap/soap.c:2549
#8 0x01246ba3 in do_soap_call (this_ptr=0x84d9bd0, function=0x84d6b50
"login", function_len=, arg_count=1,
real_args=0x84d9db0, return_value=0x84dc610,
location=0x84e49a4 "http://dev.avtooglasnik.lan/api/api_v0.2.php";,
soap_action=0x0, call_uri=0x0, soap_headers=0x0, output_headers=0x0)
at /usr/src/redhat/BUILD/php-5.2.5/ext/soap/soap.c:2673
#9 0x012479ec in zim_SoapClient___call (ht=2, return_value=0x84dc610,
return_value_ptr=0x0, this_ptr=0x84d9bd0, return_value_used=1)
at /usr/src/redhat/BUILD/php-5.2.5/ext/soap/soap.c:2889
#10 0x0820b4ee in zend_call_function ()
#11 0x0822ca6f in zend_call_method ()
#12 0x08233c05 in zend_std_call_user_call ()
#13 0x08238e20 in zend_do_fcall_common_helper_SPEC ()
#14 0x08237c7d in execute ()
#15 0x08216f1a in zend_execute_scripts ()
#16 0x081d0093 in php_execute_script ()
#17 0x0829cc76 in main ()
--
Edit this bug report at http://bugs.php.net/?id=43437&edit=1
#43447 [NEW]: comparison in a for-loop is not exact
From: jumo at gmx dot de Operating system: Ubuntu Linux PHP version: 5.2.5 PHP Bug Type: *General Issues Bug description: comparison in a for-loop is not exact Description: the comparison in a special for-loop is not correct. Reproduce code: --- "; } ?> Expected result: 400.84 400.85 400.86 400.87 Actual result: -- 400.84 400.85 400.86 400.87 400.88 -- Edit bug report at http://bugs.php.net/?id=43447&edit=1 -- Try a CVS snapshot (PHP 4.4): http://bugs.php.net/fix.php?id=43447&r=trysnapshot44 Try a CVS snapshot (PHP 5.2): http://bugs.php.net/fix.php?id=43447&r=trysnapshot52 Try a CVS snapshot (PHP 5.3): http://bugs.php.net/fix.php?id=43447&r=trysnapshot53 Try a CVS snapshot (PHP 6.0): http://bugs.php.net/fix.php?id=43447&r=trysnapshot60 Fixed in CVS: http://bugs.php.net/fix.php?id=43447&r=fixedcvs Fixed in release: http://bugs.php.net/fix.php?id=43447&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=43447&r=needtrace Need Reproduce Script:http://bugs.php.net/fix.php?id=43447&r=needscript Try newer version:http://bugs.php.net/fix.php?id=43447&r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=43447&r=support Expected behavior:http://bugs.php.net/fix.php?id=43447&r=notwrong Not enough info: http://bugs.php.net/fix.php?id=43447&r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=43447&r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=43447&r=globals PHP 3 support discontinued: http://bugs.php.net/fix.php?id=43447&r=php3 Daylight Savings: http://bugs.php.net/fix.php?id=43447&r=dst IIS Stability:http://bugs.php.net/fix.php?id=43447&r=isapi Install GNU Sed: http://bugs.php.net/fix.php?id=43447&r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=43447&r=float No Zend Extensions: http://bugs.php.net/fix.php?id=43447&r=nozend MySQL Configuration Error:http://bugs.php.net/fix.php?id=43447&r=mysqlcfg
#43444 [Opn->Bgs]: date('F', $timestamp) returns wrong month
ID: 43444
Updated by: [EMAIL PROTECTED]
Reported By: anter dot x at gmail dot com
-Status: Open
+Status: Bogus
Bug Type: Date/time related
Operating System: Windows XP
PHP Version: 5.2.5
New Comment:
It's because mktime() defaults to the day of current date if the day
parameter is omitted. From the manual page for mktime(): "Arguments may
be left out in order from right to left; any arguments thus omitted will
be set to the current value according to the local date and time."
And as february this year had only 28 days and you're giving it 29, it
overflows to march. No bug here.
Previous Comments:
[2007-11-29 10:34:56] anter dot x at gmail dot com
Description:
Function date('F', $timestamp) returns wrong month name.
NOTE:
print mktime(0, 0, 0, 2); // 117270
print mktime(0, 0, 0, 3); // 1175115600
Reproduce code:
---
print date('F', mktime(0, 0, 0, 2));
print date('F', mktime(0, 0, 0, 3));
Expected result:
February
March
Actual result:
--
March
March
--
Edit this bug report at http://bugs.php.net/?id=43444&edit=1
#43388 [Fbk->Csd]: Segmentaion fault(core dupmed) on ibase_connect()
ID: 43388 User updated by: bearsite at gmail dot com Reported By: bearsite at gmail dot com -Status: Feedback +Status: Closed Bug Type: InterBase related Operating System: FreeBSD/amd64 7.0_beta3 PHP Version: 5.2.5 New Comment: I've solve this problem for me. In fact, I think, problem wath in firebird-client2.0.3. As a solution, I 've replace `libfbclient.so.2.0.3` (on my FreeBSD/amd64 7.0_beta3) with a precompiled same file from firebird-client-2.0.3.tbz package for FreeBSD/amd64 6.2STABLE . And than rebuild `php5-interbase` and now everything looks fine. Previous Comments: [2007-11-26 10:45:48] [EMAIL PROTECTED] Please try using this CVS snapshot: http://snaps.php.net/php5.2-latest.tar.gz For Windows (zip): http://snaps.php.net/win32/php5.2-win32-latest.zip For Windows (installer): http://snaps.php.net/win32/php5.2-win32-installer-latest.msi [2007-11-23 11:15:17] bearsite at gmail dot com Description: It looks like php5 - works fine. Until I try to php5-interbase functions. # Options for php5-5.2.5 WITH_CLI=true WITH_CGI=true WITH_SUHOSIN=true WITH_MULTIBYTE=true WITH_FASTCGI=true WITH_PATHINFO=true And php5 compiled only with one extension 'php5-interbase'. No other etnension is used. Firebird-server running on the same mashine and it looks works fine, I can simple connect and make queries from other mashine. //firebird-client-2.0.3_1 //firebird-server-2.0.3_1 Reproduce code: --- Expected result: I expecting to see. >'OK' Actual result: -- But every time I get: >'Segementation fault( core dumped )' or >'Segementation fault: 11' (gdb) bt #0 0x00080153abf9 in ThreadData::restoreSpecific () from /usr/local/lib/libfbclient.so.2 #1 0x00080154fc19 in error () from /usr/local/lib/libfbclient.so.2 #2 0x000801557d66 in REM_attach_database () from /usr/local/lib/libfbclient.so.2 #3 0x00080154551b in isc_attach_database () from /usr/local/lib/libfbclient.so.2 #4 0x00080140732f in _php_ibase_attach_db () from /usr/local/lib/php/20060613-debug/interbase.so #5 0x0008014078c2 in _php_ibase_connect () from /usr/local/lib/php/20060613-debug/interbase.so #6 0x000801407b7f in zif_ibase_connect () from /usr/local/lib/php/20060613-debug/interbase.so #7 0x00594c09 in zend_do_fcall_common_helper_SPEC (execute_data=0x7fffc7e0) at zend_vm_execute.h:200 #8 0x0059afc1 in ZEND_DO_FCALL_SPEC_CONST_HANDLER (execute_data=0x7fffc7e0) at zend_vm_execute.h:1681 #9 0x00594697 in execute (op_array=0x801331558) at zend_vm_execute.h:92 #10 0x00594d98 in zend_do_fcall_common_helper_SPEC (execute_data=0x7fffd0d0) at zend_vm_execute.h:234 #11 0x005959a5 in ZEND_DO_FCALL_BY_NAME_SPEC_HANDLER (execute_data=0x7fffd0d0) at zend_vm_execute.h:322 #12 0x00594697 in execute (op_array=0x80132e718) at zend_vm_execute.h:92 #13 0x00569f76 in zend_execute_scripts (type=8, retval=0x0, file_count=3) at /usr/ports/lang/php5/work/php-5.2.5/Zend/zend.c:1215 #14 0x0050e410 in php_execute_script (primary_file=0x7fffea10) at /usr/ports/lang/php5/work/php-5.2.5/main/main.c:2025 #15 0x005f0325 in main (argc=2, argv=0x7fffeba0) at /usr/ports/lang/php5/work/php-5.2.5/sapi/cli/php_cli.c:1146 -- Edit this bug report at http://bugs.php.net/?id=43388&edit=1
#43442 [Opn->Fbk]: __destruct is calling right after __construct
ID: 43442
Updated by: [EMAIL PROTECTED]
Reported By: cjshark at mail dot ru
-Status: Open
+Status: Feedback
Bug Type: Scripting Engine problem
Operating System: FreeBSD v60
PHP Version: 5.2.5
New Comment:
Me too:
$ src/build/php_5_2/sapi/cli/php t.php
construct
method!!
destruct
So what could be wrong with your build / setup? In what SAPI? What
configure line was used? What 3rd party extensions are loaded?
Previous Comments:
[2007-11-29 08:03:16] [EMAIL PROTECTED]
This is not what I'm seeing, I see the correct:
constructmethod!!destruct
[2007-11-28 17:48:15] cjshark at mail dot ru
Description:
__destruct is calling right after __construct before using any methods!
Reproduce code:
---
class test
{
function __construct()
{
echo "construct";
}
function method($i)
{
echo $i."";
}
function __destruct()
{
echo "destruct";
}
}
$cl = new test();
$cl->method('method!!');
Expected result:
construct
method!!
destruct
Actual result:
--
construct
destruct
method!!
destruct
--
Edit this bug report at http://bugs.php.net/?id=43442&edit=1
#43445 [NEW]: Segfault when selecting from a "long" column using Odbc with TimesTen driver
From: akoebel at capgemini dot fr
Operating system: Ubuntu 7.10
PHP version: 5.2.5
PHP Bug Type: PDO related
Bug description: Segfault when selecting from a "long" column using Odbc with
TimesTen driver
Description:
We're having some difficulties using PDO
in conjunction with Oracle TimesTen 7.03 ODBC driver
and long column datatypes.
Oracle table :
CREATE TABLE TEST (ID NUMBER(10) NOT NULL PRIMARY KEY,DATA LONG NOT
NULL);
INSERT INTO TEST VALUES (1,'sample');
TimesTen :
CREATE READONLY CACHE GROUP FROM TEST (ID NUMBER(10) NOT NULL PRIMARY KEY,
DATA VARCHAR(256000);
Note that timesten doesn't support the long datatype directly.
Odbc.ini :
[myDSN]
Datastore=/home/sieadmin/tt
PermSize=100
TempSize=100
UID=test
OracleId=XE
OraclePwd=test
DatabaseCharacterSet=WE8MSWIN1252
[testClient]
DRIVER = /opt/TimesTen/tt70/lib/libtten.so
DataStore=/home/sieadmin/tt
PermSize=100
PHP File :
PDO
prepare($sql);
$rs->execute();
while ($res=$rs->fetch()) {
print_r($res);
}
$conn=null;
?>
This script was executed on these platforms:
-Ubuntu 7.10 with PHP5.2.3 PDO/unixODBC, TimesTen ODBC Driver
-Ubuntu 7.10 with PHP5.2.3 PDO/unixODBC, Oracle ODBC Driver
-Ubuntu 7.10 with PHP5.2.3 ODBC, TimesTen Driver
-Windows with PHP5.2.3 PDO, TimesTen Driver
-Windows with PHP5.2.5 PDO, TimesTen Driver
On Ubuntu with PDO and the timesten driver, the script segfaults, unless
the long column is restricted to less than 255 characters (with a SUBSTR in
the SQL query).
On windows, the script doesn't segfaults, but no data is displayed from
the long column, wether it is over or under 255 chars long.
Other configurations (using odbc instead of PDO or using the Oracle driver
instead of the TimesTen driver) work well
Unix backtrace (without PHP debug):
Program received signal SIGSEGV, Segmentation fault.
[Switching to Thread -1216518480 (LWP 5544)]
0xb6f719d6 in ?? () from /usr/lib/libodbccr.so.1
(gdb) bt
#0 0xb6f719d6 in ?? () from /usr/lib/libodbccr.so.1
#1 0x083c7310 in ?? ()
#2 0x0001 in ?? ()
#3 0x0001 in ?? ()
#4 0x0001 in ?? ()
#5 0x0001 in ?? ()
#6 0x000e in ?? ()
#7 0x in ?? ()
--
Edit bug report at http://bugs.php.net/?id=43445&edit=1
--
Try a CVS snapshot (PHP 4.4):
http://bugs.php.net/fix.php?id=43445&r=trysnapshot44
Try a CVS snapshot (PHP 5.2):
http://bugs.php.net/fix.php?id=43445&r=trysnapshot52
Try a CVS snapshot (PHP 5.3):
http://bugs.php.net/fix.php?id=43445&r=trysnapshot53
Try a CVS snapshot (PHP 6.0):
http://bugs.php.net/fix.php?id=43445&r=trysnapshot60
Fixed in CVS: http://bugs.php.net/fix.php?id=43445&r=fixedcvs
Fixed in release:
http://bugs.php.net/fix.php?id=43445&r=alreadyfixed
Need backtrace: http://bugs.php.net/fix.php?id=43445&r=needtrace
Need Reproduce Script:http://bugs.php.net/fix.php?id=43445&r=needscript
Try newer version:http://bugs.php.net/fix.php?id=43445&r=oldversion
Not developer issue: http://bugs.php.net/fix.php?id=43445&r=support
Expected behavior:http://bugs.php.net/fix.php?id=43445&r=notwrong
Not enough info:
http://bugs.php.net/fix.php?id=43445&r=notenoughinfo
Submitted twice:
http://bugs.php.net/fix.php?id=43445&r=submittedtwice
register_globals: http://bugs.php.net/fix.php?id=43445&r=globals
PHP 3 support discontinued: http://bugs.php.net/fix.php?id=43445&r=php3
Daylight Savings: http://bugs.php.net/fix.php?id=43445&r=dst
IIS Stability:http://bugs.php.net/fix.php?id=43445&r=isapi
Install GNU Sed: http://bugs.php.net/fix.php?id=43445&r=gnused
Floating point limitations: http://bugs.php.net/fix.php?id=43445&r=float
No Zend Extensions: http://bugs.php.net/fix.php?id=43445&r=nozend
MySQL Configuration Error:http://bugs.php.net/fix.php?id=43445&r=mysqlcfg
#43444 [NEW]: date('F', $timestamp) returns wrong month
From: anter dot x at gmail dot com
Operating system: Windows XP
PHP version: 5.2.5
PHP Bug Type: Date/time related
Bug description: date('F', $timestamp) returns wrong month
Description:
Function date('F', $timestamp) returns wrong month name.
NOTE:
print mktime(0, 0, 0, 2); // 117270
print mktime(0, 0, 0, 3); // 1175115600
Reproduce code:
---
print date('F', mktime(0, 0, 0, 2));
print date('F', mktime(0, 0, 0, 3));
Expected result:
February
March
Actual result:
--
March
March
--
Edit bug report at http://bugs.php.net/?id=43444&edit=1
--
Try a CVS snapshot (PHP 4.4):
http://bugs.php.net/fix.php?id=43444&r=trysnapshot44
Try a CVS snapshot (PHP 5.2):
http://bugs.php.net/fix.php?id=43444&r=trysnapshot52
Try a CVS snapshot (PHP 5.3):
http://bugs.php.net/fix.php?id=43444&r=trysnapshot53
Try a CVS snapshot (PHP 6.0):
http://bugs.php.net/fix.php?id=43444&r=trysnapshot60
Fixed in CVS: http://bugs.php.net/fix.php?id=43444&r=fixedcvs
Fixed in release:
http://bugs.php.net/fix.php?id=43444&r=alreadyfixed
Need backtrace: http://bugs.php.net/fix.php?id=43444&r=needtrace
Need Reproduce Script:http://bugs.php.net/fix.php?id=43444&r=needscript
Try newer version:http://bugs.php.net/fix.php?id=43444&r=oldversion
Not developer issue: http://bugs.php.net/fix.php?id=43444&r=support
Expected behavior:http://bugs.php.net/fix.php?id=43444&r=notwrong
Not enough info:
http://bugs.php.net/fix.php?id=43444&r=notenoughinfo
Submitted twice:
http://bugs.php.net/fix.php?id=43444&r=submittedtwice
register_globals: http://bugs.php.net/fix.php?id=43444&r=globals
PHP 3 support discontinued: http://bugs.php.net/fix.php?id=43444&r=php3
Daylight Savings: http://bugs.php.net/fix.php?id=43444&r=dst
IIS Stability:http://bugs.php.net/fix.php?id=43444&r=isapi
Install GNU Sed: http://bugs.php.net/fix.php?id=43444&r=gnused
Floating point limitations: http://bugs.php.net/fix.php?id=43444&r=float
No Zend Extensions: http://bugs.php.net/fix.php?id=43444&r=nozend
MySQL Configuration Error:http://bugs.php.net/fix.php?id=43444&r=mysqlcfg
#42318 [Asn]: problem with nm not finding object files
ID: 42318 User updated by: rainer dot tammer at schulergroup dot com Reported By: rainer dot tammer at schulergroup dot com Status: Assigned Bug Type: Compile Failure Operating System: AIX 5.2/5.3 PHP Version: 5.2CVS-2007-08-17 Assigned To: dmitry New Comment: Hello, with my suggested patch to the two configure files the errors will be gone. I have checked this on all 5.2.x releases. In sapi/cgi/config9.m4 and sapi/cli/config.m4 ... case $host_alias in *aix*) change ... sed 's/\([A-Za-z0-9_]*\)\.lo/\1.o/g'\` ... to ... sed 's/\([A-Za-z0-9_]*\)\.lo/.libs\/\1.o/g'\` ... Do not forget to call utoconf to regenerate the configure script after the change. It looks like you only need this patch if you user the --with-apxs configure switch. Bye Rainer Previous Comments: [2007-11-28 22:59:46] bduncan8 at yahoo dot com Using gcc 4 on AIX 5.3 and trying to compile PHP 5.2.5 When running make there are many messages about nm not finding files. If make install is attempted it completely fails. If I skip make install I can copy over the libphp5.so and get apache to return phpinfo() output but I have my doubts about being able to install pecl extensions I need like ibm-db2 and informix. It doesn't seem like there has been any official resolution proposed ... is this being looked at still? Thanks. [2007-11-12 11:52:17] rainer dot tammer at schulergroup dot com Hello, any news ?? Bye Rainer [2007-09-26 15:45:54] ppryor at pobox dot com I have the same problem on AIX 5.2 with gcc when I compiled with --apxs and --enable-cli. However it does not cause any problems and it is just an annoyance. However, I will find out when I use phpize and build PECL extension to dynamically load into php under Apache 1.3. I believe (not yet proven) that I will have to insert the following line in config.m4 for PECL extensions: EXTRA_LDFLAGS="$EXTRA_LDFLAGS -Wl,-bI:/usr/HTTPServer/libexec/libphp5.exp" And the first line of the libphp5.exp contains: #!/usr/HTTPServer/libexec/libphp5.so In order to have PECL extension loaded without causing Apache to core dump. I don't see libphp5.exp created and this is what we may need under AIX 5.2. Generally under AIX 4.x (not sure if its true of AIX 5.x) the dynamically loaded libraries need to reference other dynamically loaded libraries where they can resolve symbols (forward linking) by adding a header that you can inspect with dump -H. Example follows for oci8: $ dump -H oci8.so oci8.so: ***Loader Section*** Loader Header Information VERSION# #SYMtableENT #RELOCentLENidSTR 0x0001 0x00b0 0x01a5 0x0079 #IMPfilIDOFFidSTR LENstrTBLOFFstrTBL 0x0004 0x245c 0x0ba6 0x24d5 ***Import File Strings*** INDEX PATH BASEMEMBER 0 /ora01/app/oracle/product/8.1.7/lib:/usr/lib:/lib 1libc.a shr.o 2 /usr/HTTPServer/libexec libphp4.so 3libclntsh.a shr.o You see index number 2, the absolute path for libphp4.so is in /usr/HTTPServer/libexec. I hope this clears up somewhat. And I hope this issue will be fixed for AIX releases definitely (I feel that my config.m4 hack is not quite the right way to do it, through, but it works). Paul. [2007-09-06 06:15:31] rainer dot tammer at schulergroup dot com Hello, first of all AIX 5.1 is no longer supported. I tested the build on AIX 5.2 and 5.3 with IBM xlC/C++ 8.0 and with gcc 3.3.2. It looks like the .libs directory only appears if you build for apache (--with-apxs) and sapi/cgi; sapi/cli. If you need another test I can try almost every combination with the following OS versions / compilers: * AIX 5.2 and AIX 5.3 * xlC/C++ 6.0; 8.0; and 9.0 * gcc 3.3.2; gcc 4.0.0 Bye Rainer [2007-09-05 15:48:51] [EMAIL PROTECTED] I've just recompiled PHP-5.2.4 on AIX 5.1 with gcc without problems. I don't have any ".libs" directories, however in boundled libtool I have "objdir=.libs". I have no idea what is wrong on your (or my) AIX system and how to support both. Try to build CLI and CGI without "--with-apxs". The remainder of the comments for this report are too long. To view the rest of the comm
#43442 [Opn]: __destruct is calling right after __construct
ID: 43442
Updated by: [EMAIL PROTECTED]
Reported By: cjshark at mail dot ru
Status: Open
Bug Type: Scripting Engine problem
Operating System: FreeBSD v60
PHP Version: 5.2.5
New Comment:
This is not what I'm seeing, I see the correct:
constructmethod!!destruct
Previous Comments:
[2007-11-28 17:48:15] cjshark at mail dot ru
Description:
__destruct is calling right after __construct before using any methods!
Reproduce code:
---
class test
{
function __construct()
{
echo "construct";
}
function method($i)
{
echo $i."";
}
function __destruct()
{
echo "destruct";
}
}
$cl = new test();
$cl->method('method!!');
Expected result:
construct
method!!
destruct
Actual result:
--
construct
destruct
method!!
destruct
--
Edit this bug report at http://bugs.php.net/?id=43442&edit=1
