#32860 [Opn]: quoted-string cookies not handled correctly
ID: 32860
Updated by: [EMAIL PROTECTED]
Reported By: ast at gmx dot ch
Status: Open
Bug Type: Feature/Change Request
Operating System: *
PHP Version: 4.3.11
New Comment:
When PHP was written, this RFC did not yet exist - that's why we
classify it as a feature request - it's basically cookie version 1.1.
Previous Comments:
[2005-04-28 00:04:15] ast at gmx dot ch
Feature/Change request?
I don't agree. Handling a HTTP header not according to the RFCs they
are defined in doesn't make sense at all. Therefore, it's a bug.
But it's not that important to me. Do what you consider the right
thing.
[2005-04-28 00:00:18] [EMAIL PROTECTED]
Reclassified.
[2005-04-27 23:20:34] ast at gmx dot ch
Obviously, the bug report was mangled.
Here's a pretty print of the report / fix:
http://nei.ch/articles/quoted_string_cookie_fix.php
[2005-04-27 21:46:18] ast at gmx dot ch
Description:
/*
* Description:
*RFC 2965 describes the HTTP State Management mechanism.
*From section 3.1 Syntax: General:
* av-pairs= av-pair *(; av-pair)
* av-pair = attr [= value] ; optional
value
* attr= token
* value = token | quoted-string
*
*PHP 4.3.11 does not handle the case of quoted-string values.
*See RFC 2616 section 2.2 Basic Rules for a definition of
quoted-string.
*quoted-string = ( *(qdtext | quoted-pair ) )
*qdtext = any TEXT except
*
* The backslash character (\) MAY be used as a
single-character
* quoting mechanism only within quoted-string and comment
constructs.
*
*quoted-pair= \ CHAR
*
*PHP 4.3.11 urlencodes all cookie name = value pairs. Therefore,
it can handle
*values that contain the separators , and ;. But the RFC 2965
describes that
*a HTTP Cookie header sent from the user agent to the server may
have av-pairs,
*where the value may be a token or a quoted string.
*
*If one sets a cookie not with PHP's setCookie() method, but
directly with header(),
*then it is sent correctly to the user agent and the user agent
returns it also
*correctly. But when PHP reads the HTTP Cookie header back into
$_COOKIE, it does
*not handle quoted-strings.
*
*Result:
* Wrong cookie values in $_COOKIE.
*
*The bug is in PHP's source in function
* SAPI_API SAPI_TREAT_DATA_FUNC(php_default_treat_data)
*It parses the HTTP Cookie header and directly uses , and ; as
separators.
*A slightly more complicated handling of the HTTP Cookie header is
required.
*In addition to the current code, one has to handle:
* - quoted-strings: separators , and ; may be in
quoted-strings
* - double-quote marks escaped by \ don't end a quoted-string
*
*Cookies with values that are not urlencoded may come from:
* - non-PHP applications on the same host
* - RFC 2965 compliant PHP cookies that were set with header()
instead of setcookie().
*
*Example:
* In PHP script:
*header('Set-Cookie: TestCookie = value with , perfectly ;
allowed 8-Bit characters ' .
*'and escaped \ double-quote marks!');
* The cookie is successfully sent to the user agent. The user
agent sends it back with a
* perfectly intact value.
* PHP receives the HTTP Cookie header from the webserver (I
inserted the line break):
*Cookie: TestCookie=value with , perfectly ; allowed 8-Bit
characters and escaped \
*double-quote marks!\r\n
* Then PHP parses the HTTP Cookie header ignoring the case of
quoted-strings and fills the
* superglobal $_COOKIE with:
* [TestCookie]=
*string(24) value with , perfectly
*
[allowed_8-BIT_characters_and_escaped_\_double-quote_marks!]=
*string(0)
* If PHP handled the HTTP Cookie header correctly, one would
get:
* [TestCookie]=
*string(86) value with , perfectly ; allowed 8-BIT
characters and escaped \ double-quote marks!
*
* I even think, if PHP handled , and ; as separators, the
current PHP should have
* created three cookies out of the above name = value pair.
*
* References:
*RFC 2965: http://rfc.net/rfc2965.html
*RFC 2616: http://rfc.net/rfc2616.html
*/
Proposed fix:
In the PHP source, replace the simple strtok() call in SAPI_API
SAPI_TREAT_DATA_FUNC(php_default_treat_data) by the C++ equivalent of
the following PHP code:
/**
* Fix the superglobal $_COOKIE to conform with RFC 2965
*
* This function reevaluates the HTTP Cookie header and
#32858 [Opn-Bgs]: Bug #25649 has crept back into PHP - Improper feof() handling under FreeBSD
ID: 32858
Updated by: [EMAIL PROTECTED]
Reported By: lew at mailduct dot com
-Status: Open
+Status: Bogus
Bug Type: Filesystem function related
Operating System: FreeBSD 4.11-REL
PHP Version: 4.3.10
New Comment:
It wouldn't be the first time when something is magically fixed by
updating..and the changes might seem totally unrelated.
Previous Comments:
[2005-04-28 07:17:35] lew at mailduct dot com
I don't see any changes to the PHP feof library implementation between
4.3.10 and 4.3.11... shall I try it anyway and see if it magically
heals itself? I say this sarcastically because, if you look at
PR#25649 you'll see that I had to pull teeth just to get someone to
take this seriously. The default assumption is OE (Operator Error).
[2005-04-28 00:04:38] [EMAIL PROTECTED]
Have you tried PHP 4.3.11, the LATEST release..?
[2005-04-27 21:36:47] lew at mailduct dot com
Description:
In my prior bug report #25649 from September 2003, I pointed out a
serious bug in how PHP handles FEOF under FreeBSD. It was fixed by
[EMAIL PROTECTED] and committed.
This same problem (improper handling of feof() by PHP under FreeBSD)
has now crept into current 4.3.X versions of PHP...
Problem: Once set, the FEOF indicator is not properly cleared when
more data is appended to a file that is opened for read by a PHP
application.
Example: Suppose I want to tail a file using PHP. Once I hit the
EOF, I will no longer be able to read data from that file even when
another application appends to it. This is not the correct behaviour
for feof(), as illustrated by the prior fix done by [EMAIL PROTECTED]
Reproduce code:
---
--- program:
$fp = fopen( '/var/log/maillog','r' );
while( TRUE ) {
$r = array( $fp );
$n = stream_select( $r,$w=NULL,$e=NULL,30 );
if( $n ) {
echo fgets( $fp );
}
}
--- feeder:
echo This is a test... /var/log/maillog
Expected result:
For as long as PROGRAM is running, each time I run
FEEDER I expect to see PROGRAM output This is a test...
but it does not, because once EOF is reached, it is not
properly reset upon more data being appended to the file.
See pr #25649 for historical info...
Actual result:
--
PROGRAM will read the contents of /var/log/maillog until it
reaches EOF, and will not output anything else, even if new
data is appeneded to the file.
--
Edit this bug report at http://bugs.php.net/?id=32858edit=1
#32858 [Bgs-Fbk]: Bug #25649 has crept back into PHP - Improper feof() handling under FreeBSD
ID: 32858
Updated by: [EMAIL PROTECTED]
Reported By: lew at mailduct dot com
-Status: Bogus
+Status: Feedback
Bug Type: Filesystem function related
Operating System: FreeBSD 4.11-REL
PHP Version: 4.3.10
Previous Comments:
[2005-04-28 08:26:42] [EMAIL PROTECTED]
It wouldn't be the first time when something is magically fixed by
updating..and the changes might seem totally unrelated.
[2005-04-28 07:17:35] lew at mailduct dot com
I don't see any changes to the PHP feof library implementation between
4.3.10 and 4.3.11... shall I try it anyway and see if it magically
heals itself? I say this sarcastically because, if you look at
PR#25649 you'll see that I had to pull teeth just to get someone to
take this seriously. The default assumption is OE (Operator Error).
[2005-04-28 00:04:38] [EMAIL PROTECTED]
Have you tried PHP 4.3.11, the LATEST release..?
[2005-04-27 21:36:47] lew at mailduct dot com
Description:
In my prior bug report #25649 from September 2003, I pointed out a
serious bug in how PHP handles FEOF under FreeBSD. It was fixed by
[EMAIL PROTECTED] and committed.
This same problem (improper handling of feof() by PHP under FreeBSD)
has now crept into current 4.3.X versions of PHP...
Problem: Once set, the FEOF indicator is not properly cleared when
more data is appended to a file that is opened for read by a PHP
application.
Example: Suppose I want to tail a file using PHP. Once I hit the
EOF, I will no longer be able to read data from that file even when
another application appends to it. This is not the correct behaviour
for feof(), as illustrated by the prior fix done by [EMAIL PROTECTED]
Reproduce code:
---
--- program:
$fp = fopen( '/var/log/maillog','r' );
while( TRUE ) {
$r = array( $fp );
$n = stream_select( $r,$w=NULL,$e=NULL,30 );
if( $n ) {
echo fgets( $fp );
}
}
--- feeder:
echo This is a test... /var/log/maillog
Expected result:
For as long as PROGRAM is running, each time I run
FEEDER I expect to see PROGRAM output This is a test...
but it does not, because once EOF is reached, it is not
properly reset upon more data being appended to the file.
See pr #25649 for historical info...
Actual result:
--
PROGRAM will read the contents of /var/log/maillog until it
reaches EOF, and will not output anything else, even if new
data is appeneded to the file.
--
Edit this bug report at http://bugs.php.net/?id=32858edit=1
#32862 [Opn-Bgs]: session_register() causes Segmentation fault
ID: 32862 Updated by: [EMAIL PROTECTED] Reported By: svenl at haberer-online dot de -Status: Open +Status: Bogus Bug Type: Session related Operating System: SUSE Linux 9.2 PHP Version: 4.3.11 New Comment: It can hardly work if you have '--disable-session' in your configure line. Previous Comments: [2005-04-28 02:32:53] svenl at haberer-online dot de Actually the same problem exists if register_globals = Off [2005-04-28 02:22:23] svenl at haberer-online dot de Description: Hi, when calling session_register() using php 4.3.11 and apache 2.0.50, I get an Seg-Fault. When using $_SESSION, it works fine Using php 4.3.10 and exactly the same configuration, it worked fine. my config looks as follows: ./configure --prefix=/usr --datadir=/usr/share/php --mandir=/usr/share/man --bindir=/usr/bin --libdir=/usr/share --includedir=/usr/include --sysconfdir=/etc --with-_lib=lib --with-config-file-path=/etc --with-exec-dir=/usr/lib/php/bin --disable-debug --enable-inline-optimization --enable-memory-limit --enable-magic-quotes --enable-safe-mode --enable-sigchild --disable-ctype --disable-session --without-mysql --disable-cli --without-pear --with-openssl --with-apxs2=/usr/sbin/apxs2-prefork i586-suse-linux --with-unixODBC=/usr/lib/unixODBC php-ini: register_globals = On Reproduce code: --- Script 1: crashes ? $barney = A big purple dinosaur.; session_register(barney); echo date=.date(H:i:s,time()); ? Script 2: works ? $_SESSION[barney] = A big purple dinosaur.; echo date=.date(H:i:s,time()); ? Expected result: both times I expect the time to be displayed Actual result: -- With the first script the browser shows nothing (FireFox) or complains that the server closed the connection (Konqueror). Also apache adds the following warning to the error_log: [date] [notice] child pid 30727 exit signal Segmentation fault (11) --- The second script shows the time as expected -- Edit this bug report at http://bugs.php.net/?id=32862edit=1
#29297 [Asn-WFx]: PDFLib 6 make error
ID: 29297 Updated by: [EMAIL PROTECTED] Reported By: v_santhanam at ettimadai dot amrita dot edu -Status: Assigned +Status: Wont fix Bug Type: Compile Failure Operating System: Redhat Enterprise Linux AS 3 PHP Version: 4.3.8 Assigned To: rjs New Comment: Use the PECL extension if you need PDFLib 6 support. Previous Comments: [2004-11-29 10:14:14] [EMAIL PROTECTED] I reverted this fix in CVS now, please make a proper one that allows PDFLib 4 and 5 to work. [2004-11-22 13:05:14] [EMAIL PROTECTED] Reiner, you didn't not commit anything so don't use the quick fix Fixed in CVS. Also, there is no good reason to block the use of PDFLIb 5 here, as it works fine, it just doesn't have a full implementation. That is not a problem as it is the case for most other bindings to libraries. I'm re-assigning this until the confiure check is fixed. [2004-11-22 12:01:30] [EMAIL PROTECTED] 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. There is a wrapper that works with PDFlib 5 and PDFlib 6. You can find this wrapper at pecl.php.net. The wrapper included here supports the PDFlib 4 API and not more. It is true, that it also would compile with PDFlib 5, but it does not support PDFlib 5, as the new API's from PDFlib 5 are not implemented. This is the reason why configure strictly checks this. [2004-11-16 06:07:01] v_santhanam at ettimadai dot amrita dot edu Dear Friends, very happy to know that the bug has been fixed. But i have one doubt. rjs has told Configure now only allows to work with PDFlib up to PDFlib 4. But for my little brain tells that PHP can work perfectly upto PDFLib 5. Please kindly clarify. Thanks a lot in advance. With Regards Santhanam [2004-11-14 00:42:03] [EMAIL PROTECTED] 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. Configure now only allows to work with PDFlib up to PDFlib 4, as newer PDFlib versions need the code from the PDFlib PECL module. 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/29297 -- Edit this bug report at http://bugs.php.net/?id=29297edit=1
#32844 [Fbk-Opn]: libphp4.so not created
ID: 32844 User updated by: adam at adamandliz dot com Reported By: adam at adamandliz dot com -Status: Feedback +Status: Open Bug Type: Compile Failure Operating System: Fedora Core 2 PHP Version: 4.3.11 New Comment: my apologies... I had previously found advice on other pages that uses libtoolize Anyway, I deleted the directory and re-created from the tar (4.3.11) the .so gets created this time. Previous Comments: [2005-04-28 00:15:36] [EMAIL PROTECTED] You did use fresh sources? And you are not doing something silly like running buildconf or autoconf or libtoolize..? [2005-04-27 18:17:29] adam at adamandliz dot com Still no .so created, only a .a and .la additionally, the following messages appeared in the make using piecewise archive linking... /usr/php-4.3.11/libtool: line 5386: test: : integer expression expected /usr/php-4.3.11/libtool: line 5386: test: : integer expression expected (last message repeated dozens of times) [2005-04-27 12:54:51] [EMAIL PROTECTED] Try with this configure line: # ./configure --disable-all --with-apxs2=/usr/local/apache2/bin/apxs [2005-04-26 18:29:17] adam at adamandliz dot com Description: Firstly, I have no problems under 4.3.9. However 4.3.10, 4.3.11 and a recent snapshot fail. Whenc ompiling php using standard ./configure, make, make install. the libphp4.so file is not created. the configure command is: ./configure --with-apxs2=/usr/local/apache2/bin/apxs --enable-track-vars --enable-force-cgi-redirect --with-gettext --with-mysql=/usr/local/mysql --with-config-file-path=/usr/local/lib/php -with-imap --enable-mbstring --with-kerberos --with-imap-ssl Before the last libtool in the make command, the following is displayed (this may well be ared herring) *** Warning: inter-library dependencies are not known to be supported. *** All declared inter-library dependencies are being dropped. *** Warning: libtool could not satisfy all declared inter-library *** dependencies of module libphp4. Therefore, libtool will create *** a static module, that should work as long as the dlopening *** application is linked with the -dlopen flag. When doing a make install, I get (from the recent snapshot): [EMAIL PROTECTED] php4-STABLE-200504251836]# make install Installing PHP SAPI module: apache2handler /usr/local/apache2/build/instdso.sh SH_LIBTOOL='/usr/local/apache2/build/libtool' libphp4.la /usr/local/apache2/modules /usr/local/apache2/build/libtool --mode=install cp libphp4.la /usr/local/apache2/modules/ cp .libs/libphp4.lai /usr/local/apache2/modules/libphp4.la cp .libs/libphp4.a /usr/local/apache2/modules/libphp4.a ranlib /usr/local/apache2/modules/libphp4.a chmod 644 /usr/local/apache2/modules/libphp4.a libtool: install: warning: remember to run `libtool --finish /usr/php4-STABLE-200504251836/libs' Warning! dlname not found in /usr/local/apache2/modules/libphp4.la. Assuming installing a .so rather than a libtool archive. chmod 755 /usr/local/apache2/modules/libphp4.so chmod: cannot access `/usr/local/apache2/modules/libphp4.so': No such file or directory apxs:Error: Command failed with rc=65536 . make: *** [install-sapi] Error 1 -- Edit this bug report at http://bugs.php.net/?id=32844edit=1
#32844 [Opn-Bgs]: libphp4.so not created
ID: 32844 Updated by: [EMAIL PROTECTED] Reported By: adam at adamandliz dot com -Status: Open +Status: Bogus Bug Type: Compile Failure Operating System: Fedora Core 2 PHP Version: 4.3.11 New Comment: No bug - bogus. Previous Comments: [2005-04-28 09:04:18] adam at adamandliz dot com my apologies... I had previously found advice on other pages that uses libtoolize Anyway, I deleted the directory and re-created from the tar (4.3.11) the .so gets created this time. [2005-04-28 00:15:36] [EMAIL PROTECTED] You did use fresh sources? And you are not doing something silly like running buildconf or autoconf or libtoolize..? [2005-04-27 18:17:29] adam at adamandliz dot com Still no .so created, only a .a and .la additionally, the following messages appeared in the make using piecewise archive linking... /usr/php-4.3.11/libtool: line 5386: test: : integer expression expected /usr/php-4.3.11/libtool: line 5386: test: : integer expression expected (last message repeated dozens of times) [2005-04-27 12:54:51] [EMAIL PROTECTED] Try with this configure line: # ./configure --disable-all --with-apxs2=/usr/local/apache2/bin/apxs [2005-04-26 18:29:17] adam at adamandliz dot com Description: Firstly, I have no problems under 4.3.9. However 4.3.10, 4.3.11 and a recent snapshot fail. Whenc ompiling php using standard ./configure, make, make install. the libphp4.so file is not created. the configure command is: ./configure --with-apxs2=/usr/local/apache2/bin/apxs --enable-track-vars --enable-force-cgi-redirect --with-gettext --with-mysql=/usr/local/mysql --with-config-file-path=/usr/local/lib/php -with-imap --enable-mbstring --with-kerberos --with-imap-ssl Before the last libtool in the make command, the following is displayed (this may well be ared herring) *** Warning: inter-library dependencies are not known to be supported. *** All declared inter-library dependencies are being dropped. *** Warning: libtool could not satisfy all declared inter-library *** dependencies of module libphp4. Therefore, libtool will create *** a static module, that should work as long as the dlopening *** application is linked with the -dlopen flag. When doing a make install, I get (from the recent snapshot): [EMAIL PROTECTED] php4-STABLE-200504251836]# make install Installing PHP SAPI module: apache2handler /usr/local/apache2/build/instdso.sh SH_LIBTOOL='/usr/local/apache2/build/libtool' libphp4.la /usr/local/apache2/modules /usr/local/apache2/build/libtool --mode=install cp libphp4.la /usr/local/apache2/modules/ cp .libs/libphp4.lai /usr/local/apache2/modules/libphp4.la cp .libs/libphp4.a /usr/local/apache2/modules/libphp4.a ranlib /usr/local/apache2/modules/libphp4.a chmod 644 /usr/local/apache2/modules/libphp4.a libtool: install: warning: remember to run `libtool --finish /usr/php4-STABLE-200504251836/libs' Warning! dlname not found in /usr/local/apache2/modules/libphp4.la. Assuming installing a .so rather than a libtool archive. chmod 755 /usr/local/apache2/modules/libphp4.so chmod: cannot access `/usr/local/apache2/modules/libphp4.so': No such file or directory apxs:Error: Command failed with rc=65536 . make: *** [install-sapi] Error 1 -- Edit this bug report at http://bugs.php.net/?id=32844edit=1
#30578 [Opn-Csd]: Output buffers flush explicitly before all variables have gone out of scope
ID: 30578
Updated by: [EMAIL PROTECTED]
Reported By: anthony at ectrolinux dot com
-Status: Open
+Status: Closed
Bug Type: Output Control
Operating System: *
PHP Version: 5CVS-2005-03-07
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.
Fix will be in PHP 5.1
Previous Comments:
[2004-10-27 08:09:59] anthony at ectrolinux dot com
Description:
During script termination, PHP's explicit output buffer flush should
wait until all variables have gone -completely- out of scope. Using an
instantiated object that manages buffers, the data has already been
flushed before __destruct() is called, which prevents the script from
properly finalizing data collection and flushing the output normally.
This is not the appropriate behavior.
Reproduce code:
---
?php
error_reporting(E_ALL);
class Example
{
function __construct()
{
ob_start();
echo 'This should be displayed last.'.\n;
}
function __destruct()
{
$buffered_data = ob_get_contents();
ob_end_clean();
echo 'This should be displayed first.'.\n;
echo 'Buffered data: '. $buffered_data;
}
}
$obj = new Example;
?
Expected result:
This should be displayed first.
Buffered data: This should be displayed last.
Actual result:
--
This should be displayed last.
Notice: ob_end_clean(): failed to delete buffer. No buffer to delete.
in /--snip--/test.php on line 17
This should be displayed first.
Buffered data:
--
Edit this bug report at http://bugs.php.net/?id=30578edit=1
#32852 [Fbk-Opn]: Crash with singleton and __destruct
ID: 32852 User updated by: cox at idecnet dot com Reported By: cox at idecnet dot com -Status: Feedback +Status: Open Bug Type: Reproducible crash Operating System: Linux PHP Version: 5.0.4 New Comment: With today's CVS (5.1), it does not crash. But the output is: Output: i'm called i'm called i'm called i'm called The __destruct() function is called 4 times. With php5-STABLE-200504271035 (5.0.5dev): $ make distclean $ ./configure \ --prefix=/usr \ --with-config-file-path=/etc/php5 \ --enable-cli \ --disable-cgi \ --disable-pear \ --enable-debug Still the same output and same crash. Previous Comments: [2005-04-28 00:25:57] [EMAIL PROTECTED] If you configure with --enable-debug (rm config.cache ./configure + your options + --enable-debug make clean make) does it still crash? Are you sure you ARE using the latest CVS? (the snapshots might not be updated again..) [2005-04-27 23:25:44] [EMAIL PROTECTED] Still works fine here. Both with HEAD and 5.0.x. [2005-04-27 16:52:39] cox at idecnet dot com Versions and compile options for the two that crashes for me. In case it says something for you, if I remove the __destructor() function the code works good (also you see in the output this function is being called twice). 5.0.4 ~~~ PHP 5.0.4 (cli) (built: Apr 27 2005 11:48:13) Configure Command = './configure' '--prefix=/usr' '--with-config-file-path=/etc/php5' '--with-xml' '--with-zlib' '--with-gd' '--enable-gd-native-ttf' '--with-freetype-dir' '--with-png-dir' '--with-jpeg-dir' '--disable-pear' '--with-mysql=/usr' '--with-imap=/usr/include/imap' '--with-imap-ssl' '--with-kerberos' '--with-gettext' '--enable-ftp' '--with-dom' '--with-mhash' '--with-mcrypt' '--enable-cli' '--enable-sockets' '--enable-sigchild' '--enable-pcntl' '--enable-shmop' '--enable-posix' '--enable-bcmath' '--with-xmlrpc' '--with-mime-magic' '--disable-cgi' 5.0.5 Snapshot Stable ~~~ PHP 5.0.5-dev (cli) (built: Apr 27 2005 13:47:32) (DEBUG) Configure Command = './configure' '--prefix=/usr' '--with-config-file-path=/etc/php5' '--with-xml' '--with-zlib' '--with-gd' '--enable-gd-native-ttf' '--with-freetype-dir' '--with-png-dir' '--with-jpeg-dir' '--disable-pear' '--with-mysql=/usr' '--with-imap=/usr/include/imap' '--with-imap-ssl' '--with-kerberos' '--with-gettext' '--enable-ftp' '--with-dom' '--with-mhash' '--with-mcrypt' '--enable-cli' '--enable-sockets' '--enable-sigchild' '--enable-pcntl' '--enable-shmop' '--enable-posix' '--enable-bcmath' '--with-xmlrpc' '--with-mime-magic' '--disable-cgi' '--enable-debug' [2005-04-27 14:41:26] [EMAIL PROTECTED] For some reason it doesn't crash for me..did you use --enable-debug ? [2005-04-27 14:10:28] cox at idecnet dot com I'm not very expert on gdb usage. Please tell me if you need extra info. $ gdb /usr/bin/php5.0.5dev core.31085 GNU gdb 6.0-2mdk (Mandrake Linux) Copyright 2003 Free Software Foundation, Inc. GDB is free software, covered by the GNU General Public License, and you are welcome to change it and/or distribute copies of it under certain conditions. Type show copying to see the conditions. There is absolutely no warranty for GDB. Type show warranty for details. This GDB was configured as i586-mandrake-linux-gnu...Using host libthread_db library /lib/tls/libthread_db.so.1. Core was generated by `/usr/bin/php5.0.5dev test.php'. Program terminated with signal 11, Segmentation fault. warning: current_sos: Can't read pathname for load map: Input/output error Reading symbols from /lib/libcrypt.so.1...done. Loaded symbols for /lib/libcrypt.so.1 Reading symbols from /usr/lib/libexpat.so.0...done. Loaded symbols for /usr/lib/libexpat.so.0 Reading symbols from /usr/lib/libmysqlclient.so.12...done. Loaded symbols for /usr/lib/libmysqlclient.so.12 Reading symbols from /lib/libz.so.1...done. Loaded symbols for /lib/libz.so.1 Reading symbols from /lib/tls/libm.so.6...done. Loaded symbols for /lib/tls/libm.so.6 Reading symbols from /usr/lib/libmhash.so.2...done. Loaded symbols for /usr/lib/libmhash.so.2 Reading symbols from /usr/lib/libmcrypt.so.4...done. Loaded symbols for /usr/lib/libmcrypt.so.4 Reading symbols from /lib/libdl.so.2...done. Loaded symbols for /lib/libdl.so.2 Reading symbols from /usr/lib/libltdl.so.3...done. Loaded symbols for /usr/lib/libltdl.so.3 Reading symbols from /lib/libpam.so.0...done. Loaded symbols for /lib/libpam.so.0 Reading symbols from /usr/lib/libfreetype.so.6...done. Loaded symbols for /usr/lib/libfreetype.so.6 Reading symbols from
#32841 [Asn-WFx]: returned a member variable cannot be turned into reference
ID: 32841
Updated by: [EMAIL PROTECTED]
Reported By: wagner at bonn dot edu
-Status: Assigned
+Status: Wont fix
Bug Type: Scripting Engine problem
Operating System: *
PHP Version: 4.3.11, 5.0.4
Assigned To: andi
New Comment:
What you are trying to do is feasable in different ways. - just not
the way you are trying.. (try the support channels for suggestions.)
- whether what you are trying to do is a good idea (maintance, code
readability, creating bugs) is another question...
changing the engine behavior to do what you say is extremely complex.
And the return on fixing this would not be worth the instability that
it would involve (we know from previous efforts at looking at this).
hint: use
return $this-var;
$tmp = $foo-f_default();
incr($tmp);
Previous Comments:
[2005-04-28 06:34:50] wagner at bonn dot edu
In your case f_default() returns *copy*, not a reference
No it doesn't.
Try this as case 1 in the reproduce code as above:
--
case 1:
//forced reference works AND makes default behaviour
//work afterwards
echo incr($foo-f_ref()).\n;
echo incr($foo-f_default()).\n;
echo incr($foo-f_default()).\n;
break;
Expected result:
1
2
2
f_default() should return a copy
Actual result:
--
1
2
3
incr() gets a reference to $foo-v and modifies it
Since I filed this behaviour as another bug here
http://bugs.php.net/bug.php?id=32840
could it please be looked at too and be unbogusified?
[2005-04-27 23:45:04] [EMAIL PROTECTED]
Short version:
this is expected and the error message clearly says why:
only variables can be referenced and you cannot make a reference to an
expression result.
Long version:
In your case f_default() returns *copy*, not a reference as you wrongly
consider, while f_ref() returns reference and should work indeed.
But I'm a bit surprised to see that f_copy() works, as it should give
the same warning as with f_default().
Concerning the case 2, AFAIK it's because of some reference magic: when
you return $this-v as reference, it turns in refernce itself
(refcount++) and the following call to f_default() returns this
reference.
Though, it would be interesting to see what engine gurus say about it.
[2005-04-26 14:54:41] wagner at bonn dot edu
Description:
When returning a member-variable directly as a reference
parameter into a function, a fatal error occurs:
Fatal error: Only variables can be passed by reference ...
The reproduce code displays the bug (for $case=0) as well
as two simple workarounds that IMHO show that the
ZEND-Engine should be able to handle this with no need for
any error.
This seems to have been around for a while, at least PHP
4.3.x
Probably related to
http://bugs.php.net/bug.php?id=32840
Reproduce code:
---
$case = 0;
function incr($int) {
return $int++;
}
class foo {
var $v = 1;
function f_ref() { return $this-v; }
function f_copy() { return (int)$this-v; } //forced copy through
type-cast
function f_default() { return $this-v; }
}
$foo = new foo();
switch($case) {
case 0:
//default behaviour is broken
echo incr($foo-f_default()).\n;
case 1:
//forced reference works AND makes default behaviour work
afterwards
echo incr($foo-f_ref()).\n;
echo incr($foo-f_default()).\n;
break;
case 2:
//forced copy works
echo incr($foo-f_copy()).\n;
break;
}
Expected result:
incr() should get a copy of $foo-v
Actual result:
--
Fatal error: Only variables can be passed by reference in
foo.php on line 19
--
Edit this bug report at http://bugs.php.net/?id=32841edit=1
#32865 [Opn-Bgs]: explode do not works with $limit = null
ID: 32865
Updated by: [EMAIL PROTECTED]
Reported By: dan at yes dot lt
-Status: Open
+Status: Bogus
-Bug Type: *General Issues
+Bug Type: Strings related
Operating System: WinXP
PHP Version: 5.0.4
New Comment:
Yes, null == 0. (PHP is still loose typed language..)
Previous Comments:
[2005-04-28 11:19:04] dan at yes dot lt
Description:
explode() do not explodes string if $limit argument is null, but
explodes if no $limit argument given.
Reproduce code:
---
print_r(explode(',', 'a,b,c'));
print_r(explode(',', 'a,b,c', null));
Expected result:
Array
(
[0] = a
[1] = b
[2] = c
)
Array
(
[0] = a
[1] = b
[2] = c
)
Actual result:
--
Array
(
[0] = a
[1] = b
[2] = c
)
Array
(
[0] = a,b,c
)
--
Edit this bug report at http://bugs.php.net/?id=32865edit=1
#32865 [NEW]: explode do not works with $limit = null
From: dan at yes dot lt
Operating system: WinXP
PHP version: 5.0.4
PHP Bug Type: *General Issues
Bug description: explode do not works with $limit = null
Description:
explode() do not explodes string if $limit argument is null, but explodes
if no $limit argument given.
Reproduce code:
---
print_r(explode(',', 'a,b,c'));
print_r(explode(',', 'a,b,c', null));
Expected result:
Array
(
[0] = a
[1] = b
[2] = c
)
Array
(
[0] = a
[1] = b
[2] = c
)
Actual result:
--
Array
(
[0] = a
[1] = b
[2] = c
)
Array
(
[0] = a,b,c
)
--
Edit bug report at http://bugs.php.net/?id=32865edit=1
--
Try a CVS snapshot (php4): http://bugs.php.net/fix.php?id=32865r=trysnapshot4
Try a CVS snapshot (php5.0):
http://bugs.php.net/fix.php?id=32865r=trysnapshot50
Try a CVS snapshot (php5.1):
http://bugs.php.net/fix.php?id=32865r=trysnapshot51
Fixed in CVS:http://bugs.php.net/fix.php?id=32865r=fixedcvs
Fixed in release:http://bugs.php.net/fix.php?id=32865r=alreadyfixed
Need backtrace: http://bugs.php.net/fix.php?id=32865r=needtrace
Need Reproduce Script: http://bugs.php.net/fix.php?id=32865r=needscript
Try newer version: http://bugs.php.net/fix.php?id=32865r=oldversion
Not developer issue: http://bugs.php.net/fix.php?id=32865r=support
Expected behavior: http://bugs.php.net/fix.php?id=32865r=notwrong
Not enough info:
http://bugs.php.net/fix.php?id=32865r=notenoughinfo
Submitted twice:
http://bugs.php.net/fix.php?id=32865r=submittedtwice
register_globals:http://bugs.php.net/fix.php?id=32865r=globals
PHP 3 support discontinued: http://bugs.php.net/fix.php?id=32865r=php3
Daylight Savings:http://bugs.php.net/fix.php?id=32865r=dst
IIS Stability: http://bugs.php.net/fix.php?id=32865r=isapi
Install GNU Sed: http://bugs.php.net/fix.php?id=32865r=gnused
Floating point limitations: http://bugs.php.net/fix.php?id=32865r=float
No Zend Extensions: http://bugs.php.net/fix.php?id=32865r=nozend
MySQL Configuration Error: http://bugs.php.net/fix.php?id=32865r=mysqlcfg
#32789 [Bgs]: array_pop doesn't work correctly
ID: 32789
User updated by: php at thoftware dot de
Reported By: php at thoftware dot de
Status: Bogus
Bug Type: Arrays related
Operating System: *
PHP Version: 4.3.11
New Comment:
I don't know, who is deleting my submissions, but I think it would be
better to delete the whole thread instead of deleting only some
submissions which makes the references in other submissions nonsense. I
accept that you don't accept this as a bug and I wont post any new found
bugs as it seems to be easyer to handle with bugs than to get a bug
reported. Nice job.
Previous Comments:
[2005-04-26 14:08:02] php at thoftware dot de
Looks like nobody is listening here - sigh. After discussing this in
another forum, we are still sure this _is_ a bug. As I was ordered not
to set this bug back to open we are trying to start over with a new
bug-report in a new location (it's not really a bug in array_pop() but
something in the reference system). Someone with a hopefully better
ability to explain where the bug is located will post it and I will add
a link to it afterwards - hope that's o.k.
[2005-04-25 22:18:30] php at thoftware dot de
Maybe this one from Waq explains it in a better way why I think it's a
bug: http://www.php.de/viewtopic.php?p=252840#252840 (it's from a
german forum where the people tried to understand what I tried to
say).
I didn't ask for help, the script that crashed because of this bogus
bug was already fixed when I submitted this. Sorry for taking your
time, surely PHP acts perfect in this case :-(
P.S. Why are you deleting your comments? Do you think it makes it even
more bogus when it looks like I'm talking to myself? Not nice :-(
[2005-04-23 09:05:35] [EMAIL PROTECTED]
Sorry, but your problem does not imply a bug in PHP itself. For a
list of more appropriate places to ask for help using PHP, please
visit http://www.php.net/support.php as this bug system is not the
appropriate forum for asking support questions. 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.
bugs is not a helpdesk - please leave this as bogus and ask on
php-general.
[2005-04-22 15:56:37] php at thoftware dot de
Sorry again, maybe I should stop coding %-(, this is the real
Actual result:
--
it's forever mine
noone else should be able to change it
it's mine
this is my cache
for the example directly above ...
[2005-04-22 15:54:09] php at thoftware dot de
Sorry, the fatal error results from the result of cache() being an
empty array (but that may be another bug?), correct code should be:
Reproduce code:
---
class foobar {
var $cache = array();
function cache() {
if (!count($this-cache)) {
$this-cache[1] = array(
'this is my cachebr',
'it\'s minebr',
'noone else should be able to change itbr',
'it\'s forever minebr',
);
}
return($this-cache[1]);
}
}
$foobar = new foobar();
echo array_pop($foobar-cache());
echo array_pop($foobar-cache());
echo array_pop($foobar-cache());
echo array_pop($foobar-cache());
Expected result:
it's forever mine
it's forever mine
it's forever mine
it's forever mine
Actual result:
--
Fatal error: Only variables can be passed by reference in ...
Using a static variable within the method will work like the example
using a plain function, using an object-variable will work like shown
above, even if you remove the '[1]'-part.
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/32789
--
Edit this bug report at http://bugs.php.net/?id=32789edit=1
#32860 [Opn]: quoted-string cookies not handled correctly
ID: 32860
User updated by: ast at gmx dot ch
Reported By: ast at gmx dot ch
Status: Open
Bug Type: Feature/Change Request
Operating System: *
PHP Version: 4.3.11
New Comment:
But even the initial cookie RFC, http://rfc.net/rfc2109.html, described
that a value may be either a TOKEN or a quoted-string. The only
difference to the new cookie RFC, RFC 2965, is that are not allowed
in quoted-string values of the old version while they may be in
quoted-string values, just escaped by the escape character \ in the
new version.
Therefore, the separaters , and ; are allowed in quoted-string
values even in the old cookie RFC.
Maybe you could list it as a low-priority bug, but it's a bug and not a
feature or a change request.
Previous Comments:
[2005-04-28 08:16:09] [EMAIL PROTECTED]
When PHP was written, this RFC did not yet exist - that's why we
classify it as a feature request - it's basically cookie version 1.1.
[2005-04-28 00:04:15] ast at gmx dot ch
Feature/Change request?
I don't agree. Handling a HTTP header not according to the RFCs they
are defined in doesn't make sense at all. Therefore, it's a bug.
But it's not that important to me. Do what you consider the right
thing.
[2005-04-28 00:00:18] [EMAIL PROTECTED]
Reclassified.
[2005-04-27 23:20:34] ast at gmx dot ch
Obviously, the bug report was mangled.
Here's a pretty print of the report / fix:
http://nei.ch/articles/quoted_string_cookie_fix.php
[2005-04-27 21:46:18] ast at gmx dot ch
Description:
/*
* Description:
*RFC 2965 describes the HTTP State Management mechanism.
*From section 3.1 Syntax: General:
* av-pairs= av-pair *(; av-pair)
* av-pair = attr [= value] ; optional
value
* attr= token
* value = token | quoted-string
*
*PHP 4.3.11 does not handle the case of quoted-string values.
*See RFC 2616 section 2.2 Basic Rules for a definition of
quoted-string.
*quoted-string = ( *(qdtext | quoted-pair ) )
*qdtext = any TEXT except
*
* The backslash character (\) MAY be used as a
single-character
* quoting mechanism only within quoted-string and comment
constructs.
*
*quoted-pair= \ CHAR
*
*PHP 4.3.11 urlencodes all cookie name = value pairs. Therefore,
it can handle
*values that contain the separators , and ;. But the RFC 2965
describes that
*a HTTP Cookie header sent from the user agent to the server may
have av-pairs,
*where the value may be a token or a quoted string.
*
*If one sets a cookie not with PHP's setCookie() method, but
directly with header(),
*then it is sent correctly to the user agent and the user agent
returns it also
*correctly. But when PHP reads the HTTP Cookie header back into
$_COOKIE, it does
*not handle quoted-strings.
*
*Result:
* Wrong cookie values in $_COOKIE.
*
*The bug is in PHP's source in function
* SAPI_API SAPI_TREAT_DATA_FUNC(php_default_treat_data)
*It parses the HTTP Cookie header and directly uses , and ; as
separators.
*A slightly more complicated handling of the HTTP Cookie header is
required.
*In addition to the current code, one has to handle:
* - quoted-strings: separators , and ; may be in
quoted-strings
* - double-quote marks escaped by \ don't end a quoted-string
*
*Cookies with values that are not urlencoded may come from:
* - non-PHP applications on the same host
* - RFC 2965 compliant PHP cookies that were set with header()
instead of setcookie().
*
*Example:
* In PHP script:
*header('Set-Cookie: TestCookie = value with , perfectly ;
allowed 8-Bit characters ' .
*'and escaped \ double-quote marks!');
* The cookie is successfully sent to the user agent. The user
agent sends it back with a
* perfectly intact value.
* PHP receives the HTTP Cookie header from the webserver (I
inserted the line break):
*Cookie: TestCookie=value with , perfectly ; allowed 8-Bit
characters and escaped \
*double-quote marks!\r\n
* Then PHP parses the HTTP Cookie header ignoring the case of
quoted-strings and fills the
* superglobal $_COOKIE with:
* [TestCookie]=
*string(24) value with , perfectly
*
[allowed_8-BIT_characters_and_escaped_\_double-quote_marks!]=
*string(0)
* If PHP handled the HTTP Cookie header correctly, one would
get:
* [TestCookie]=
*
#32865 [Bgs]: explode do not works with $limit = null
ID: 32865
User updated by: dan at yes dot lt
Reported By: dan at yes dot lt
Status: Bogus
Bug Type: Strings related
Operating System: WinXP
PHP Version: 5.0.4
New Comment:
So what should I give to $limit to explode unlimited ???... As I know -
in PHP no parameter means some default value - what default value is
defined to default $limit ?..
Previous Comments:
[2005-04-28 11:43:01] [EMAIL PROTECTED]
Yes, null == 0. (PHP is still loose typed language..)
[2005-04-28 11:19:04] dan at yes dot lt
Description:
explode() do not explodes string if $limit argument is null, but
explodes if no $limit argument given.
Reproduce code:
---
print_r(explode(',', 'a,b,c'));
print_r(explode(',', 'a,b,c', null));
Expected result:
Array
(
[0] = a
[1] = b
[2] = c
)
Array
(
[0] = a
[1] = b
[2] = c
)
Actual result:
--
Array
(
[0] = a
[1] = b
[2] = c
)
Array
(
[0] = a,b,c
)
--
Edit this bug report at http://bugs.php.net/?id=32865edit=1
#32866 [NEW]: implicit (and redundant) mysql_close on mysql resource destruction
From: kevin at hatry dot com
Operating system: windows XP + linux
PHP version: 4.3.11
PHP Bug Type: MySQL related
Bug description: implicit (and redundant) mysql_close on mysql resource
destruction
Description:
I originally posted this info on follow up of bug id 30525 but it has been
reported as bogus and i dont think the problem has been fully understood.
Please *do* try to understand the problem here as there *is* one !
PHP version used :
- php 4.3.11 on win32 with the bundled 3.23.49 mysql client
- php 4.3.11 on linux kernel 2.4.29 with external 4.1.11 mysql client
both with apache 1.3.33 and with the cli binary.
Preface :
I *do* understand that by default MySQL connections are shared in PHP. I
also note that in older versions a single mysql_close() would close all of
the links but that there now appears to be reference counting before
finally closing the TCP connection which is a better thing for me.
The problem is :
It seems that affecting a value or 'unset'ing a variable of type mysql
resource or living the function in which the variable was created calls
mysql_close on that variable (and so reduces the reference) even if a
previous call was already made on that variable. So the reference count
becomes wrong.
So it is very hard to keep track of the real status (connected, not
connected, of type mysql, of type unknown) of a mysql resource.
The reproduce code is quite simple but is, i think, a typical way of
programming : you have a function (or class) that query mysql by creating
its own resource.
Normally, with this version of PHP, the call to mysql_close should not
close the shared connection so the code is ok to use. But with the bug a
second call to mysl_close is made when the function returns.
A last note : the same bug can be found if, instead of calling the
function do_something_in_mysql we do $link1 = -1; after the line
mysql_close($link1);.
Thank you for your time, i hope you will see the bug this time.
Reproduce code:
---
?php
$link1 = mysql_connect('localhost','root','',false);
$link2 = mysql_connect('localhost','root','',false);
echo link1 : ; var_dump($link1);
echo link2 : ; var_dump($link2);
do_something_in_mysql();
// here $link1 and $link2 are still usable to do
// queries which is ok for me
mysql_close($link1);
// here $link2 is no more usable to do queries
// which is *not* ok = the bug.
echo link1 : ; var_dump($link1);
echo link2 : ; var_dump($link2);
function do_something_in_mysql () {
$link3 = mysql_connect('localhost','root','',false);
echo link3 : ; var_dump($link3);
// do some common queries here
mysql_close($link3);
}
?
Expected result:
link1 : resource(4) of type (mysql link)
link2 : resource(4) of type (mysql link)
link3 : resource(4) of type (mysql link)
link1 : resource(4) of type (Unknown)
link2 : resource(4) of type (mysql link)
because $link2 has not been explicitly closed the reference count should
be of 1 instead of 0 (there was 3 calls to mysql_connect and only 2 calls
to mysql_close) and link2 should still be usable.
Actual result:
--
link1 : resource(4) of type (mysql link)
link2 : resource(4) of type (mysql link)
link3 : resource(4) of type (mysql link)
link1 : resource(4) of type (Unknown)
link2 : resource(4) of type (Unknown)
$link2 is no longer a mysql resource and the TCP connection to the mysql
server is lost although there was 3 calls to mysql_connect and only 2
explicit calls to mysql_close.
--
Edit bug report at http://bugs.php.net/?id=32866edit=1
--
Try a CVS snapshot (php4): http://bugs.php.net/fix.php?id=32866r=trysnapshot4
Try a CVS snapshot (php5.0):
http://bugs.php.net/fix.php?id=32866r=trysnapshot50
Try a CVS snapshot (php5.1):
http://bugs.php.net/fix.php?id=32866r=trysnapshot51
Fixed in CVS:http://bugs.php.net/fix.php?id=32866r=fixedcvs
Fixed in release:http://bugs.php.net/fix.php?id=32866r=alreadyfixed
Need backtrace: http://bugs.php.net/fix.php?id=32866r=needtrace
Need Reproduce Script: http://bugs.php.net/fix.php?id=32866r=needscript
Try newer version: http://bugs.php.net/fix.php?id=32866r=oldversion
Not developer issue: http://bugs.php.net/fix.php?id=32866r=support
Expected behavior: http://bugs.php.net/fix.php?id=32866r=notwrong
Not enough info:
http://bugs.php.net/fix.php?id=32866r=notenoughinfo
Submitted twice:
http://bugs.php.net/fix.php?id=32866r=submittedtwice
register_globals:http://bugs.php.net/fix.php?id=32866r=globals
PHP 3 support discontinued: http://bugs.php.net/fix.php?id=32866r=php3
Daylight Savings:http://bugs.php.net/fix.php?id=32866r=dst
IIS Stability: http://bugs.php.net/fix.php?id=32866r=isapi
Install GNU Sed: http://bugs.php.net/fix.php?id=32866r=gnused
Floating point limitations: http://bugs.php.net/fix.php?id=32866r=float
No Zend Extensions:
#32867 [NEW]: ini_set has no effect for magic_quotes_gpc
From: Arne dot Heizmann at csr dot com
Operating system: Windows 2000
PHP version: 4.3.11
PHP Bug Type: PHP options/info functions
Bug description: ini_set has no effect for magic_quotes_gpc
Description:
I have tried
ini_set ('magic_quotes_gpc', 0);
and
ini_set ('magic_quotes_gpc', 'Off');
and various others, but I still get those stupid backslashes.
Reproduce code:
---
ini_set ('magic_quotes_gpc', 0);
echo 'pre'. get_array_val ('x', $_POST) . '/pre';
echo form action='/test2.php' method='post'
input type='text' name='x' value='#39;' /
input type='submit' /
/form;
Expected result:
Upon submitting the form, you should see an apostrophe.
Actual result:
--
You see a backslash followed by an apostrophe.
--
Edit bug report at http://bugs.php.net/?id=32867edit=1
--
Try a CVS snapshot (php4): http://bugs.php.net/fix.php?id=32867r=trysnapshot4
Try a CVS snapshot (php5.0):
http://bugs.php.net/fix.php?id=32867r=trysnapshot50
Try a CVS snapshot (php5.1):
http://bugs.php.net/fix.php?id=32867r=trysnapshot51
Fixed in CVS:http://bugs.php.net/fix.php?id=32867r=fixedcvs
Fixed in release:http://bugs.php.net/fix.php?id=32867r=alreadyfixed
Need backtrace: http://bugs.php.net/fix.php?id=32867r=needtrace
Need Reproduce Script: http://bugs.php.net/fix.php?id=32867r=needscript
Try newer version: http://bugs.php.net/fix.php?id=32867r=oldversion
Not developer issue: http://bugs.php.net/fix.php?id=32867r=support
Expected behavior: http://bugs.php.net/fix.php?id=32867r=notwrong
Not enough info:
http://bugs.php.net/fix.php?id=32867r=notenoughinfo
Submitted twice:
http://bugs.php.net/fix.php?id=32867r=submittedtwice
register_globals:http://bugs.php.net/fix.php?id=32867r=globals
PHP 3 support discontinued: http://bugs.php.net/fix.php?id=32867r=php3
Daylight Savings:http://bugs.php.net/fix.php?id=32867r=dst
IIS Stability: http://bugs.php.net/fix.php?id=32867r=isapi
Install GNU Sed: http://bugs.php.net/fix.php?id=32867r=gnused
Floating point limitations: http://bugs.php.net/fix.php?id=32867r=float
No Zend Extensions: http://bugs.php.net/fix.php?id=32867r=nozend
MySQL Configuration Error: http://bugs.php.net/fix.php?id=32867r=mysqlcfg
#32866 [Opn-Bgs]: implicit (and redundant) mysql_close on mysql resource destruction
ID: 32866
Updated by: [EMAIL PROTECTED]
Reported By: kevin at hatry dot com
-Status: Open
+Status: Bogus
Bug Type: MySQL related
Operating System: windows XP + linux
PHP Version: 4.3.11
New Comment:
Change false to true in mysql_connect() and it will work like you want
it to work. Still not a bug.
Previous Comments:
[2005-04-28 12:26:33] kevin at hatry dot com
Description:
I originally posted this info on follow up of bug id 30525 but it has
been reported as bogus and i dont think the problem has been fully
understood.
Please *do* try to understand the problem here as there *is* one !
PHP version used :
- php 4.3.11 on win32 with the bundled 3.23.49 mysql client
- php 4.3.11 on linux kernel 2.4.29 with external 4.1.11 mysql client
both with apache 1.3.33 and with the cli binary.
Preface :
I *do* understand that by default MySQL connections are shared in PHP.
I also note that in older versions a single mysql_close() would close
all of the links but that there now appears to be reference counting
before finally closing the TCP connection which is a better thing for
me.
The problem is :
It seems that affecting a value or 'unset'ing a variable of type mysql
resource or living the function in which the variable was created calls
mysql_close on that variable (and so reduces the reference) even if a
previous call was already made on that variable. So the reference count
becomes wrong.
So it is very hard to keep track of the real status (connected, not
connected, of type mysql, of type unknown) of a mysql resource.
The reproduce code is quite simple but is, i think, a typical way of
programming : you have a function (or class) that query mysql by
creating its own resource.
Normally, with this version of PHP, the call to mysql_close should not
close the shared connection so the code is ok to use. But with the bug
a second call to mysl_close is made when the function returns.
A last note : the same bug can be found if, instead of calling the
function do_something_in_mysql we do $link1 = -1; after the line
mysql_close($link1);.
Thank you for your time, i hope you will see the bug this time.
Reproduce code:
---
?php
$link1 = mysql_connect('localhost','root','',false);
$link2 = mysql_connect('localhost','root','',false);
echo link1 : ; var_dump($link1);
echo link2 : ; var_dump($link2);
do_something_in_mysql();
// here $link1 and $link2 are still usable to do
// queries which is ok for me
mysql_close($link1);
// here $link2 is no more usable to do queries
// which is *not* ok = the bug.
echo link1 : ; var_dump($link1);
echo link2 : ; var_dump($link2);
function do_something_in_mysql () {
$link3 = mysql_connect('localhost','root','',false);
echo link3 : ; var_dump($link3);
// do some common queries here
mysql_close($link3);
}
?
Expected result:
link1 : resource(4) of type (mysql link)
link2 : resource(4) of type (mysql link)
link3 : resource(4) of type (mysql link)
link1 : resource(4) of type (Unknown)
link2 : resource(4) of type (mysql link)
because $link2 has not been explicitly closed the reference count
should be of 1 instead of 0 (there was 3 calls to mysql_connect and
only 2 calls to mysql_close) and link2 should still be usable.
Actual result:
--
link1 : resource(4) of type (mysql link)
link2 : resource(4) of type (mysql link)
link3 : resource(4) of type (mysql link)
link1 : resource(4) of type (Unknown)
link2 : resource(4) of type (Unknown)
$link2 is no longer a mysql resource and the TCP connection to the
mysql server is lost although there was 3 calls to mysql_connect and
only 2 explicit calls to mysql_close.
--
Edit this bug report at http://bugs.php.net/?id=32866edit=1
#32867 [Opn-Bgs]: ini_set has no effect for magic_quotes_gpc
ID: 32867
Updated by: [EMAIL PROTECTED]
Reported By: Arne dot Heizmann at csr dot com
-Status: Open
+Status: Bogus
Bug Type: PHP options/info functions
Operating System: Windows 2000
PHP Version: 4.3.11
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.
By the time that ini_set() call is run, the request data is already
processed.
Previous Comments:
[2005-04-28 12:46:05] Arne dot Heizmann at csr dot com
Description:
I have tried
ini_set ('magic_quotes_gpc', 0);
and
ini_set ('magic_quotes_gpc', 'Off');
and various others, but I still get those stupid backslashes.
Reproduce code:
---
ini_set ('magic_quotes_gpc', 0);
echo 'pre'. get_array_val ('x', $_POST) . '/pre';
echo form action='/test2.php' method='post'
input type='text' name='x' value='#39;' /
input type='submit' /
/form;
Expected result:
Upon submitting the form, you should see an apostrophe.
Actual result:
--
You see a backslash followed by an apostrophe.
--
Edit this bug report at http://bugs.php.net/?id=32867edit=1
#31222 [Opn-Fbk]: ocicommit not working
ID: 31222 Updated by: [EMAIL PROTECTED] Reported By: amonw at hotmail dot com -Status: Open +Status: Feedback Bug Type: OCI8 related Operating System: * PHP Version: 4CVS-2005-04-04 Assigned To: tony2001 New Comment: Please try using this CVS snapshot: http://snaps.php.net/php5-STABLE-latest.tar.gz For Windows: http://snaps.php.net/win32/php5.0-win32-latest.zip Previous Comments: [2005-04-26 04:20:18] amonw at hotmail dot com I don't know why, but I upgrate my php again this morning to php4-stable-200504260035, and the problem remains unchanged. I have make the code as simple as possible, and as I mentioned in the first comment, even some minor changes which seem not relevant may affect the result, and I don't know why. I deeply appreciate your patiense and please read my first post again. I can live with it if you are tired of this because it takes so long. Thank you. [2005-04-05 17:55:52] [EMAIL PROTECTED] Works just perfectly for all of oci8 users except you. Try to simplify the code and to look for the problem there. [2005-04-04 09:27:40] amonw at hotmail dot com I tried the http://snaps.php.net/php4-STABLE-latest.tar.gz,which extracted to be php4-STABLE-200504040230,but the code produced the same result. [2005-03-30 23:06:56] [EMAIL PROTECTED] Please try using this CVS snapshot: http://snaps.php.net/php4-STABLE-latest.tar.gz For Windows: http://snaps.php.net/win32/php4-win32-STABLE-latest.zip [2004-12-24 03:08:50] amonw at hotmail dot com Thank you for your help. But can you explain why the 4 methods I listed in the first comment can change the result? And why can't I add ocilogoff($c) before the second ocilogon to change the result? 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/31222 -- Edit this bug report at http://bugs.php.net/?id=31222edit=1
#28074 [Opn-Asn]: Fast CGI standard compliance : stderr should be written in a FCGI stderr stream
ID: 28074
Updated by: [EMAIL PROTECTED]
Reported By: bogus_idp at yahoo dot fr
-Status: Open
+Status: Assigned
Bug Type: CGI related
Operating System: *
PHP Version: 4CVS, 5CVS (2005-01-10)
-Assigned To:
+Assigned To: sas
New Comment:
Feel free to fix it then.
Previous Comments:
[2005-04-21 11:43:51] [EMAIL PROTECTED]
This is an ugly change for users who redirect PHP's stderr to a log
file due to file permissions (PHP is not allowed to open the log
file).
Instead of writing to the log file, the Apache log now contains tons of
rows like this:
[Thu Apr 21 11:18:27 2005] [error] [client 129.0.10.119] FastCGI:
server /home/www/PHP/php/bin/php stderr: array (
[Thu Apr 21 11:18:27 2005] [error] [client 129.0.10.119] FastCGI:
server /home/www/PHP/php/bin/php stderr: 'rcs' =
[Thu Apr 21 11:18:27 2005] [error] [client 129.0.10.119] FastCGI:
server /home/www/PHP/php/bin/php stderr: array (
etc.
This needs to be addressed -- make logging to fastcgi's stderr
optional.
[2005-01-10 16:01:29] chris at ex-parrot dot com
This one turns out to be easy to fix, thus:
--- cgi_main.c.orig Mon Jan 10 14:57:04 2005
+++ cgi_main.c Mon Jan 10 14:53:44 2005
@@ -481,7 +481,14 @@
static void sapi_cgi_log_message(char *message)
{
- fprintf(stderr, %s\n, message);
+#if PHP_FASTCGI
+if (!FCGX_IsCGI()) {
+FCGX_Request *request = (FCGX_Request *)SG(server_context);
+FCGX_FPrintF( request-err, %s\n, message );
+/* ignore return code */
+} else
+#endif /* PHP_FASTCGI */
+ fprintf(stderr, %s\n, message);
}
static int sapi_cgi_deactivate(TSRMLS_D)
However, there is another similar bug, which is that a stream opened on
php://stderr should also direct its output to the FCGI error stream
(rather than just to file descriptor #2).
-- Chris Lightfoot
[2004-04-20 12:03:30] bogus_idp at yahoo dot fr
Description:
The Fast CGI standard require that error be reported through the
FastCGI connection as a Stderr data stream.
But PHP Fast CGI processes still write errors to original stderr (file
handle 3) which prevent from clean standard centralized FCGI logging,
especially when the Fast CGI PHP process is not started by the web
server (remote Fast CGI).
In most cases, it makes debugging PHP scripts impossible.
--
Edit this bug report at http://bugs.php.net/?id=28074edit=1
#32865 [Bgs-Opn]: explode do not works with $limit = null
ID: 32865
User updated by: dan at yes dot lt
Reported By: dan at yes dot lt
-Status: Bogus
+Status: Open
Bug Type: Strings related
Operating System: WinXP
PHP Version: 5.0.4
New Comment:
now I have to write..
if ($lim === null) {
$parts = explode(',', $str);
} else {
$parts = explode(',', $str, $lim);
}
..instead of..
$parts = explode(',', $str, $lim);
Isn't it some sort of crap ?..
Previous Comments:
[2005-04-28 12:09:12] dan at yes dot lt
So what should I give to $limit to explode unlimited ???... As I know -
in PHP no parameter means some default value - what default value is
defined to default $limit ?..
[2005-04-28 11:43:01] [EMAIL PROTECTED]
Yes, null == 0. (PHP is still loose typed language..)
[2005-04-28 11:19:04] dan at yes dot lt
Description:
explode() do not explodes string if $limit argument is null, but
explodes if no $limit argument given.
Reproduce code:
---
print_r(explode(',', 'a,b,c'));
print_r(explode(',', 'a,b,c', null));
Expected result:
Array
(
[0] = a
[1] = b
[2] = c
)
Array
(
[0] = a
[1] = b
[2] = c
)
Actual result:
--
Array
(
[0] = a
[1] = b
[2] = c
)
Array
(
[0] = a,b,c
)
--
Edit this bug report at http://bugs.php.net/?id=32865edit=1
#32865 [Opn-Bgs]: explode do not works with $limit = null
ID: 32865
Updated by: [EMAIL PROTECTED]
Reported By: dan at yes dot lt
-Status: Open
+Status: Bogus
Bug Type: Strings related
Operating System: WinXP
PHP Version: 5.0.4
New Comment:
No, it's how the language works.
Previous Comments:
[2005-04-28 13:06:47] dan at yes dot lt
now I have to write..
if ($lim === null) {
$parts = explode(',', $str);
} else {
$parts = explode(',', $str, $lim);
}
..instead of..
$parts = explode(',', $str, $lim);
Isn't it some sort of crap ?..
[2005-04-28 12:09:12] dan at yes dot lt
So what should I give to $limit to explode unlimited ???... As I know -
in PHP no parameter means some default value - what default value is
defined to default $limit ?..
[2005-04-28 11:43:01] [EMAIL PROTECTED]
Yes, null == 0. (PHP is still loose typed language..)
[2005-04-28 11:19:04] dan at yes dot lt
Description:
explode() do not explodes string if $limit argument is null, but
explodes if no $limit argument given.
Reproduce code:
---
print_r(explode(',', 'a,b,c'));
print_r(explode(',', 'a,b,c', null));
Expected result:
Array
(
[0] = a
[1] = b
[2] = c
)
Array
(
[0] = a
[1] = b
[2] = c
)
Actual result:
--
Array
(
[0] = a
[1] = b
[2] = c
)
Array
(
[0] = a,b,c
)
--
Edit this bug report at http://bugs.php.net/?id=32865edit=1
#32866 [Bgs]: implicit (and redundant) mysql_close on mysql resource destruction
ID: 32866
User updated by: kevin at hatry dot com
Reported By: kevin at hatry dot com
Status: Bogus
Bug Type: MySQL related
Operating System: windows XP + linux
PHP Version: 4.3.11
New Comment:
thank you for your direct answer however this solution cannot work
with a heavily loaded website as it would open too much connections on
the mysql server :
for example a page called 50 times a second and opening 3 connections
at a the same time means 150 connections /sec to the mysql server
instead of 50 !
This situation is clearly one where the shared connection is useful.
i will try one last example to make sure you really know how i want it
to work, please read it through and answer the last question below,
thank you.
the following script (without any function to make it clearer) :
?php
$link1 = mysql_connect('localhost','root','',false);
$link2 = mysql_connect('localhost','root','',false);
echo link1 : ; var_dump($link1);
echo link2 : ; var_dump($link2);
echo 'mysql thread : '.mysql_thread_id($link2).\n;
mysql_close($link1);
echo -- after closing link1 :\n;
echo link1 : ; var_dump($link1);
echo link2 : ; var_dump($link2);
echo 'mysql thread : '.mysql_thread_id($link2).\n;
// this query works fine and that's ok with me
mysql_query('select * from user',$link2);
$link1 = NULL;
echo -- after link1 = NULL :\n;
echo link1 : ; var_dump($link1);
echo link2 : ; var_dump($link2);
echo 'mysql thread : '.mysql_thread_id($link2).\n;
// oops $link2 is no more usable to do queries,
// that's a bug for me !
mysql_query('select * from user',$link2); // line 28
?
generate this output :
link1 : resource(4) of type (mysql link)
link2 : resource(4) of type (mysql link)
mysql thread : 16
-- after closing link1 :
link1 : resource(4) of type (mysql link)
link2 : resource(4) of type (mysql link)
mysql thread : 16
-- after link1 = NULL :
link1 : NULL
link2 : resource(4) of type (Unknown)
Warning: mysql_thread_id(): 4 is not a valid MySQL-Link resource in ...
on line 24
mysql thread :
Warning: mysql_query(): 4 is not a valid MySQL-Link resource in ... on
line 28
If you could please answer this one last question :
why does affecting NULL to $link1 make $link2 to become Unkown ?
In other words, why don't we see this output instead :
link1 : resource(4) of type (mysql link)
link2 : resource(4) of type (mysql link)
mysql thread : 16
-- after closing link1 :
link1 : resource(4) of type (Unknown)
link2 : resource(4) of type (mysql link)
mysql thread : 16
-- after link1 = NULL :
link1 : NULL
link2 : resource(4) of type (mysql link)
mysql thread : 16
If this is a feature than it should be documented as it is not obvious
that changing the value of the resource variable will close the
connection, even if it has been closed before.
--
Edit this bug report at http://bugs.php.net/?id=32866edit=1
#32852 [Opn-Fbk]: Crash with singleton and __destruct
ID: 32852 Updated by: [EMAIL PROTECTED] Reported By: cox at idecnet dot com -Status: Open +Status: Feedback Bug Type: Reproducible crash Operating System: Linux PHP Version: 5.0.4 New Comment: I still can't reproduce this. I get same result with both HEAD and PHP_5_0 branches and also with the snapshot. Does it give same result if you make sure you don't load any php.ini: sapi/cli/php -n file.php What bison version do you have installed? What compiler (and version) ? Previous Comments: [2005-04-28 10:53:13] cox at idecnet dot com With today's CVS (5.1), it does not crash. But the output is: Output: i'm called i'm called i'm called i'm called The __destruct() function is called 4 times. With php5-STABLE-200504271035 (5.0.5dev): $ make distclean $ ./configure \ --prefix=/usr \ --with-config-file-path=/etc/php5 \ --enable-cli \ --disable-cgi \ --disable-pear \ --enable-debug Still the same output and same crash. [2005-04-28 00:25:57] [EMAIL PROTECTED] If you configure with --enable-debug (rm config.cache ./configure + your options + --enable-debug make clean make) does it still crash? Are you sure you ARE using the latest CVS? (the snapshots might not be updated again..) [2005-04-27 23:25:44] [EMAIL PROTECTED] Still works fine here. Both with HEAD and 5.0.x. [2005-04-27 16:52:39] cox at idecnet dot com Versions and compile options for the two that crashes for me. In case it says something for you, if I remove the __destructor() function the code works good (also you see in the output this function is being called twice). 5.0.4 ~~~ PHP 5.0.4 (cli) (built: Apr 27 2005 11:48:13) Configure Command = './configure' '--prefix=/usr' '--with-config-file-path=/etc/php5' '--with-xml' '--with-zlib' '--with-gd' '--enable-gd-native-ttf' '--with-freetype-dir' '--with-png-dir' '--with-jpeg-dir' '--disable-pear' '--with-mysql=/usr' '--with-imap=/usr/include/imap' '--with-imap-ssl' '--with-kerberos' '--with-gettext' '--enable-ftp' '--with-dom' '--with-mhash' '--with-mcrypt' '--enable-cli' '--enable-sockets' '--enable-sigchild' '--enable-pcntl' '--enable-shmop' '--enable-posix' '--enable-bcmath' '--with-xmlrpc' '--with-mime-magic' '--disable-cgi' 5.0.5 Snapshot Stable ~~~ PHP 5.0.5-dev (cli) (built: Apr 27 2005 13:47:32) (DEBUG) Configure Command = './configure' '--prefix=/usr' '--with-config-file-path=/etc/php5' '--with-xml' '--with-zlib' '--with-gd' '--enable-gd-native-ttf' '--with-freetype-dir' '--with-png-dir' '--with-jpeg-dir' '--disable-pear' '--with-mysql=/usr' '--with-imap=/usr/include/imap' '--with-imap-ssl' '--with-kerberos' '--with-gettext' '--enable-ftp' '--with-dom' '--with-mhash' '--with-mcrypt' '--enable-cli' '--enable-sockets' '--enable-sigchild' '--enable-pcntl' '--enable-shmop' '--enable-posix' '--enable-bcmath' '--with-xmlrpc' '--with-mime-magic' '--disable-cgi' '--enable-debug' [2005-04-27 14:41:26] [EMAIL PROTECTED] For some reason it doesn't crash for me..did you use --enable-debug ? 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/32852 -- Edit this bug report at http://bugs.php.net/?id=32852edit=1
#32866 [Bgs]: implicit (and redundant) mysql_close on mysql resource destruction
ID: 32866
Updated by: [EMAIL PROTECTED]
Reported By: kevin at hatry dot com
Status: Bogus
Bug Type: MySQL related
Operating System: windows XP + linux
PHP Version: 4.3.11
New Comment:
Please don't abuse the bug system for questions and discussions. Use
PHP's mailinglists (http://www.php.net/mailing-lists.php)
Previous Comments:
[2005-04-28 13:48:26] kevin at hatry dot com
thank you for your direct answer however this solution cannot work
with a heavily loaded website as it would open too much connections on
the mysql server :
for example a page called 50 times a second and opening 3 connections
at a the same time means 150 connections /sec to the mysql server
instead of 50 !
This situation is clearly one where the shared connection is useful.
i will try one last example to make sure you really know how i want it
to work, please read it through and answer the last question below,
thank you.
the following script (without any function to make it clearer) :
?php
$link1 = mysql_connect('localhost','root','',false);
$link2 = mysql_connect('localhost','root','',false);
echo link1 : ; var_dump($link1);
echo link2 : ; var_dump($link2);
echo 'mysql thread : '.mysql_thread_id($link2).\n;
mysql_close($link1);
echo -- after closing link1 :\n;
echo link1 : ; var_dump($link1);
echo link2 : ; var_dump($link2);
echo 'mysql thread : '.mysql_thread_id($link2).\n;
// this query works fine and that's ok with me
mysql_query('select * from user',$link2);
$link1 = NULL;
echo -- after link1 = NULL :\n;
echo link1 : ; var_dump($link1);
echo link2 : ; var_dump($link2);
echo 'mysql thread : '.mysql_thread_id($link2).\n;
// oops $link2 is no more usable to do queries,
// that's a bug for me !
mysql_query('select * from user',$link2); // line 28
?
generate this output :
link1 : resource(4) of type (mysql link)
link2 : resource(4) of type (mysql link)
mysql thread : 16
-- after closing link1 :
link1 : resource(4) of type (mysql link)
link2 : resource(4) of type (mysql link)
mysql thread : 16
-- after link1 = NULL :
link1 : NULL
link2 : resource(4) of type (Unknown)
Warning: mysql_thread_id(): 4 is not a valid MySQL-Link resource in ...
on line 24
mysql thread :
Warning: mysql_query(): 4 is not a valid MySQL-Link resource in ... on
line 28
If you could please answer this one last question :
why does affecting NULL to $link1 make $link2 to become Unkown ?
In other words, why don't we see this output instead :
link1 : resource(4) of type (mysql link)
link2 : resource(4) of type (mysql link)
mysql thread : 16
-- after closing link1 :
link1 : resource(4) of type (Unknown)
link2 : resource(4) of type (mysql link)
mysql thread : 16
-- after link1 = NULL :
link1 : NULL
link2 : resource(4) of type (mysql link)
mysql thread : 16
If this is a feature than it should be documented as it is not obvious
that changing the value of the resource variable will close the
connection, even if it has been closed before.
[2005-04-28 12:49:42] [EMAIL PROTECTED]
Change false to true in mysql_connect() and it will work like you want
it to work. Still not a bug.
[2005-04-28 12:26:33] kevin at hatry dot com
Description:
I originally posted this info on follow up of bug id 30525 but it has
been reported as bogus and i dont think the problem has been fully
understood.
Please *do* try to understand the problem here as there *is* one !
PHP version used :
- php 4.3.11 on win32 with the bundled 3.23.49 mysql client
- php 4.3.11 on linux kernel 2.4.29 with external 4.1.11 mysql client
both with apache 1.3.33 and with the cli binary.
Preface :
I *do* understand that by default MySQL connections are shared in PHP.
I also note that in older versions a single mysql_close() would close
all of the links but that there now appears to be reference counting
before finally closing the TCP connection which is a better thing for
me.
The problem is :
It seems that affecting a value or 'unset'ing a variable of type mysql
resource or living the function in which the variable was created calls
mysql_close on that variable (and so reduces the reference) even if a
previous call was already made on that variable. So the reference count
becomes wrong.
So it is very hard to keep track of the real status (connected, not
connected, of type mysql, of type unknown) of a mysql resource.
The reproduce code is quite simple but is, i think, a typical way of
programming : you have a function (or class) that query mysql by
creating its own resource.
Normally, with this version of PHP, the call to mysql_close should not
close the shared connection so the code is ok to use. But with the bug
a second call to mysl_close is made when the function returns.
A last note : the same bug
#32245 [Ver-Csd]: xml_parser_free() in a function assigned to the xml parser gives a segfault
ID: 32245
Updated by: [EMAIL PROTECTED]
Reported By: MageOfChrisz at Gmail dot com
-Status: Verified
+Status: Closed
Bug Type: XML related
Operating System: Linux 2.6.10
PHP Version: 5CVS-2005-03-09
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:
[2005-03-09 11:40:29] [EMAIL PROTECTED]
Starting program: /usr/src/dev/php-src/sapi/cli/php
/www/function_example.php
[Thread debugging using libthread_db enabled]
[New Thread 1080248256 (LWP 30048)]
foo bar=example /
Program received signal SIGSEGV, Segmentation fault.
[Switching to Thread 1080248256 (LWP 30048)]
0x08225b82 in _xml_endElementHandler (userData=0x85813ac,
name=0x856fd68 foo) at /usr/src/dev/php-src/ext/xml/xml.c:768
768
add_assoc_string(*(parser-ctag),type,complete,1);
(gdb) bt
#0 0x08225b82 in _xml_endElementHandler (userData=0x85813ac,
name=0x856fd68 foo) at /usr/src/dev/php-src/ext/xml/xml.c:768
#1 0x08228569 in _end_element_handler (user=0x8582164, name=0x857cf5f
foo) at /usr/src/dev/php-src/ext/xml/compat.c:143
#2 0x40551d57 in xmlParseTryOrFinish (ctxt=0x857fe68, terminate=0) at
parser.c:9261
#3 0x4055288f in xmlParseChunk__internal_alias (ctxt=0x857fe68,
chunk=0x857ce4c ?xml version=\1.0\ encoding=\iso-8859-1\?
\nphp \n example \nfoo bar=\example\ / \n /example
\n/php , size=139963800,
terminate=0) at parser.c:9872
#4 0x08228ccc in php_XML_Parse (parser=0x8582164,
data=0x857ce4c ?xml version=\1.0\ encoding=\iso-8859-1\?
\nphp \n example \nfoo bar=\example\ / \n /example
\n/php , data_len=113, is_final=0)
at /usr/src/dev/php-src/ext/xml/compat.c:512
#5 0x08227114 in zif_xml_parse (ht=2, return_value=0x857cef4,
this_ptr=0x0, return_value_used=0) at
/usr/src/dev/php-src/ext/xml/xml.c:1333
#6 0x08293dec in zend_do_fcall_common_helper_SPEC
(execute_data=0xbfffcbb0) at zend_vm_execute.h:175
#7 0x08296890 in ZEND_DO_FCALL_SPEC_CONST_HANDLER
(execute_data=0xbfffcbb0) at zend_vm_execute.h:1535
#8 0x08293b06 in execute (op_array=0x857ac9c) at zend_vm_execute.h:78
#9 0x0826f69f in zend_execute_scripts (type=8, retval=0x0,
file_count=3) at /usr/src/dev/php-src/Zend/zend.c:1058
#10 0x0822d0c9 in php_execute_script (primary_file=0xbfffefe0) at
/usr/src/dev/php-src/main/main.c:1642
#11 0x082e2db9 in main (argc=2, argv=0xb0b4) at
/usr/src/dev/php-src/sapi/cli/php_cli.c:944
(gdb) p *parser
$1 = {index = 1515870810, case_folding = 1515870810, parser =
0x5a5a5a5a, target_encoding = 0x5a5a5a5a Address 0x5a5a5a5a out of
bounds, startElementHandler = 0x5a5a5a5a,
endElementHandler = 0x5a5a5a5a, characterDataHandler = 0x5a5a5a5a,
processingInstructionHandler = 0x5a5a5a5a, defaultHandler =
0x5a5a5a5a,
unparsedEntityDeclHandler = 0x5a5a5a5a, notationDeclHandler =
0x5a5a5a5a, externalEntityRefHandler = 0x5a5a5a5a,
unknownEncodingHandler = 0x5a5a5a5a,
startNamespaceDeclHandler = 0x5a5a5a5a, endNamespaceDeclHandler =
0x5a5a5a5a, startElementPtr = 0x5a5a5a5a, endElementPtr = 0x5a5a5a5a,
characterDataPtr = 0x5a5a5a5a,
processingInstructionPtr = 0x5a5a5a5a, defaultPtr = 0x5a5a5a5a,
unparsedEntityDeclPtr = 0x5a5a5a5a, notationDeclPtr = 0x5a5a5a5a,
externalEntityRefPtr = 0x5a5a5a5a,
unknownEncodingPtr = 0x5a5a5a5a, startNamespaceDeclPtr = 0x5a5a5a5a,
endNamespaceDeclPtr = 0x5a5a5a5a, object = 0x5a5a5a5a, data =
0x5a5a5a5a, info = 0x5a5a5a5a,
level = 1515870810, toffset = 1515870810, curtag = 1515870810, ctag =
0x5a5a5a5a, ltags = 0x5a5a5a5a, lastwasopen = 1515870810, skipwhite =
1515870810,
baseURI = 0x5a5a5a5a Address 0x5a5a5a5a out of bounds}
[2005-03-09 08:07:06] MageOfChrisz at Gmail dot com
Description:
(Most of what I say here can be found at
http://chrisallan.info/segfault/)
When putting xml_parser_free in a function assigned to the XML parser
with xml_set_element_handler, Apache/PHP Gives a Segmentation Fault.
The only browser that you can feasibly see it blow up, would be in
lynx. In FireFox, if you're at www.google.com and type in the link to
the file (http://chrisallan.info/segfault/function_example.php) it will
still show google.com and fail to load the new page. A similar result
occurs with Internet Explorer, but in Lynx it'll say:
Alert!: Unexpected Network read error; connection aborted;
I made a PHP5.0.4-dev build (as of Mar 09, 2005 05:30 GMT) from
snaps.php.net.
This was originally discovered in PHP 5.0.3, and then tested in
PHP5.0.4-dev
Reproduce code:
---
You can find the code (neatly) here:
http://chrisallan.info/segfault/
Expected result:
Some sort of error telling me
#32860 [Opn]: quoted-string cookies not handled correctly
ID: 32860 Updated by: [EMAIL PROTECTED] Reported By: ast at gmx dot ch Status: Open Bug Type: Feature/Change Request Operating System: * PHP Version: 4.3.11 New Comment: You are wrong. It is not a bug. PHP implements Cookie version 0 which is based upon the Netscape Cookie standard. Both RFCs 2109/2965 speak of Cookie version 1. Previous Comments: [2005-04-28 12:03:44] ast at gmx dot ch But even the initial cookie RFC, http://rfc.net/rfc2109.html, described that a value may be either a TOKEN or a quoted-string. The only difference to the new cookie RFC, RFC 2965, is that are not allowed in quoted-string values of the old version while they may be in quoted-string values, just escaped by the escape character \ in the new version. Therefore, the separaters , and ; are allowed in quoted-string values even in the old cookie RFC. Maybe you could list it as a low-priority bug, but it's a bug and not a feature or a change request. [2005-04-28 08:16:09] [EMAIL PROTECTED] When PHP was written, this RFC did not yet exist - that's why we classify it as a feature request - it's basically cookie version 1.1. [2005-04-28 00:04:15] ast at gmx dot ch Feature/Change request? I don't agree. Handling a HTTP header not according to the RFCs they are defined in doesn't make sense at all. Therefore, it's a bug. But it's not that important to me. Do what you consider the right thing. [2005-04-28 00:00:18] [EMAIL PROTECTED] Reclassified. [2005-04-27 23:20:34] ast at gmx dot ch Obviously, the bug report was mangled. Here's a pretty print of the report / fix: http://nei.ch/articles/quoted_string_cookie_fix.php The remainder of the comments for this report are too long. To view the rest of the comments, please view the bug report online at http://bugs.php.net/32860 -- Edit this bug report at http://bugs.php.net/?id=32860edit=1
#32866 [Bgs]: implicit (and redundant) mysql_close on mysql resource destruction
ID: 32866
User updated by: kevin at hatry dot com
Reported By: kevin at hatry dot com
Status: Bogus
Bug Type: MySQL related
Operating System: windows XP + linux
PHP Version: 4.3.11
New Comment:
i didn't think i was having a discussion just thought you hadn't seen
my point and wanted to make it clear.
But if you say that it is normal that affecting NULL to $link1 makes
$link2 to become Unkown i will not bother you anymore.
I understand that you are all very busy (as i am by the way, this
problem has put me way behind schedule) and i am sorry that my feedback
has made you lose your time.
Previous Comments:
[2005-04-28 14:13:35] [EMAIL PROTECTED]
Please don't abuse the bug system for questions and discussions. Use
PHP's mailinglists (http://www.php.net/mailing-lists.php)
[2005-04-28 13:48:26] kevin at hatry dot com
thank you for your direct answer however this solution cannot work
with a heavily loaded website as it would open too much connections on
the mysql server :
for example a page called 50 times a second and opening 3 connections
at a the same time means 150 connections /sec to the mysql server
instead of 50 !
This situation is clearly one where the shared connection is useful.
i will try one last example to make sure you really know how i want it
to work, please read it through and answer the last question below,
thank you.
the following script (without any function to make it clearer) :
?php
$link1 = mysql_connect('localhost','root','',false);
$link2 = mysql_connect('localhost','root','',false);
echo link1 : ; var_dump($link1);
echo link2 : ; var_dump($link2);
echo 'mysql thread : '.mysql_thread_id($link2).\n;
mysql_close($link1);
echo -- after closing link1 :\n;
echo link1 : ; var_dump($link1);
echo link2 : ; var_dump($link2);
echo 'mysql thread : '.mysql_thread_id($link2).\n;
// this query works fine and that's ok with me
mysql_query('select * from user',$link2);
$link1 = NULL;
echo -- after link1 = NULL :\n;
echo link1 : ; var_dump($link1);
echo link2 : ; var_dump($link2);
echo 'mysql thread : '.mysql_thread_id($link2).\n;
// oops $link2 is no more usable to do queries,
// that's a bug for me !
mysql_query('select * from user',$link2); // line 28
?
generate this output :
link1 : resource(4) of type (mysql link)
link2 : resource(4) of type (mysql link)
mysql thread : 16
-- after closing link1 :
link1 : resource(4) of type (mysql link)
link2 : resource(4) of type (mysql link)
mysql thread : 16
-- after link1 = NULL :
link1 : NULL
link2 : resource(4) of type (Unknown)
Warning: mysql_thread_id(): 4 is not a valid MySQL-Link resource in ...
on line 24
mysql thread :
Warning: mysql_query(): 4 is not a valid MySQL-Link resource in ... on
line 28
If you could please answer this one last question :
why does affecting NULL to $link1 make $link2 to become Unkown ?
In other words, why don't we see this output instead :
link1 : resource(4) of type (mysql link)
link2 : resource(4) of type (mysql link)
mysql thread : 16
-- after closing link1 :
link1 : resource(4) of type (Unknown)
link2 : resource(4) of type (mysql link)
mysql thread : 16
-- after link1 = NULL :
link1 : NULL
link2 : resource(4) of type (mysql link)
mysql thread : 16
If this is a feature than it should be documented as it is not obvious
that changing the value of the resource variable will close the
connection, even if it has been closed before.
[2005-04-28 12:49:42] [EMAIL PROTECTED]
Change false to true in mysql_connect() and it will work like you want
it to work. Still not a bug.
[2005-04-28 12:26:33] kevin at hatry dot com
Description:
I originally posted this info on follow up of bug id 30525 but it has
been reported as bogus and i dont think the problem has been fully
understood.
Please *do* try to understand the problem here as there *is* one !
PHP version used :
- php 4.3.11 on win32 with the bundled 3.23.49 mysql client
- php 4.3.11 on linux kernel 2.4.29 with external 4.1.11 mysql client
both with apache 1.3.33 and with the cli binary.
Preface :
I *do* understand that by default MySQL connections are shared in PHP.
I also note that in older versions a single mysql_close() would close
all of the links but that there now appears to be reference counting
before finally closing the TCP connection which is a better thing for
me.
The problem is :
It seems that affecting a value or 'unset'ing a variable of type mysql
resource or living the function in which the variable was created calls
mysql_close on that variable (and so reduces the reference) even if a
previous call was already made on that variable. So the reference count
becomes wrong.
So it
#32859 [Opn-Fbk]: Error when attempting to write Clob to oracle
ID: 32859 Updated by: [EMAIL PROTECTED] Reported By: Diomedes_01 at yahoo dot com -Status: Open +Status: Feedback Bug Type: OCI8 related Operating System: Solaris 9 (Server) PHP Version: 5.0.4 New Comment: Thank you for this bug report. To properly diagnose the problem, we need a short but complete example script to be able to reproduce this bug ourselves. A proper reproducing script starts with ?php and ends with ?, is max. 10-20 lines long and does not require any external resources such as databases, etc. If possible, make the script source available online and provide an URL to it here. Try to avoid embedding huge scripts into the report. Also, you don't have to modify your script to make it run with PHP5. Old-style named functions are working in the same way as in PHP4. Previous Comments: [2005-04-27 21:44:58] Diomedes_01 at yahoo dot com Description: I am receiving errors after upgrading from php 4.3.9 to php 5.0.4 when attempting to upload a clob to my Oracle database. The code has already been modified to follow the PHP 5 paradigm; but it is refusing to function. Code is as follows: Reproduce code: --- $sql1 = (begin append_comments(:incident_id,:comments_id);end;); $sth = oci_parse ( $connection, $sql1 ) or display_main_error(); $clob = oci_new_descriptor ($connection, OCI_D_LOB); oci_bind_by_name ( $sth, :incident_id, $incident ); oci_bind_by_name ($sth, :comments_id, $clob, -1, OCI_B_CLOB ); $clob-write($comments); oci_execute ($sth, OCI_DEFAULT) or display_main_error(); oci_commit($connection); $clob-free(); oci_free_statement($sth); Expected result: The above code should properly insert the clob into the Oracle database. The code executed correctly in php4.3.9 and the stored procedure being used functions normally in SQL*Plus. Actual result: -- I receive the following warnings from PHP when attempting to execute the code: Warning: OCI-Lob::write() [function.write]: OCILobGetLength: OCI_INVALID_HANDLE in /www/htdocs/EtrackTest/oracle_update.php on line 218 Warning: oci_execute() [function.oci-execute]: OCIStmtExecute: ORA-22275: invalid LOB locator specified ORA-06512: at SYS.DBMS_LOB, line 366 ORA-06512: at ETRACK.APPEND_COMMENTS, line 14 ORA-06512: at line 1 in /www/htdocs/EtrackTest/oracle_update.php on line 219 The code I use is virtually identical to what exists in the PHP documentation. -- Edit this bug report at http://bugs.php.net/?id=32859edit=1
#28074 [Asn-Csd]: Fast CGI standard compliance : stderr should be written in a FCGI stderr stream
ID: 28074
Updated by: [EMAIL PROTECTED]
Reported By: bogus_idp at yahoo dot fr
-Status: Assigned
+Status: Closed
Bug Type: CGI related
Operating System: *
PHP Version: 4CVS, 5CVS (2005-01-10)
Assigned To: sas
New Comment:
Added fastcgi.logging php.ini option to make it possible for people
like Sascha to disable this.
Previous Comments:
[2005-04-28 12:58:03] [EMAIL PROTECTED]
Feel free to fix it then.
[2005-04-21 11:43:51] [EMAIL PROTECTED]
This is an ugly change for users who redirect PHP's stderr to a log
file due to file permissions (PHP is not allowed to open the log
file).
Instead of writing to the log file, the Apache log now contains tons of
rows like this:
[Thu Apr 21 11:18:27 2005] [error] [client 129.0.10.119] FastCGI:
server /home/www/PHP/php/bin/php stderr: array (
[Thu Apr 21 11:18:27 2005] [error] [client 129.0.10.119] FastCGI:
server /home/www/PHP/php/bin/php stderr: 'rcs' =
[Thu Apr 21 11:18:27 2005] [error] [client 129.0.10.119] FastCGI:
server /home/www/PHP/php/bin/php stderr: array (
etc.
This needs to be addressed -- make logging to fastcgi's stderr
optional.
[2005-01-10 16:01:29] chris at ex-parrot dot com
This one turns out to be easy to fix, thus:
--- cgi_main.c.orig Mon Jan 10 14:57:04 2005
+++ cgi_main.c Mon Jan 10 14:53:44 2005
@@ -481,7 +481,14 @@
static void sapi_cgi_log_message(char *message)
{
- fprintf(stderr, %s\n, message);
+#if PHP_FASTCGI
+if (!FCGX_IsCGI()) {
+FCGX_Request *request = (FCGX_Request *)SG(server_context);
+FCGX_FPrintF( request-err, %s\n, message );
+/* ignore return code */
+} else
+#endif /* PHP_FASTCGI */
+ fprintf(stderr, %s\n, message);
}
static int sapi_cgi_deactivate(TSRMLS_D)
However, there is another similar bug, which is that a stream opened on
php://stderr should also direct its output to the FCGI error stream
(rather than just to file descriptor #2).
-- Chris Lightfoot
[2004-04-20 12:03:30] bogus_idp at yahoo dot fr
Description:
The Fast CGI standard require that error be reported through the
FastCGI connection as a Stderr data stream.
But PHP Fast CGI processes still write errors to original stderr (file
handle 3) which prevent from clean standard centralized FCGI logging,
especially when the Fast CGI PHP process is not started by the web
server (remote Fast CGI).
In most cases, it makes debugging PHP scripts impossible.
--
Edit this bug report at http://bugs.php.net/?id=28074edit=1
#32860 [Opn]: quoted-string cookies not handled correctly
ID: 32860 User updated by: ast at gmx dot ch Reported By: ast at gmx dot ch Status: Open Bug Type: Feature/Change Request Operating System: * PHP Version: 4.3.11 New Comment: Fact is that PHP 2 was released after RFC 2109 and the dev cycle of PHP 3, 4, and 5 started completely after RFC 2109 was published. Interpret the issue as you want. I just wanted to help you to be more standards compliant. Previous Comments: [2005-04-28 14:40:05] [EMAIL PROTECTED] You are wrong. It is not a bug. PHP implements Cookie version 0 which is based upon the Netscape Cookie standard. Both RFCs 2109/2965 speak of Cookie version 1. [2005-04-28 12:03:44] ast at gmx dot ch But even the initial cookie RFC, http://rfc.net/rfc2109.html, described that a value may be either a TOKEN or a quoted-string. The only difference to the new cookie RFC, RFC 2965, is that are not allowed in quoted-string values of the old version while they may be in quoted-string values, just escaped by the escape character \ in the new version. Therefore, the separaters , and ; are allowed in quoted-string values even in the old cookie RFC. Maybe you could list it as a low-priority bug, but it's a bug and not a feature or a change request. [2005-04-28 08:16:09] [EMAIL PROTECTED] When PHP was written, this RFC did not yet exist - that's why we classify it as a feature request - it's basically cookie version 1.1. [2005-04-28 00:04:15] ast at gmx dot ch Feature/Change request? I don't agree. Handling a HTTP header not according to the RFCs they are defined in doesn't make sense at all. Therefore, it's a bug. But it's not that important to me. Do what you consider the right thing. [2005-04-28 00:00:18] [EMAIL PROTECTED] Reclassified. 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/32860 -- Edit this bug report at http://bugs.php.net/?id=32860edit=1
#32852 [Fbk-Opn]: Crash with singleton and __destruct
ID: 32852 User updated by: cox at idecnet dot com Reported By: cox at idecnet dot com -Status: Feedback +Status: Open Bug Type: Reproducible crash Operating System: Linux PHP Version: 5.0.4 New Comment: Not using my php.ini doesn't crash in 5.0.4, 5.0.5dev or 5.1cvs and the output match the expected. So investigating my modified settings from the original php.ini-dist, I've found that ze1_compat generates the problem: zend.ze1_compatibility_mode = On (turning it Off does not crash, well, afterall it's php5 only syntax). The other requested data: gcc-3.4.1 bison-1.875 glibc-2.3.3 Previous Comments: [2005-04-28 13:52:55] [EMAIL PROTECTED] I still can't reproduce this. I get same result with both HEAD and PHP_5_0 branches and also with the snapshot. Does it give same result if you make sure you don't load any php.ini: sapi/cli/php -n file.php What bison version do you have installed? What compiler (and version) ? [2005-04-28 10:53:13] cox at idecnet dot com With today's CVS (5.1), it does not crash. But the output is: Output: i'm called i'm called i'm called i'm called The __destruct() function is called 4 times. With php5-STABLE-200504271035 (5.0.5dev): $ make distclean $ ./configure \ --prefix=/usr \ --with-config-file-path=/etc/php5 \ --enable-cli \ --disable-cgi \ --disable-pear \ --enable-debug Still the same output and same crash. [2005-04-28 00:25:57] [EMAIL PROTECTED] If you configure with --enable-debug (rm config.cache ./configure + your options + --enable-debug make clean make) does it still crash? Are you sure you ARE using the latest CVS? (the snapshots might not be updated again..) [2005-04-27 23:25:44] [EMAIL PROTECTED] Still works fine here. Both with HEAD and 5.0.x. [2005-04-27 16:52:39] cox at idecnet dot com Versions and compile options for the two that crashes for me. In case it says something for you, if I remove the __destructor() function the code works good (also you see in the output this function is being called twice). 5.0.4 ~~~ PHP 5.0.4 (cli) (built: Apr 27 2005 11:48:13) Configure Command = './configure' '--prefix=/usr' '--with-config-file-path=/etc/php5' '--with-xml' '--with-zlib' '--with-gd' '--enable-gd-native-ttf' '--with-freetype-dir' '--with-png-dir' '--with-jpeg-dir' '--disable-pear' '--with-mysql=/usr' '--with-imap=/usr/include/imap' '--with-imap-ssl' '--with-kerberos' '--with-gettext' '--enable-ftp' '--with-dom' '--with-mhash' '--with-mcrypt' '--enable-cli' '--enable-sockets' '--enable-sigchild' '--enable-pcntl' '--enable-shmop' '--enable-posix' '--enable-bcmath' '--with-xmlrpc' '--with-mime-magic' '--disable-cgi' 5.0.5 Snapshot Stable ~~~ PHP 5.0.5-dev (cli) (built: Apr 27 2005 13:47:32) (DEBUG) Configure Command = './configure' '--prefix=/usr' '--with-config-file-path=/etc/php5' '--with-xml' '--with-zlib' '--with-gd' '--enable-gd-native-ttf' '--with-freetype-dir' '--with-png-dir' '--with-jpeg-dir' '--disable-pear' '--with-mysql=/usr' '--with-imap=/usr/include/imap' '--with-imap-ssl' '--with-kerberos' '--with-gettext' '--enable-ftp' '--with-dom' '--with-mhash' '--with-mcrypt' '--enable-cli' '--enable-sockets' '--enable-sigchild' '--enable-pcntl' '--enable-shmop' '--enable-posix' '--enable-bcmath' '--with-xmlrpc' '--with-mime-magic' '--disable-cgi' '--enable-debug' 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/32852 -- Edit this bug report at http://bugs.php.net/?id=32852edit=1
#32868 [NEW]: Although localeconv() reports , for decimal_point calculations fail
From: andy at laut dot de Operating system: SuSe Linux 9.2 PHP version: 4.3.10 PHP Bug Type: *General Issues Bug description: Although localeconv() reports , for decimal_point calculations fail Description: There seems to be a failure in internal number formating. Although my locale is set correctly and localeconf returns the expected information, which says, that decimal_point is the komma, calculations with komma as decimal-separator fail. Versions of PHP 4.3 behave as i expect, but since 4.3 scripts which uses the komma for decimal-separator don't calculate correctly anymore... My Configure-Line: './configure' '--with-apxs=/www/apache-1.3.33/bin/apxs' '--prefix=/www/apache-1.3.33/php-4.3.10' '--with-gd' '--with-zlib' '--with-mysql' '--enable-trans-sid' '--enable-ftp' '--with-mnogosearch=/www/mnogosearch' Reproduce code: --- #As anybody can see here, the locale is set correctly setlocale (LC_ALL, '[EMAIL PROTECTED]', 'de_DE', 'de', 'ge'); echo strftime (%A %e %B %Y, mktime (0, 0, 0, 12, 22, 1978)); #localeconf returns the expected information $locale_info = localeconv(); print_r($locale_info); #But what the heck, this print doesn't print(1,00+1,99= . 1,00 + 1,99 . br/\n); /* If you uncomment this, parse error occurs $x = 2,99; $y = 3,27; print($x+$y); */ Expected result: Freitag 22 Dezember 1978 Array ( [decimal_point] = , [thousands_sep] = . [int_curr_symbol] = EUR [currency_symbol] = ¤ [mon_decimal_point] = , [mon_thousands_sep] = . [positive_sign] = [negative_sign] = - [int_frac_digits] = 2 [frac_digits] = 2 [p_cs_precedes] = 0 [p_sep_by_space] = 1 [n_cs_precedes] = 0 [n_sep_by_space] = 1 [p_sign_posn] = 1 [n_sign_posn] = 1 [grouping] = Array ( [0] = 3 [1] = 3 ) [mon_grouping] = Array ( [0] = 3 [1] = 3 ) ) 2,99 6,26 Actual result: -- Freitag 22 Dezember 1978 Array ( [decimal_point] = , [thousands_sep] = . [int_curr_symbol] = EUR [currency_symbol] = ¤ [mon_decimal_point] = , [mon_thousands_sep] = . [positive_sign] = [negative_sign] = - [int_frac_digits] = 2 [frac_digits] = 2 [p_cs_precedes] = 0 [p_sep_by_space] = 1 [n_cs_precedes] = 0 [n_sep_by_space] = 1 [p_sign_posn] = 1 [n_sign_posn] = 1 [grouping] = Array ( [0] = 3 [1] = 3 ) [mon_grouping] = Array ( [0] = 3 [1] = 3 ) ) 2 5 -- Edit bug report at http://bugs.php.net/?id=32868edit=1 -- Try a CVS snapshot (php4): http://bugs.php.net/fix.php?id=32868r=trysnapshot4 Try a CVS snapshot (php5.0): http://bugs.php.net/fix.php?id=32868r=trysnapshot50 Try a CVS snapshot (php5.1): http://bugs.php.net/fix.php?id=32868r=trysnapshot51 Fixed in CVS:http://bugs.php.net/fix.php?id=32868r=fixedcvs Fixed in release:http://bugs.php.net/fix.php?id=32868r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=32868r=needtrace Need Reproduce Script: http://bugs.php.net/fix.php?id=32868r=needscript Try newer version: http://bugs.php.net/fix.php?id=32868r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=32868r=support Expected behavior: http://bugs.php.net/fix.php?id=32868r=notwrong Not enough info: http://bugs.php.net/fix.php?id=32868r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=32868r=submittedtwice register_globals:http://bugs.php.net/fix.php?id=32868r=globals PHP 3 support discontinued: http://bugs.php.net/fix.php?id=32868r=php3 Daylight Savings:http://bugs.php.net/fix.php?id=32868r=dst IIS Stability: http://bugs.php.net/fix.php?id=32868r=isapi Install GNU Sed: http://bugs.php.net/fix.php?id=32868r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=32868r=float No Zend Extensions: http://bugs.php.net/fix.php?id=32868r=nozend MySQL Configuration Error: http://bugs.php.net/fix.php?id=32868r=mysqlcfg
#32860 [Opn]: quoted-string cookies not handled correctly
ID: 32860 User updated by: ast at gmx dot ch Reported By: ast at gmx dot ch Status: Open Bug Type: Feature/Change Request Operating System: * PHP Version: 4.3.11 New Comment: quoted-string cookies are defined as cookies with a value that is a quoted-string, quoted by double-quote marks. You refer to PHP's mechanism to urlencode all cookie values resulting in TOKEN values. This mechanism is indeed suggested in netscapes standard. I've pointed the difference of these things out in my bug report. So, please don't say what I claim is wrong, because that is simply not true. Handle it as a feature request if you prefer that. It's ok. Thanks for the discussion. After all, we all agree on the state (PHP 4.3.11 implements cookie standard 0 (netscape)) and what it doesn't (RFC 2109 which is as old as PHP 2). Previous Comments: [2005-04-28 16:52:08] [EMAIL PROTECTED] You claimed that PHP handles quoted-strings within cookies incorrectly. This is simply wrong. PHP supports version 0 cookies, like all browsers do by default and there are no quoted-strings in the version 0 standard. It doesn't matter when the Cookie Version 1 RFCs were released. Fact is: the web uses mainly version 0 cookies. So Jani was right when he changed this into a feature request. [2005-04-28 15:41:08] ast at gmx dot ch Fact is that PHP 2 was released after RFC 2109 and the dev cycle of PHP 3, 4, and 5 started completely after RFC 2109 was published. Interpret the issue as you want. I just wanted to help you to be more standards compliant. [2005-04-28 14:40:05] [EMAIL PROTECTED] You are wrong. It is not a bug. PHP implements Cookie version 0 which is based upon the Netscape Cookie standard. Both RFCs 2109/2965 speak of Cookie version 1. [2005-04-28 12:03:44] ast at gmx dot ch But even the initial cookie RFC, http://rfc.net/rfc2109.html, described that a value may be either a TOKEN or a quoted-string. The only difference to the new cookie RFC, RFC 2965, is that are not allowed in quoted-string values of the old version while they may be in quoted-string values, just escaped by the escape character \ in the new version. Therefore, the separaters , and ; are allowed in quoted-string values even in the old cookie RFC. Maybe you could list it as a low-priority bug, but it's a bug and not a feature or a change request. [2005-04-28 08:16:09] [EMAIL PROTECTED] When PHP was written, this RFC did not yet exist - that's why we classify it as a feature request - it's basically cookie version 1.1. 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/32860 -- Edit this bug report at http://bugs.php.net/?id=32860edit=1
#32828 [Ver-Csd]: Throwing exception in output_callback function with ob_start and ob_end_clean
ID: 32828
Updated by: [EMAIL PROTECTED]
Reported By: rbro at hotmail dot com
-Status: Verified
+Status: Closed
Bug Type: Reproducible crash
Operating System: *
PHP Version: 5.0,5.1 CVS (2005-04-26)
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:
[2005-04-26 00:52:03] rbro at hotmail dot com
Description:
If you throw an exception inside an output_callback function as a
result of using ob_start() and ob_end_clean(), a Segmentation fault
occurs.
Reproduce code:
---
?php
function output_handler($buffer)
{
throw new Exception;
}
ob_start('output_handler');
ob_end_clean();
?
Expected result:
Exception is thrown.
Actual result:
--
Segmentation fault
--
Edit this bug report at http://bugs.php.net/?id=32828edit=1
#32860 [Opn]: quoted-string cookies not handled correctly
ID: 32860 Updated by: [EMAIL PROTECTED] Reported By: ast at gmx dot ch Status: Open Bug Type: Feature/Change Request Operating System: * PHP Version: 4.3.11 New Comment: You claimed that PHP handles quoted-strings within cookies incorrectly. This is simply wrong. PHP supports version 0 cookies, like all browsers do by default and there are no quoted-strings in the version 0 standard. It doesn't matter when the Cookie Version 1 RFCs were released. Fact is: the web uses mainly version 0 cookies. So Jani was right when he changed this into a feature request. Previous Comments: [2005-04-28 15:41:08] ast at gmx dot ch Fact is that PHP 2 was released after RFC 2109 and the dev cycle of PHP 3, 4, and 5 started completely after RFC 2109 was published. Interpret the issue as you want. I just wanted to help you to be more standards compliant. [2005-04-28 14:40:05] [EMAIL PROTECTED] You are wrong. It is not a bug. PHP implements Cookie version 0 which is based upon the Netscape Cookie standard. Both RFCs 2109/2965 speak of Cookie version 1. [2005-04-28 12:03:44] ast at gmx dot ch But even the initial cookie RFC, http://rfc.net/rfc2109.html, described that a value may be either a TOKEN or a quoted-string. The only difference to the new cookie RFC, RFC 2965, is that are not allowed in quoted-string values of the old version while they may be in quoted-string values, just escaped by the escape character \ in the new version. Therefore, the separaters , and ; are allowed in quoted-string values even in the old cookie RFC. Maybe you could list it as a low-priority bug, but it's a bug and not a feature or a change request. [2005-04-28 08:16:09] [EMAIL PROTECTED] When PHP was written, this RFC did not yet exist - that's why we classify it as a feature request - it's basically cookie version 1.1. [2005-04-28 00:04:15] ast at gmx dot ch Feature/Change request? I don't agree. Handling a HTTP header not according to the RFCs they are defined in doesn't make sense at all. Therefore, it's a bug. But it's not that important to me. Do what you consider the right thing. 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/32860 -- Edit this bug report at http://bugs.php.net/?id=32860edit=1
#32868 [Opn-Csd]: Although localeconv() reports , for decimal_point calculations fail
ID: 32868 Updated by: [EMAIL PROTECTED] Reported By: andy at laut dot de -Status: Open +Status: Closed Bug Type: *General Issues Operating System: SuSe Linux 9.2 PHP Version: 4.3.10 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: [2005-04-28 16:59:46] andy at laut dot de Description: There seems to be a failure in internal number formating. Although my locale is set correctly and localeconf returns the expected information, which says, that decimal_point is the komma, calculations with komma as decimal-separator fail. Versions of PHP 4.3 behave as i expect, but since 4.3 scripts which uses the komma for decimal-separator don't calculate correctly anymore... My Configure-Line: './configure' '--with-apxs=/www/apache-1.3.33/bin/apxs' '--prefix=/www/apache-1.3.33/php-4.3.10' '--with-gd' '--with-zlib' '--with-mysql' '--enable-trans-sid' '--enable-ftp' '--with-mnogosearch=/www/mnogosearch' Reproduce code: --- #As anybody can see here, the locale is set correctly setlocale (LC_ALL, '[EMAIL PROTECTED]', 'de_DE', 'de', 'ge'); echo strftime (%A %e %B %Y, mktime (0, 0, 0, 12, 22, 1978)); #localeconf returns the expected information $locale_info = localeconv(); print_r($locale_info); #But what the heck, this print doesn't print(1,00+1,99= . 1,00 + 1,99 . br/\n); /* If you uncomment this, parse error occurs $x = 2,99; $y = 3,27; print($x+$y); */ Expected result: Freitag 22 Dezember 1978 Array ( [decimal_point] = , [thousands_sep] = . [int_curr_symbol] = EUR [currency_symbol] = ¤ [mon_decimal_point] = , [mon_thousands_sep] = . [positive_sign] = [negative_sign] = - [int_frac_digits] = 2 [frac_digits] = 2 [p_cs_precedes] = 0 [p_sep_by_space] = 1 [n_cs_precedes] = 0 [n_sep_by_space] = 1 [p_sign_posn] = 1 [n_sign_posn] = 1 [grouping] = Array ( [0] = 3 [1] = 3 ) [mon_grouping] = Array ( [0] = 3 [1] = 3 ) ) 2,99 6,26 Actual result: -- Freitag 22 Dezember 1978 Array ( [decimal_point] = , [thousands_sep] = . [int_curr_symbol] = EUR [currency_symbol] = ¤ [mon_decimal_point] = , [mon_thousands_sep] = . [positive_sign] = [negative_sign] = - [int_frac_digits] = 2 [frac_digits] = 2 [p_cs_precedes] = 0 [p_sep_by_space] = 1 [n_cs_precedes] = 0 [n_sep_by_space] = 1 [p_sign_posn] = 1 [n_sign_posn] = 1 [grouping] = Array ( [0] = 3 [1] = 3 ) [mon_grouping] = Array ( [0] = 3 [1] = 3 ) ) 2 5 -- Edit this bug report at http://bugs.php.net/?id=32868edit=1
#32869 [NEW]: Session and reference related
From: thomas dot ene at gmail dot com
Operating system: Windows
PHP version: 4.3.9
PHP Bug Type: Session related
Bug description: Session and reference related
Description:
Let's say I have a class c1. Doing this:
$obj = $_SESSION['obj'];
$obj = new c1();
would set $_SESSION['obj'] to NULL.
Reproduce code:
---
?php
class c1
{
var $v;
function c1($a) { $this-v = $a; }
function say() { print {$this-v}br; }
}
session_start();
session_destroy();
$obj = $_SESSION['aaa'];
$obj = new c1(6);
var_dump($_SESSION['aaa']);
?
Expected result:
I would expect to have an object in the $_SESSION['aaa']
Actual result:
--
The actual result is NULL. Sorry if this is post in not pertinent but I
haven't found any support related to this.
--
Edit bug report at http://bugs.php.net/?id=32869edit=1
--
Try a CVS snapshot (php4): http://bugs.php.net/fix.php?id=32869r=trysnapshot4
Try a CVS snapshot (php5.0):
http://bugs.php.net/fix.php?id=32869r=trysnapshot50
Try a CVS snapshot (php5.1):
http://bugs.php.net/fix.php?id=32869r=trysnapshot51
Fixed in CVS:http://bugs.php.net/fix.php?id=32869r=fixedcvs
Fixed in release:http://bugs.php.net/fix.php?id=32869r=alreadyfixed
Need backtrace: http://bugs.php.net/fix.php?id=32869r=needtrace
Need Reproduce Script: http://bugs.php.net/fix.php?id=32869r=needscript
Try newer version: http://bugs.php.net/fix.php?id=32869r=oldversion
Not developer issue: http://bugs.php.net/fix.php?id=32869r=support
Expected behavior: http://bugs.php.net/fix.php?id=32869r=notwrong
Not enough info:
http://bugs.php.net/fix.php?id=32869r=notenoughinfo
Submitted twice:
http://bugs.php.net/fix.php?id=32869r=submittedtwice
register_globals:http://bugs.php.net/fix.php?id=32869r=globals
PHP 3 support discontinued: http://bugs.php.net/fix.php?id=32869r=php3
Daylight Savings:http://bugs.php.net/fix.php?id=32869r=dst
IIS Stability: http://bugs.php.net/fix.php?id=32869r=isapi
Install GNU Sed: http://bugs.php.net/fix.php?id=32869r=gnused
Floating point limitations: http://bugs.php.net/fix.php?id=32869r=float
No Zend Extensions: http://bugs.php.net/fix.php?id=32869r=nozend
MySQL Configuration Error: http://bugs.php.net/fix.php?id=32869r=mysqlcfg
#32870 [NEW]: Setting output_handler does not work with custom functions
From: ng4rrjanbiah at rediffmail dot com
Operating system: Windows XP
PHP version: 5.0.4
PHP Bug Type: Output Control
Bug description: Setting output_handler does not work with custom functions
Description:
Setting output_handler (either through php.ini our .htaccess) does not
work with custom functions. It works for ob_gzhandler but *not* on any
custom functions--say foo.
There was a detail discussion on c.l.php about this
http://groups.google.com/[EMAIL PROTECTED]
Though we could set custom callback functions through ob_start(), we
couldn't set output_handler (for custom functions) via php.ini. The manual
also hints that it could be set PHP_INI_PERDIR basis
http://in2.php.net/ref.outcontrol#AEN111555
Peace to you all PHP saints...
-R. Rajesh Jeba Anbiah
Reproduce code:
---
in php.ini set:
output_handler foo_callback
in test.php:
?php
function foo_callback($buffer) //callback defined
{
return $buffer;
}
print_r(ob_list_handlers());
?
Expected result:
foo_callback to be listed
Actual result:
--
nothing. (Callback not registered.)
--
Edit bug report at http://bugs.php.net/?id=32870edit=1
--
Try a CVS snapshot (php4): http://bugs.php.net/fix.php?id=32870r=trysnapshot4
Try a CVS snapshot (php5.0):
http://bugs.php.net/fix.php?id=32870r=trysnapshot50
Try a CVS snapshot (php5.1):
http://bugs.php.net/fix.php?id=32870r=trysnapshot51
Fixed in CVS:http://bugs.php.net/fix.php?id=32870r=fixedcvs
Fixed in release:http://bugs.php.net/fix.php?id=32870r=alreadyfixed
Need backtrace: http://bugs.php.net/fix.php?id=32870r=needtrace
Need Reproduce Script: http://bugs.php.net/fix.php?id=32870r=needscript
Try newer version: http://bugs.php.net/fix.php?id=32870r=oldversion
Not developer issue: http://bugs.php.net/fix.php?id=32870r=support
Expected behavior: http://bugs.php.net/fix.php?id=32870r=notwrong
Not enough info:
http://bugs.php.net/fix.php?id=32870r=notenoughinfo
Submitted twice:
http://bugs.php.net/fix.php?id=32870r=submittedtwice
register_globals:http://bugs.php.net/fix.php?id=32870r=globals
PHP 3 support discontinued: http://bugs.php.net/fix.php?id=32870r=php3
Daylight Savings:http://bugs.php.net/fix.php?id=32870r=dst
IIS Stability: http://bugs.php.net/fix.php?id=32870r=isapi
Install GNU Sed: http://bugs.php.net/fix.php?id=32870r=gnused
Floating point limitations: http://bugs.php.net/fix.php?id=32870r=float
No Zend Extensions: http://bugs.php.net/fix.php?id=32870r=nozend
MySQL Configuration Error: http://bugs.php.net/fix.php?id=32870r=mysqlcfg
#32868 [Csd-Bgs]: Although localeconv() reports , for decimal_point calculations fail
ID: 32868 Updated by: [EMAIL PROTECTED] Reported By: andy at laut dot de -Status: Closed +Status: Bogus Bug Type: *General Issues Operating System: SuSe Linux 9.2 PHP Version: 4.3.10 New Comment: Thank you for taking the time to write to us, but this is not a bug. Please double-check the documentation available at http://www.php.net/manual/ and the instructions on how to report a bug at http://bugs.php.net/how-to-report.php This is actually the intended behaviours, PHP only uses the . for as the decimal separators regardless of the locale. Previous Comments: [2005-04-28 17:35:29] [EMAIL PROTECTED] 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. [2005-04-28 16:59:46] andy at laut dot de Description: There seems to be a failure in internal number formating. Although my locale is set correctly and localeconf returns the expected information, which says, that decimal_point is the komma, calculations with komma as decimal-separator fail. Versions of PHP 4.3 behave as i expect, but since 4.3 scripts which uses the komma for decimal-separator don't calculate correctly anymore... My Configure-Line: './configure' '--with-apxs=/www/apache-1.3.33/bin/apxs' '--prefix=/www/apache-1.3.33/php-4.3.10' '--with-gd' '--with-zlib' '--with-mysql' '--enable-trans-sid' '--enable-ftp' '--with-mnogosearch=/www/mnogosearch' Reproduce code: --- #As anybody can see here, the locale is set correctly setlocale (LC_ALL, '[EMAIL PROTECTED]', 'de_DE', 'de', 'ge'); echo strftime (%A %e %B %Y, mktime (0, 0, 0, 12, 22, 1978)); #localeconf returns the expected information $locale_info = localeconv(); print_r($locale_info); #But what the heck, this print doesn't print(1,00+1,99= . 1,00 + 1,99 . br/\n); /* If you uncomment this, parse error occurs $x = 2,99; $y = 3,27; print($x+$y); */ Expected result: Freitag 22 Dezember 1978 Array ( [decimal_point] = , [thousands_sep] = . [int_curr_symbol] = EUR [currency_symbol] = ¤ [mon_decimal_point] = , [mon_thousands_sep] = . [positive_sign] = [negative_sign] = - [int_frac_digits] = 2 [frac_digits] = 2 [p_cs_precedes] = 0 [p_sep_by_space] = 1 [n_cs_precedes] = 0 [n_sep_by_space] = 1 [p_sign_posn] = 1 [n_sign_posn] = 1 [grouping] = Array ( [0] = 3 [1] = 3 ) [mon_grouping] = Array ( [0] = 3 [1] = 3 ) ) 2,99 6,26 Actual result: -- Freitag 22 Dezember 1978 Array ( [decimal_point] = , [thousands_sep] = . [int_curr_symbol] = EUR [currency_symbol] = ¤ [mon_decimal_point] = , [mon_thousands_sep] = . [positive_sign] = [negative_sign] = - [int_frac_digits] = 2 [frac_digits] = 2 [p_cs_precedes] = 0 [p_sep_by_space] = 1 [n_cs_precedes] = 0 [n_sep_by_space] = 1 [p_sign_posn] = 1 [n_sign_posn] = 1 [grouping] = Array ( [0] = 3 [1] = 3 ) [mon_grouping] = Array ( [0] = 3 [1] = 3 ) ) 2 5 -- Edit this bug report at http://bugs.php.net/?id=32868edit=1
#32859 [Fbk-Opn]: Error when attempting to write Clob to oracle
ID: 32859 User updated by: Diomedes_01 at yahoo dot com Reported By: Diomedes_01 at yahoo dot com -Status: Feedback +Status: Open Bug Type: OCI8 related Operating System: Solaris 9 (Server) PHP Version: 5.0.4 New Comment: Unfortunately, my website is behind a firewall and contains company sensitive information; so I cannot grant access. The reproducible code is already included; please note that I attempted to continue using my previous PHP4 code (that worked beforehand) and it failed. That code was: ?php $sql1 = (begin append_comments(:incident_id,:comments_id);end;); $sth = OCIParse ( $connection, $sql1 ) or display_main_error(); $clob = OCINewDescriptor ($connection, OCI_D_LOB); OCIBindByName ( $sth, :incident_id, $incident, -1 ); OCIBindByName ($sth, :comments_id, $clob, -1, OCI_B_CLOB ); $clob-WriteTemporary($comments); OCIExecute ($sth, OCI_DEFAULT) or display_main_error(); $clob-close(); $clob-free(); OCIFreeStatement($sth); ? When I attempted to execute the above code, I received a fatal error from PHP indicating that the writeTemporary method was not found. According to what I read in the documentation, it appears to not be part of the new OCI class. So when I followed the documentation and re-implemented the code following the instructions provided; which by the way, look like so: (straight from your online help) ?php /* Calling PL/SQL stored procedures which contain clobs as input * parameters (PHP 4 = 4.0.6). * Example PL/SQL stored procedure signature is: * * PROCEDURE save_data * Argument Name TypeIn/Out Default? * -- --- -- * KEYNUMBER(38) IN * DATA CLOBIN * */ $conn = oci_connect($user, $password); $stmt = oci_parse($conn, begin save_data(:key, :data); end;); $clob = oci_new_descriptor($conn, OCI_D_LOB); oci_bind_by_name($stmt, ':key', $key); oci_bind_by_name($stmt, ':data', $clob, -1, OCI_B_CLOB); $clob-write($data); oci_execute($stmt, OCI_DEFAULT); oci_commit($conn); $clob-free(); oci_free_statement($stmt); ? Here is the documentation URL: http://us2.php.net/manual/en/function.oci-new-descriptor.php That is when I receive a problem with regards to the 'write' method. So either this is a bug or a documentation problem; I know the stored procedure I am using works and that the variables being passed are valid. It works in SQL*Plus and it works if I revert back to PHP4. Please advise. Previous Comments: [2005-04-28 15:04:53] [EMAIL PROTECTED] Thank you for this bug report. To properly diagnose the problem, we need a short but complete example script to be able to reproduce this bug ourselves. A proper reproducing script starts with ?php and ends with ?, is max. 10-20 lines long and does not require any external resources such as databases, etc. If possible, make the script source available online and provide an URL to it here. Try to avoid embedding huge scripts into the report. Also, you don't have to modify your script to make it run with PHP5. Old-style named functions are working in the same way as in PHP4. [2005-04-27 21:44:58] Diomedes_01 at yahoo dot com Description: I am receiving errors after upgrading from php 4.3.9 to php 5.0.4 when attempting to upload a clob to my Oracle database. The code has already been modified to follow the PHP 5 paradigm; but it is refusing to function. Code is as follows: Reproduce code: --- $sql1 = (begin append_comments(:incident_id,:comments_id);end;); $sth = oci_parse ( $connection, $sql1 ) or display_main_error(); $clob = oci_new_descriptor ($connection, OCI_D_LOB); oci_bind_by_name ( $sth, :incident_id, $incident ); oci_bind_by_name ($sth, :comments_id, $clob, -1, OCI_B_CLOB ); $clob-write($comments); oci_execute ($sth, OCI_DEFAULT) or display_main_error(); oci_commit($connection); $clob-free(); oci_free_statement($sth); Expected result: The above code should properly insert the clob into the Oracle database. The code executed correctly in php4.3.9 and the stored procedure being used functions normally in SQL*Plus. Actual result: -- I receive the following warnings from PHP when attempting to execute the code: Warning: OCI-Lob::write() [function.write]: OCILobGetLength: OCI_INVALID_HANDLE in /www/htdocs/EtrackTest/oracle_update.php on line 218 Warning: oci_execute() [function.oci-execute]: OCIStmtExecute: ORA-22275: invalid LOB locator specified ORA-06512: at SYS.DBMS_LOB, line 366 ORA-06512: at ETRACK.APPEND_COMMENTS, line 14 ORA-06512: at
#29015 [Ver-Csd]: Incorrect behavior of member vars(non string ones)-numeric mem vars und others
ID: 29015
Updated by: [EMAIL PROTECTED]
Reported By: tomas_matousek at hotmail dot com
-Status: Verified
+Status: Closed
Bug Type: Zend Engine 2 problem
Operating System: *
PHP Version: 5CVS-2005-03-06
New Comment:
Fixed in CVS HEAD and PHP_5_0.
Empty property and string properties started with '\0' are disallowed.
Previous Comments:
[2004-08-14 00:43:06] php at hristov dot com
AFAUK, internally the private member variables are stored in such a way
that the first byte is \0, which maybe you emulate with your test case.
:private means that the member var is private one.
shorter example for creating of a private variable :
php -r '$a=new stdclass();$a-$b=3;var_dump($a);'
and of integer member variable
php -r '$a=new stdclass();$b=3;$a-$b=3;var_dump($a);'
andrey
[2004-07-05 15:02:12] tomas_matousek at hotmail dot com
Description:
If I try to use variable with non-string name (e.g.
$x = 10; $$x = ...) the name is converted to a string using standard
conversion rules. That's ok.
But this doesn't work on object's field which is IMHO a bug and it
implies some a buggy behavior.
See the code bellow.
It seems that by:
$x = null;
$a-$x = whatever;
one can somehow create a private variable (or something like that,
don't know what :private means)!
Moreover, there is possibly a bug in get_object_vars when a field name
is a numeric string (e.g. 10) (compare the first item of results of
get_object_vars and var_dump).
Reproduce code:
---
function field_names_test()
{
$a = new stdClass();
$x = 10;
$a-$x = int(10);
$x = 10;
$a-$x = string('10');
$x = ;
$a-$x = string('');
$x = null;
$a-$x = null;
$x = 1.8;
$a-$x = double(1.8);
$x = false;
$a-$x = bool(false);
$x = array(1,2,3);
$a-$x = array(1,2,3);
var_dump(get_object_vars($a));
var_dump($a);
}
field_names_test();
Expected result:
array(4) {
[10]=
string(12) string('10')
[]=
string(11) bool(false)
[1.8]=
string(11) double(1.8)
[Array]=
string(12) array(1,2,3)
}
object(stdClass)#1 (4) {
[10]=
string(12) string('10')
[]=
string(11) bool(false)
[1.8]=
string(11) double(1.8)
[Array]=
string(12) array(1,2,3)
}
Actual result:
--
array(3) {
[10]=
string(12) string('10')
[1.8]=
string(11) double(1.8)
[Array]=
string(12) array(1,2,3)
}
object(stdClass)#1 (4) {
[10]=
string(12) string('10')
[:private]=
string(11) bool(false)
[1.8]=
string(11) double(1.8)
[Array]=
string(12) array(1,2,3)
}
--
Edit this bug report at http://bugs.php.net/?id=29015edit=1
#32873 [NEW]: file_get_contents appends \n
From: mbm at interflow dot dk Operating system: FreeBSD 5.2 PHP version: 5.0.3 PHP Bug Type: Filesystem function related Bug description: file_get_contents appends \n Description: When loading a file with file_get_contents theres an \n appended to the content. Reproduce code: --- echo foo file.txt php -r 'var_dump(file_get_contents(file.txt));' Expected result: string(3) foo Actual result: -- string(4) foo -- Edit bug report at http://bugs.php.net/?id=32873edit=1 -- Try a CVS snapshot (php4): http://bugs.php.net/fix.php?id=32873r=trysnapshot4 Try a CVS snapshot (php5.0): http://bugs.php.net/fix.php?id=32873r=trysnapshot50 Try a CVS snapshot (php5.1): http://bugs.php.net/fix.php?id=32873r=trysnapshot51 Fixed in CVS:http://bugs.php.net/fix.php?id=32873r=fixedcvs Fixed in release:http://bugs.php.net/fix.php?id=32873r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=32873r=needtrace Need Reproduce Script: http://bugs.php.net/fix.php?id=32873r=needscript Try newer version: http://bugs.php.net/fix.php?id=32873r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=32873r=support Expected behavior: http://bugs.php.net/fix.php?id=32873r=notwrong Not enough info: http://bugs.php.net/fix.php?id=32873r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=32873r=submittedtwice register_globals:http://bugs.php.net/fix.php?id=32873r=globals PHP 3 support discontinued: http://bugs.php.net/fix.php?id=32873r=php3 Daylight Savings:http://bugs.php.net/fix.php?id=32873r=dst IIS Stability: http://bugs.php.net/fix.php?id=32873r=isapi Install GNU Sed: http://bugs.php.net/fix.php?id=32873r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=32873r=float No Zend Extensions: http://bugs.php.net/fix.php?id=32873r=nozend MySQL Configuration Error: http://bugs.php.net/fix.php?id=32873r=mysqlcfg
#32873 [Opn-Bgs]: file_get_contents appends \n
ID: 32873 Updated by: [EMAIL PROTECTED] Reported By: mbm at interflow dot dk -Status: Open +Status: Bogus Bug Type: Filesystem function related Operating System: FreeBSD 5.2 PHP Version: 5.0.3 New Comment: The echo shell command does this by default. Use echo -n to prevent it. Previous Comments: [2005-04-28 20:17:06] mbm at interflow dot dk Description: When loading a file with file_get_contents theres an \n appended to the content. Reproduce code: --- echo foo file.txt php -r 'var_dump(file_get_contents(file.txt));' Expected result: string(3) foo Actual result: -- string(4) foo -- Edit this bug report at http://bugs.php.net/?id=32873edit=1
#32874 [NEW]: Circular call leeds to segmentation fault
From: mbm at interflow dot dk
Operating system: Multiple OS
PHP version: 5.0.4
PHP Bug Type: Reproducible crash
Bug description: Circular call leeds to segmentation fault
Description:
Recursively calling two functions in a class leads to a segmentation
fault.
Reproduce code:
---
class SegFault {
public function call(){
$this-back();
}
public function back(){
$this-call();
}
}
$seg = new SegFault();
$seg-Call();
Expected result:
I'd expect some kind of error when php runs out of buffer for the
callstack - this function clearly is an example of bad code in the script
- however php shouldnt die by segmentation fault.
Actual result:
--
Segmentation fault
--
Edit bug report at http://bugs.php.net/?id=32874edit=1
--
Try a CVS snapshot (php4): http://bugs.php.net/fix.php?id=32874r=trysnapshot4
Try a CVS snapshot (php5.0):
http://bugs.php.net/fix.php?id=32874r=trysnapshot50
Try a CVS snapshot (php5.1):
http://bugs.php.net/fix.php?id=32874r=trysnapshot51
Fixed in CVS:http://bugs.php.net/fix.php?id=32874r=fixedcvs
Fixed in release:http://bugs.php.net/fix.php?id=32874r=alreadyfixed
Need backtrace: http://bugs.php.net/fix.php?id=32874r=needtrace
Need Reproduce Script: http://bugs.php.net/fix.php?id=32874r=needscript
Try newer version: http://bugs.php.net/fix.php?id=32874r=oldversion
Not developer issue: http://bugs.php.net/fix.php?id=32874r=support
Expected behavior: http://bugs.php.net/fix.php?id=32874r=notwrong
Not enough info:
http://bugs.php.net/fix.php?id=32874r=notenoughinfo
Submitted twice:
http://bugs.php.net/fix.php?id=32874r=submittedtwice
register_globals:http://bugs.php.net/fix.php?id=32874r=globals
PHP 3 support discontinued: http://bugs.php.net/fix.php?id=32874r=php3
Daylight Savings:http://bugs.php.net/fix.php?id=32874r=dst
IIS Stability: http://bugs.php.net/fix.php?id=32874r=isapi
Install GNU Sed: http://bugs.php.net/fix.php?id=32874r=gnused
Floating point limitations: http://bugs.php.net/fix.php?id=32874r=float
No Zend Extensions: http://bugs.php.net/fix.php?id=32874r=nozend
MySQL Configuration Error: http://bugs.php.net/fix.php?id=32874r=mysqlcfg
#32875 [NEW]: Repetition quantifiers
From: chiaroscuro at achromatic dot fsnet dot co dot uk
Operating system: Apache 1.3.31
PHP version: 4.3.10
PHP Bug Type: PCRE related
Bug description: Repetition quantifiers
Description:
I'm using quantifiers in preg_match_all functions,amongst other things, to
restrict the length of strings strings submitted from HTML forms. The lower
limit catches discrepant strings, but the upper limit has no effect. I've
tried using very basic code, but unsuccessfully.
Reproduce code:
---
$failure = 0;
$userpattern = /t{3,6}/;
$username = 'ttt';
$usercheck = preg_match_all($userpattern,$username,$results);
if ( !$usercheck )
{ $failure++; }
Expected result:
$usercheck = 'tt';
This would be a disallowed string
$usercheck = 'ttt';
This would also be a disallowed string
Actual result:
--
$usercheck = 'tt'; results in $failure == 1 the string 'fails' as it
should.
$usercheck = 'ttt'; results in $failure = 0 the string is allowed.
This happens however many repetitions the string comprises and with any
upper limit set.
--
Edit bug report at http://bugs.php.net/?id=32875edit=1
--
Try a CVS snapshot (php4): http://bugs.php.net/fix.php?id=32875r=trysnapshot4
Try a CVS snapshot (php5.0):
http://bugs.php.net/fix.php?id=32875r=trysnapshot50
Try a CVS snapshot (php5.1):
http://bugs.php.net/fix.php?id=32875r=trysnapshot51
Fixed in CVS:http://bugs.php.net/fix.php?id=32875r=fixedcvs
Fixed in release:http://bugs.php.net/fix.php?id=32875r=alreadyfixed
Need backtrace: http://bugs.php.net/fix.php?id=32875r=needtrace
Need Reproduce Script: http://bugs.php.net/fix.php?id=32875r=needscript
Try newer version: http://bugs.php.net/fix.php?id=32875r=oldversion
Not developer issue: http://bugs.php.net/fix.php?id=32875r=support
Expected behavior: http://bugs.php.net/fix.php?id=32875r=notwrong
Not enough info:
http://bugs.php.net/fix.php?id=32875r=notenoughinfo
Submitted twice:
http://bugs.php.net/fix.php?id=32875r=submittedtwice
register_globals:http://bugs.php.net/fix.php?id=32875r=globals
PHP 3 support discontinued: http://bugs.php.net/fix.php?id=32875r=php3
Daylight Savings:http://bugs.php.net/fix.php?id=32875r=dst
IIS Stability: http://bugs.php.net/fix.php?id=32875r=isapi
Install GNU Sed: http://bugs.php.net/fix.php?id=32875r=gnused
Floating point limitations: http://bugs.php.net/fix.php?id=32875r=float
No Zend Extensions: http://bugs.php.net/fix.php?id=32875r=nozend
MySQL Configuration Error: http://bugs.php.net/fix.php?id=32875r=mysqlcfg
#32875 [Opn-Bgs]: Repetition quantifiers
ID: 32875
Updated by: [EMAIL PROTECTED]
Reported By: chiaroscuro at achromatic dot fsnet dot co dot uk
-Status: Open
+Status: Bogus
Bug Type: PCRE related
Operating System: Apache 1.3.31
PHP Version: 4.3.10
New Comment:
Anchor your regex using ^ and $
Previous Comments:
[2005-04-28 20:52:02] chiaroscuro at achromatic dot fsnet dot co dot uk
Description:
I'm using quantifiers in preg_match_all functions,amongst other things,
to restrict the length of strings strings submitted from HTML forms. The
lower limit catches discrepant strings, but the upper limit has no
effect. I've tried using very basic code, but unsuccessfully.
Reproduce code:
---
$failure = 0;
$userpattern = /t{3,6}/;
$username = 'ttt';
$usercheck = preg_match_all($userpattern,$username,$results);
if ( !$usercheck )
{ $failure++; }
Expected result:
$usercheck = 'tt';
This would be a disallowed string
$usercheck = 'ttt';
This would also be a disallowed string
Actual result:
--
$usercheck = 'tt'; results in $failure == 1 the string 'fails' as it
should.
$usercheck = 'ttt'; results in $failure = 0 the string is
allowed.
This happens however many repetitions the string comprises and with any
upper limit set.
--
Edit this bug report at http://bugs.php.net/?id=32875edit=1
#32874 [Opn-Bgs]: Circular call leeds to segmentation fault
ID: 32874
Updated by: [EMAIL PROTECTED]
Reported By: mbm at interflow dot dk
-Status: Open
+Status: Bogus
Bug Type: Reproducible crash
Operating System: Multiple OS
PHP Version: 5.0.4
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
.
Previous Comments:
[2005-04-28 20:28:23] mbm at interflow dot dk
Description:
Recursively calling two functions in a class leads to a segmentation
fault.
Reproduce code:
---
class SegFault {
public function call(){
$this-back();
}
public function back(){
$this-call();
}
}
$seg = new SegFault();
$seg-Call();
Expected result:
I'd expect some kind of error when php runs out of buffer for the
callstack - this function clearly is an example of bad code in the
script - however php shouldnt die by segmentation fault.
Actual result:
--
Segmentation fault
--
Edit this bug report at http://bugs.php.net/?id=32874edit=1
#32850 [Ctl]: PHP crashes on startup because zend_do_implement_interface is called with NULL
ID: 32850
Updated by: [EMAIL PROTECTED]
Reported By: [EMAIL PROTECTED]
Status: Critical
Bug Type: SQLite related
Operating System: Debian Sarge Unstable
PHP Version: 5CVS-2005-04-27 (dev)
New Comment:
Any info on how to reproduce it?
Previous Comments:
[2005-04-27 12:04:51] [EMAIL PROTECTED]
Description:
#0 zend_hash_merge_ex (target=0x82f2d38, source=0x98,
pCopyConstructor=0x81d6e10 zval_add_ref, size=4,
pMergeSource=0x81c8ec0 do_inherit_constant_check, pParam=0x0) at
/home/.../php5-200504251230/Zend/zend_hash.c:818
p = (Bucket *) 0x82f2ca0
t = (void *) 0x82f4908
#1 0x081c8f79 in zend_do_implement_interface (ce=0x82f2ca0,
iface=0x0)
at /home/.../php5-200504251230/Zend/zend_compile.c:2099
No locals.
#2 0x081dbfa9 in zend_class_implements (class_entry=0x82f2ca0,
num_interfaces=2)
at /home/.../php5-200504251230/Zend/zend_API.c:1646
interface_entry = (zend_class_entry *) 0x98
ce_num = 2
impl_num = 2
interface_list = 0xb390 è#@ ¦/@\214
#3 0x080f6102 in zm_startup_sqlite (type=1, module_number=4) at
/home/.../php5-200504251230/ext/sqlite/sqlite.c:1024
No locals.
#4 0x081daf38 in zend_register_module_ex (module=0x82f0028) at
/home/.../php5-200504251230/Zend/zend_API.c:1227
lcname = 0x0
module_ptr = (zend_module_entry *) 0x82f0028
#5 0x081a0dc0 in php_startup_extensions (ptr=0x82a450c, count=152) at
/home/.../php5-200504251230/main/main.c:1269
end = (zend_module_entry **) 0x82a453c
#6 0x08246d2b in php_startup_internal_extensions () at
main/internal_functions_cli.c:72
No locals.
#7 0x081a13ea in php_module_startup (sf=0x828396c,
additional_modules=0x0, num_additional_modules=152)
at /home/.../php5-200504251230/main/main.c:1454
zuf = {error_function = 0x819fbb0 php_error_cb,
printf_function = 0x819f510 php_printf,
write_function = 0x81a0d70 php_body_write_wrapper, fopen_function =
0x81a0220 php_fopen_wrapper_for_zend,
message_handler = 0x81a0340 php_message_handler_for_zend,
block_interruptions = 0, unblock_interruptions = 0,
get_configuration_directive = 0x81a02f0
php_get_configuration_directive_for_zend,
ticks_function = 0x81abd60 php_run_ticks, on_timeout =
0x81a0480 php_on_timeout,
stream_open_function = 0x81a0270 php_stream_open_for_zend,
vspprintf_function = 0x81a42c0 vspprintf,
getenv_function = 0x81a7620 sapi_getenv}
zuv = {import_use_extension = 0x82576e6 .php,
import_use_extension_length = 136766146, html_errors = 1 '\001'}
#8 0x08245c9e in main (argc=1, argv=0xbbd4) at
/home/.../php5-200504251230/sapi/cli/php_cli.c:632
exit_status = 0
c = 152
file_handle = {type = 0 '\0', filename = 0x82a46f4
[EMAIL PROTECTED],
opened_path = 0xbb28 Hûÿ¿Ûs$\bÜûÿ¿`\234/@, handle = {fd =
134697609, fp = 0x8075289, stream = {handle = 0x8075289,
reader = 0x402f9c50 sys_sigabbrev+25040, closer = 0xbb34,
interactive = -1073743032}}, free_filename = 219 'Û'}
--
Edit this bug report at http://bugs.php.net/?id=32850edit=1
#32850 [Ctl-Fbk]: PHP crashes on startup because zend_do_implement_interface is called with NULL
ID: 32850
Updated by: [EMAIL PROTECTED]
Reported By: [EMAIL PROTECTED]
-Status: Critical
+Status: Feedback
Bug Type: SQLite related
Operating System: Debian Sarge Unstable
PHP Version: 5CVS-2005-04-27 (dev)
Previous Comments:
[2005-04-28 22:00:13] [EMAIL PROTECTED]
Any info on how to reproduce it?
[2005-04-27 12:04:51] [EMAIL PROTECTED]
Description:
#0 zend_hash_merge_ex (target=0x82f2d38, source=0x98,
pCopyConstructor=0x81d6e10 zval_add_ref, size=4,
pMergeSource=0x81c8ec0 do_inherit_constant_check, pParam=0x0) at
/home/.../php5-200504251230/Zend/zend_hash.c:818
p = (Bucket *) 0x82f2ca0
t = (void *) 0x82f4908
#1 0x081c8f79 in zend_do_implement_interface (ce=0x82f2ca0,
iface=0x0)
at /home/.../php5-200504251230/Zend/zend_compile.c:2099
No locals.
#2 0x081dbfa9 in zend_class_implements (class_entry=0x82f2ca0,
num_interfaces=2)
at /home/.../php5-200504251230/Zend/zend_API.c:1646
interface_entry = (zend_class_entry *) 0x98
ce_num = 2
impl_num = 2
interface_list = 0xb390 è#@ ¦/@\214
#3 0x080f6102 in zm_startup_sqlite (type=1, module_number=4) at
/home/.../php5-200504251230/ext/sqlite/sqlite.c:1024
No locals.
#4 0x081daf38 in zend_register_module_ex (module=0x82f0028) at
/home/.../php5-200504251230/Zend/zend_API.c:1227
lcname = 0x0
module_ptr = (zend_module_entry *) 0x82f0028
#5 0x081a0dc0 in php_startup_extensions (ptr=0x82a450c, count=152) at
/home/.../php5-200504251230/main/main.c:1269
end = (zend_module_entry **) 0x82a453c
#6 0x08246d2b in php_startup_internal_extensions () at
main/internal_functions_cli.c:72
No locals.
#7 0x081a13ea in php_module_startup (sf=0x828396c,
additional_modules=0x0, num_additional_modules=152)
at /home/.../php5-200504251230/main/main.c:1454
zuf = {error_function = 0x819fbb0 php_error_cb,
printf_function = 0x819f510 php_printf,
write_function = 0x81a0d70 php_body_write_wrapper, fopen_function =
0x81a0220 php_fopen_wrapper_for_zend,
message_handler = 0x81a0340 php_message_handler_for_zend,
block_interruptions = 0, unblock_interruptions = 0,
get_configuration_directive = 0x81a02f0
php_get_configuration_directive_for_zend,
ticks_function = 0x81abd60 php_run_ticks, on_timeout =
0x81a0480 php_on_timeout,
stream_open_function = 0x81a0270 php_stream_open_for_zend,
vspprintf_function = 0x81a42c0 vspprintf,
getenv_function = 0x81a7620 sapi_getenv}
zuv = {import_use_extension = 0x82576e6 .php,
import_use_extension_length = 136766146, html_errors = 1 '\001'}
#8 0x08245c9e in main (argc=1, argv=0xbbd4) at
/home/.../php5-200504251230/sapi/cli/php_cli.c:632
exit_status = 0
c = 152
file_handle = {type = 0 '\0', filename = 0x82a46f4
[EMAIL PROTECTED],
opened_path = 0xbb28 Hûÿ¿Ûs$\bÜûÿ¿`\234/@, handle = {fd =
134697609, fp = 0x8075289, stream = {handle = 0x8075289,
reader = 0x402f9c50 sys_sigabbrev+25040, closer = 0xbb34,
interactive = -1073743032}}, free_filename = 219 'Û'}
--
Edit this bug report at http://bugs.php.net/?id=32850edit=1
#32850 [Fbk]: PHP crashes on startup because zend_do_implement_interface is called with NULL
ID: 32850
Updated by: [EMAIL PROTECTED]
Reported By: [EMAIL PROTECTED]
Status: Feedback
Bug Type: SQLite related
Operating System: Debian Sarge Unstable
PHP Version: 5CVS-2005-04-27 (dev)
New Comment:
PHP crashes in the second I invoke ./php
Like the backtrace shows it dies when loading sqlite extension because
it ends up calling zend_do_implement_interface (ce=0x82f2ca0,
iface=0x0) --- with a 0x0 NULL pointer
Previous Comments:
[2005-04-28 22:00:13] [EMAIL PROTECTED]
Any info on how to reproduce it?
[2005-04-27 12:04:51] [EMAIL PROTECTED]
Description:
#0 zend_hash_merge_ex (target=0x82f2d38, source=0x98,
pCopyConstructor=0x81d6e10 zval_add_ref, size=4,
pMergeSource=0x81c8ec0 do_inherit_constant_check, pParam=0x0) at
/home/.../php5-200504251230/Zend/zend_hash.c:818
p = (Bucket *) 0x82f2ca0
t = (void *) 0x82f4908
#1 0x081c8f79 in zend_do_implement_interface (ce=0x82f2ca0,
iface=0x0)
at /home/.../php5-200504251230/Zend/zend_compile.c:2099
No locals.
#2 0x081dbfa9 in zend_class_implements (class_entry=0x82f2ca0,
num_interfaces=2)
at /home/.../php5-200504251230/Zend/zend_API.c:1646
interface_entry = (zend_class_entry *) 0x98
ce_num = 2
impl_num = 2
interface_list = 0xb390 è#@ ¦/@\214
#3 0x080f6102 in zm_startup_sqlite (type=1, module_number=4) at
/home/.../php5-200504251230/ext/sqlite/sqlite.c:1024
No locals.
#4 0x081daf38 in zend_register_module_ex (module=0x82f0028) at
/home/.../php5-200504251230/Zend/zend_API.c:1227
lcname = 0x0
module_ptr = (zend_module_entry *) 0x82f0028
#5 0x081a0dc0 in php_startup_extensions (ptr=0x82a450c, count=152) at
/home/.../php5-200504251230/main/main.c:1269
end = (zend_module_entry **) 0x82a453c
#6 0x08246d2b in php_startup_internal_extensions () at
main/internal_functions_cli.c:72
No locals.
#7 0x081a13ea in php_module_startup (sf=0x828396c,
additional_modules=0x0, num_additional_modules=152)
at /home/.../php5-200504251230/main/main.c:1454
zuf = {error_function = 0x819fbb0 php_error_cb,
printf_function = 0x819f510 php_printf,
write_function = 0x81a0d70 php_body_write_wrapper, fopen_function =
0x81a0220 php_fopen_wrapper_for_zend,
message_handler = 0x81a0340 php_message_handler_for_zend,
block_interruptions = 0, unblock_interruptions = 0,
get_configuration_directive = 0x81a02f0
php_get_configuration_directive_for_zend,
ticks_function = 0x81abd60 php_run_ticks, on_timeout =
0x81a0480 php_on_timeout,
stream_open_function = 0x81a0270 php_stream_open_for_zend,
vspprintf_function = 0x81a42c0 vspprintf,
getenv_function = 0x81a7620 sapi_getenv}
zuv = {import_use_extension = 0x82576e6 .php,
import_use_extension_length = 136766146, html_errors = 1 '\001'}
#8 0x08245c9e in main (argc=1, argv=0xbbd4) at
/home/.../php5-200504251230/sapi/cli/php_cli.c:632
exit_status = 0
c = 152
file_handle = {type = 0 '\0', filename = 0x82a46f4
[EMAIL PROTECTED],
opened_path = 0xbb28 Hûÿ¿Ûs$\bÜûÿ¿`\234/@, handle = {fd =
134697609, fp = 0x8075289, stream = {handle = 0x8075289,
reader = 0x402f9c50 sys_sigabbrev+25040, closer = 0xbb34,
interactive = -1073743032}}, free_filename = 219 'Û'}
--
Edit this bug report at http://bugs.php.net/?id=32850edit=1
#32878 [NEW]: iframe and session problems
From: iztok dot polanic at gmail dot com Operating system: Windows XP PHP version: 5.0.4 PHP Bug Type: Session related Bug description: iframe and session problems Description: PHP seems to have some problems with frames, in my case iframes. I noticed this error when I tried to load one template in two separate iframes. If they are loaded simultanously there comes to a problem with session variables getting lost. And also getting Permission denied(13) in session_start(). As it seems PHP doesn't check if the session file is already in use. To reproduce the actual result, you have to click on a link 'odpri' atleast 5-15 times Reproduce code: --- main.php ? session_start(); ? ? $_SESSION['name'] = 'iztok'; ? a href=# onClick=bla.location.href = 'left.php';bla2.location.href = 'right.php';odpri/abrbr iframe name=bla width=100% height=100/iframe iframe name=bla2 width=100% height=100/iframe left.php ? session_start(); ? ? print $_SESSION['name']; ? right.php ? session_start(); ? ? print $_SESSION['name']; ? Expected result: iztok Actual result: -- Warning: session_start() [function.session-start]: open(c:\php\sessiondata\sess_793ef570090b599c6d973dfc64696a46, O_RDWR) failed: Permission denied (13) in C:\Documents and Settings\Iztok\My Documents\My Website\left.php on line 1 -- Edit bug report at http://bugs.php.net/?id=32878edit=1 -- Try a CVS snapshot (php4): http://bugs.php.net/fix.php?id=32878r=trysnapshot4 Try a CVS snapshot (php5.0): http://bugs.php.net/fix.php?id=32878r=trysnapshot50 Try a CVS snapshot (php5.1): http://bugs.php.net/fix.php?id=32878r=trysnapshot51 Fixed in CVS:http://bugs.php.net/fix.php?id=32878r=fixedcvs Fixed in release:http://bugs.php.net/fix.php?id=32878r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=32878r=needtrace Need Reproduce Script: http://bugs.php.net/fix.php?id=32878r=needscript Try newer version: http://bugs.php.net/fix.php?id=32878r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=32878r=support Expected behavior: http://bugs.php.net/fix.php?id=32878r=notwrong Not enough info: http://bugs.php.net/fix.php?id=32878r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=32878r=submittedtwice register_globals:http://bugs.php.net/fix.php?id=32878r=globals PHP 3 support discontinued: http://bugs.php.net/fix.php?id=32878r=php3 Daylight Savings:http://bugs.php.net/fix.php?id=32878r=dst IIS Stability: http://bugs.php.net/fix.php?id=32878r=isapi Install GNU Sed: http://bugs.php.net/fix.php?id=32878r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=32878r=float No Zend Extensions: http://bugs.php.net/fix.php?id=32878r=nozend MySQL Configuration Error: http://bugs.php.net/fix.php?id=32878r=mysqlcfg
#32880 [NEW]: Unable to properly convert from ISO-8859-1 to UTF-8
From: Diomedes_01 at yahoo dot com Operating system: Solaris 9 PHP version: 5.0.4 PHP Bug Type: Strings related Bug description: Unable to properly convert from ISO-8859-1 to UTF-8 Description: I am unable to properly encode certain strings from ISO-8859-1 to UTF-8. I have tried using utf8_encode, mb_convert_encoding and iconv with no success. The code I am attempting this on is as follows: Reproduce code: --- ?php $main_test_string = référendum sur la Constitution européenne; $string_test = mb_detect_encoding($main_test_string, 'UTF-8, ISO-8859-1'); echo Encoding used: $string_testbr; // Properly displays ISO-8859-1 // First try converting with iconv $iconv_test = iconv(ISO-8859-1, UTF-8, $main_test_string); echo Iconv test: $iconv_testbr; // Displays nothing. No data whatsoever // Now try converting with mb_convert_encoding $mb_test = mb_convert_encoding($main_test_string, UTF-8, ISO-8859-1); $string_test2 = mb_detect_encoding($mb_test, 'UTF-8, ISO-8859-1'); echo Encoding used: $string_test2br; // Indicates string is now UTF-8 encoded (which is wrong) echo MB Test convert value: $mb_testbr; // Displays: référendum sur la Constitution européenne; doesn't look like UTF-8 to me // Finally try utf8_encode $utf8_encode_test = utf8_encode($main_test_string); $string_test3 = mb_detect_encoding($textfieldabstract, 'UTF-8, ISO-8859-1'); echo Encoding used: $string_test3br; // Indicates string is now UTF-8 encoded (which is wrong) echo Abstract post conversion: $utf8_encode_testbr; // Same as before, displays: référendum sur la Constitution européenne ? Expected result: I should be seeing UTF-8 (Unicode) translated text of the style: '#917;#955;#955;#951;#957;#953;' Note that the above does work for non-latin based character sets like chinese, japanese, russian, greek, etc. Actual result: -- What I am seeing is the following string: référendum sur la Constitution européenne Definately not UTF-8. Could be Klingon. :-) I will admit I am not a Unicode master but this is certainly quite puzzling. According to the documentation, iconv is supposed to work in this case but it is not displaying any data. I am running PHP 5.0.4 with iconv enabled. (I see it in my phpinfo output) Please advise. -- Edit bug report at http://bugs.php.net/?id=32880edit=1 -- Try a CVS snapshot (php4): http://bugs.php.net/fix.php?id=32880r=trysnapshot4 Try a CVS snapshot (php5.0): http://bugs.php.net/fix.php?id=32880r=trysnapshot50 Try a CVS snapshot (php5.1): http://bugs.php.net/fix.php?id=32880r=trysnapshot51 Fixed in CVS:http://bugs.php.net/fix.php?id=32880r=fixedcvs Fixed in release:http://bugs.php.net/fix.php?id=32880r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=32880r=needtrace Need Reproduce Script: http://bugs.php.net/fix.php?id=32880r=needscript Try newer version: http://bugs.php.net/fix.php?id=32880r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=32880r=support Expected behavior: http://bugs.php.net/fix.php?id=32880r=notwrong Not enough info: http://bugs.php.net/fix.php?id=32880r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=32880r=submittedtwice register_globals:http://bugs.php.net/fix.php?id=32880r=globals PHP 3 support discontinued: http://bugs.php.net/fix.php?id=32880r=php3 Daylight Savings:http://bugs.php.net/fix.php?id=32880r=dst IIS Stability: http://bugs.php.net/fix.php?id=32880r=isapi Install GNU Sed: http://bugs.php.net/fix.php?id=32880r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=32880r=float No Zend Extensions: http://bugs.php.net/fix.php?id=32880r=nozend MySQL Configuration Error: http://bugs.php.net/fix.php?id=32880r=mysqlcfg
#32869 [Opn-Bgs]: Session and reference related
ID: 32869
Updated by: [EMAIL PROTECTED]
Reported By: thomas dot ene at gmail dot com
-Status: Open
+Status: Bogus
Bug Type: Session related
Operating System: Windows
PHP Version: 4.3.9
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.
This has nothing to do with sessions. (same happens if you replace
$_SESSION['aaa'] with e.g. $bar)
Please read this manual page and try to understand how references
work:
http://www.php.net/manual/en/language.references.php
Previous Comments:
[2005-04-28 17:31:31] thomas dot ene at gmail dot com
Description:
Let's say I have a class c1. Doing this:
$obj = $_SESSION['obj'];
$obj = new c1();
would set $_SESSION['obj'] to NULL.
Reproduce code:
---
?php
class c1
{
var $v;
function c1($a) { $this-v = $a; }
function say() { print {$this-v}br; }
}
session_start();
session_destroy();
$obj = $_SESSION['aaa'];
$obj = new c1(6);
var_dump($_SESSION['aaa']);
?
Expected result:
I would expect to have an object in the $_SESSION['aaa']
Actual result:
--
The actual result is NULL. Sorry if this is post in not pertinent but I
haven't found any support related to this.
--
Edit this bug report at http://bugs.php.net/?id=32869edit=1
#32680 [Opn-Asn]: PHP_MSHUTDOWN PHP_MINIT
ID: 32680 Updated by: [EMAIL PROTECTED] Reported By: dejan at akton dot si -Status: Open +Status: Assigned Bug Type: SNMP related Operating System: * PHP Version: 4CVS, 5CVS (2005-04-15) Assigned To: sniper New Comment: I need to test this with Apache1 sometime, but atm I have no time. (I use Apache2 myself) If you can, do try with Apache2 to see if the problem disappears. Previous Comments: [2005-04-26 14:17:18] dejan at akton dot si Same thing happened. Any clues as to what is causing this problem? Is this a specific problem only on my computer? [2005-04-25 23:57:15] [EMAIL PROTECTED] Try this configure line: # ./configure --disable-all --with-apxs=/usr/local/apache/bin/apxs --with-snmp=/usr/local Using this snapshot: http://snaps.php.net/php4-STABLE-latest.tar.gz [2005-04-25 08:27:52] dejan at akton dot si My configure line: './configure' '--with-apxs=/usr/local/apache/bin/apxs' '--with-zlib' '--enable-bcmath' '--enable-calendar' '--with-dom' '--with-dom-xslt' '--with-dom-exslt' '--enable-exif' '--enable-ftp' '--with-gd' '--with-t1lib' '--with-gettext' '--with-imap=/usr/include/imap' '--with-mysql=/usr/local' '--with-ncurses' '--enable-pcntl' '--with-readline' '--with-snmp=/usr/local' '--enable-sockets' '--enable-sysvmsg' '--enable-sysvsem' '--enable-sysvshm' '--enable-msdblib' '--enable-dbmfix' '--with-tdsver=7.0' '--with-freetds=/usr/local' '--with-mssql' '--with-openssl' '--with-ttf' '--with-freetype-dir=/usr/local' '--disable-ipv6' '--disable-debug' '--enable-dio' Apache Version: Apache/1.3.29 I tried with two net-snmp versions, including the new one 5.2.1 PHP_MINIT should be called with every request to a PHP script via Apache? And PHP_MSHUTDOWN when script ends? [2005-04-23 23:31:34] [EMAIL PROTECTED] I can not reproduce this. What apache version are you using? What configure line did you use with PHP? [2005-04-15 14:04:28] [EMAIL PROTECTED] It was me who added the MSHUTDOWN() to get rid of the memleaks..fixing. 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/32680 -- Edit this bug report at http://bugs.php.net/?id=32680edit=1
#32881 [NEW]: php_check_syntax / require_once
From: zapco dot bo197_php at gadz dot org Operating system: windows XP PHP version: 5.0.4 PHP Bug Type: Unknown/Other Function Bug description: php_check_syntax / require_once Description: I have some problems with the function php_check_syntax, require_once and ReflectionClass. when I use the script at this page : http://zapco.free.fr/bug.txt , I don't know if the included file (fichier_a.php or fichier_b.php in my exemple) herite or not from an other class, so index_x.php haven't the same result if the class in file used herite or not from an other class. -- Edit bug report at http://bugs.php.net/?id=32881edit=1 -- Try a CVS snapshot (php4): http://bugs.php.net/fix.php?id=32881r=trysnapshot4 Try a CVS snapshot (php5.0): http://bugs.php.net/fix.php?id=32881r=trysnapshot50 Try a CVS snapshot (php5.1): http://bugs.php.net/fix.php?id=32881r=trysnapshot51 Fixed in CVS:http://bugs.php.net/fix.php?id=32881r=fixedcvs Fixed in release:http://bugs.php.net/fix.php?id=32881r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=32881r=needtrace Need Reproduce Script: http://bugs.php.net/fix.php?id=32881r=needscript Try newer version: http://bugs.php.net/fix.php?id=32881r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=32881r=support Expected behavior: http://bugs.php.net/fix.php?id=32881r=notwrong Not enough info: http://bugs.php.net/fix.php?id=32881r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=32881r=submittedtwice register_globals:http://bugs.php.net/fix.php?id=32881r=globals PHP 3 support discontinued: http://bugs.php.net/fix.php?id=32881r=php3 Daylight Savings:http://bugs.php.net/fix.php?id=32881r=dst IIS Stability: http://bugs.php.net/fix.php?id=32881r=isapi Install GNU Sed: http://bugs.php.net/fix.php?id=32881r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=32881r=float No Zend Extensions: http://bugs.php.net/fix.php?id=32881r=nozend MySQL Configuration Error: http://bugs.php.net/fix.php?id=32881r=mysqlcfg
#32881 [Opn-Bgs]: php_check_syntax / require_once
ID: 32881 Updated by: [EMAIL PROTECTED] Reported By: zapco dot bo197_php at gadz dot org -Status: Open +Status: Bogus Bug Type: Unknown/Other Function Operating System: windows XP PHP Version: 5.0.4 New Comment: php_check_syntax() function is removed as of PHP 5.0.5 Previous Comments: [2005-04-29 01:12:51] zapco dot bo197_php at gadz dot org Description: I have some problems with the function php_check_syntax, require_once and ReflectionClass. when I use the script at this page : http://zapco.free.fr/bug.txt , I don't know if the included file (fichier_a.php or fichier_b.php in my exemple) herite or not from an other class, so index_x.php haven't the same result if the class in file used herite or not from an other class. -- Edit this bug report at http://bugs.php.net/?id=32881edit=1
#27406 [Asn-WFx]: php_check_syntax executes code
ID: 27406
Updated by: [EMAIL PROTECTED]
Reported By: thomas at stauntons dot org
-Status: Assigned
+Status: Wont fix
-Bug Type: Unknown/Other Function
+Bug Type: *General Issues
-Operating System: All
+Operating System: *
-PHP Version: php5.0-200412100930
+PHP Version: 5.*
Assigned To: iliaa
New Comment:
This was fixed by removing the function altogether.
It was nice idea but not one that could ever work reliably/be stable.
Use something like 'system(php -l foo.php);' to check the syntax..
Previous Comments:
[2005-03-26 02:43:14] patrick at 5etdemi dot com
If the file that is syntax checked has includes, the includes won't be
executed. That means as soon as you use php_check_syntax on such a
file, you won't be able to include it and you won't be able to use it
either because it's included files are MIA. That makes the function
pretty useless for any practical purposes.
[2005-03-07 22:59:52] linus at mccabe dot nu
Another important use for this function would be when using eval()'s to
test the code before eval'ing it. In this case a string would be the
only option and declaring functions would definately not work...
Since this function isn't experimental any more, I assume it cant be
altered to do this, but a new one would need to be implemented?
[2005-03-03 08:30:18] phpbugs at majiclab dot com
I would have to agree with most of the other posters, that the
php_check_syntax() function as it stands right now does MORE than its
name implies. I feel that a true php_check_syntax() function that
STRICTLY checks the syntax of a file or string and returns TRUE/FALSE
and has reference to an error message is the best. In fact, I would
also like to see the possibility of having an additional reference
variable for the line number of an error.
I am developing a fairly advanced framework that does compile certain
aspects of a web site dynamically. At first glance, I tried to
implement this function to check the syntax of the file both before
saving it and even before including it in the future. However, I ran
into some confusing messages about my classes being redefined and I
couldn't understand until I read the docs closer.
The simple fact is that the REAL functionality of this function is the
syntax checking, NOT the including. Any PHP programmer with more than
5 minutes of experience can probably include an external file. So
adding that particular aspect of the functionality to
php_check_syntax() seems useless. The code I have in my system goes a
little like this:
?php
...
function includeafile($sFile, $bOnce = FALSE)
{
if (file_exists($sFile)) {
if ([EMAIL PROTECTED]($sFile, $sMessage)) {
error_handler(File '$sFile' has a syntax error:
$sMessage, __LINE__, __FILE__);
} else {
... // go on including the file, etc.
}
}
return FALSE;
}
?
Now, I started getting errors all of a sudden saying that a class in
the file being included is being redeclared. I thought that odd since
I set $bOnce = TRUE, so it shouldn't ever be included more than once.
I think ideally I should be able to do this:
?php
...
function includeafile($sFile, $bOnce = FALSE)
{
if (file_exists($sFile)) {
if ([EMAIL PROTECTED]($sFile, $sMessage, $iLine)) {
error_handler(File '$sFile' has a syntax error:
$sMessage, $iLine, $sFile);
} else {
... // go on including the file, etc.
// it should not raise redeclaring errors
}
}
return FALSE;
}
?
Basically, it should:
1. Not include the file at all, just strictly do a lint check.
2. It would be nice to be able to get the line number of the file (for
debugging purposes).
At the lowest level, this function should be able to run like described
by many others:
?php
if (php_check_syntax($file, $message)) {
include $file;
} else {
error(Syntax Error: '$message');
}
?
It should be up to the PHP programmer to include the file...
[2005-02-23 17:32:01] de_bruut at hotmail dot com
Couple of points:
1. there are already half a dozen functions that include files or
execute strings
2. there's no other function that allows you to check the validity of a
piece of php code
3. right now, php_check_syntax does more than its name implies (it
includes the file)
4. there are several situations where a 'clean' lint check of php code
is useful (snippet submissions, UNIT TESTS(!), ...)
5. in general, functions should do only one thing, not two only
slightly related things, and one of them badly
I would love to see php_check_syntax implemented as its name implies: a
lint check for a
#32881 [Bgs-WFx]: php_check_syntax / require_once
ID: 32881 Updated by: [EMAIL PROTECTED] Reported By: zapco dot bo197_php at gadz dot org -Status: Bogus +Status: Wont fix -Bug Type: Unknown/Other Function +Bug Type: *General Issues Operating System: windows XP PHP Version: 5.0.4 New Comment: php_check_syntax() will be removed in next PHP versions due to the fact that it can't be made reliable/stable, ever. So plain and simple: Do not use it. It's dangerous. Use something like 'system(php -l foo.php);' to check the syntax.. Previous Comments: [2005-04-29 01:38:51] [EMAIL PROTECTED] php_check_syntax() function is removed as of PHP 5.0.5 [2005-04-29 01:12:51] zapco dot bo197_php at gadz dot org Description: I have some problems with the function php_check_syntax, require_once and ReflectionClass. when I use the script at this page : http://zapco.free.fr/bug.txt , I don't know if the included file (fichier_a.php or fichier_b.php in my exemple) herite or not from an other class, so index_x.php haven't the same result if the class in file used herite or not from an other class. -- Edit this bug report at http://bugs.php.net/?id=32881edit=1
#32878 [Opn-Bgs]: iframe and session problems
ID: 32878 Updated by: [EMAIL PROTECTED] Reported By: iztok dot polanic at gmail dot com -Status: Open +Status: Bogus Bug Type: Session related Operating System: Windows XP PHP Version: 5.0.4 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. RTFM: http://www.php.net/manual/en/function.session-write-close.php Previous Comments: [2005-04-28 22:21:17] iztok dot polanic at gmail dot com Description: PHP seems to have some problems with frames, in my case iframes. I noticed this error when I tried to load one template in two separate iframes. If they are loaded simultanously there comes to a problem with session variables getting lost. And also getting Permission denied(13) in session_start(). As it seems PHP doesn't check if the session file is already in use. To reproduce the actual result, you have to click on a link 'odpri' atleast 5-15 times Reproduce code: --- main.php ? session_start(); ? ? $_SESSION['name'] = 'iztok'; ? a href=# onClick=bla.location.href = 'left.php';bla2.location.href = 'right.php';odpri/abrbr iframe name=bla width=100% height=100/iframe iframe name=bla2 width=100% height=100/iframe left.php ? session_start(); ? ? print $_SESSION['name']; ? right.php ? session_start(); ? ? print $_SESSION['name']; ? Expected result: iztok Actual result: -- Warning: session_start() [function.session-start]: open(c:\php\sessiondata\sess_793ef570090b599c6d973dfc64696a46, O_RDWR) failed: Permission denied (13) in C:\Documents and Settings\Iztok\My Documents\My Website\left.php on line 1 -- Edit this bug report at http://bugs.php.net/?id=32878edit=1
#32880 [Opn-Bgs]: Unable to properly convert from ISO-8859-1 to UTF-8
ID: 32880 Updated by: [EMAIL PROTECTED] Reported By: Diomedes_01 at yahoo dot com -Status: Open +Status: Bogus Bug Type: Strings related Operating System: Solaris 9 PHP Version: 5.0.4 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. What you're getting is really UTF-8 encoded string.. Previous Comments: [2005-04-28 23:46:20] Diomedes_01 at yahoo dot com Description: I am unable to properly encode certain strings from ISO-8859-1 to UTF-8. I have tried using utf8_encode, mb_convert_encoding and iconv with no success. The code I am attempting this on is as follows: Reproduce code: --- ?php $main_test_string = référendum sur la Constitution européenne; $string_test = mb_detect_encoding($main_test_string, 'UTF-8, ISO-8859-1'); echo Encoding used: $string_testbr; // Properly displays ISO-8859-1 // First try converting with iconv $iconv_test = iconv(ISO-8859-1, UTF-8, $main_test_string); echo Iconv test: $iconv_testbr; // Displays nothing. No data whatsoever // Now try converting with mb_convert_encoding $mb_test = mb_convert_encoding($main_test_string, UTF-8, ISO-8859-1); $string_test2 = mb_detect_encoding($mb_test, 'UTF-8, ISO-8859-1'); echo Encoding used: $string_test2br; // Indicates string is now UTF-8 encoded (which is wrong) echo MB Test convert value: $mb_testbr; // Displays: référendum sur la Constitution européenne; doesn't look like UTF-8 to me // Finally try utf8_encode $utf8_encode_test = utf8_encode($main_test_string); $string_test3 = mb_detect_encoding($textfieldabstract, 'UTF-8, ISO-8859-1'); echo Encoding used: $string_test3br; // Indicates string is now UTF-8 encoded (which is wrong) echo Abstract post conversion: $utf8_encode_testbr; // Same as before, displays: référendum sur la Constitution européenne ? Expected result: I should be seeing UTF-8 (Unicode) translated text of the style: '#917;#955;#955;#951;#957;#953;' Note that the above does work for non-latin based character sets like chinese, japanese, russian, greek, etc. Actual result: -- What I am seeing is the following string: référendum sur la Constitution européenne Definately not UTF-8. Could be Klingon. :-) I will admit I am not a Unicode master but this is certainly quite puzzling. According to the documentation, iconv is supposed to work in this case but it is not displaying any data. I am running PHP 5.0.4 with iconv enabled. (I see it in my phpinfo output) Please advise. -- Edit this bug report at http://bugs.php.net/?id=32880edit=1
#30525 [Bgs-Opn]: mysql_close() fails in some situations with shared links
ID: 30525
User updated by: l dot cameron2 at ugrad dot unimelb dot edu dot au
Reported By: l dot cameron2 at ugrad dot unimelb dot edu dot au
-Status: Bogus
+Status: Open
Bug Type: MySQL related
-Operating System: win32
+Operating System: *
PHP Version: 5.0.x and 4.x
New Comment:
Please reread the first post where I explicitly talked about shared
connection behaviour.
The bug is that when using shared connections, if you ever use
mysql_close() *and* set your links to null, your shared connections
will be closed prematurely.
As outlined above, the net result of the is that you can never call
mysql_close() on a shared connection and expect to have it work
correctly.
Previous Comments:
[2005-04-27 14:48:13] [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
When using same connection parameters no new connection will be
established by default, instead an exisiting one will be reused. Set
the optional newlink parameter to true if you want to establish more
than one physical connection.
[2005-04-27 13:25:23] kevin at hatry dot com
i just want to add a last comment to make clear that this bug is
important.
this is (i think) a much used type of program :
?php
function do_something_in_mysql () {
$link3 = mysql_connect('localhost','root','',false);
// do some common queries here
mysql_close($link3);
echo link3:; var_dump($link3);
}
$link1 = mysql_connect('localhost','root','',false);
echo link1:; var_dump($link1);
do_something_in_mysql();
// here $link1 is UNUSABLE !!
mysql_close($link1);
echo link1:; var_dump($link1);
?
fails with :
link1:resource(4) of type (mysql link)
link3:resource(4) of type (mysql link)
Warning: mysql_close(): 4 is not a valid MySQL-Link resource in ... on
line 14
link1:resource(4) of type (Unknown)
i think that closing a connection in the same environnement that it was
open (like in the function here) is good programming so it shouldn't
fail like that !
And the problem is *not* that the mysql_close closed all connections as
shown by this example :
?php
function do_something_in_mysql () {
$link3 = mysql_connect('localhost','root','',false);
echo link3:; var_dump($link3);
// do some common queries here
mysql_close($link3);
}
$link1 = mysql_connect('localhost','root','',false);
$link2 = mysql_connect('localhost','root','',false);
echo link1:; var_dump($link1);
echo link2:; var_dump($link2);
do_something_in_mysql();
// here $link1 is still USABLE
mysql_close($link1);
echo link1:; var_dump($link1);
echo link2:; var_dump($link2);
?
here there is no failure :
link1:resource(4) of type (mysql link)
link2:resource(4) of type (mysql link)
link3:resource(4) of type (mysql link)
link1:resource(4) of type (Unknown)
link2:resource(4) of type (Unknown)
there would be one if we had closed $link2 after $link1 for example.
[2004-10-22 06:19:48] l dot cameron2 at ugrad dot unimelb dot edu dot
au
Description:
Preface: I *do* understand that by default MySQL connections are shared
in PHP.
I also note that in older versions a single mysql_close() would close
all of the links; see #9107: there now there appears to be reference
counting before finally closing the TCP connection -- which is IMHO
better than the older behaviour, but the implementation has its own
bugs:
PHP appears to keeps an internal count of the number of times a link
has been duplicated. When the link count is = 0, the underlying TCP
connection is actually closed.
* close() reduces the link count by 1
* setting the connection to null *also* reduces the link count by 1 --
even if that link has already been close()d
Currently the only workarounds for this are to:
[1] Set new_link to true every time you mysql_connect() -- potentially
creating a lot of TCP connections and slowing the program down
[2] close() the link, but never set it to null and hope that PHP won't
clean it up until the end of the program: This *will* fail sometimes
though; see the example at http://www.levi.id.au/mysql4.php.txt
[3] Never mysql_close() links, only set them to null and hope that PHP
will in fact clean up the TCP connection before MySQL runs out of
available connections (admittedly only a problem when you have a lot of
simultaneous connections to your database) -- this does work now, but
we're not supposed to assume anything about when PHP does its object
destruction.
The third is really the only viable solution; but is dependent on the
internal implementation of the MySQL extension.
At best, the current situation is that if you
#32850 [Fbk-Opn]: PHP crashes on startup because zend_do_implement_interface is called with NULL
ID: 32850
Updated by: [EMAIL PROTECTED]
Reported By: [EMAIL PROTECTED]
-Status: Feedback
+Status: Open
Bug Type: SQLite related
Operating System: Debian Sarge Unstable
PHP Version: 5CVS-2005-04-27 (dev)
Previous Comments:
[2005-04-28 22:46:11] [EMAIL PROTECTED]
PHP crashes in the second I invoke ./php
Like the backtrace shows it dies when loading sqlite extension because
it ends up calling zend_do_implement_interface (ce=0x82f2ca0,
iface=0x0) --- with a 0x0 NULL pointer
[2005-04-28 22:00:13] [EMAIL PROTECTED]
Any info on how to reproduce it?
[2005-04-27 12:04:51] [EMAIL PROTECTED]
Description:
#0 zend_hash_merge_ex (target=0x82f2d38, source=0x98,
pCopyConstructor=0x81d6e10 zval_add_ref, size=4,
pMergeSource=0x81c8ec0 do_inherit_constant_check, pParam=0x0) at
/home/.../php5-200504251230/Zend/zend_hash.c:818
p = (Bucket *) 0x82f2ca0
t = (void *) 0x82f4908
#1 0x081c8f79 in zend_do_implement_interface (ce=0x82f2ca0,
iface=0x0)
at /home/.../php5-200504251230/Zend/zend_compile.c:2099
No locals.
#2 0x081dbfa9 in zend_class_implements (class_entry=0x82f2ca0,
num_interfaces=2)
at /home/.../php5-200504251230/Zend/zend_API.c:1646
interface_entry = (zend_class_entry *) 0x98
ce_num = 2
impl_num = 2
interface_list = 0xb390 è#@ ¦/@\214
#3 0x080f6102 in zm_startup_sqlite (type=1, module_number=4) at
/home/.../php5-200504251230/ext/sqlite/sqlite.c:1024
No locals.
#4 0x081daf38 in zend_register_module_ex (module=0x82f0028) at
/home/.../php5-200504251230/Zend/zend_API.c:1227
lcname = 0x0
module_ptr = (zend_module_entry *) 0x82f0028
#5 0x081a0dc0 in php_startup_extensions (ptr=0x82a450c, count=152) at
/home/.../php5-200504251230/main/main.c:1269
end = (zend_module_entry **) 0x82a453c
#6 0x08246d2b in php_startup_internal_extensions () at
main/internal_functions_cli.c:72
No locals.
#7 0x081a13ea in php_module_startup (sf=0x828396c,
additional_modules=0x0, num_additional_modules=152)
at /home/.../php5-200504251230/main/main.c:1454
zuf = {error_function = 0x819fbb0 php_error_cb,
printf_function = 0x819f510 php_printf,
write_function = 0x81a0d70 php_body_write_wrapper, fopen_function =
0x81a0220 php_fopen_wrapper_for_zend,
message_handler = 0x81a0340 php_message_handler_for_zend,
block_interruptions = 0, unblock_interruptions = 0,
get_configuration_directive = 0x81a02f0
php_get_configuration_directive_for_zend,
ticks_function = 0x81abd60 php_run_ticks, on_timeout =
0x81a0480 php_on_timeout,
stream_open_function = 0x81a0270 php_stream_open_for_zend,
vspprintf_function = 0x81a42c0 vspprintf,
getenv_function = 0x81a7620 sapi_getenv}
zuv = {import_use_extension = 0x82576e6 .php,
import_use_extension_length = 136766146, html_errors = 1 '\001'}
#8 0x08245c9e in main (argc=1, argv=0xbbd4) at
/home/.../php5-200504251230/sapi/cli/php_cli.c:632
exit_status = 0
c = 152
file_handle = {type = 0 '\0', filename = 0x82a46f4
[EMAIL PROTECTED],
opened_path = 0xbb28 Hûÿ¿Ûs$\bÜûÿ¿`\234/@, handle = {fd =
134697609, fp = 0x8075289, stream = {handle = 0x8075289,
reader = 0x402f9c50 sys_sigabbrev+25040, closer = 0xbb34,
interactive = -1073743032}}, free_filename = 219 'Û'}
--
Edit this bug report at http://bugs.php.net/?id=32850edit=1
#32850 [Opn-Fbk]: PHP crashes on startup because zend_do_implement_interface is called with NULL
ID: 32850
Updated by: [EMAIL PROTECTED]
Reported By: [EMAIL PROTECTED]
-Status: Open
+Status: Feedback
Bug Type: SQLite related
Operating System: Debian Sarge Unstable
PHP Version: 5CVS-2005-04-27 (dev)
New Comment:
It doesn't crash for me (either, as I guess it didn't for Antony?).
So..start with the configure line you used? :)
Previous Comments:
[2005-04-28 22:46:11] [EMAIL PROTECTED]
PHP crashes in the second I invoke ./php
Like the backtrace shows it dies when loading sqlite extension because
it ends up calling zend_do_implement_interface (ce=0x82f2ca0,
iface=0x0) --- with a 0x0 NULL pointer
[2005-04-28 22:00:13] [EMAIL PROTECTED]
Any info on how to reproduce it?
[2005-04-27 12:04:51] [EMAIL PROTECTED]
Description:
#0 zend_hash_merge_ex (target=0x82f2d38, source=0x98,
pCopyConstructor=0x81d6e10 zval_add_ref, size=4,
pMergeSource=0x81c8ec0 do_inherit_constant_check, pParam=0x0) at
/home/.../php5-200504251230/Zend/zend_hash.c:818
p = (Bucket *) 0x82f2ca0
t = (void *) 0x82f4908
#1 0x081c8f79 in zend_do_implement_interface (ce=0x82f2ca0,
iface=0x0)
at /home/.../php5-200504251230/Zend/zend_compile.c:2099
No locals.
#2 0x081dbfa9 in zend_class_implements (class_entry=0x82f2ca0,
num_interfaces=2)
at /home/.../php5-200504251230/Zend/zend_API.c:1646
interface_entry = (zend_class_entry *) 0x98
ce_num = 2
impl_num = 2
interface_list = 0xb390 è#@ ¦/@\214
#3 0x080f6102 in zm_startup_sqlite (type=1, module_number=4) at
/home/.../php5-200504251230/ext/sqlite/sqlite.c:1024
No locals.
#4 0x081daf38 in zend_register_module_ex (module=0x82f0028) at
/home/.../php5-200504251230/Zend/zend_API.c:1227
lcname = 0x0
module_ptr = (zend_module_entry *) 0x82f0028
#5 0x081a0dc0 in php_startup_extensions (ptr=0x82a450c, count=152) at
/home/.../php5-200504251230/main/main.c:1269
end = (zend_module_entry **) 0x82a453c
#6 0x08246d2b in php_startup_internal_extensions () at
main/internal_functions_cli.c:72
No locals.
#7 0x081a13ea in php_module_startup (sf=0x828396c,
additional_modules=0x0, num_additional_modules=152)
at /home/.../php5-200504251230/main/main.c:1454
zuf = {error_function = 0x819fbb0 php_error_cb,
printf_function = 0x819f510 php_printf,
write_function = 0x81a0d70 php_body_write_wrapper, fopen_function =
0x81a0220 php_fopen_wrapper_for_zend,
message_handler = 0x81a0340 php_message_handler_for_zend,
block_interruptions = 0, unblock_interruptions = 0,
get_configuration_directive = 0x81a02f0
php_get_configuration_directive_for_zend,
ticks_function = 0x81abd60 php_run_ticks, on_timeout =
0x81a0480 php_on_timeout,
stream_open_function = 0x81a0270 php_stream_open_for_zend,
vspprintf_function = 0x81a42c0 vspprintf,
getenv_function = 0x81a7620 sapi_getenv}
zuv = {import_use_extension = 0x82576e6 .php,
import_use_extension_length = 136766146, html_errors = 1 '\001'}
#8 0x08245c9e in main (argc=1, argv=0xbbd4) at
/home/.../php5-200504251230/sapi/cli/php_cli.c:632
exit_status = 0
c = 152
file_handle = {type = 0 '\0', filename = 0x82a46f4
[EMAIL PROTECTED],
opened_path = 0xbb28 Hûÿ¿Ûs$\bÜûÿ¿`\234/@, handle = {fd =
134697609, fp = 0x8075289, stream = {handle = 0x8075289,
reader = 0x402f9c50 sys_sigabbrev+25040, closer = 0xbb34,
interactive = -1073743032}}, free_filename = 219 'Û'}
--
Edit this bug report at http://bugs.php.net/?id=32850edit=1
#32882 [NEW]: Stored Procedure spoils connection
From: sales at girderboot dot com
Operating system: Windows Server 2003
PHP version: 5.0.4
PHP Bug Type: MySQLi related
Bug description: Stored Procedure spoils connection
Description:
After executing a query using a stored procedure that returns a result
set, no futher queries can be executed.
SProc's that don't return a result set, or embedded SQL queries are not
affected (but even they still cannot run after a SP with a result set is
run.)
MySQL and PHP both version 5.0.4
Reproduce code:
---
$db = new mysqli('localhost','xxx','xxx','campnet');
if (!$exec = $db-query(CALL Acct_Bal(1)))
echo $db-error;
$balance = $exec-fetch_row();
$exec-close();
echo $balance[0];
echo BR;
// Second Time
if (!$exec = $db-query(CALL Acct_Bal(1)))
echo $db-error;
$balance = $exec-fetch_row();
$exec-close();
echo $balance[0];
Expected result:
Should Output the same result Twice (In this case, the accout balance):
0.00
0.00
Actual result:
--
0.00
Lost connection to MySQL server during query
Fatal error: Call to a member function fetch_row() on a non-object in
C:\Program Files\Apache Group\Apache2\htdocs\driver.php on line 40
--
Edit bug report at http://bugs.php.net/?id=32882edit=1
--
Try a CVS snapshot (php4): http://bugs.php.net/fix.php?id=32882r=trysnapshot4
Try a CVS snapshot (php5.0):
http://bugs.php.net/fix.php?id=32882r=trysnapshot50
Try a CVS snapshot (php5.1):
http://bugs.php.net/fix.php?id=32882r=trysnapshot51
Fixed in CVS:http://bugs.php.net/fix.php?id=32882r=fixedcvs
Fixed in release:http://bugs.php.net/fix.php?id=32882r=alreadyfixed
Need backtrace: http://bugs.php.net/fix.php?id=32882r=needtrace
Need Reproduce Script: http://bugs.php.net/fix.php?id=32882r=needscript
Try newer version: http://bugs.php.net/fix.php?id=32882r=oldversion
Not developer issue: http://bugs.php.net/fix.php?id=32882r=support
Expected behavior: http://bugs.php.net/fix.php?id=32882r=notwrong
Not enough info:
http://bugs.php.net/fix.php?id=32882r=notenoughinfo
Submitted twice:
http://bugs.php.net/fix.php?id=32882r=submittedtwice
register_globals:http://bugs.php.net/fix.php?id=32882r=globals
PHP 3 support discontinued: http://bugs.php.net/fix.php?id=32882r=php3
Daylight Savings:http://bugs.php.net/fix.php?id=32882r=dst
IIS Stability: http://bugs.php.net/fix.php?id=32882r=isapi
Install GNU Sed: http://bugs.php.net/fix.php?id=32882r=gnused
Floating point limitations: http://bugs.php.net/fix.php?id=32882r=float
No Zend Extensions: http://bugs.php.net/fix.php?id=32882r=nozend
MySQL Configuration Error: http://bugs.php.net/fix.php?id=32882r=mysqlcfg
#32882 [Opn]: Stored Procedure spoils connection
ID: 32882
User updated by: sales at girderboot dot com
Reported By: sales at girderboot dot com
Status: Open
Bug Type: MySQLi related
Operating System: Windows Server 2003
PHP Version: 5.0.4
New Comment:
Upgraded to latest CVS [5.1.0-dev, Apr 26 2005 04:15:08 ]
Still same Problem.
Previous Comments:
[2005-04-29 02:45:50] sales at girderboot dot com
Description:
After executing a query using a stored procedure that returns a result
set, no futher queries can be executed.
SProc's that don't return a result set, or embedded SQL queries are not
affected (but even they still cannot run after a SP with a result set is
run.)
MySQL and PHP both version 5.0.4
Reproduce code:
---
$db = new mysqli('localhost','xxx','xxx','campnet');
if (!$exec = $db-query(CALL Acct_Bal(1)))
echo $db-error;
$balance = $exec-fetch_row();
$exec-close();
echo $balance[0];
echo BR;
// Second Time
if (!$exec = $db-query(CALL Acct_Bal(1)))
echo $db-error;
$balance = $exec-fetch_row();
$exec-close();
echo $balance[0];
Expected result:
Should Output the same result Twice (In this case, the accout
balance):
0.00
0.00
Actual result:
--
0.00
Lost connection to MySQL server during query
Fatal error: Call to a member function fetch_row() on a non-object in
C:\Program Files\Apache Group\Apache2\htdocs\driver.php on line 40
--
Edit this bug report at http://bugs.php.net/?id=32882edit=1
#32852 [Opn-Asn]: Crash with singleton and __destruct when zend.ze1_compatibility_mode = On
ID: 32852 Updated by: [EMAIL PROTECTED] -Summary: Crash with singleton and __destruct Reported By: cox at idecnet dot com -Status: Open +Status: Assigned -Bug Type: Reproducible crash +Bug Type: Zend Engine 2 problem -Operating System: Linux +Operating System: * -PHP Version: 5.0.4 +PHP Version: 5CVS-2005-04-29 -Assigned To: +Assigned To: dmitry New Comment: Dmitry, if you have time, can you look into these reports with problems with zend.ze1_compatibility_mode? Some of them happen with only PHP_5_0 and some with both it and HEAD. Here's list (this bug excluded): bug #30332 bug #31828 bug #32080 Previous Comments: [2005-04-28 16:03:57] cox at idecnet dot com Not using my php.ini doesn't crash in 5.0.4, 5.0.5dev or 5.1cvs and the output match the expected. So investigating my modified settings from the original php.ini-dist, I've found that ze1_compat generates the problem: zend.ze1_compatibility_mode = On (turning it Off does not crash, well, afterall it's php5 only syntax). The other requested data: gcc-3.4.1 bison-1.875 glibc-2.3.3 [2005-04-28 13:52:55] [EMAIL PROTECTED] I still can't reproduce this. I get same result with both HEAD and PHP_5_0 branches and also with the snapshot. Does it give same result if you make sure you don't load any php.ini: sapi/cli/php -n file.php What bison version do you have installed? What compiler (and version) ? [2005-04-28 10:53:13] cox at idecnet dot com With today's CVS (5.1), it does not crash. But the output is: Output: i'm called i'm called i'm called i'm called The __destruct() function is called 4 times. With php5-STABLE-200504271035 (5.0.5dev): $ make distclean $ ./configure \ --prefix=/usr \ --with-config-file-path=/etc/php5 \ --enable-cli \ --disable-cgi \ --disable-pear \ --enable-debug Still the same output and same crash. [2005-04-28 00:25:57] [EMAIL PROTECTED] If you configure with --enable-debug (rm config.cache ./configure + your options + --enable-debug make clean make) does it still crash? Are you sure you ARE using the latest CVS? (the snapshots might not be updated again..) [2005-04-27 23:25:44] [EMAIL PROTECTED] Still works fine here. Both with HEAD and 5.0.x. 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/32852 -- Edit this bug report at http://bugs.php.net/?id=32852edit=1
#29514 [Opn-Csd]: auto_globals_jit not in php.ini
ID: 29514
Updated by: [EMAIL PROTECTED]
Reported By: holliwell at gmx dot net
-Status: Open
+Status: Closed
Bug Type: *Configuration Issues
Operating System: linux -2.4.20
PHP Version: 5.0.0
New Comment:
Committed.
Previous Comments:
[2005-04-26 16:28:03] [EMAIL PROTECTED]
Docu people doesn't have karma to add it to php.ini, can someone from
source code guys do it?
[2005-04-11 09:28:04] [EMAIL PROTECTED]
A message was sent to php-internals with a patch for php.ini here:
* http://marc.theaimsgroup.com/?l=php-devm=111204914824598
[2005-02-25 22:31:07] [EMAIL PROTECTED]
This is now documented in the PHP Manual but still needs to find its
way into php.ini-{dist|recommended)
Here's the diff:
http://cvs.php.net/diff.php/phpdoc/en/appendices/ini.xml?r1=1.11r2=1.12ty=h
[2004-08-17 18:06:18] [EMAIL PROTECTED]
Changed to docu problem, 'cos it's not documented too. Probably Zeev
can tell about Just-In-Time variables initialization, as he was the
person who implemented it.
[2004-08-03 23:59:30] holliwell at gmx dot net
Description:
Hi,
phpinfo() reports about auto_globals_jit, but this directive is neither
in php.ini-dist nor php.ini-recommended.
Regards
Friedhelm Betz
--
Edit this bug report at http://bugs.php.net/?id=29514edit=1
#30525 [Opn-Bgs]: mysql_close() fails in some situations with shared links
ID: 30525
Updated by: [EMAIL PROTECTED]
Reported By: l dot cameron2 at ugrad dot unimelb dot edu dot au
-Status: Open
+Status: Bogus
Bug Type: MySQL related
Operating System: *
PHP Version: 5.0.x and 4.x
New Comment:
Please stop reopening this, this is not a bug but just how it works.
Previous Comments:
[2005-04-29 01:56:54] l dot cameron2 at ugrad dot unimelb dot edu dot
au
Please reread the first post where I explicitly talked about shared
connection behaviour.
The bug is that when using shared connections, if you ever use
mysql_close() *and* set your links to null, your shared connections
will be closed prematurely.
As outlined above, the net result of the is that you can never call
mysql_close() on a shared connection and expect to have it work
correctly.
[2005-04-27 14:48:13] [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
When using same connection parameters no new connection will be
established by default, instead an exisiting one will be reused. Set
the optional newlink parameter to true if you want to establish more
than one physical connection.
[2005-04-27 13:25:23] kevin at hatry dot com
i just want to add a last comment to make clear that this bug is
important.
this is (i think) a much used type of program :
?php
function do_something_in_mysql () {
$link3 = mysql_connect('localhost','root','',false);
// do some common queries here
mysql_close($link3);
echo link3:; var_dump($link3);
}
$link1 = mysql_connect('localhost','root','',false);
echo link1:; var_dump($link1);
do_something_in_mysql();
// here $link1 is UNUSABLE !!
mysql_close($link1);
echo link1:; var_dump($link1);
?
fails with :
link1:resource(4) of type (mysql link)
link3:resource(4) of type (mysql link)
Warning: mysql_close(): 4 is not a valid MySQL-Link resource in ... on
line 14
link1:resource(4) of type (Unknown)
i think that closing a connection in the same environnement that it was
open (like in the function here) is good programming so it shouldn't
fail like that !
And the problem is *not* that the mysql_close closed all connections as
shown by this example :
?php
function do_something_in_mysql () {
$link3 = mysql_connect('localhost','root','',false);
echo link3:; var_dump($link3);
// do some common queries here
mysql_close($link3);
}
$link1 = mysql_connect('localhost','root','',false);
$link2 = mysql_connect('localhost','root','',false);
echo link1:; var_dump($link1);
echo link2:; var_dump($link2);
do_something_in_mysql();
// here $link1 is still USABLE
mysql_close($link1);
echo link1:; var_dump($link1);
echo link2:; var_dump($link2);
?
here there is no failure :
link1:resource(4) of type (mysql link)
link2:resource(4) of type (mysql link)
link3:resource(4) of type (mysql link)
link1:resource(4) of type (Unknown)
link2:resource(4) of type (Unknown)
there would be one if we had closed $link2 after $link1 for example.
[2004-10-22 06:19:48] l dot cameron2 at ugrad dot unimelb dot edu dot
au
Description:
Preface: I *do* understand that by default MySQL connections are shared
in PHP.
I also note that in older versions a single mysql_close() would close
all of the links; see #9107: there now there appears to be reference
counting before finally closing the TCP connection -- which is IMHO
better than the older behaviour, but the implementation has its own
bugs:
PHP appears to keeps an internal count of the number of times a link
has been duplicated. When the link count is = 0, the underlying TCP
connection is actually closed.
* close() reduces the link count by 1
* setting the connection to null *also* reduces the link count by 1 --
even if that link has already been close()d
Currently the only workarounds for this are to:
[1] Set new_link to true every time you mysql_connect() -- potentially
creating a lot of TCP connections and slowing the program down
[2] close() the link, but never set it to null and hope that PHP won't
clean it up until the end of the program: This *will* fail sometimes
though; see the example at http://www.levi.id.au/mysql4.php.txt
[3] Never mysql_close() links, only set them to null and hope that PHP
will in fact clean up the TCP connection before MySQL runs out of
available connections (admittedly only a problem when you have a lot of
simultaneous connections to your database) -- this does work now, but
we're not supposed to assume anything about when PHP does its object
destruction.
The
#31525 [Opn-Asn]: object reference being dropped. $this getting lost.
ID: 31525
Updated by: [EMAIL PROTECTED]
Reported By: yml at yml dot com
-Status: Open
+Status: Assigned
Bug Type: Zend Engine 2 problem
Operating System: *
PHP Version: 5CVS-2005-03-03
-Assigned To:
+Assigned To: andi
New Comment:
Andi, I think you once responded to similar issue regarding return()
with/without parenthesis..
Previous Comments:
[2005-03-06 05:55:37] yml at yml dot com
Problem found.
Removing all the ()'s from reference returning functions and the
problem has completely disappeared.
However, the case should be caught by the parser and a warning
generated. Using parens around returns returning references will cause
symbol table corruption occassionally ...
[2005-03-06 02:43:51] michaels at crye-leike dot com
True, if getThis() is declared to return a reference then everything
works as expected. However, looking through the original reproduce
code I noticed something else. If you add parentheses around $this in
getThis() then the unexpected behavior returns. Complete code:
?php
class Foo {
function getThis() {
return ($this);
}
function destroyThis() {
$baz = $this-getThis();
}
}
$bar = new Foo();
$bar-destroyThis();
var_dump($bar);
?
Produces:
NULL
Expected:
object(Foo)#1 (0) {
}
[2005-03-06 01:50:27] yml at yml dot com
Unfortunately the shortened script works as it should if you declare
getThis to return a reference as in
function getThis()
If however, you refer to the too-long script I put together at:
http://www.formvista.com/uploaded_files/php5_drops_object.php.txt
There is something different about it that causes $this to get dropped
even when the method is declared return-by-reference.
I haven't been able to narrow it down but it's entirely possible I'm
overlooking something obvious.
It's got to be something related to legacy pass by reference notation
=. The strange thing is it worked in 5.0.1 and broke in 5.0.2 or .3.
[2005-03-06 01:26:05] michaels at crye-leike dot com
FWIW, here's a shorter script that reproduces the problem for me on PHP
5.0.3:
?php
class Foo {
function getThis() {
return $this;
}
function destroyThis() {
$baz = $this-getThis();
}
}
$bar = new Foo();
$bar-destroyThis();
var_dump($bar);
?
This outputs:
NULL
If I change the assign-by-reference operator (=) to the normal
assignment operator (=) inside destroyThis(), I get:
object(Foo)#1 (0) {
}
Hope this helps...
[2005-03-03 18:32:24] yml at yml dot com
1. Same problem. No improvement. $this is getting dropped. Used to work
in 5.0RC2. Since 5.0.3 it's been broken.
2. The script I sent was puny. Given how terribly buggy the Zend engine
is, expecting that all serious parser errors can be reproduced in a
total of 20 lines or less is ridiculous. The meat of the script I sent
clearly reproduces the problem in 8 lines, not including the supporting
classes.
You guys wouldn't pull it from my site; and now you won't look at it if
I send it to you. Exactly what would you propose I do to help you track
this down?
The 85,000 lines of code that's actually having this problem (and
producing a coredump), now that's a huge script.
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/31525
--
Edit this bug report at http://bugs.php.net/?id=31525edit=1
#31774 [Opn-Asn]: Data missing using DirectoryIterator with ftp:// wrapper
ID: 31774
Updated by: [EMAIL PROTECTED]
Reported By: php at lachoseinteractive dot net
-Status: Open
+Status: Assigned
Bug Type: FTP related
Operating System: Linux Mac OS X
PHP Version: 5CVS-2005-03-20
-Assigned To:
+Assigned To: pollita
New Comment:
Assigned to the FTP maintainer.. :)
Previous Comments:
[2005-03-22 20:33:11] php at lachoseinteractive dot net
Same bug in php5-200503201530
[2005-02-28 20:53:47] [EMAIL PROTECTED]
Please try using this CVS snapshot:
http://snaps.php.net/php5-latest.tar.gz
For Windows:
http://snaps.php.net/win32/php5-win32-latest.zip
[2005-01-31 12:41:10] php at lachoseinteractive dot net
After more investigation, it turns out that the iterator
reconnects to the server several times for each file of
list in order to get SIZE information, etc instead of
parsing a raw list from an FTP LIST command.
Looks like DirectoryIterator needs optimization for use
with ftp wrapper.
[2005-01-31 02:32:17] php at lachoseinteractive dot net
Description:
Reading a directory with a DirectoryIterator using an
ftp wrapper doesn't work well.
Tested on 3 ftp servers. (proftp, ncftp, and ..unknown
:-/). on 3 different machines and network.
With proftp and ncftp, some items are missing from the
retrieved directory list. (whereas it works well with
readdir()), even with a directory containing no more
than 2 or 3 files. This doesn't seem to be related to
the nature of the file, but rather to its position in
the list : add a new file to the directory, and the
previously missing file would show up, while another one
is now missing.
On the third server (ftpperso.free.fr), the directory
was correctly read.
In all cases, retrieving the list is very slow, and
often fails.
Reproduce code:
---
example:
$dir = new DirectoryIterator(ftp://myftpserver.com/;);
foreach ( $dir as $f ) {
if ( $f-isDot() ) continue;
echo $f-getFilename().\n;
}
--
Edit this bug report at http://bugs.php.net/?id=31774edit=1
#31222 [Fbk-Opn]: ocicommit not working
ID: 31222 User updated by: amonw at hotmail dot com Reported By: amonw at hotmail dot com -Status: Feedback +Status: Open Bug Type: OCI8 related Operating System: * PHP Version: 4CVS-2005-04-04 Assigned To: tony2001 New Comment: Thank you for your suggestion. But I'm not ready to upgrade my system to php5 because I don't have much time to modify the old codes to fit in php5 yet. Previous Comments: [2005-04-28 12:56:06] [EMAIL PROTECTED] Please try using this CVS snapshot: http://snaps.php.net/php5-STABLE-latest.tar.gz For Windows: http://snaps.php.net/win32/php5.0-win32-latest.zip [2005-04-26 04:20:18] amonw at hotmail dot com I don't know why, but I upgrate my php again this morning to php4-stable-200504260035, and the problem remains unchanged. I have make the code as simple as possible, and as I mentioned in the first comment, even some minor changes which seem not relevant may affect the result, and I don't know why. I deeply appreciate your patiense and please read my first post again. I can live with it if you are tired of this because it takes so long. Thank you. [2005-04-05 17:55:52] [EMAIL PROTECTED] Works just perfectly for all of oci8 users except you. Try to simplify the code and to look for the problem there. [2005-04-04 09:27:40] amonw at hotmail dot com I tried the http://snaps.php.net/php4-STABLE-latest.tar.gz,which extracted to be php4-STABLE-200504040230,but the code produced the same result. [2005-03-30 23:06:56] [EMAIL PROTECTED] Please try using this CVS snapshot: http://snaps.php.net/php4-STABLE-latest.tar.gz For Windows: http://snaps.php.net/win32/php4-win32-STABLE-latest.zip 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/31222 -- Edit this bug report at http://bugs.php.net/?id=31222edit=1
#32883 [NEW]: Last character truncated from each line of post-moved file
From: jack at martinelli dot org
Operating system: Linux (Debian)
PHP version: 4.3.10
PHP Bug Type: Filesystem function related
Bug description: Last character truncated from each line of post-moved file
Description:
On Windows upload a text file, e.g.,
123
456
789
Then on the server move the uploaded file to some directory then dump the
file its:
12
45
78
Reproduce code:
---
move_uploaded_file( $_FILES[$filename],['tmp_name'], 'tmp/tmp.txt');
echo file_get_contents ('tmp/tmp.txt');
Expected result:
123
456
789
Actual result:
--
12
45
78
--
Edit bug report at http://bugs.php.net/?id=32883edit=1
--
Try a CVS snapshot (php4): http://bugs.php.net/fix.php?id=32883r=trysnapshot4
Try a CVS snapshot (php5.0):
http://bugs.php.net/fix.php?id=32883r=trysnapshot50
Try a CVS snapshot (php5.1):
http://bugs.php.net/fix.php?id=32883r=trysnapshot51
Fixed in CVS:http://bugs.php.net/fix.php?id=32883r=fixedcvs
Fixed in release:http://bugs.php.net/fix.php?id=32883r=alreadyfixed
Need backtrace: http://bugs.php.net/fix.php?id=32883r=needtrace
Need Reproduce Script: http://bugs.php.net/fix.php?id=32883r=needscript
Try newer version: http://bugs.php.net/fix.php?id=32883r=oldversion
Not developer issue: http://bugs.php.net/fix.php?id=32883r=support
Expected behavior: http://bugs.php.net/fix.php?id=32883r=notwrong
Not enough info:
http://bugs.php.net/fix.php?id=32883r=notenoughinfo
Submitted twice:
http://bugs.php.net/fix.php?id=32883r=submittedtwice
register_globals:http://bugs.php.net/fix.php?id=32883r=globals
PHP 3 support discontinued: http://bugs.php.net/fix.php?id=32883r=php3
Daylight Savings:http://bugs.php.net/fix.php?id=32883r=dst
IIS Stability: http://bugs.php.net/fix.php?id=32883r=isapi
Install GNU Sed: http://bugs.php.net/fix.php?id=32883r=gnused
Floating point limitations: http://bugs.php.net/fix.php?id=32883r=float
No Zend Extensions: http://bugs.php.net/fix.php?id=32883r=nozend
MySQL Configuration Error: http://bugs.php.net/fix.php?id=32883r=mysqlcfg
#32854 [Opn-Asn]: mssql_pconnect fails under load and doesn't recover
ID: 32854 Updated by: [EMAIL PROTECTED] Reported By: gerritgiliomee at hotmail dot com -Status: Open +Status: Assigned Bug Type: MSSQL related Operating System: Windows 2000 sp4 PHP Version: 5.0.4 -Assigned To: +Assigned To: fmk Previous Comments: [2005-04-27 13:09:17] gerritgiliomee at hotmail dot com Description: Using mssql_pconnect to connect to a MS SQL2000 server on another box. Everything works a treat until I put some load on. When I go above a certain threshhold, e.g. using Apache Benchmark, 20 concurrent users, 500 requests, mssql_pconnect fails with this error: Warning: mssql_pconnect() [function.mssql-pconnect]: Unable to connect to server: servername This is understandable as things will break above a certain point, however, after this happens, mssql_pconnect seems to have hung, even if I change the connection details, or try using mssql_connect, I still get the same error. The only thing that resolves it is restarting IIS. Using Win2K (sp4), IIS5, MS SQL 200 (sp2). PS: I have made sure I'm using the right version of ntwdblib.dll. It's also worth noting that my phpinfo() reports Library Version: 7.0 instead of the presumed 8.0. Not sure if this is connected to the SQL version though. I've toggled around and have these mssql settings in my php.ini [MSSQL] ; Allow or prevent persistent links. mssql.allow_persistent = On ; Maximum number of persistent links. -1 means no limit. mssql.max_persistent = 100 ; Maximum number of links (persistent+non persistent). -1 means no limit. mssql.max_links = 100 ; Minimum error severity to display. mssql.min_error_severity = 10 ; Minimum message severity to display. mssql.min_message_severity = 10 ; Compatability mode with old versions of PHP 3.0. mssql.compatability_mode = Off ; Connect timeout mssql.connect_timeout = 5 ; Query timeout mssql.timeout = 60 ; Valid range 0 - 2147483647. Default = 4096. mssql.textlimit = 4096 ; Valid range 0 - 2147483647. Default = 4096. mssql.textsize = 4096 ; Limits the number of records in each batch. 0 = all records in one batch. mssql.batchsize = 0 ; Specify how datetime and datetim4 columns are returned ; On = Returns data converted to SQL server settings ; Off = Returns values as -MM-DD hh:mm:ss ;DEV - used to be completely commented out mssql.datetimeconvert = Off ; Use NT authentication when connecting to the server mssql.secure_connection = Off ; Specify max number of processes. Default = 25 mssql.max_procs = 25 Any help will be much appreciated. -- Edit this bug report at http://bugs.php.net/?id=32854edit=1
