#42450 [Opn]: pdo_pgsql: persistent connections fails on PostgreSQL server restart
ID: 42450 User updated by: davojan at mail dot ru Reported By: davojan at mail dot ru Status: Open Bug Type: PostgreSQL related Operating System: FreeBSD and WinXP -PHP Version: 5.2.3 +PHP Version: 5.2.4 New Comment: The same problem in php-5.2.4 release. Checked under WinXP. Previous Comments: [2007-08-28 09:15:15] davojan at mail dot ru New information: not only the first try. Rather first try to use of any of the old (being created before restart) persistent connections fails. P.S.: Sorry for my English. I hope you understand me :) [2007-08-28 08:14:12] davojan at mail dot ru I've tried the latest version under WinXP. The first try to open persistent connection after PostgreSQL server restart fails in the same way as above. The following connections is OK. Could you please repair the first connection too? :) [2007-08-27 23:27:44] [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-08-27 20:56:27] davojan at mail dot ru Description: When using PDO pgSQL with persistent connections and restarting the PostgreSQL server, which the PDO has been connected with, PDO raises exception (see below). So I need to restart PHP to reset persistent connections. The bug was reproduced in two different environments: Apache2 (multi-threaded) + mod_php + WinXP lighttpd + PHP(FastCGI) + FreeBSD MySQL persistent connections in the same situation works fine... Reproduce code: --- true ) ); echo 'ok'; ?> # /usr/local/etc/rc.d/postgresql restart and again the above php script Expected result: ok Actual result: -- Unknown exception: SQLSTATE[57P01]: Admin shutdown: 7 FATAL: (this is my translation from russian message) server closed the connection unexpectedly This probably means the server terminated abnormally before or while processing the request. -- Edit this bug report at http://bugs.php.net/?id=42450&edit=1
#42379 [Fbk->Csd]: flush() will eat my server's memory!!
ID: 42379 User updated by: mika at netstock dot net Reported By: mika at netstock dot net -Status: Feedback +Status: Closed Bug Type: Output Control Operating System: freebsd-6.2 PHP Version: 5.2.3 New Comment: i got answer,it is apache bugs!!! Previous Comments: [2007-08-24 10:21:31] [EMAIL PROTECTED] How about you first upgrade your apache to something more recent. And then you really need to provide the configure line you used to configure PHP. Also: using "register_globals = On" is something you really shouldn't be doing.. [2007-08-23 23:32:08] mika at netstock dot net you probably need excute it for a while (5 min maybe!!) and $var maybe need to put some data inside at client browser, every things looks fine i didn't get any error but memory leak it seem call sapi or something . [2007-08-23 10:51:23] [EMAIL PROTECTED] Only thing I get is this output: Notice: Undefined variable: var in /opt/www/t.php on line 4 And no leak. How about providing us a bit more information and a script that does not have any errors/notices in it? Your configure line would be nice to know. And what extensions (if any) you load in php.ini.. [2007-08-22 13:21:04] mika at netstock dot net Description: when i use flush() or ob_implicit_flush() to push data to browser it will keep eating my server's memory like 4k 4k 4k..and another 4k .. and my apache is 2.0.59 Do anyone can help me Reproduce code: --- or -- Edit this bug report at http://bugs.php.net/?id=42379&edit=1
#42490 [Fbk->Opn]: PHP will not compile with BIND 9 installed
ID: 42490 User updated by: jerry at scene-naturally dot dyndns dot org Reported By: jerry at scene-naturally dot dyndns dot org -Status: Feedback +Status: Open Bug Type: Compile Failure Operating System: OS X 10.4.10 PHP Version: 5.2.4RC3 New Comment: The libraries installed by BIND 9 are libbind9.a libbind.a These are in /usr/local/lib libbind.a does seem to have the symbols, however, libbind9.a does not have these missing symbols. The path /usr/local/lib IS in LD_LIBRARY_PATH The configure app is finding either the library or the header file, but apparently not completely following though on that; the screen echo: checking if your OS can spawn processes with inherited handles... yes checking for res_nmkquery... no checking for __res_nmkquery... no checking for res_nmkquery in -lresolv... no checking for __res_nmkquery in -lresolv... no checking for res_nmkquery in -lbind... no checking for __res_nmkquery in -lbind... yes checking for res_nsend... no checking for __res_nsend... yes checking for dn_expand... yes This is in the configure.log as well. A small part of libbind.a: Previous Comments: [2007-08-30 20:21:16] [EMAIL PROTECTED] Where is the library located containing those symbols (can't remember what it was called :) and is the path to that library in LD_LIBRARY_PATH? [2007-08-30 18:15:25] jerry at scene-naturally dot dyndns dot org Description: 1) Compiling fails for various version of PHP 5. It has been suggested to install BIND 8 over the BIND 9 installation, compile PHP and then re-install BIND 9. Not very elegant, but it might work if the older BIND were available. This has become a bigger problem because BIND 8 was declared EOL as of August 27, (no more support either) and the links to the older software were removed from the ISC site. http://www.isc.org/index.pl 2) In comparison, this next one is far more minor, but still a problem: If there are multiple versions of Berkeley DB installed (say 4.1 -- 4.6) Config picks up the older (lowered numbered) version instead o the newest version. The various Makefiles, etc. have to be hand-edited to replace the occurrences of say db-4.5 with db-4.6 Reproduce code: --- Compile fails regardless of using a simple ./configure make or a full ./configure options options ... options make 2) Expected result: The usual line saying to the effect that the compile was successful and reminding the user to run 'make test'. Actual result: -- /usr/bin/ld: Undefined symbols: _res_nclose _res_ninit _res_nmkquery _res_nsend collect2: ld returned 1 exit status make: *** [libs/libphp5.bundle] Error 1 -- Edit this bug report at http://bugs.php.net/?id=42490&edit=1
#42464 [Fbk->Opn]: MySQL library location issues
ID: 42464 User updated by: juan at pons dot org Reported By: juan at pons dot org -Status: Feedback +Status: Open Bug Type: MySQL related Operating System: OSX 10.4.10 PHP Version: 5.2.4 New Comment: The reason I need to run buildconf is because I am installing some php extensions that are not part of the standard package and after copying the extensions to the ext directory I run buildconf to recreate the configure script with the right extensions. I am going thru the buildconf step without installing the extension to take one more variable out of the equation and make sure the problem was/is not the extension. If there is a different way to accomplish the same I would love to know. Previous Comments: [2007-08-30 20:19:05] [EMAIL PROTECTED] Why are you running buildconf? That's complete waste of time. [2007-08-30 14:23:04] juan at pons dot org Tried compiling with the new snapshot as requested and the problem still persists. Here is the error from config.log configure:98591: ./conftest dyld: Library not loaded: /usr/local/mysql/lib/mysql/libmysqlclient.15.dylib Here is the sequence of to reproduce the problem Install MySQL from the mysql.org packages # tar -zxvf php5.2-latest.tar.gz # cd php5.2-200708301230/ # rm configure # ./buildconf --force ./configure --with-apxs2=/app/apache2/bin/apxs --without-pear --with- config-file-path=/app/ini --with-mcrypt --with-curl --with- curlwrappers --enable-cli --with-mysql=/usr/local/mysql configure gives lots of statuses and then: checking for PDO includes... checking for PDO includes... /Users/jpons/app/src/php5.2-200708301230/ext checking for char *... yes checking size of char *... configure: error: cannot compute sizeof (char *), 77 See `config.log' for more details. [2007-08-28 21:33:53] [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-08-28 19:21:35] juan at pons dot org Description: Under OSX, the MySQL binaries from mysql.org get installed under /usr/local/mysql When you try to compile php with --with-mysql=/usr/local/mysql you are unable to compile because the php mysql libs are trying to link against libraries at /usr/local/mysql/lib/mysql which does not exist in this MySQL installation, The correct path should be /usr/local/mysql/lib I found a way around this problem, by creating appropiate symlinks, but this is obviously not ideal Reproduce code: --- # tar -zxvf php-5.2.3.tar.gz # cd php-5.2.3 # rm configure # ./buildconf --force # ./configure --with-apxs2=/app/apache2/bin/apxs --without-pear --with-config-file-path=/app/ini --with-mysql=/usr/local/mysql # make # make install # /app/apache2/bin/apachectl start Expected result: compile php and have it work with apache Actual result: -- httpd: Syntax error on line 53 of /app/apache2/conf/httpd.conf: Cannot load /app/apache2/modules/libphp5.so into server: Library not loaded: /usr/local/mysql/lib/mysql/libmysqlclient.15.dylib\n Referenced from: /app/apache2/modules/libphp5.so\n Reason: image not found -- Edit this bug report at http://bugs.php.net/?id=42464&edit=1
#42490 [Opn->Fbk]: PHP will not compile with BIND 9 installed
ID: 42490 Updated by: [EMAIL PROTECTED] Reported By: jerry at scene-naturally dot dyndns dot org -Status: Open +Status: Feedback Bug Type: Compile Failure Operating System: OS X 10.4.10 PHP Version: 5.2.4RC3 New Comment: Where is the library located containing those symbols (can't remember what it was called :) and is the path to that library in LD_LIBRARY_PATH? Previous Comments: [2007-08-30 18:15:25] jerry at scene-naturally dot dyndns dot org Description: 1) Compiling fails for various version of PHP 5. It has been suggested to install BIND 8 over the BIND 9 installation, compile PHP and then re-install BIND 9. Not very elegant, but it might work if the older BIND were available. This has become a bigger problem because BIND 8 was declared EOL as of August 27, (no more support either) and the links to the older software were removed from the ISC site. http://www.isc.org/index.pl 2) In comparison, this next one is far more minor, but still a problem: If there are multiple versions of Berkeley DB installed (say 4.1 -- 4.6) Config picks up the older (lowered numbered) version instead o the newest version. The various Makefiles, etc. have to be hand-edited to replace the occurrences of say db-4.5 with db-4.6 Reproduce code: --- Compile fails regardless of using a simple ./configure make or a full ./configure options options ... options make 2) Expected result: The usual line saying to the effect that the compile was successful and reminding the user to run 'make test'. Actual result: -- /usr/bin/ld: Undefined symbols: _res_nclose _res_ninit _res_nmkquery _res_nsend collect2: ld returned 1 exit status make: *** [libs/libphp5.bundle] Error 1 -- Edit this bug report at http://bugs.php.net/?id=42490&edit=1
#42464 [Opn->Fbk]: MySQL library location issues
ID: 42464 Updated by: [EMAIL PROTECTED] Reported By: juan at pons dot org -Status: Open +Status: Feedback Bug Type: MySQL related Operating System: OSX 10.4.10 PHP Version: 5.2.3 New Comment: Why are you running buildconf? That's complete waste of time. Previous Comments: [2007-08-30 14:23:04] juan at pons dot org Tried compiling with the new snapshot as requested and the problem still persists. Here is the error from config.log configure:98591: ./conftest dyld: Library not loaded: /usr/local/mysql/lib/mysql/libmysqlclient.15.dylib Here is the sequence of to reproduce the problem Install MySQL from the mysql.org packages # tar -zxvf php5.2-latest.tar.gz # cd php5.2-200708301230/ # rm configure # ./buildconf --force ./configure --with-apxs2=/app/apache2/bin/apxs --without-pear --with- config-file-path=/app/ini --with-mcrypt --with-curl --with- curlwrappers --enable-cli --with-mysql=/usr/local/mysql configure gives lots of statuses and then: checking for PDO includes... checking for PDO includes... /Users/jpons/app/src/php5.2-200708301230/ext checking for char *... yes checking size of char *... configure: error: cannot compute sizeof (char *), 77 See `config.log' for more details. [2007-08-28 21:33:53] [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-08-28 19:21:35] juan at pons dot org Description: Under OSX, the MySQL binaries from mysql.org get installed under /usr/local/mysql When you try to compile php with --with-mysql=/usr/local/mysql you are unable to compile because the php mysql libs are trying to link against libraries at /usr/local/mysql/lib/mysql which does not exist in this MySQL installation, The correct path should be /usr/local/mysql/lib I found a way around this problem, by creating appropiate symlinks, but this is obviously not ideal Reproduce code: --- # tar -zxvf php-5.2.3.tar.gz # cd php-5.2.3 # rm configure # ./buildconf --force # ./configure --with-apxs2=/app/apache2/bin/apxs --without-pear --with-config-file-path=/app/ini --with-mysql=/usr/local/mysql # make # make install # /app/apache2/bin/apachectl start Expected result: compile php and have it work with apache Actual result: -- httpd: Syntax error on line 53 of /app/apache2/conf/httpd.conf: Cannot load /app/apache2/modules/libphp5.so into server: Library not loaded: /usr/local/mysql/lib/mysql/libmysqlclient.15.dylib\n Referenced from: /app/apache2/modules/libphp5.so\n Reason: image not found -- Edit this bug report at http://bugs.php.net/?id=42464&edit=1
#42389 [Opn]: PHP+Apache2+mod_fcgid kills all processes after submit
ID: 42389 User updated by: webmaster at machostlink dot net Reported By: webmaster at machostlink dot net Status: Open Bug Type: CGI related Operating System: OSX 10.4.10 PHP Version: 5.2CVS-2007-08-23 New Comment: Any news on this? Previous Comments: [2007-08-24 15:16:16] webmaster at machostlink dot net Ok, now here is the output for latest CVS: Attaching to program: `/usr/local/bin/php-cgi', process 25912. Reading symbols for shared libraries .. done 0x9004eb97 in accept () (gdb) c Continuing. Program received signal SIGPIPE, Broken pipe. 0x9001029c in write () (gdb) bt #0 0x9001029c in write () #1 0x002e79b3 in fcgi_flush (req=0xbfffdc00, close=1) at /usr/local/php5.2-200708230830/sapi/cgi/fastcgi.c:543 #2 0x002e7a29 in fcgi_finish_request (req=0xbfffdc00) at /usr/local/php5.2-200708230830/sapi/cgi/fastcgi.c:1163 #3 0x002e825f in fcgi_accept_request (req=0xbfffdc00) at /usr/local/php5.2-200708230830/sapi/cgi/fastcgi.c:869 #4 0x002ea880 in main (argc=1, argv=0xbdd0) at /usr/local/php5.2-200708230830/sapi/cgi/cgi_main.c:1491 [2007-08-24 04:47:00] webmaster at machostlink dot net @jani Ok will do and let you know what the result is. @crrodriguez Here is my config for mod_fcgid: -- SharememPath /tmp/fcgid_shm SocketPath /opt/local/apache2/logs/fcgidsock IPCConnectTimeout 60 IPCCommTimeout 60 MaxRequestsPerProcess 500 MaxRequestInMem 150 MaxRequestLen 150 I think I have tried EVERY possible combination there is. I read ALL the threads and issues posted on sourceforge page as well as pretty much every thread I could find on google regarding mod_fcgid issues. :( That's why I am quite desperate to solve this. Thanks for you help... [2007-08-24 02:54:52] crrodriguez at suse dot de err.. I meant it should be set to 500 NOT -1 [2007-08-24 02:52:55] crrodriguez at suse dot de what is the value of MaxRequestsPerProcess in your mod_fcgid configuration, it should be -1 This is a known issue of mod_fcgid see the documentation http://fastcgi.coremail.cn/doc.htm This is not a bug in PHP. [2007-08-23 22:25:37] [EMAIL PROTECTED] My guess is it's crashing so you should try and attach GDB to the running process and see what the crash is about (note: you need to use latest CVS snapshot configured using --enable-debug option!) Make sure you only start 1 PHP FastCGI child, check what it's pid is and attach gdb: # gdb /path/to/php-cgi 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/42389 -- Edit this bug report at http://bugs.php.net/?id=42389&edit=1
#42490 [NEW]: PHP will not compile with BIND 9 installed
From: jerry at scene-naturally dot dyndns dot org Operating system: OS X 10.4.10 PHP version: 5.2.4RC3 PHP Bug Type: Compile Failure Bug description: PHP will not compile with BIND 9 installed Description: 1) Compiling fails for various version of PHP 5. It has been suggested to install BIND 8 over the BIND 9 installation, compile PHP and then re-install BIND 9. Not very elegant, but it might work if the older BIND were available. This has become a bigger problem because BIND 8 was declared EOL as of August 27, (no more support either) and the links to the older software were removed from the ISC site. http://www.isc.org/index.pl 2) In comparison, this next one is far more minor, but still a problem: If there are multiple versions of Berkeley DB installed (say 4.1 -- 4.6) Config picks up the older (lowered numbered) version instead o the newest version. The various Makefiles, etc. have to be hand-edited to replace the occurrences of say db-4.5 with db-4.6 Reproduce code: --- Compile fails regardless of using a simple ./configure make or a full ./configure options options ... options make 2) Expected result: The usual line saying to the effect that the compile was successful and reminding the user to run 'make test'. Actual result: -- /usr/bin/ld: Undefined symbols: _res_nclose _res_ninit _res_nmkquery _res_nsend collect2: ld returned 1 exit status make: *** [libs/libphp5.bundle] Error 1 -- Edit bug report at http://bugs.php.net/?id=42490&edit=1 -- Try a CVS snapshot (PHP 4.4): http://bugs.php.net/fix.php?id=42490&r=trysnapshot44 Try a CVS snapshot (PHP 5.2): http://bugs.php.net/fix.php?id=42490&r=trysnapshot52 Try a CVS snapshot (PHP 6.0): http://bugs.php.net/fix.php?id=42490&r=trysnapshot60 Fixed in CVS: http://bugs.php.net/fix.php?id=42490&r=fixedcvs Fixed in release: http://bugs.php.net/fix.php?id=42490&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=42490&r=needtrace Need Reproduce Script:http://bugs.php.net/fix.php?id=42490&r=needscript Try newer version:http://bugs.php.net/fix.php?id=42490&r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=42490&r=support Expected behavior:http://bugs.php.net/fix.php?id=42490&r=notwrong Not enough info: http://bugs.php.net/fix.php?id=42490&r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=42490&r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=42490&r=globals PHP 3 support discontinued: http://bugs.php.net/fix.php?id=42490&r=php3 Daylight Savings: http://bugs.php.net/fix.php?id=42490&r=dst IIS Stability:http://bugs.php.net/fix.php?id=42490&r=isapi Install GNU Sed: http://bugs.php.net/fix.php?id=42490&r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=42490&r=float No Zend Extensions: http://bugs.php.net/fix.php?id=42490&r=nozend MySQL Configuration Error:http://bugs.php.net/fix.php?id=42490&r=mysqlcfg
#42462 [Asn->Csd]: Segmentation when trying to set an attribute in a DOMElement
ID: 42462
Updated by: [EMAIL PROTECTED]
Reported By: romain dot lalaut at laposte dot net
-Status: Assigned
+Status: Closed
Bug Type: DOM XML related
Operating System: Linux Ubuntu 2.6.20-16-server
PHP Version: 5.2CVS-2007-08-28
Assigned To: rrichards
New Comment:
This bug has been fixed in CVS.
Snapshots of the sources are packaged every three hours; this change
will be in the next snapshot. You can grab the snapshot at
http://snaps.php.net/.
Thank you for the report, and for helping us make PHP better.
Previous Comments:
[2007-08-29 09:55:54] [EMAIL PROTECTED]
Same backtrace:
Program received signal SIGSEGV, Segmentation fault.
0x080e8785 in php_dom_object_get_data (obj=0x64616568) at
/home/jani/src/php-5.2/ext/dom/php_dom.c:242
242 if (obj && obj->_private != NULL) {
(gdb) bt
#0 0x080e8785 in php_dom_object_get_data (obj=0x64616568) at
/home/jani/src/php-5.2/ext/dom/php_dom.c:242
#1 0x080ed4bc in node_list_unlink (node=0x64616568) at
/home/jani/src/php-5.2/ext/dom/php_dom.c:931
#2 0x080ed51c in node_list_unlink (node=0x8c59438) at
/home/jani/src/php-5.2/ext/dom/php_dom.c:948
#3 0x080f55b1 in zif_dom_element_set_attribute (ht=2,
return_value=0x8c29930, return_value_ptr=0x0, this_ptr=0x8c2903c,
return_value_used=0)
at /home/jani/src/php-5.2/ext/dom/element.c:308
#4 0x08303d68 in zend_do_fcall_common_helper_SPEC
(execute_data=0xbfb0a4c4) at
/home/jani/src/php-5.2/Zend/zend_vm_execute.h:200
[2007-08-29 06:15:58] romain dot lalaut at laposte dot net
For your information, if I import the nodes and copy them into an
another document, there is no problem even with LIBXML_COMPACT
[2007-08-29 06:09:23] romain dot lalaut at laposte dot net
http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd";>
http://www.w3.org/1999/xhtml";>
foo;
$doc = new DOMDocument( '1.0.', 'utf-8' );
$doc->loadXML( $xml, LIBXML_COMPACT );
$xpath = new DOMXPath( $doc );
$xpath->registerNamespace( 'xhtml', 'http://www.w3.org/1999/xhtml' );
$res = $xpath->query( "/xhtml:html[1]/xhtml:body[1]//xhtml:[EMAIL PROTECTED]",
$doc->documentElement );
foreach($res as $el)
{
echo('ID : '.$el->getAttribute('id')."\n"); flush();
$el->setAttribute('id', 'foo');
echo("OK\n"); flush();
}
?>
But if i remove LIBXML_COMPAT, it works perfectly...
[2007-08-28 20:28:16] romain dot lalaut at laposte dot net
Sorry, i'm tired... The version i used for the test is
PHP 5.2.4RC4-dev (cli) (built: Aug 28 2007 17:24:11) (DEBUG)
Copyright (c) 1997-2007 The PHP Group
Zend Engine v2.2.0, Copyright (c) 1998-2007 Zend Technologies
And make test report some bugs (4) but not for DOM...
[2007-08-28 16:36:07] [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
5.2.1 is relatively old, if you\'re going to report a bug at least try
the latest version.
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/42462
--
Edit this bug report at http://bugs.php.net/?id=42462&edit=1
#36561 [Opn]: PDO_ODBC/MSSQL does not work with bound params in subquery
ID: 36561
User updated by: travis at raybold dot com
Reported By: travis at raybold dot com
Status: Open
Bug Type: PDO related
Operating System: Windows XP
-PHP Version: 5.1.2
+PHP Version: 5.2.4
New Comment:
the problem still occurs on:
PHP 5.2.4 (cli) (built: Aug 30 2007 07:06:31)
Previous Comments:
[2007-08-30 14:14:53] travis at raybold dot com
fixing bug summary...
[2007-08-30 14:13:49] travis at raybold dot com
this bug is still happening, as "blohr at triad dot rr dot com" logged.
[2007-07-18 01:00:00] php-bugs at lists dot php dot net
No feedback was provided for this bug for over a week, so it is
being suspended automatically. If you are able to provide the
information that was originally requested, please do so and change
the status of the bug back to "Open".
[2007-07-10 17:20:05] blohr at triad dot rr dot com
I tried the code I posted previously with the snapshot you referenced.
Unfortunately, it didn't fix the problem. Here are the results:
> php -v
PHP 5.2.4-dev (cli) (built: Jul 10 2007 12:04:20)
Copyright (c) 1997-2007 The PHP Group
Zend Engine v2.2.0, Copyright (c) 1998-2007 Zend Technologies
> php mssql-odbc.php
array(4) {
[0]=>
string(5) "42000"
[1]=>
int(402)
[2]=>
string(166) "[Microsoft][SQL Native Client][SQL Server]The data types
varchar and text are incompatible in the equal to operator.
(SQLExecute[402] at ext\pdo_odbc\odbc_stmt.c:133)"
[3]=>
string(5) "42000"
}
array(4) {
[0]=>
string(5) "22018"
[1]=>
int(206)
[2]=>
string(141) "[Microsoft][SQL Native Client][SQL Server]Operand type
clash: text is incompatible with int (SQLExecute[206] at
ext\pdo_odbc\odbc_stmt.c:133)"
[3]=>
string(5) "22018"
}
array(4) {
[0]=>
string(5) "42000"
[1]=>
int(402)
[2]=>
string(166) "[Microsoft][SQL Native Client][SQL Server]The data types
varchar and text are incompatible in the equal to operator.
(SQLExecute[402] at ext\pdo_odbc\odbc_stmt.c:133)"
[3]=>
string(5) "42000"
}
array(4) {
[0]=>
string(5) "22018"
[1]=>
int(206)
[2]=>
string(141) "[Microsoft][SQL Native Client][SQL Server]Operand type
clash: text is incompatible with int (SQLExecute[206] at
ext\pdo_odbc\odbc_stmt.c:133)"
[3]=>
string(5) "22018"
}
array(4) {
[0]=>
string(5) "42000"
[1]=>
int(402)
[2]=>
string(166) "[Microsoft][SQL Native Client][SQL Server]The data types
varchar and text are incompatible in the equal to operator.
(SQLExecute[402] at ext\pdo_odbc\odbc_stmt.c:133)"
[3]=>
string(5) "42000"
}
array(4) {
[0]=>
string(5) "22018"
[1]=>
int(206)
[2]=>
string(141) "[Microsoft][SQL Native Client][SQL Server]Operand type
clash: text is incompatible with int (SQLExecute[206] at
ext\pdo_odbc\odbc_stmt.c:133)"
[3]=>
string(5) "22018"
}
array(4) {
[0]=>
string(5) "42000"
[1]=>
int(402)
[2]=>
string(166) "[Microsoft][SQL Native Client][SQL Server]The data types
varchar and text are incompatible in the equal to operator.
(SQLExecute[402] at ext\pdo_odbc\odbc_stmt.c:133)"
[3]=>
string(5) "42000"
}
array(4) {
[0]=>
string(5) "22018"
[1]=>
int(206)
[2]=>
string(141) "[Microsoft][SQL Native Client][SQL Server]Operand type
clash: text is incompatible with int (SQLExecute[206] at
ext\pdo_odbc\odbc_stmt.c:133)"
[3]=>
string(5) "22018"
}
[2007-07-10 11:33:49] [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
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/36561
--
Edit this bug report at http://bugs.php.net/?id=36561&edit=1
#42489 [NEW]: Quirk in strtotime using 'next' relative keyword
From: chet at somedec dot com Operating system: Linux PHP version: 5.2.4RC3 PHP Bug Type: Date/time related Bug description: Quirk in strtotime using 'next' relative keyword Description: Adding time (even zero) to a relative date using the "next" keyword fails. Reproduce code: --- Expected result: The four tests should pass; none do. Actual result: -- Using the current day (according to your computer clock) in conjunction with the next keyword (i.e. "Next Thursday" when run on Thursday) correctly returns one week from the current date. However, adding or subtracting any amount of time results in an erroneous result of the /current date/ plus or minus the offset. -- Edit bug report at http://bugs.php.net/?id=42489&edit=1 -- Try a CVS snapshot (PHP 4.4): http://bugs.php.net/fix.php?id=42489&r=trysnapshot44 Try a CVS snapshot (PHP 5.2): http://bugs.php.net/fix.php?id=42489&r=trysnapshot52 Try a CVS snapshot (PHP 6.0): http://bugs.php.net/fix.php?id=42489&r=trysnapshot60 Fixed in CVS: http://bugs.php.net/fix.php?id=42489&r=fixedcvs Fixed in release: http://bugs.php.net/fix.php?id=42489&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=42489&r=needtrace Need Reproduce Script:http://bugs.php.net/fix.php?id=42489&r=needscript Try newer version:http://bugs.php.net/fix.php?id=42489&r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=42489&r=support Expected behavior:http://bugs.php.net/fix.php?id=42489&r=notwrong Not enough info: http://bugs.php.net/fix.php?id=42489&r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=42489&r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=42489&r=globals PHP 3 support discontinued: http://bugs.php.net/fix.php?id=42489&r=php3 Daylight Savings: http://bugs.php.net/fix.php?id=42489&r=dst IIS Stability:http://bugs.php.net/fix.php?id=42489&r=isapi Install GNU Sed: http://bugs.php.net/fix.php?id=42489&r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=42489&r=float No Zend Extensions: http://bugs.php.net/fix.php?id=42489&r=nozend MySQL Configuration Error:http://bugs.php.net/fix.php?id=42489&r=mysqlcfg
#42464 [Fbk->Opn]: MySQL library location issues
ID: 42464 User updated by: juan at pons dot org Reported By: juan at pons dot org -Status: Feedback +Status: Open Bug Type: MySQL related Operating System: OSX 10.4.10 PHP Version: 5.2.3 New Comment: Tried compiling with the new snapshot as requested and the problem still persists. Here is the error from config.log configure:98591: ./conftest dyld: Library not loaded: /usr/local/mysql/lib/mysql/libmysqlclient.15.dylib Here is the sequence of to reproduce the problem Install MySQL from the mysql.org packages # tar -zxvf php5.2-latest.tar.gz # cd php5.2-200708301230/ # rm configure # ./buildconf --force ./configure --with-apxs2=/app/apache2/bin/apxs --without-pear --with- config-file-path=/app/ini --with-mcrypt --with-curl --with- curlwrappers --enable-cli --with-mysql=/usr/local/mysql configure gives lots of statuses and then: checking for PDO includes... checking for PDO includes... /Users/jpons/app/src/php5.2-200708301230/ext checking for char *... yes checking size of char *... configure: error: cannot compute sizeof (char *), 77 See `config.log' for more details. Previous Comments: [2007-08-28 21:33:53] [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-08-28 19:21:35] juan at pons dot org Description: Under OSX, the MySQL binaries from mysql.org get installed under /usr/local/mysql When you try to compile php with --with-mysql=/usr/local/mysql you are unable to compile because the php mysql libs are trying to link against libraries at /usr/local/mysql/lib/mysql which does not exist in this MySQL installation, The correct path should be /usr/local/mysql/lib I found a way around this problem, by creating appropiate symlinks, but this is obviously not ideal Reproduce code: --- # tar -zxvf php-5.2.3.tar.gz # cd php-5.2.3 # rm configure # ./buildconf --force # ./configure --with-apxs2=/app/apache2/bin/apxs --without-pear --with-config-file-path=/app/ini --with-mysql=/usr/local/mysql # make # make install # /app/apache2/bin/apachectl start Expected result: compile php and have it work with apache Actual result: -- httpd: Syntax error on line 53 of /app/apache2/conf/httpd.conf: Cannot load /app/apache2/modules/libphp5.so into server: Library not loaded: /usr/local/mysql/lib/mysql/libmysqlclient.15.dylib\n Referenced from: /app/apache2/modules/libphp5.so\n Reason: image not found -- Edit this bug report at http://bugs.php.net/?id=42464&edit=1
#42488 [NEW]: SoapServer reports an encoding error and the error itself breaks
From: edman007 at edman007 dot com
Operating system: Linux
PHP version: 5CVS-2007-08-30 (snap)
PHP Bug Type: SOAP related
Bug description: SoapServer reports an encoding error and the error itself
breaks
Description:
when a function passes a string that is not UTF-8 compliant back to
SoapServer as part of a response SoapServer throws and error saying (or i
guess its suppose to) that it could not encode it.
However the error message reports the error message itself, not the
problematic string as the cause of the error, and then finishes off with a
small portion of the problematic string, resulting in a very hard to
understand error message that also does not really say where it failed.
Reproduce code:
---
---client.php--
getBadUTF();
} catch (SoapFault $e){
echo $e->faultstring;
}
?>
---server.php---
addFunction('getBadUTF');
$soap->handle();
?>
---something.wsdl---
http://www.example.com/";
xmlns:soapenc12="http://www.w3.org/2003/05/soap-encoding";
xmlns:tns="http://www.example.com/";
xmlns:wsdl="http://schemas.xmlsoap.org/wsdl/";
xmlns:xsd="http://www.w3.org/2001/XMLSchema";
xmlns:soap11="http://schemas.xmlsoap.org/soap/envelope/";
xmlns:wsdlsoap="http://schemas.xmlsoap.org/wsdl/soap/";
xmlns:soapenc11="http://schemas.xmlsoap.org/soap/encoding/";
xmlns:soap12="http://www.w3.org/2003/05/soap-envelope";
xmlns:soap="http://schemas.xmlsoap.org/wsdl/soap/";>
http://schemas.xmlsoap.org/soap/http"/>
http://localhost/server.php"/>
Expected result:
SOAP-ERROR: Encoding: string 'stuff"thing'
Actual result:
--
SOAP-ERROR: Encoding: string 'SOAP-ERROR: Encoding: string 'SOAP-ERROR:
Encoding: string 'SOAP-ERROR: Encoding: string 'SOAP-ERROR: Encoding:
string 'SOAP-ERROR: Encoding: string 'SOAP-ERROR: Encoding: string
'SOAP-ERROR: Encoding: string 'SOAP-ERROR: Encoding: string 'SOAP-ERROR:
Encoding: string 'SOAP-ERROR: Encoding: string 'SOAP-ERROR: Encoding:
string 'SOAP-ERROR: Encoding: string 'SOAP-ERROR: Encoding: string
'SOAP-ERROR: Encoding: string 'SOAP-ERROR: Encoding: string 'SOAP-ERROR:
Encoding: string 'SOAP-ERROR: Encoding: string 'SOAP-ERROR: Encoding:
string 'SOAP-ERROR: Encoding: string 'SOAP-ERROR: Encoding: string
'SOAP-ERROR: Encoding: string 'SOAP-ERROR: Encoding: string 'SOAP-ERROR:
Encoding: string 'SOAP-ERROR: Encoding: string 'SOAP-ERROR: Encoding:
string 'SOAP-ERROR: Encoding: string 'SOAP-ERROR: Encoding: string
'SOAP-ERROR: Encoding: string 'SOAP-ERROR: Encoding: string 'SOAP-ERROR:
Encoding: string 'SOAP-ERROR: Encoding: string 'SOAP-ERROR: Encoding:
string 'SOAP-ERROR: Encoding: string 'st
--
Edit bug report at http://bugs.php.net/?id=42488&edit=1
--
Try a CVS snapshot (PHP 4.4):
http://bugs.php.net/fix.php?id=42488&r=trysnapshot44
Try a CVS snapshot (PHP 5.2):
http://bugs.php.net/fix.php?id=42488&r=trysnapshot52
Try a CVS snapshot (PHP 6.0):
http://bugs.php.net/fix.php?id=42488&r=trysnapshot60
Fixed in CVS: http://bugs.php.net/fix.php?id=42488&r=fixedcvs
Fixed in release:
http://bugs.php.net/fix.php?id=42488&r=alreadyfixed
Need backtrace: http://bugs.php.net/fix.php?id=42488&r=needtrace
Need Reproduce Script:http://bugs.php.net/fix.php?id=42488&r=needscript
Try newer version:http://bugs.php.net/fix.php?id=42488&r=oldversion
Not developer issue: http://bugs.php.net/fix.php?id=42488&r=support
Expected behavior:http://bugs.php.net/fix.php?id=42488&r=notwrong
Not enough info:
http://bugs.php.net/fix.php?id=42488&r=notenoughinfo
Submitted twice:
http://bugs.php.net/fix.php?id=42488&r=submittedtwice
register_globals: http://bugs.php.net/fix.php?id=42488&r=globals
PHP 3 support discontinued: http://bugs.php.net/fix.php?id=42488&r=php3
Daylight Savings: http://bugs.php.net/fix.php?id=42488&r=dst
IIS Stability:http://bugs.php.net/fix.php?id=42488&r=isapi
Install GNU Sed: http://bugs.php.net/fix.php?id=42488&r=gnused
Floating point limitations: http://bugs.php.net/fix.php?id=42488&r=float
No Zend Extensions: http://bugs.php.net/fix.php?id=42488&r=nozend
MySQL Configuration Error:http://bugs.php.net/fix.php?id=42488&r=mysqlcfg
#36561 [Opn]: PDO_ODBC/MSSQL does not work with bound params in subquery
ID: 36561
User updated by: travis at raybold dot com
-Summary: this bug is still happening, as "blohr at triad dot rr
dot com" logged.
Reported By: travis at raybold dot com
Status: Open
Bug Type: PDO related
Operating System: Windows XP
PHP Version: 5.1.2
New Comment:
fixing bug summary...
Previous Comments:
[2007-08-30 14:13:49] travis at raybold dot com
this bug is still happening, as "blohr at triad dot rr dot com" logged.
[2007-07-18 01:00:00] php-bugs at lists dot php dot net
No feedback was provided for this bug for over a week, so it is
being suspended automatically. If you are able to provide the
information that was originally requested, please do so and change
the status of the bug back to "Open".
[2007-07-10 17:20:05] blohr at triad dot rr dot com
I tried the code I posted previously with the snapshot you referenced.
Unfortunately, it didn't fix the problem. Here are the results:
> php -v
PHP 5.2.4-dev (cli) (built: Jul 10 2007 12:04:20)
Copyright (c) 1997-2007 The PHP Group
Zend Engine v2.2.0, Copyright (c) 1998-2007 Zend Technologies
> php mssql-odbc.php
array(4) {
[0]=>
string(5) "42000"
[1]=>
int(402)
[2]=>
string(166) "[Microsoft][SQL Native Client][SQL Server]The data types
varchar and text are incompatible in the equal to operator.
(SQLExecute[402] at ext\pdo_odbc\odbc_stmt.c:133)"
[3]=>
string(5) "42000"
}
array(4) {
[0]=>
string(5) "22018"
[1]=>
int(206)
[2]=>
string(141) "[Microsoft][SQL Native Client][SQL Server]Operand type
clash: text is incompatible with int (SQLExecute[206] at
ext\pdo_odbc\odbc_stmt.c:133)"
[3]=>
string(5) "22018"
}
array(4) {
[0]=>
string(5) "42000"
[1]=>
int(402)
[2]=>
string(166) "[Microsoft][SQL Native Client][SQL Server]The data types
varchar and text are incompatible in the equal to operator.
(SQLExecute[402] at ext\pdo_odbc\odbc_stmt.c:133)"
[3]=>
string(5) "42000"
}
array(4) {
[0]=>
string(5) "22018"
[1]=>
int(206)
[2]=>
string(141) "[Microsoft][SQL Native Client][SQL Server]Operand type
clash: text is incompatible with int (SQLExecute[206] at
ext\pdo_odbc\odbc_stmt.c:133)"
[3]=>
string(5) "22018"
}
array(4) {
[0]=>
string(5) "42000"
[1]=>
int(402)
[2]=>
string(166) "[Microsoft][SQL Native Client][SQL Server]The data types
varchar and text are incompatible in the equal to operator.
(SQLExecute[402] at ext\pdo_odbc\odbc_stmt.c:133)"
[3]=>
string(5) "42000"
}
array(4) {
[0]=>
string(5) "22018"
[1]=>
int(206)
[2]=>
string(141) "[Microsoft][SQL Native Client][SQL Server]Operand type
clash: text is incompatible with int (SQLExecute[206] at
ext\pdo_odbc\odbc_stmt.c:133)"
[3]=>
string(5) "22018"
}
array(4) {
[0]=>
string(5) "42000"
[1]=>
int(402)
[2]=>
string(166) "[Microsoft][SQL Native Client][SQL Server]The data types
varchar and text are incompatible in the equal to operator.
(SQLExecute[402] at ext\pdo_odbc\odbc_stmt.c:133)"
[3]=>
string(5) "42000"
}
array(4) {
[0]=>
string(5) "22018"
[1]=>
int(206)
[2]=>
string(141) "[Microsoft][SQL Native Client][SQL Server]Operand type
clash: text is incompatible with int (SQLExecute[206] at
ext\pdo_odbc\odbc_stmt.c:133)"
[3]=>
string(5) "22018"
}
[2007-07-10 11:33:49] [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-06-22 17:50:11] blohr at triad dot rr dot com
This bug affects my app, too. I'm using PHP 5.2.3 on Windows XP Pro
SP2, under both IIS 5.1 and Apache 2.2, with SQL Server 2005 Express.
I don't know if it'll help or not, but here's some more reproduce code.
Just fix the PDO DSN string to something valid.
exec($createTable);
$db->exec($createTable2);
$ins = $db->prepare('INSERT INTO ##test (intCol, textCol) VALUES (:i,
:t)');
$ins->execute(array('i'=>1, 't'=>'A String'));
$ins2 = $db->prepare('INSERT INTO ##test2 (intCol2, textCol2) VALUES
(:i, :t)');
$ins2->execute(array('i'=>1, 't'=>'Another String'));
$sel = $db->prepare('SELECT * FROM ##test WHERE intCol = (SELECT
intCol2 FROM ##test2 WHERE textCol2 = :t)');
$sel->execute(array('t'=>'Another String')) or
var_dump($sel->errorInfo());
$sel = $db->prepare('SELECT * FROM ##test WHERE intCol = (SELECT
intCol2 FROM ##test2 WHERE intCol2 = :i)');
$sel->execute(array('i'=>1)) or var_dump($sel->errorInfo());
$sel = $db->prepare('SELECT * FROM ##test WHERE intC
#36561 [NoF->Opn]: this bug is still happening, as "blohr at triad dot rr dot com" logged.
ID: 36561
User updated by: travis at raybold dot com
-Summary: PDO_ODBC/MSSQL does not work with bound params in
subquery
Reported By: travis at raybold dot com
-Status: No Feedback
+Status: Open
Bug Type: PDO related
Operating System: Windows XP
PHP Version: 5.1.2
New Comment:
this bug is still happening, as "blohr at triad dot rr dot com" logged.
Previous Comments:
[2007-07-18 01:00:00] php-bugs at lists dot php dot net
No feedback was provided for this bug for over a week, so it is
being suspended automatically. If you are able to provide the
information that was originally requested, please do so and change
the status of the bug back to "Open".
[2007-07-10 17:20:05] blohr at triad dot rr dot com
I tried the code I posted previously with the snapshot you referenced.
Unfortunately, it didn't fix the problem. Here are the results:
> php -v
PHP 5.2.4-dev (cli) (built: Jul 10 2007 12:04:20)
Copyright (c) 1997-2007 The PHP Group
Zend Engine v2.2.0, Copyright (c) 1998-2007 Zend Technologies
> php mssql-odbc.php
array(4) {
[0]=>
string(5) "42000"
[1]=>
int(402)
[2]=>
string(166) "[Microsoft][SQL Native Client][SQL Server]The data types
varchar and text are incompatible in the equal to operator.
(SQLExecute[402] at ext\pdo_odbc\odbc_stmt.c:133)"
[3]=>
string(5) "42000"
}
array(4) {
[0]=>
string(5) "22018"
[1]=>
int(206)
[2]=>
string(141) "[Microsoft][SQL Native Client][SQL Server]Operand type
clash: text is incompatible with int (SQLExecute[206] at
ext\pdo_odbc\odbc_stmt.c:133)"
[3]=>
string(5) "22018"
}
array(4) {
[0]=>
string(5) "42000"
[1]=>
int(402)
[2]=>
string(166) "[Microsoft][SQL Native Client][SQL Server]The data types
varchar and text are incompatible in the equal to operator.
(SQLExecute[402] at ext\pdo_odbc\odbc_stmt.c:133)"
[3]=>
string(5) "42000"
}
array(4) {
[0]=>
string(5) "22018"
[1]=>
int(206)
[2]=>
string(141) "[Microsoft][SQL Native Client][SQL Server]Operand type
clash: text is incompatible with int (SQLExecute[206] at
ext\pdo_odbc\odbc_stmt.c:133)"
[3]=>
string(5) "22018"
}
array(4) {
[0]=>
string(5) "42000"
[1]=>
int(402)
[2]=>
string(166) "[Microsoft][SQL Native Client][SQL Server]The data types
varchar and text are incompatible in the equal to operator.
(SQLExecute[402] at ext\pdo_odbc\odbc_stmt.c:133)"
[3]=>
string(5) "42000"
}
array(4) {
[0]=>
string(5) "22018"
[1]=>
int(206)
[2]=>
string(141) "[Microsoft][SQL Native Client][SQL Server]Operand type
clash: text is incompatible with int (SQLExecute[206] at
ext\pdo_odbc\odbc_stmt.c:133)"
[3]=>
string(5) "22018"
}
array(4) {
[0]=>
string(5) "42000"
[1]=>
int(402)
[2]=>
string(166) "[Microsoft][SQL Native Client][SQL Server]The data types
varchar and text are incompatible in the equal to operator.
(SQLExecute[402] at ext\pdo_odbc\odbc_stmt.c:133)"
[3]=>
string(5) "42000"
}
array(4) {
[0]=>
string(5) "22018"
[1]=>
int(206)
[2]=>
string(141) "[Microsoft][SQL Native Client][SQL Server]Operand type
clash: text is incompatible with int (SQLExecute[206] at
ext\pdo_odbc\odbc_stmt.c:133)"
[3]=>
string(5) "22018"
}
[2007-07-10 11:33:49] [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-06-22 17:50:11] blohr at triad dot rr dot com
This bug affects my app, too. I'm using PHP 5.2.3 on Windows XP Pro
SP2, under both IIS 5.1 and Apache 2.2, with SQL Server 2005 Express.
I don't know if it'll help or not, but here's some more reproduce code.
Just fix the PDO DSN string to something valid.
exec($createTable);
$db->exec($createTable2);
$ins = $db->prepare('INSERT INTO ##test (intCol, textCol) VALUES (:i,
:t)');
$ins->execute(array('i'=>1, 't'=>'A String'));
$ins2 = $db->prepare('INSERT INTO ##test2 (intCol2, textCol2) VALUES
(:i, :t)');
$ins2->execute(array('i'=>1, 't'=>'Another String'));
$sel = $db->prepare('SELECT * FROM ##test WHERE intCol = (SELECT
intCol2 FROM ##test2 WHERE textCol2 = :t)');
$sel->execute(array('t'=>'Another String')) or
var_dump($sel->errorInfo());
$sel = $db->prepare('SELECT * FROM ##test WHERE intCol = (SELECT
intCol2 FROM ##test2 WHERE intCol2 = :i)');
$sel->execute(array('i'=>1)) or var_dump($sel->errorInfo());
$sel = $db->prepare('SELECT * FROM ##test WHERE intCol = (SELECT
intCol2 FROM ##test2 WHERE textCol2 = :t)');
$sel->bindValue('t', 'Another String');
$sel->execute() or var_dump($s
#42452 [Opn->Csd]: PDO classes do not expose Reflection API information
ID: 42452 Updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] -Status: Open +Status: Closed Bug Type: Feature/Change Request Operating System: Irrelevant PHP Version: 5CVS-2007-08-28 (CVS) -Assigned To: +Assigned To: bjori New Comment: This bug has been fixed in CVS. Snapshots of the sources are packaged every three hours; this change will be in the next snapshot. You can grab the snapshot at http://snaps.php.net/. Thank you for the report, and for helping us make PHP better. Previous Comments: [2007-08-28 08:16:17] [EMAIL PROTECTED] Description: PDOStatement, for instance, does not expose the data required by the Reflection API. -- Edit this bug report at http://bugs.php.net/?id=42452&edit=1
#42473 [Opn]: ob_start php://output and headers
ID: 42473 User updated by: ce at netage dot bg Reported By: ce at netage dot bg Status: Open Bug Type: Output Control Operating System: Irrelevant PHP Version: 5.2.4RC3 New Comment: with windows and apache and again Server API -> Apache 2.0 Handler it is reproducable, so I suppose the problem is something connected to the server api here the CGI version in action - no problem [EMAIL PROTECTED]:/usr/local/php-5.2.4/bin$ ./php-cgi http://www.php.net/manual/en/wrappers.php.php) so from the written the following code http://bugs.php.net/42473 -- Edit this bug report at http://bugs.php.net/?id=42473&edit=1
#42473 [Fbk->Opn]: ob_start php://output and headers
ID: 42473 User updated by: ce at netage dot bg Reported By: ce at netage dot bg -Status: Feedback +Status: Open Bug Type: Output Control Operating System: Irrelevant PHP Version: 5.2.4RC3 New Comment: I just compile the latest version 5.2.4RC3 ./configure --with-apxs2=/usr/bin/apxs2 --prefix=/usr/local/php-5.2.4 no php.ini, so everything is default but I have discovered that if using CGI server api it is not reproducable this is from phpinfo() I can give some other info for my configuration if needed Build Date Aug 30 2007 15:09:33 Configure Command './configure' '--with-apxs2=/usr/bin/apxs2' '--prefix=/usr/local/php-5.2.4' Server API Apache 2.0 Handler Virtual Directory Support disabled Configuration File (php.ini) Path /usr/local/php-5.2.4/lib Loaded Configuration File (none) PHP API 20041225 PHP Extension 20060613 Zend Extension 220060519 Debug Build no Previous Comments: [2007-08-30 13:14:29] [EMAIL PROTECTED] It's not enough to just say "I reproduced" when someone else can't. Provide some information how to reproduce this.. [2007-08-30 12:52:05] [EMAIL PROTECTED] I'm reproducing the bug on Windows XP, PHP 5.2.3, Apache 2.0.54. [2007-08-30 11:32:59] [EMAIL PROTECTED] I don't know what your php.ini settings are but I can't even reproduce it.. [2007-08-30 09:54:51] ce at netage dot bg from the documentation: php://output allows you to write to the output buffer mechanism in the same way as print() and echo(). (taken from http://www.php.net/manual/en/wrappers.php.php) so from the written the following code http://www.php.net/manual/ and the instructions on how to report a bug at http://bugs.php.net/how-to-report.php >From manual: "ob_get_clean() essentially executes both ob_get_contents() and ob_end_clean()." 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/42473 -- Edit this bug report at http://bugs.php.net/?id=42473&edit=1
#42487 [Opn->Bgs]: php.ini setting for "precision" ignored. value is always 6
ID: 42487
Updated by: [EMAIL PROTECTED]
Reported By: gerhard dot mueller at travian dot org
-Status: Open
+Status: Bogus
Bug Type: Math related
Operating System: Linux Debian
PHP Version: 5.2.3
New Comment:
Precision has nothing to do with this.
Previous Comments:
[2007-08-30 13:17:18] gerhard dot mueller at travian dot org
Description:
The php.ini setting of "precision" seems to be ignored and is always 6.
I makes no difference when you override it with ini_set() or directly in
php.ini.
tested on 5.1.6, 5.2.2 and 5.2.3 on several Linux Servers and 2 Windows
PCs. Only in 5.1.6 change of "precision" was not ignored.
Example in php.ini
; The number of significant digits displayed in floating point
numbers.
precision= 12
Same as this report but bug has nothing to do with round()
http://bugs.php.net/bug.php?id=42484
Reproduce code:
---
ini_set('precision','6');
$big_int = (float)120;
print "precision6: $big_int \n\n";
ini_set('precision','12');
$big_int = (float)120;
print "precision12: $big_int";
Expected result:
precision6: 1.2E+006
precision12: 120
Actual result:
--
precision6: 1.2E+006
precision12: 1.2E+006
--
Edit this bug report at http://bugs.php.net/?id=42487&edit=1
#42487 [NEW]: php.ini setting for "precision" ignored. value is always 6
From: gerhard dot mueller at travian dot org
Operating system: Linux Debian
PHP version: 5.2.3
PHP Bug Type: Math related
Bug description: php.ini setting for "precision" ignored. value is always 6
Description:
The php.ini setting of "precision" seems to be ignored and is always 6. I
makes no difference when you override it with ini_set() or directly in
php.ini.
tested on 5.1.6, 5.2.2 and 5.2.3 on several Linux Servers and 2 Windows
PCs. Only in 5.1.6 change of "precision" was not ignored.
Example in php.ini
; The number of significant digits displayed in floating point numbers.
precision= 12
Same as this report but bug has nothing to do with round()
http://bugs.php.net/bug.php?id=42484
Reproduce code:
---
ini_set('precision','6');
$big_int = (float)120;
print "precision6: $big_int \n\n";
ini_set('precision','12');
$big_int = (float)120;
print "precision12: $big_int";
Expected result:
precision6: 1.2E+006
precision12: 120
Actual result:
--
precision6: 1.2E+006
precision12: 1.2E+006
--
Edit bug report at http://bugs.php.net/?id=42487&edit=1
--
Try a CVS snapshot (PHP 4.4):
http://bugs.php.net/fix.php?id=42487&r=trysnapshot44
Try a CVS snapshot (PHP 5.2):
http://bugs.php.net/fix.php?id=42487&r=trysnapshot52
Try a CVS snapshot (PHP 6.0):
http://bugs.php.net/fix.php?id=42487&r=trysnapshot60
Fixed in CVS: http://bugs.php.net/fix.php?id=42487&r=fixedcvs
Fixed in release:
http://bugs.php.net/fix.php?id=42487&r=alreadyfixed
Need backtrace: http://bugs.php.net/fix.php?id=42487&r=needtrace
Need Reproduce Script:http://bugs.php.net/fix.php?id=42487&r=needscript
Try newer version:http://bugs.php.net/fix.php?id=42487&r=oldversion
Not developer issue: http://bugs.php.net/fix.php?id=42487&r=support
Expected behavior:http://bugs.php.net/fix.php?id=42487&r=notwrong
Not enough info:
http://bugs.php.net/fix.php?id=42487&r=notenoughinfo
Submitted twice:
http://bugs.php.net/fix.php?id=42487&r=submittedtwice
register_globals: http://bugs.php.net/fix.php?id=42487&r=globals
PHP 3 support discontinued: http://bugs.php.net/fix.php?id=42487&r=php3
Daylight Savings: http://bugs.php.net/fix.php?id=42487&r=dst
IIS Stability:http://bugs.php.net/fix.php?id=42487&r=isapi
Install GNU Sed: http://bugs.php.net/fix.php?id=42487&r=gnused
Floating point limitations: http://bugs.php.net/fix.php?id=42487&r=float
No Zend Extensions: http://bugs.php.net/fix.php?id=42487&r=nozend
MySQL Configuration Error:http://bugs.php.net/fix.php?id=42487&r=mysqlcfg
#42395 [Opn->Fbk]: httpd crashes near file uploading
ID: 42395 Updated by: [EMAIL PROTECTED] Reported By: jille at hexon dot cx -Status: Open +Status: Feedback Bug Type: Apache related Operating System: MacOS 10.4.9 PHP Version: 5.2.3 New Comment: Did you build PHP with --enable-debug or not? As long as you're not able to provide any useful way for anybody to reproduce this or a decent backtrace there's not much we can do about it. And you need to do it using PHP 5.2.4. (it's the one you get from snaps.php.net atm) Previous Comments: [2007-08-30 12:55:23] jille at hexon dot cx Well, I disabled the zend extensions on one server, but it crashed anyway... Got any other ideas to try to locate the problem (without slowing down the entire server) ? [2007-08-23 14:12:09] [EMAIL PROTECTED] So it crashes but you can't build a debug version of PHP for your live site to get better backtraces so that we could actually fix it and you don't know how to reproduce it reliably..quite a chicken'n'egg problem here. :) [2007-08-23 11:48:36] jille at hexon dot cx true, but I can't reproduce it on my dev server... [2007-08-23 11:46:12] [EMAIL PROTECTED] Nobody asked you to run it on live site.. [2007-08-23 11:33:40] jille at hexon dot cx I can't run 5.2.4-dev in gdb on a live server. That will slow down about 1000+ sites i`m hosting. But I will try to run one server without Zend extensions. Let`s see whether I still get crashes on that one 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/42395 -- Edit this bug report at http://bugs.php.net/?id=42395&edit=1
#42486 [WFx]: strtotime() fails with UT timezone
ID: 42486 User updated by: up at co dot inbox dot lv Reported By: up at co dot inbox dot lv Status: Wont fix Bug Type: Unknown/Other Function Operating System: Gentoo Linux PHP Version: 5.2.4RC3 New Comment: Ok, I believe the user, that have sent me an email message with the "Tue, 21 Aug 2007 06:23:46 UT" in the Date: header not mentioned this "Earth Rotation" timezone :D I suspect there's a bug in some mailing software, kind of missing "C" char after "UT". >From the link that you provided I see that difference between UT1 − UTC is allways less than one second, but strtotime() returns result exactly in seconds, not so precise. So by replacing "UT" string by "UTC" before parsing the date, we should get exactly the same time. I think this is more a documentation issue, but users will never meet this bug again. Previous Comments: [2007-08-30 12:49:17] [EMAIL PROTECTED] UT is not really a easy measurable timezone, unlike UTC. To support this correctly we should take care of leapseconds, and this is very much something you don't want to do. See http://en.wikipedia.org/wiki/DUT1 for what is different between UTC and UT. [2007-08-30 12:37:25] up at co dot inbox dot lv Description: strtotime() returns false if timezone is set to UT, it worked in php4 but is broken in php5 Reproduce code: --- Expected result: On PHP Version 4.4.1: 1187677426 Actual result: -- Empty -- Edit this bug report at http://bugs.php.net/?id=42486&edit=1
#42473 [Ver->Fbk]: ob_start php://output and headers
ID: 42473 Updated by: [EMAIL PROTECTED] Reported By: ce at netage dot bg -Status: Verified +Status: Feedback Bug Type: Output Control Operating System: Irrelevant PHP Version: 5.2.4RC3 New Comment: It's not enough to just say "I reproduced" when someone else can't. Provide some information how to reproduce this.. Previous Comments: [2007-08-30 12:52:05] [EMAIL PROTECTED] I'm reproducing the bug on Windows XP, PHP 5.2.3, Apache 2.0.54. [2007-08-30 11:32:59] [EMAIL PROTECTED] I don't know what your php.ini settings are but I can't even reproduce it.. [2007-08-30 09:54:51] ce at netage dot bg from the documentation: php://output allows you to write to the output buffer mechanism in the same way as print() and echo(). (taken from http://www.php.net/manual/en/wrappers.php.php) so from the written the following code http://www.php.net/manual/ and the instructions on how to report a bug at http://bugs.php.net/how-to-report.php >From manual: "ob_get_clean() essentially executes both ob_get_contents() and ob_end_clean()." [2007-08-29 17:15:33] ce at netage dot bg Description: it is actually a duplicate problem with 40429, but since you have closed the bug I cannot reopen it, but it is still present with all versions including the new 5.2.4RC3 when open through a browser, not a cli! Reproduce code: --- http://bugs.php.net/?id=42473&edit=1
#42395 [Fbk->Opn]: httpd crashes near file uploading
ID: 42395 User updated by: jille at hexon dot cx Reported By: jille at hexon dot cx -Status: Feedback +Status: Open Bug Type: Apache related Operating System: MacOS 10.4.9 PHP Version: 5.2.3 New Comment: Well, I disabled the zend extensions on one server, but it crashed anyway... Got any other ideas to try to locate the problem (without slowing down the entire server) ? Previous Comments: [2007-08-23 14:12:09] [EMAIL PROTECTED] So it crashes but you can't build a debug version of PHP for your live site to get better backtraces so that we could actually fix it and you don't know how to reproduce it reliably..quite a chicken'n'egg problem here. :) [2007-08-23 11:48:36] jille at hexon dot cx true, but I can't reproduce it on my dev server... [2007-08-23 11:46:12] [EMAIL PROTECTED] Nobody asked you to run it on live site.. [2007-08-23 11:33:40] jille at hexon dot cx I can't run 5.2.4-dev in gdb on a live server. That will slow down about 1000+ sites i`m hosting. But I will try to run one server without Zend extensions. Let`s see whether I still get crashes on that one [2007-08-23 10:26:12] [EMAIL PROTECTED] First get the latst 5.2.4-dev snapshot: http://snaps.php.net/php4-STABLE-latest.tar.gz Then compile it with using --enable-debug in your configure line. Before you launch Apache, disable all Zend extensions in your php.ini. Run Apache under GDB: # gdb --arg httpd -X (gdb) run Then do the things required to crash it and: (gdb) bt And you should have better backtrace. Although it seems to be coming from the filter extension by looking at the current backtrace, it's easier to pinpoint the exact place when the debug symbols are around. 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/42395 -- Edit this bug report at http://bugs.php.net/?id=42395&edit=1
#42473 [Bgs->Ver]: ob_start php://output and headers
ID: 42473 Updated by: [EMAIL PROTECTED] Reported By: ce at netage dot bg -Status: Bogus +Status: Verified Bug Type: Output Control -Operating System: linux +Operating System: Irrelevant PHP Version: 5.2.4RC3 New Comment: I'm reproducing the bug on Windows XP, PHP 5.2.3, Apache 2.0.54. Previous Comments: [2007-08-30 11:32:59] [EMAIL PROTECTED] I don't know what your php.ini settings are but I can't even reproduce it.. [2007-08-30 09:54:51] ce at netage dot bg from the documentation: php://output allows you to write to the output buffer mechanism in the same way as print() and echo(). (taken from http://www.php.net/manual/en/wrappers.php.php) so from the written the following code http://www.php.net/manual/ and the instructions on how to report a bug at http://bugs.php.net/how-to-report.php >From manual: "ob_get_clean() essentially executes both ob_get_contents() and ob_end_clean()." [2007-08-29 17:15:33] ce at netage dot bg Description: it is actually a duplicate problem with 40429, but since you have closed the bug I cannot reopen it, but it is still present with all versions including the new 5.2.4RC3 when open through a browser, not a cli! Reproduce code: --- http://bugs.php.net/?id=42473&edit=1
#42486 [Opn->WFx]: strtotime() fails with UT timezone
ID: 42486 Updated by: [EMAIL PROTECTED] Reported By: up at co dot inbox dot lv -Status: Open +Status: Wont fix Bug Type: Unknown/Other Function Operating System: Gentoo Linux PHP Version: 5.2.4RC3 New Comment: UT is not really a easy measurable timezone, unlike UTC. To support this correctly we should take care of leapseconds, and this is very much something you don't want to do. See http://en.wikipedia.org/wiki/DUT1 for what is different between UTC and UT. Previous Comments: [2007-08-30 12:37:25] up at co dot inbox dot lv Description: strtotime() returns false if timezone is set to UT, it worked in php4 but is broken in php5 Reproduce code: --- Expected result: On PHP Version 4.4.1: 1187677426 Actual result: -- Empty -- Edit this bug report at http://bugs.php.net/?id=42486&edit=1
#42486 [NEW]: strtotime() fails with UT timezone
From: up at co dot inbox dot lv Operating system: Gentoo Linux PHP version: 5.2.4RC3 PHP Bug Type: Unknown/Other Function Bug description: strtotime() fails with UT timezone Description: strtotime() returns false if timezone is set to UT, it worked in php4 but is broken in php5 Reproduce code: --- Expected result: On PHP Version 4.4.1: 1187677426 Actual result: -- Empty -- Edit bug report at http://bugs.php.net/?id=42486&edit=1 -- Try a CVS snapshot (PHP 4.4): http://bugs.php.net/fix.php?id=42486&r=trysnapshot44 Try a CVS snapshot (PHP 5.2): http://bugs.php.net/fix.php?id=42486&r=trysnapshot52 Try a CVS snapshot (PHP 6.0): http://bugs.php.net/fix.php?id=42486&r=trysnapshot60 Fixed in CVS: http://bugs.php.net/fix.php?id=42486&r=fixedcvs Fixed in release: http://bugs.php.net/fix.php?id=42486&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=42486&r=needtrace Need Reproduce Script:http://bugs.php.net/fix.php?id=42486&r=needscript Try newer version:http://bugs.php.net/fix.php?id=42486&r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=42486&r=support Expected behavior:http://bugs.php.net/fix.php?id=42486&r=notwrong Not enough info: http://bugs.php.net/fix.php?id=42486&r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=42486&r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=42486&r=globals PHP 3 support discontinued: http://bugs.php.net/fix.php?id=42486&r=php3 Daylight Savings: http://bugs.php.net/fix.php?id=42486&r=dst IIS Stability:http://bugs.php.net/fix.php?id=42486&r=isapi Install GNU Sed: http://bugs.php.net/fix.php?id=42486&r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=42486&r=float No Zend Extensions: http://bugs.php.net/fix.php?id=42486&r=nozend MySQL Configuration Error:http://bugs.php.net/fix.php?id=42486&r=mysqlcfg
#42485 [Opn->Bgs]: allow_url_fopen and allow_url_include dont work fine
ID: 42485 Updated by: [EMAIL PROTECTED] Reported By: marciomaianunes at hotmail dot com -Status: Open +Status: Bogus Bug Type: PHP options/info functions Operating System: windos xp PHP Version: 5.2.3 New Comment: Sorry, but your problem does not imply a bug in PHP itself. For a list of more appropriate places to ask for help using PHP, please visit http://www.php.net/support.php as this bug system is not the appropriate forum for asking support questions. Due to the volume of reports we can not explain in detail here why your report is not a bug. The support channels will be able to provide an explanation for you. Thank you for your interest in PHP. Previous Comments: [2007-08-30 12:02:51] marciomaianunes at hotmail dot com Description: With the parameters "allow_url_fopen" = "on" and "allow_url_include" = "on" I can include URL like files, but I cannot declare the classes and cannot use the functions declared in the include file... Reproduce code: --- /* FILE PHPbug.php */ http://localhost:8080/MyClass.php";); require_once(DIR); $bug = new MyClass(); //ERROR, dont found the class... echo $bug->getNumber(); echo ""; echo callFunction();//ERROR, dont found the function... ?> /* FILE MyClass.php */ Expected result: I expect... 100 ok Actual result: -- Fatal error: Class 'MyClass' not found in C:\MARCIO\public_html\PHPbug.php on line 11 -- Edit this bug report at http://bugs.php.net/?id=42485&edit=1
#42485 [NEW]: allow_url_fopen and allow_url_include dont work fine
From: marciomaianunes at hotmail dot com Operating system: windos xp PHP version: 5.2.3 PHP Bug Type: PHP options/info functions Bug description: allow_url_fopen and allow_url_include dont work fine Description: With the parameters "allow_url_fopen" = "on" and "allow_url_include" = "on" I can include URL like files, but I cannot declare the classes and cannot use the functions declared in the include file... Reproduce code: --- /* FILE PHPbug.php */ http://localhost:8080/MyClass.php";); require_once(DIR); $bug = new MyClass(); //ERROR, dont found the class... echo $bug->getNumber(); echo ""; echo callFunction();//ERROR, dont found the function... ?> /* FILE MyClass.php */ Expected result: I expect... 100 ok Actual result: -- Fatal error: Class 'MyClass' not found in C:\MARCIO\public_html\PHPbug.php on line 11 -- Edit bug report at http://bugs.php.net/?id=42485&edit=1 -- Try a CVS snapshot (PHP 4.4): http://bugs.php.net/fix.php?id=42485&r=trysnapshot44 Try a CVS snapshot (PHP 5.2): http://bugs.php.net/fix.php?id=42485&r=trysnapshot52 Try a CVS snapshot (PHP 6.0): http://bugs.php.net/fix.php?id=42485&r=trysnapshot60 Fixed in CVS: http://bugs.php.net/fix.php?id=42485&r=fixedcvs Fixed in release: http://bugs.php.net/fix.php?id=42485&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=42485&r=needtrace Need Reproduce Script:http://bugs.php.net/fix.php?id=42485&r=needscript Try newer version:http://bugs.php.net/fix.php?id=42485&r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=42485&r=support Expected behavior:http://bugs.php.net/fix.php?id=42485&r=notwrong Not enough info: http://bugs.php.net/fix.php?id=42485&r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=42485&r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=42485&r=globals PHP 3 support discontinued: http://bugs.php.net/fix.php?id=42485&r=php3 Daylight Savings: http://bugs.php.net/fix.php?id=42485&r=dst IIS Stability:http://bugs.php.net/fix.php?id=42485&r=isapi Install GNU Sed: http://bugs.php.net/fix.php?id=42485&r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=42485&r=float No Zend Extensions: http://bugs.php.net/fix.php?id=42485&r=nozend MySQL Configuration Error:http://bugs.php.net/fix.php?id=42485&r=mysqlcfg
#42484 [Opn->Bgs]: different behavior of rand, precission ini parameter has no effect
ID: 42484
Updated by: [EMAIL PROTECTED]
Reported By: twen at travian dot org
-Status: Open
+Status: Bogus
Bug Type: Math related
Operating System: Linux 2.6.18-5-amd64 x86_64
PHP Version: 5.2.3
New Comment:
Precision has nothing to do with this.
Previous Comments:
[2007-08-30 11:43:07] twen at travian dot org
Description:
on php 5.2.1 the return value of the round function can be modified in
its precision via the "precision" ini parameter. but on php 5.2.3, the
precision parameter doesn't have any affect on the return value of the
round function. The phpinfo function displays the configured paramter,
therefore it can't be an configuration problem.
Reproduce code:
---
";
ini_set('precision','12');
print "precision: ".ini_get('precision');
$number = round($number);
print "$number ".gettype($number);
ini_set('precision','6');
print "precision: ".ini_get('precision');
$number = round($number);
print "$number ".gettype($number);
$number = (int)$number;
print "$number ".gettype($number);
?>
Expected result:
on php 5.2.1 you get:
120 integer
precision: 12
120 double
precision: 6
1.2E+06 double
120 integer
Actual result:
--
on php 5.2.3 you get:
120 integer
precision: 12
1.2E+6 double
precision: 6
1.2E+6 double
120 integer
--
Edit this bug report at http://bugs.php.net/?id=42484&edit=1
#42484 [NEW]: different behavior of rand, precission ini parameter has no effect
From: twen at travian dot org
Operating system: Linux 2.6.18-5-amd64 x86_64
PHP version: 5.2.3
PHP Bug Type: Math related
Bug description: different behavior of rand, precission ini parameter has no
effect
Description:
on php 5.2.1 the return value of the round function can be modified in its
precision via the "precision" ini parameter. but on php 5.2.3, the
precision parameter doesn't have any affect on the return value of the
round function. The phpinfo function displays the configured paramter,
therefore it can't be an configuration problem.
Reproduce code:
---
";
ini_set('precision','12');
print "precision: ".ini_get('precision');
$number = round($number);
print "$number ".gettype($number);
ini_set('precision','6');
print "precision: ".ini_get('precision');
$number = round($number);
print "$number ".gettype($number);
$number = (int)$number;
print "$number ".gettype($number);
?>
Expected result:
on php 5.2.1 you get:
120 integer
precision: 12
120 double
precision: 6
1.2E+06 double
120 integer
Actual result:
--
on php 5.2.3 you get:
120 integer
precision: 12
1.2E+6 double
precision: 6
1.2E+6 double
120 integer
--
Edit bug report at http://bugs.php.net/?id=42484&edit=1
--
Try a CVS snapshot (PHP 4.4):
http://bugs.php.net/fix.php?id=42484&r=trysnapshot44
Try a CVS snapshot (PHP 5.2):
http://bugs.php.net/fix.php?id=42484&r=trysnapshot52
Try a CVS snapshot (PHP 6.0):
http://bugs.php.net/fix.php?id=42484&r=trysnapshot60
Fixed in CVS: http://bugs.php.net/fix.php?id=42484&r=fixedcvs
Fixed in release:
http://bugs.php.net/fix.php?id=42484&r=alreadyfixed
Need backtrace: http://bugs.php.net/fix.php?id=42484&r=needtrace
Need Reproduce Script:http://bugs.php.net/fix.php?id=42484&r=needscript
Try newer version:http://bugs.php.net/fix.php?id=42484&r=oldversion
Not developer issue: http://bugs.php.net/fix.php?id=42484&r=support
Expected behavior:http://bugs.php.net/fix.php?id=42484&r=notwrong
Not enough info:
http://bugs.php.net/fix.php?id=42484&r=notenoughinfo
Submitted twice:
http://bugs.php.net/fix.php?id=42484&r=submittedtwice
register_globals: http://bugs.php.net/fix.php?id=42484&r=globals
PHP 3 support discontinued: http://bugs.php.net/fix.php?id=42484&r=php3
Daylight Savings: http://bugs.php.net/fix.php?id=42484&r=dst
IIS Stability:http://bugs.php.net/fix.php?id=42484&r=isapi
Install GNU Sed: http://bugs.php.net/fix.php?id=42484&r=gnused
Floating point limitations: http://bugs.php.net/fix.php?id=42484&r=float
No Zend Extensions: http://bugs.php.net/fix.php?id=42484&r=nozend
MySQL Configuration Error:http://bugs.php.net/fix.php?id=42484&r=mysqlcfg
#42439 [Opn->Bgs]: Derivating a method in a class that implements an interface that declares it
ID: 42439
Updated by: [EMAIL PROTECTED]
Reported By: romain dot tartiere at healthgrid dot org
-Status: Open
+Status: Bogus
Bug Type: Class/Object related
Operating System: GNU/Linux
PHP Version: 5.2.3
New Comment:
.
Previous Comments:
[2007-08-27 10:24:59] [EMAIL PROTECTED]
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
[2007-08-27 09:35:06] romain dot tartiere at healthgrid dot org
Description:
Considering a class that implements an interface and has methods that
require many arguments. You may expect to make your life easier
derivating this class and providing simpler methods.
Reproduce code:
---
fooize($str, $n))
*/
function fooize($str, $n) {
echo "$str $n\n";
}
}
class c_bar extends c_foo {
function fooize($str) { /* simple ($class->fooize($str)) */
$n = strlen($str);
parent::fooize($str, $n);
}
}
?>
Expected result:
This should not pose any kind of problem.
Actual result:
--
Fatal error: Declaration of c_bar::fooize() must be compatible with
that of i_foo::fooize()
--
Edit this bug report at http://bugs.php.net/?id=42439&edit=1
#42473 [Opn->Bgs]: ob_start php://output and headers
ID: 42473 Updated by: [EMAIL PROTECTED] Reported By: ce at netage dot bg -Status: Open +Status: Bogus Bug Type: Output Control Operating System: linux PHP Version: 5.2.4RC3 New Comment: I don't know what your php.ini settings are but I can't even reproduce it.. Previous Comments: [2007-08-30 09:54:51] ce at netage dot bg from the documentation: php://output allows you to write to the output buffer mechanism in the same way as print() and echo(). (taken from http://www.php.net/manual/en/wrappers.php.php) so from the written the following code http://www.php.net/manual/ and the instructions on how to report a bug at http://bugs.php.net/how-to-report.php >From manual: "ob_get_clean() essentially executes both ob_get_contents() and ob_end_clean()." [2007-08-29 17:15:33] ce at netage dot bg Description: it is actually a duplicate problem with 40429, but since you have closed the bug I cannot reopen it, but it is still present with all versions including the new 5.2.4RC3 when open through a browser, not a cli! Reproduce code: --- http://bugs.php.net/?id=42473&edit=1
#42473 [Bgs->Opn]: ob_start php://output and headers
ID: 42473 User updated by: ce at netage dot bg Reported By: ce at netage dot bg -Status: Bogus +Status: Open Bug Type: Output Control Operating System: linux PHP Version: 5.2.4RC3 New Comment: from the documentation: php://output allows you to write to the output buffer mechanism in the same way as print() and echo(). (taken from http://www.php.net/manual/en/wrappers.php.php) so from the written the following code http://www.php.net/manual/ and the instructions on how to report a bug at http://bugs.php.net/how-to-report.php >From manual: "ob_get_clean() essentially executes both ob_get_contents() and ob_end_clean()." [2007-08-29 17:15:33] ce at netage dot bg Description: it is actually a duplicate problem with 40429, but since you have closed the bug I cannot reopen it, but it is still present with all versions including the new 5.2.4RC3 when open through a browser, not a cli! Reproduce code: --- http://bugs.php.net/?id=42473&edit=1
#42438 [Opn->Fbk]: require require_once include include_once
ID: 42438 Updated by: [EMAIL PROTECTED] Reported By: perching_eagle at yahoo dot com -Status: Open +Status: Feedback Bug Type: Scripting Engine problem Operating System: windows xp PHP Version: 5.2.3 New Comment: When you installed the snapshot, did you first shutdown whatever webserver you use and delete (!!) all old installed PHP related dlls/executables BEFORE you installed the snapshot version?? I can't reproduce this on Windows XP (yes, I have that..) nor on Linux (preferred OS). I suspect it's simply bad installation. Previous Comments: [2007-08-30 06:01:25] perching_eagle at yahoo dot com one more thing i went to google translate to check what language was being dumped on my screen, and it was only the "chinese to english" translator that was able to decipher it, the words were meaningless but i wonder why. i hope someone can get to the bottom of this, the only solution i have right now is to manually copy all the files i would have included with the include or require directives, into one file for each class definition. the include,require,require_once,include_once all worked for non-object oriented programs. whenever it encountered the $this-> operator in my code, especially in the constructor (just like the code in my first post), it dumps everything else after the $this-> operator on my screen. [2007-08-30 02:17:15] perching_eagle at yahoo dot com not loading mbstrings didn't change anything, versions prior to 5.2.3 work well with no problem at all. i guess anyone that still uses a microsoft os like xp, can comfirm my complaint. well thanks jani for your help. if you have access to windows xp with php 5.2.3 installed on it, you may be able to figure out what the problem is. till then bye.. [2007-08-28 21:42:01] [EMAIL PROTECTED] Well, do you get readable error messages when you don't load mbstring? (this is getting quite boring..) [2007-08-28 18:57:35] perching_eagle at yahoo dot com i followed your advice, set display_errors to On and error_reporting to E_ALL, it didn't do much help but when i set the error_reporting to E_ALL & E_STRICT the japanese characters disappeared from the output of my code when using a php editor (i use php designer), however nothing changed when i tried display my output on a browser window using apache httpd. i also noticed some comments or non-directives in the php ini file, that were not properly "commented" with ";" and correcting them still didn't help. i also think that in the window edition of php 5.2.3 download, mb_string language was set to japanese by default, even for english language speakers, and those japanese characters dumped on the output screen from my code, could be error messages automatically translated into japanese. [2007-08-28 11:19:54] [EMAIL PROTECTED] Try rewriting those files of yours from scratch and set error_reporting to E_ALL and display_errors=On in your php.ini.. 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/42438 -- Edit this bug report at http://bugs.php.net/?id=42438&edit=1
#42456 [Bgs]: i foud solution, publish it on website
ID: 42456 Updated by: [EMAIL PROTECTED] Reported By: astorozhuk at ukrcard dot com dot ua Status: Bogus Bug Type: OCI8 related Operating System: sles9 PHP Version: 5.2.3 New Comment: JFYI: I do read Ukrainian. Please next time do not spend time on filling the report form, keep your emotions and teenager problems to yourself. Previous Comments: [2007-08-30 07:33:01] astorozhuk at ukrcard dot com dot ua seems to be source of problem that i was compilling it with Application, not Database ve compiled it with db and now is ok without changing source [2007-08-30 06:34:01] astorozhuk at ukrcard dot com dot ua вото тупорилі копіпастять відповіді і помиляються їм тикаєщ носом що потрібно виправити в ісходніках, а вони не втикають воно і не дивно що в пхп стільки глюків [2007-08-29 08:45:34] [EMAIL PROTECTED] >(/oracle/as is oracle application server. we use also oracle9 >database. all from official installation) What's the EXACT version number? 9.what? >useful information: Oh, please keep this useful information to yourself. >please add 4 lines to source of oci8 extension lines: Please stop telling me what to do. >why some php developers not analysing problem , but just make >copy-paste, and even make errors in copy-pasting :) Why some users think they may call other people stupid and expect these very people to help them? Do you think you're clever? Name me at least one reason why should I even listen to you after that. [2007-08-29 07:15:25] astorozhuk at ukrcard dot com dot ua i definitly wrote in OS field - sles9 (sles9= Suse Linux Enterprise server version 9) , service pack 3, OFFICIAL i mention freebsd as link, not because i use it. i found link with problem solution. configure ./configure --with-apxs=/usr/local/apache/bin/apxs --prefix=/usr/local --with-config-file-path=/usr/local/apache/conf --with-oci8=/oracle/as --disable-rpath --enable-soap --enable-iconv --enable-oracle --with-gd -with-png-dir=/usr --with-jpeg-dir=/usr --with-freetype-dir=/usr --with-zlib=/usr (/oracle/as is oracle application server. we use also oracle9 database. all from official installation) version 5.1.6 compilations is normal version 5.2.3 not compiling , error i've mentioned above !useful information: -- please add 4 lines to source of oci8 extension lines: #ifdef OCI_NLS_CHARSET_MAXBYTESZ #else bytes_per_char = 4; #endif in ext/oci8/oci8_lob.c, near line 340 as i mensioned above --- another questions: why some php developers not analysing problem , but just make copy-paste, and even make errors in copy-pasting :) [2007-08-28 21:08:45] [EMAIL PROTECTED] OCI8 builds and works perfectly fine with Oracle 9, 10 and 11. It can also be used to communicate with earlier versions, though we do not support clients < 9 because of several reasons which I'm not going to explain here. If you are using an unsupported platform (FreeBSD), then it's your responsibility to make it work - we're definitely not going to support hacks and unofficial "ports". If you mentioned FreeBSD for another reason, then please try to be more verbose: I can see a lot of emotions in your report, but almost no useful information. What kind of OS is that? Which version of Oracle client was used? Do you use official distribution or something manually hacked? How did you configure PHP? Without this information the report is bogus. 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/42456 -- Edit this bug report at http://bugs.php.net/?id=42456&edit=1
#42456 [Csd->Bgs]: i foud solution, publish it on website
ID: 42456 Updated by: [EMAIL PROTECTED] Reported By: astorozhuk at ukrcard dot com dot ua -Status: Closed +Status: Bogus Bug Type: OCI8 related Operating System: sles9 PHP Version: 5.2.3 Previous Comments: [2007-08-30 07:33:01] astorozhuk at ukrcard dot com dot ua seems to be source of problem that i was compilling it with Application, not Database ve compiled it with db and now is ok without changing source [2007-08-30 06:34:01] astorozhuk at ukrcard dot com dot ua вото тупорилі копіпастять відповіді і помиляються їм тикаєщ носом що потрібно виправити в ісходніках, а вони не втикають воно і не дивно що в пхп стільки глюків [2007-08-29 08:45:34] [EMAIL PROTECTED] >(/oracle/as is oracle application server. we use also oracle9 >database. all from official installation) What's the EXACT version number? 9.what? >useful information: Oh, please keep this useful information to yourself. >please add 4 lines to source of oci8 extension lines: Please stop telling me what to do. >why some php developers not analysing problem , but just make >copy-paste, and even make errors in copy-pasting :) Why some users think they may call other people stupid and expect these very people to help them? Do you think you're clever? Name me at least one reason why should I even listen to you after that. [2007-08-29 07:15:25] astorozhuk at ukrcard dot com dot ua i definitly wrote in OS field - sles9 (sles9= Suse Linux Enterprise server version 9) , service pack 3, OFFICIAL i mention freebsd as link, not because i use it. i found link with problem solution. configure ./configure --with-apxs=/usr/local/apache/bin/apxs --prefix=/usr/local --with-config-file-path=/usr/local/apache/conf --with-oci8=/oracle/as --disable-rpath --enable-soap --enable-iconv --enable-oracle --with-gd -with-png-dir=/usr --with-jpeg-dir=/usr --with-freetype-dir=/usr --with-zlib=/usr (/oracle/as is oracle application server. we use also oracle9 database. all from official installation) version 5.1.6 compilations is normal version 5.2.3 not compiling , error i've mentioned above !useful information: -- please add 4 lines to source of oci8 extension lines: #ifdef OCI_NLS_CHARSET_MAXBYTESZ #else bytes_per_char = 4; #endif in ext/oci8/oci8_lob.c, near line 340 as i mensioned above --- another questions: why some php developers not analysing problem , but just make copy-paste, and even make errors in copy-pasting :) [2007-08-28 21:08:45] [EMAIL PROTECTED] OCI8 builds and works perfectly fine with Oracle 9, 10 and 11. It can also be used to communicate with earlier versions, though we do not support clients < 9 because of several reasons which I'm not going to explain here. If you are using an unsupported platform (FreeBSD), then it's your responsibility to make it work - we're definitely not going to support hacks and unofficial "ports". If you mentioned FreeBSD for another reason, then please try to be more verbose: I can see a lot of emotions in your report, but almost no useful information. What kind of OS is that? Which version of Oracle client was used? Do you use official distribution or something manually hacked? How did you configure PHP? Without this information the report is bogus. 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/42456 -- Edit this bug report at http://bugs.php.net/?id=42456&edit=1
#42472 [Opn->Bgs]: $_SESSION[false] = 1; Notice: Unknown: Skipping numeric key 0. in Unknown on
ID: 42472 Updated by: [EMAIL PROTECTED] Reported By: jsnell at e-normous dot com -Status: Open +Status: Bogus Bug Type: Session related Operating System: 10.4.10 PHP Version: 5.2.3 New Comment: Rebogused: This is not possible to change and that's how it works. Previous Comments: [2007-08-29 20:57:19] [EMAIL PROTECTED] This isn't exactly the problem. The problem is that the error message produced is incorrect -- not that the error shouldn't occur. It should not have an unknown file and a 0 line number, but rather the file and line number where the error occurred. This is probably superglobal-array-specific, and seems to apply to any numeric key. Reopening. [2007-08-29 20:23:52] [EMAIL PROTECTED] 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 false/true/null/etc are not valid key names. Please read the manual for what is valid and what isn't. This is no bug. [2007-08-29 17:05:02] jsnell at e-normous dot com Description: Attempting to use an array key of false on $_SESSION after a session has been started causes a notice without sufficient information to fix the problem. Also tested in latest CVS: PHP 5.2.4RC4-dev (cgi) (built: Aug 29 2007 11:53:35) Reproduce code: --- error_reporting(E_ALL); session_start(); $_SESSION[false] = 1; Expected result: Notice: Unknown: Skipping numeric key 0. in test.php on line 3 Actual result: -- Notice: Unknown: Skipping numeric key 0. in Unknown on line 0 -- Edit this bug report at http://bugs.php.net/?id=42472&edit=1
#42473 [Opn->Bgs]: ob_start php://output and headers
ID: 42473 Updated by: [EMAIL PROTECTED] Reported By: ce at netage dot bg -Status: Open +Status: Bogus Bug Type: Output Control Operating System: linux PHP Version: 5.2.4RC3 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 >From manual: "ob_get_clean() essentially executes both ob_get_contents() and ob_end_clean()." Previous Comments: [2007-08-29 17:15:33] ce at netage dot bg Description: it is actually a duplicate problem with 40429, but since you have closed the bug I cannot reopen it, but it is still present with all versions including the new 5.2.4RC3 when open through a browser, not a cli! Reproduce code: --- http://bugs.php.net/?id=42473&edit=1
#42475 [Opn->Fbk]: Got seg fault, core dump in php 5.2.3 code in _zend_hash_add_or_update
ID: 42475 Updated by: [EMAIL PROTECTED] Reported By: shawn at mbuzzy dot com -Status: Open +Status: Feedback Bug Type: Reproducible crash Operating System: RedHat Enterprise 3 PHP Version: 5.2.3 Previous Comments: [2007-08-29 23:09:31] shawn at mbuzzy dot com Hello Jani, We tried a simple test and ran php5.2.3 "clean", by disabling third party extensions, including APC. We still got the core dump and the back trace landed in exactly the same place in code. Now we'll try the other suggestion and build/install 5.2.4RC3 and see if that makes the problem go away. Thanks, -Shawn [2007-08-29 20:42:12] [EMAIL PROTECTED] First I need to quote one line from the page you sent this report from: "Always disable any Zend or other 3rd party extensions (Turck MMCache, ionCube loader, Xdebug, APC) before submitting a *PHP* bug." Before you start disabling anything, install the latest CVS snapshot from here: http://snaps.php.net/php5.2-latest.tar.gz And then disable all 3rd party extensions (APC especially..). [2007-08-29 18:42:12] shawn at mbuzzy dot com Description: I am running: Apache 1.3.31 Php 5.2.3 -- built with following switches: './configure' '--prefix=/local/service/php' '--with-apxs=/local/service/apache/bin/apxs' '--with-mysql' '--with-mysqli=/usr/bin/mysql_config' '--with-config-file-path=/local/service/php' '--with-mcrypt' '--with-curl' '--with-pdo-mysql' APC 3.0.14 We are getting a SEGV/core dump from apache httpd. The dump is reproducible in the sense that it happens regularly at about 2-3 hour intervals and the core back-trace is landing in exactly the same spot every time. However, it is not always processing the same php, so it's difficult to give you a reproducible php script to try yourself. However I do have a back-trace that might help. It appears to always be in a state where it is trying to setup the php global hash environment. Specificaly, processing the query args to populate the $_REQUESTS values. #0 _zend_hash_add_or_update (ht=0x64696f, arKey=0x80eb220 "returnURL", nKeyLength=10, pData=0xbfffd4c4, nDataSize=4, pDest=0xbfffd4c8, flag=1) at /local/palermo/redhat.es.3.0.i386/src/php-5.2.3/Zend/zend_hash.c:216 #1 0xb6ee61f0 in zend_symtable_update (ht=0x64696f, arKey=0x80eb220 "returnURL", nKeyLength=10, pData=0xbfffd4c4, nDataSize=4, pDest=0xbfffd4c8) at zend_hash.h:340 #2 0xb6ee4cf8 in php_register_variable_ex (var=0x80eb094 "returnURL", val=0xbfffd500, track_vars_array=0x458ff178) at /local/palermo/redhat.es.3.0.i386/src/php-5.2.3/main/php_variables.c:213 #3 0xb6dabc59 in php_sapi_filter (arg=1, var=0x80eb094 "returnURL", val=0xbfffd580, val_len=21, new_val_len=0xbfffd584) at /local/palermo/redhat.es.3.0.i386/src/php-5.2.3/ext/filter/filter.c:396 #4 0xb6ee50d6 in php_default_treat_data (arg=1, str=0x0, destArray=0x458ff178) at /local/palermo/redhat.es.3.0.i386/src/php-5.2.3/main/php_variables.c:369 #5 0xb6ee5cd7 in php_hash_environment () at /local/palermo/redhat.es.3.0.i386/src/php-5.2.3/main/php_variables.c:677 #6 0xb6edb970 in php_request_startup () at /local/palermo/redhat.es.3.0.i386/src/php-5.2.3/main/main.c:1143 #7 0xb6f67e93 in apache_php_module_main (r=0x809cf70, display_source_mode=0) at /local/palermo/redhat.es.3.0.i386/src/php-5.2.3/sapi/apache/sapi_apache.c:33 #8 0xb6f688ea in send_php (r=0x809cf70, display_source_mode=0, filename=0x0) at /local/palermo/redhat.es.3.0.i386/src/php-5.2.3/sapi/apache/mod_php5.c:663 #9 0xb6f689f7 in send_parsed_php (r=0x809cf70) at /local/palermo/redhat.es.3.0.i386/src/php-5.2.3/sapi/apache/mod_php5.c:678 #10 0x080552bb in ap_invoke_handler () #11 0x0806a619 in process_request_internal () #12 0x0806a678 in ap_process_request () #13 0x08061737 in child_main () #14 0x080619bd in make_child () #15 0x08061cfb in perform_idle_server_maintenance () #16 0x08062332 in standalone_main () #17 0x08062952 in main () Note that the ht parameter _zend_hash_add_or_update() is pointing to bad (invalid) memory. Thanks. -Shawn -- Edit this bug report at http://bugs.php.net/?id=42475&edit=1
#42479 [Opn->Bgs]: win32service Error code: Access is denied.
ID: 42479
Updated by: [EMAIL PROTECTED]
Reported By: tuanhwa at yahoo dot com
-Status: Open
+Status: Bogus
Bug Type: Unknown/Other Function
Operating System: Windows 2003 server 64 bits
PHP Version: 5.2.3
New Comment:
Sorry, but your problem does not imply a bug in PHP itself. For a
list of more appropriate places to ask for help using PHP, please
visit http://www.php.net/support.php as this bug system is not the
appropriate forum for asking support questions. Due to the volume
of reports we can not explain in detail here why your report is not
a bug. The support channels will be able to provide an explanation
for you.
Thank you for your interest in PHP.
Previous Comments:
[2007-08-30 05:02:59] tuanhwa at yahoo dot com
Description:
For the methods win32service
Error code: Access is denied.
OS: Windows 2003 server 64 bits
Reproduce code:
---
$svcStatus=win32_query_service_status ('MySQL-nt');
echo win32_start_service('MySQL-nt');
Expected result:
Mysql will be started
Actual result:
--
Mysql was not restarted.
--
Edit this bug report at http://bugs.php.net/?id=42479&edit=1
#42441 [Bgs]: Unable to instanciate a class who's name is in a constant
ID: 42441
User updated by: romain dot tartiere at healthgrid dot org
Reported By: romain dot tartiere at healthgrid dot org
Status: Bogus
Bug Type: Feature/Change Request
Operating System: GNU/Linux
PHP Version: 5.2.3
New Comment:
Not meant to work? haha! BTW, you may reconsider the status of bug
#23022 since it is exactly the same kind of problem (parser can only
cope with simple situations).
Previous Comments:
[2007-08-30 07:12:49] [EMAIL PROTECTED]
A quick close doesn't mean it wasn't a correct close. This is not a
bug, it's not meant to work. And don't lecture us about LALR parsers
when you have no idea how PHP works.
[2007-08-27 12:42:34] romain dot tartiere at healthgrid dot org
Thank you for your personalised answer and taking time to read and
understand my bug report.
There is nothing about this behaviour in:
-
http://php.net/manual/en/language.oop5.basic.php#language.oop5.basic.new
- http://php.net/manual/en/language.constants.php
Moreover, the behaviour I describe is common to all programming
languages I know (I don't pretent to know all languages, I just tell
that PHP constants are not like other programming language constants).
According to me, it is just a LALR parser mistake.
Something like...
stuff: [...]
| TOK_NEW string '(' ')'
| TOK_NEW variable '(' ')'
... instead of ...
stuff: [...]
| TOK_NEW expression '(' ')'
Sorry for being rude, but your copy-paste-reply make me feel my problem
has been underestimated by an inexperienced person. But maybe I am
wrong, then just prove me that what I am talking about is nonsense...
According to me, if I can't do "new a" but can do "b = a; new b", there
is something wrong.
[2007-08-27 10:22:24] [EMAIL PROTECTED]
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
[2007-08-27 10:08:45] romain dot tartiere at healthgrid dot org
Description:
If you use define to set the name of a class to a constant, you can't
use it to instanciate the class.
Reproduce code:
---
Expected result:
These way of instanciating the foo class should all work.
Actual result:
--
The two first syntax produce the same result:
Fatal error: Class name must be a valid object or a string
--
Edit this bug report at http://bugs.php.net/?id=42441&edit=1
#42480 [Bgs]: Missing DLLs
ID: 42480 Updated by: [EMAIL PROTECTED] Reported By: Slamlander at Caselle-vpn dot net Status: Bogus Bug Type: Dynamic loading Operating System: Win200 Advanced Server w/Cygwin PHP Version: 5.2.3 New Comment: For your information, I use PHP (all versions, incl. devs) on many windows platforms daily. The latest binaries work out of the box (with mysql or oracle for what I use). If you do not know how to install PHP, its extension orrelated softwares, ask someone to do it for you. But don't to blame us for your lack of knowledge, thanks you. Especially not in our bug tracker, we are not here to do not first level support but to fix real bugs. That being said, if you have issues with mysql, buy a license and contact their support. Previous Comments: [2007-08-30 08:13:23] Slamlander at Caselle-vpn dot net With that attitude of denial, it's clear that I'll have to follow the course of action I posted http://slamlander.livejournal.com/244842.html";>here. --- I get PHP5.1.4 to work again and it still won't talk to MySQL 5.0.45 so I'll have to go back down to MySQL 5.0.19. What a bummer! I really want to do some stuff with advanced Database triggers. Time to rip them both out and go back to last year's working configuration. It's a shame because the current MySQL fixes a LOT of problems and I was looking forward to playing with it. However, that can't be done until PHP gets their shit in the same bag. These sorts of issues is why I have taken to calling OpenSource products "Tinker-ware". --- [2007-08-30 08:09:09] [EMAIL PROTECTED] Ok, it seems that you don't want to understand. You can tell us whatever you like using all kinds of (bad) wording, that does not change the facts: - We do not link against aspell - Cygwin is *NOT* windows and our binaries are used to work natively on win32 - Use the php-install mailing list for further assistances [2007-08-30 07:54:33] Slamlander at Caselle-vpn dot net Maybe I should have been more clear. This is a virgin install on a clean, fresh installed, Win2K Advanced Server SP5. The only other install is a minimal Cygwin (for Open SSH), Imagemagick, and MySQL. The binaries were fresh downloaded from your site. The Aspell calls are there and I am not imagining it. Your posted binary is FUBAR! [2007-08-30 05:46:00] [EMAIL PROTECTED] It looks like there is a mess in your extensions or configuration. ASpell, for example, is not used by php (since 4.3.0, see the www.php.net/aspell). Cleanup the dlls in your system, check the extension_dir and read the windows install section in the manual should help. Also cygwin is not windows and has its own sources of troubles. Not a bug > bogus. [2007-08-30 05:19:08] Slamlander at Caselle-vpn dot net the MSDOS command shell is the only one that allows the "php -i" command to pop up the DLL load errors. Cygwin/bash suppresses those popups. 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/42480 -- Edit this bug report at http://bugs.php.net/?id=42480&edit=1
#42480 [Bgs]: Missing DLLs
ID: 42480 User updated by: Slamlander at Caselle-vpn dot net Reported By: Slamlander at Caselle-vpn dot net Status: Bogus Bug Type: Dynamic loading Operating System: Win200 Advanced Server w/Cygwin PHP Version: 5.2.3 New Comment: With that attitude of denial, it's clear that I'll have to follow the course of action I posted http://slamlander.livejournal.com/244842.html";>here. --- I get PHP5.1.4 to work again and it still won't talk to MySQL 5.0.45 so I'll have to go back down to MySQL 5.0.19. What a bummer! I really want to do some stuff with advanced Database triggers. Time to rip them both out and go back to last year's working configuration. It's a shame because the current MySQL fixes a LOT of problems and I was looking forward to playing with it. However, that can't be done until PHP gets their shit in the same bag. These sorts of issues is why I have taken to calling OpenSource products "Tinker-ware". --- Previous Comments: [2007-08-30 08:09:09] [EMAIL PROTECTED] Ok, it seems that you don't want to understand. You can tell us whatever you like using all kinds of (bad) wording, that does not change the facts: - We do not link against aspell - Cygwin is *NOT* windows and our binaries are used to work natively on win32 - Use the php-install mailing list for further assistances [2007-08-30 07:54:33] Slamlander at Caselle-vpn dot net Maybe I should have been more clear. This is a virgin install on a clean, fresh installed, Win2K Advanced Server SP5. The only other install is a minimal Cygwin (for Open SSH), Imagemagick, and MySQL. The binaries were fresh downloaded from your site. The Aspell calls are there and I am not imagining it. Your posted binary is FUBAR! [2007-08-30 05:46:00] [EMAIL PROTECTED] It looks like there is a mess in your extensions or configuration. ASpell, for example, is not used by php (since 4.3.0, see the www.php.net/aspell). Cleanup the dlls in your system, check the extension_dir and read the windows install section in the manual should help. Also cygwin is not windows and has its own sources of troubles. Not a bug > bogus. [2007-08-30 05:19:08] Slamlander at Caselle-vpn dot net the MSDOS command shell is the only one that allows the "php -i" command to pop up the DLL load errors. Cygwin/bash suppresses those popups. [2007-08-30 05:11:16] Slamlander at Caselle-vpn dot net Description: Missing DLLs during load. Reproduce code: --- C:\Documents and Settings\root>php -i popup windows report the adsence of: Aspell-15.dll lcrzo.dll intl3_sun.dll libbd43.dll I have been able to locate all but libbd43.dll. This is because the current version of that library is libbd44.dll, as released with the current subversion. Older versions (BDB 4.3) are not available from Sleepycat. Expected result: I expect that binary code releases include ALL dependent binaries, as well as their own. I don't understand why PHP would need those functions in any case and the linker depedencies should not be there. I do not have access to a Microsoft Visual C environment. You should make 5.1.4 available for download until you get these production issues dealt with. Actual result: -- I had to revert to PHP 5.1.4 for a working production system and am discovering bugs with that as well, using; eagle.NE.Caselle-NET:~ Thu Aug 30 06:55:16 [bash:root:2]$> mysql -? c:\Program Files\MySQL\MySQL Server 5.0\bin\mysql.exe Ver 14.12 Distrib 5.0.45, for Win32 (ia32) Copyright (C) 2002 MySQL AB and may have to go back to condor.NE.Caselle-NET:~ Thu Aug 30 07:06:51 [bash:root:1]$> mysql -? | less c:\Program Files\MySQL\MySQL Server 5.0\bin\mysql.exe Ver 14.12 Distrib 5.0.19, for Win32 (ia32) Copyright (C) 2002 MySQL AB Even 5.4.1 will not talk to any current MySQL database server. I am quite disappointed. -- Edit this bug report at http://bugs.php.net/?id=42480&edit=1
#42480 [Opn->Bgs]: Missing DLLs
ID: 42480 Updated by: [EMAIL PROTECTED] Reported By: Slamlander at Caselle-vpn dot net -Status: Open +Status: Bogus Bug Type: Dynamic loading Operating System: Win200 Advanced Server w/Cygwin PHP Version: 5.2.3 New Comment: Ok, it seems that you don't want to understand. You can tell us whatever you like using all kinds of (bad) wording, that does not change the facts: - We do not link against aspell - Cygwin is *NOT* windows and our binaries are used to work natively on win32 - Use the php-install mailing list for further assistances Previous Comments: [2007-08-30 07:54:33] Slamlander at Caselle-vpn dot net Maybe I should have been more clear. This is a virgin install on a clean, fresh installed, Win2K Advanced Server SP5. The only other install is a minimal Cygwin (for Open SSH), Imagemagick, and MySQL. The binaries were fresh downloaded from your site. The Aspell calls are there and I am not imagining it. Your posted binary is FUBAR! [2007-08-30 05:46:00] [EMAIL PROTECTED] It looks like there is a mess in your extensions or configuration. ASpell, for example, is not used by php (since 4.3.0, see the www.php.net/aspell). Cleanup the dlls in your system, check the extension_dir and read the windows install section in the manual should help. Also cygwin is not windows and has its own sources of troubles. Not a bug > bogus. [2007-08-30 05:19:08] Slamlander at Caselle-vpn dot net the MSDOS command shell is the only one that allows the "php -i" command to pop up the DLL load errors. Cygwin/bash suppresses those popups. [2007-08-30 05:11:16] Slamlander at Caselle-vpn dot net Description: Missing DLLs during load. Reproduce code: --- C:\Documents and Settings\root>php -i popup windows report the adsence of: Aspell-15.dll lcrzo.dll intl3_sun.dll libbd43.dll I have been able to locate all but libbd43.dll. This is because the current version of that library is libbd44.dll, as released with the current subversion. Older versions (BDB 4.3) are not available from Sleepycat. Expected result: I expect that binary code releases include ALL dependent binaries, as well as their own. I don't understand why PHP would need those functions in any case and the linker depedencies should not be there. I do not have access to a Microsoft Visual C environment. You should make 5.1.4 available for download until you get these production issues dealt with. Actual result: -- I had to revert to PHP 5.1.4 for a working production system and am discovering bugs with that as well, using; eagle.NE.Caselle-NET:~ Thu Aug 30 06:55:16 [bash:root:2]$> mysql -? c:\Program Files\MySQL\MySQL Server 5.0\bin\mysql.exe Ver 14.12 Distrib 5.0.45, for Win32 (ia32) Copyright (C) 2002 MySQL AB and may have to go back to condor.NE.Caselle-NET:~ Thu Aug 30 07:06:51 [bash:root:1]$> mysql -? | less c:\Program Files\MySQL\MySQL Server 5.0\bin\mysql.exe Ver 14.12 Distrib 5.0.19, for Win32 (ia32) Copyright (C) 2002 MySQL AB Even 5.4.1 will not talk to any current MySQL database server. I am quite disappointed. -- Edit this bug report at http://bugs.php.net/?id=42480&edit=1
#42480 [Opn]: Missing DLLs
ID: 42480 User updated by: Slamlander at Caselle-vpn dot net Reported By: Slamlander at Caselle-vpn dot net Status: Open Bug Type: Dynamic loading Operating System: Win200 Advanced Server w/Cygwin PHP Version: 5.2.3 New Comment: Maybe I should have been more clear. This is a virgin install on a clean, fresh installed, Win2K Advanced Server SP5. The only other install is a minimal Cygwin (for Open SSH), Imagemagick, and MySQL. The binaries were fresh downloaded from your site. The Aspell calls are there and I am not imagining it. Your posted binary is FUBAR! Previous Comments: [2007-08-30 05:46:00] [EMAIL PROTECTED] It looks like there is a mess in your extensions or configuration. ASpell, for example, is not used by php (since 4.3.0, see the www.php.net/aspell). Cleanup the dlls in your system, check the extension_dir and read the windows install section in the manual should help. Also cygwin is not windows and has its own sources of troubles. Not a bug > bogus. [2007-08-30 05:19:08] Slamlander at Caselle-vpn dot net the MSDOS command shell is the only one that allows the "php -i" command to pop up the DLL load errors. Cygwin/bash suppresses those popups. [2007-08-30 05:11:16] Slamlander at Caselle-vpn dot net Description: Missing DLLs during load. Reproduce code: --- C:\Documents and Settings\root>php -i popup windows report the adsence of: Aspell-15.dll lcrzo.dll intl3_sun.dll libbd43.dll I have been able to locate all but libbd43.dll. This is because the current version of that library is libbd44.dll, as released with the current subversion. Older versions (BDB 4.3) are not available from Sleepycat. Expected result: I expect that binary code releases include ALL dependent binaries, as well as their own. I don't understand why PHP would need those functions in any case and the linker depedencies should not be there. I do not have access to a Microsoft Visual C environment. You should make 5.1.4 available for download until you get these production issues dealt with. Actual result: -- I had to revert to PHP 5.1.4 for a working production system and am discovering bugs with that as well, using; eagle.NE.Caselle-NET:~ Thu Aug 30 06:55:16 [bash:root:2]$> mysql -? c:\Program Files\MySQL\MySQL Server 5.0\bin\mysql.exe Ver 14.12 Distrib 5.0.45, for Win32 (ia32) Copyright (C) 2002 MySQL AB and may have to go back to condor.NE.Caselle-NET:~ Thu Aug 30 07:06:51 [bash:root:1]$> mysql -? | less c:\Program Files\MySQL\MySQL Server 5.0\bin\mysql.exe Ver 14.12 Distrib 5.0.19, for Win32 (ia32) Copyright (C) 2002 MySQL AB Even 5.4.1 will not talk to any current MySQL database server. I am quite disappointed. -- Edit this bug report at http://bugs.php.net/?id=42480&edit=1
#25876 [NoF->Opn]: session_start(): Failed to initialize storage module
ID: 25876 User updated by: golden at riscom dot com Reported By: golden at riscom dot com -Status: No Feedback +Status: Open Bug Type: Session related Operating System: freebsd 4.8 PHP Version: 4.3.9-4.3.10 Assigned To: sniper New Comment: > We are currently having problem with the same think at one of our servers. Previous Comments: [2007-06-27 23:15:12] josh at spinningplanet dot co dot nz Try disabling safe mode [2007-02-03 16:51:38] earnie at users dot sourceforge dot net Just to note: This error happens if the functions identified in session_set_save_handler are not defined at the time of the call. [2006-12-09 20:02:53] thecancerus at gmail dot com we can pass session id to ensuser that session remains intact.. use SID it will help [2006-07-21 08:05:00] contact at far-php dot ro Hy i have this problem as well. PHP version 4.3.11 Script index.php: session_start(); ob_start(); /tmp -> /domanin_site/tmp/ [2006-06-27 06:28:57] hmahmoud1900 at gmail dot com still have same problem , user session empty and get out of the site. try all what the guys said , nothing happened 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/25876 -- Edit this bug report at http://bugs.php.net/?id=25876&edit=1
#42456 [Bgs->Csd]: i foud solution, publish it on website
ID: 42456 User updated by: astorozhuk at ukrcard dot com dot ua Reported By: astorozhuk at ukrcard dot com dot ua -Status: Bogus +Status: Closed Bug Type: OCI8 related Operating System: sles9 PHP Version: 5.2.3 New Comment: seems to be source of problem that i was compilling it with Application, not Database ve compiled it with db and now is ok without changing source Previous Comments: [2007-08-30 06:34:01] astorozhuk at ukrcard dot com dot ua вото тупорилі копіпастять відповіді і помиляються їм тикаєщ носом що потрібно виправити в ісходніках, а вони не втикають воно і не дивно що в пхп стільки глюків [2007-08-29 08:45:34] [EMAIL PROTECTED] >(/oracle/as is oracle application server. we use also oracle9 >database. all from official installation) What's the EXACT version number? 9.what? >useful information: Oh, please keep this useful information to yourself. >please add 4 lines to source of oci8 extension lines: Please stop telling me what to do. >why some php developers not analysing problem , but just make >copy-paste, and even make errors in copy-pasting :) Why some users think they may call other people stupid and expect these very people to help them? Do you think you're clever? Name me at least one reason why should I even listen to you after that. [2007-08-29 07:15:25] astorozhuk at ukrcard dot com dot ua i definitly wrote in OS field - sles9 (sles9= Suse Linux Enterprise server version 9) , service pack 3, OFFICIAL i mention freebsd as link, not because i use it. i found link with problem solution. configure ./configure --with-apxs=/usr/local/apache/bin/apxs --prefix=/usr/local --with-config-file-path=/usr/local/apache/conf --with-oci8=/oracle/as --disable-rpath --enable-soap --enable-iconv --enable-oracle --with-gd -with-png-dir=/usr --with-jpeg-dir=/usr --with-freetype-dir=/usr --with-zlib=/usr (/oracle/as is oracle application server. we use also oracle9 database. all from official installation) version 5.1.6 compilations is normal version 5.2.3 not compiling , error i've mentioned above !useful information: -- please add 4 lines to source of oci8 extension lines: #ifdef OCI_NLS_CHARSET_MAXBYTESZ #else bytes_per_char = 4; #endif in ext/oci8/oci8_lob.c, near line 340 as i mensioned above --- another questions: why some php developers not analysing problem , but just make copy-paste, and even make errors in copy-pasting :) [2007-08-28 21:08:45] [EMAIL PROTECTED] OCI8 builds and works perfectly fine with Oracle 9, 10 and 11. It can also be used to communicate with earlier versions, though we do not support clients < 9 because of several reasons which I'm not going to explain here. If you are using an unsupported platform (FreeBSD), then it's your responsibility to make it work - we're definitely not going to support hacks and unofficial "ports". If you mentioned FreeBSD for another reason, then please try to be more verbose: I can see a lot of emotions in your report, but almost no useful information. What kind of OS is that? Which version of Oracle client was used? Do you use official distribution or something manually hacked? How did you configure PHP? Without this information the report is bogus. [2007-08-28 12:04:27] astorozhuk at ukrcard dot com dot ua google: ociheaders site:oracle.com found http://www.oracle.com/technology/products/ias/ohs/htdocs/php_ohs.htm title of document: Using PHP with Oracle Application Server 10g (! version 10) url of headers found http://www.oracle.com/technology/products/ias/ohs/htdocs/ociheaders.tar wget http://www.oracle.com/technology/products/ias/ohs/htdocs/ociheaders.tar --15:00:49-- http://www.oracle.com/technology/products/ias/ohs/htdocs/ociheaders.tar => `ociheaders.tar' Resolving www.oracle.com... 141.146.8.66 Connecting to www.oracle.com[141.146.8.66]:80... connected. HTTP request sent, awaiting response... 200 OK Length: 1,330,176 [application/x-tar] 100%[==>] 1,330,176 13.60K/sETA 00:00 15:01:52 (22.22 KB/s) - `ociheaders.tar' saved [1330176/1330176] md5sum ociheaders.tar 1d1cc2502e9d1e5bf95c33b5616fb604 ociheaders.tar comparing with headers that was long time ago (few monthes), and installed on system... #OciHeaders # url http://www.oracle.com/technology/products/ias/ohs/htdocs/ociheaders.tar # md5 1d1cc2502e9d1e5bf95c33b5616fb604 -
#42441 [Opn->Bgs]: Unable to instanciate a class who's name is in a constant
ID: 42441
Updated by: [EMAIL PROTECTED]
Reported By: romain dot tartiere at healthgrid dot org
-Status: Open
+Status: Bogus
Bug Type: Feature/Change Request
Operating System: GNU/Linux
PHP Version: 5.2.3
New Comment:
A quick close doesn't mean it wasn't a correct close. This is not a
bug, it's not meant to work. And don't lecture us about LALR parsers
when you have no idea how PHP works.
Previous Comments:
[2007-08-27 12:42:34] romain dot tartiere at healthgrid dot org
Thank you for your personalised answer and taking time to read and
understand my bug report.
There is nothing about this behaviour in:
-
http://php.net/manual/en/language.oop5.basic.php#language.oop5.basic.new
- http://php.net/manual/en/language.constants.php
Moreover, the behaviour I describe is common to all programming
languages I know (I don't pretent to know all languages, I just tell
that PHP constants are not like other programming language constants).
According to me, it is just a LALR parser mistake.
Something like...
stuff: [...]
| TOK_NEW string '(' ')'
| TOK_NEW variable '(' ')'
... instead of ...
stuff: [...]
| TOK_NEW expression '(' ')'
Sorry for being rude, but your copy-paste-reply make me feel my problem
has been underestimated by an inexperienced person. But maybe I am
wrong, then just prove me that what I am talking about is nonsense...
According to me, if I can't do "new a" but can do "b = a; new b", there
is something wrong.
[2007-08-27 10:22:24] [EMAIL PROTECTED]
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
[2007-08-27 10:08:45] romain dot tartiere at healthgrid dot org
Description:
If you use define to set the name of a class to a constant, you can't
use it to instanciate the class.
Reproduce code:
---
Expected result:
These way of instanciating the foo class should all work.
Actual result:
--
The two first syntax produce the same result:
Fatal error: Class name must be a valid object or a string
--
Edit this bug report at http://bugs.php.net/?id=42441&edit=1
