#22866 [NEW]: Variable function call on object method fails
From: tys at cs dot ualberta dot ca
Operating system: Linux
PHP version: 4.3.1
PHP Bug Type: Class/Object related
Bug description: Variable function call on object method fails
A variable function can be called on a normal function just fine:
--
function test()
{
return "test1";
}
$function = "test";
echo $function();
--
This outputs: test
However trying the same thing on a funciton inside a class will fail:
--
class Test
{
function Test()
{
}
function testClass()
{
return "test 2";
}
}
$function = "Test::testClass";
echo $function();
--
Calling:
echo Test::testClass();
works fine, however the above code does not. It should output: test 2
However it returns an error similar to the following:
Fatal error: Call to undefined function: registration::formatdate() in
/home/gaza/public_html/fp_php/support/table.php on line 396
--
Edit bug report at http://bugs.php.net/?id=22866&edit=1
--
Try a CVS snapshot: http://bugs.php.net/fix.php?id=22866&r=trysnapshot
Fixed in CVS: http://bugs.php.net/fix.php?id=22866&r=fixedcvs
Fixed in release: http://bugs.php.net/fix.php?id=22866&r=alreadyfixed
Need backtrace: http://bugs.php.net/fix.php?id=22866&r=needtrace
Try newer version: http://bugs.php.net/fix.php?id=22866&r=oldversion
Not developer issue:http://bugs.php.net/fix.php?id=22866&r=support
Expected behavior: http://bugs.php.net/fix.php?id=22866&r=notwrong
Not enough info:http://bugs.php.net/fix.php?id=22866&r=notenoughinfo
Submitted twice:http://bugs.php.net/fix.php?id=22866&r=submittedtwice
register_globals: http://bugs.php.net/fix.php?id=22866&r=globals
PHP 3 support discontinued: http://bugs.php.net/fix.php?id=22866&r=php3
Daylight Savings: http://bugs.php.net/fix.php?id=22866&r=dst
IIS Stability: http://bugs.php.net/fix.php?id=22866&r=isapi
Install GNU Sed:http://bugs.php.net/fix.php?id=22866&r=gnused
#22860 [Opn]: odbc_longreadlen() corruption problem
ID: 22860 User updated by: truth at ichaos dot com Reported By: truth at ichaos dot com Status: Open Bug Type: ODBC related Operating System: SuSE 8.0 PHP Version: 4.3.2-RC New Comment: Actually I tried this with a string that was 28968 chars long, and this it was actually 16388 chars long instead of 200. The characters beyond 4096 were corrupted. Sorry for the exagerated numbers. Previous Comments: [2003-03-24 23:52:36] truth at ichaos dot com All right, this snapshot didn't work. It's hard to write a script but here is a good try: First, a table in my IBM DB2 is created CREATE TABLE test ( ID INT, DATA CLOB(1M)); Put a string in the CLOB that is greater than 5K, and and ID = 1 or so. All right, now the script result, 1) echo strlen($result); ?> This should return the length of your string. If the odbc.defaultlrl is set to 4096, the string is 200 chars long. If odbc.defaultlrl is set to 200, the string is the correct length. [2003-03-24 23:20:19] [EMAIL PROTECTED] And can you provide a script sample, and sample schema for me to use in testing? [2003-03-24 17:31:15] [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 [2003-03-24 15:01:56] truth at ichaos dot com When odbc.defaultlrl is set to 4096 in the php.ini file, and I call odbc_longreadlen($result, 200); in my script, the data returned for that $result is padded at the end with garbage (prolly from memory). When the odbc.defaultlrl is set to 200 in the php.ini file, and I call odbc_longreadlen($result, 200); in my script, the data returned for that $result is not padded at the end with garbage, and is just fine. -- Edit this bug report at http://bugs.php.net/?id=22860&edit=1
#22860 [Fbk->Opn]: odbc_longreadlen() corruption problem
ID: 22860 User updated by: truth at ichaos dot com Reported By: truth at ichaos dot com -Status: Feedback +Status: Open Bug Type: ODBC related Operating System: SuSE 8.0 -PHP Version: 4.3.0 +PHP Version: 4.3.2-RC New Comment: All right, this snapshot didn't work. It's hard to write a script but here is a good try: First, a table in my IBM DB2 is created CREATE TABLE test ( ID INT, DATA CLOB(1M)); Put a string in the CLOB that is greater than 5K, and and ID = 1 or so. All right, now the script result, 1) echo strlen($result); ?> This should return the length of your string. If the odbc.defaultlrl is set to 4096, the string is 200 chars long. If odbc.defaultlrl is set to 200, the string is the correct length. Previous Comments: [2003-03-24 23:20:19] [EMAIL PROTECTED] And can you provide a script sample, and sample schema for me to use in testing? [2003-03-24 17:31:15] [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 [2003-03-24 15:01:56] truth at ichaos dot com When odbc.defaultlrl is set to 4096 in the php.ini file, and I call odbc_longreadlen($result, 200); in my script, the data returned for that $result is padded at the end with garbage (prolly from memory). When the odbc.defaultlrl is set to 200 in the php.ini file, and I call odbc_longreadlen($result, 200); in my script, the data returned for that $result is not padded at the end with garbage, and is just fine. -- Edit this bug report at http://bugs.php.net/?id=22860&edit=1
#22860 [Fbk]: odbc_longreadlen() corruption problem
ID: 22860 Updated by: [EMAIL PROTECTED] Reported By: truth at ichaos dot com Status: Feedback Bug Type: ODBC related Operating System: SuSE 8.0 PHP Version: 4.3.0 New Comment: And can you provide a script sample, and sample schema for me to use in testing? Previous Comments: [2003-03-24 17:31:15] [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 [2003-03-24 15:01:56] truth at ichaos dot com When odbc.defaultlrl is set to 4096 in the php.ini file, and I call odbc_longreadlen($result, 200); in my script, the data returned for that $result is padded at the end with garbage (prolly from memory). When the odbc.defaultlrl is set to 200 in the php.ini file, and I call odbc_longreadlen($result, 200); in my script, the data returned for that $result is not padded at the end with garbage, and is just fine. -- Edit this bug report at http://bugs.php.net/?id=22860&edit=1
#22864 [Opn->Bgs]: FTP error occured 450 write error: No space left on device
ID: 22864 Updated by: [EMAIL PROTECTED] Reported By: blkactor at aol dot com -Status: Open +Status: Bogus Bug Type: FTP related Operating System: Mac OS X 10.2.4 PHP Version: 4.3.1 New Comment: Well, that has nothing to do with PHP. Bogus Previous Comments: [2003-03-24 20:28:44] blkactor at aol dot com The user doesn't have permission to create a directory in the default login directory of their remote server. Since there's no FTP call to get a server's time, Dreamweaver must create a directory and read the server's timestamp to establish the time difference. This allows Dreamweaver to complete functions that involve comparing files' timestamps. Solution In order for for Dreamweaver's timestamp-related functions to work correctly, users must have permission (set by the Server Administrator) to create directories in the default login directory. -- Edit this bug report at http://bugs.php.net/?id=22864&edit=1
#22865 [NEW]: including files from higher brother dirs
From: josmith at albertc dot on dot ca Operating system: WinNT 5 and Linux PHP version: 4.3.1 PHP Bug Type: *General Issues Bug description: including files from higher brother dirs ok... index.php folder1 file1 folder2 file2 That is the dir structure. file1 'include()'s file2 and file1 is included in index. When file1 is called directly from the browser it includes file2 (by using include "../folder2/file2"). However, when file1 is included in index.php the path to file to (located in file1) must be absolute, it cannot be relative (although when fil1 is called directly the path to file2 can be relative). Using any relative path does nto appear to work in this rare case. -- Edit bug report at http://bugs.php.net/?id=22865&edit=1 -- Try a CVS snapshot: http://bugs.php.net/fix.php?id=22865&r=trysnapshot Fixed in CVS: http://bugs.php.net/fix.php?id=22865&r=fixedcvs Fixed in release: http://bugs.php.net/fix.php?id=22865&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=22865&r=needtrace Try newer version: http://bugs.php.net/fix.php?id=22865&r=oldversion Not developer issue:http://bugs.php.net/fix.php?id=22865&r=support Expected behavior: http://bugs.php.net/fix.php?id=22865&r=notwrong Not enough info:http://bugs.php.net/fix.php?id=22865&r=notenoughinfo Submitted twice:http://bugs.php.net/fix.php?id=22865&r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=22865&r=globals PHP 3 support discontinued: http://bugs.php.net/fix.php?id=22865&r=php3 Daylight Savings: http://bugs.php.net/fix.php?id=22865&r=dst IIS Stability: http://bugs.php.net/fix.php?id=22865&r=isapi Install GNU Sed:http://bugs.php.net/fix.php?id=22865&r=gnused
#19983 [Com]: Compile/Link failure w/Sablotron
ID: 19983 Comment by: sqlboy at playway dot net Reported By: dahnke at adobe dot com Status: Bogus Bug Type: Compile Failure Operating System: Mac OS X 10.2 PHP Version: 4.3.0-pre1 New Comment: This compile bug is in PHP 4.3.1 as well for the x86 platform. I was able to get PHP to build and to run under apache by installing Sablotron 0.98RC2, then condfiguring PHP with --enable-xslt --with-xslt-sablot, then before typing make, I added the -lstdc++ line to ZEND_EXTRA_LIBS in the make file. After building, apache starts ok. I'm using gcc 3.2.2, libtool 1.4.1 (1.922.2.34 2001/09/03 01:22:13) and glibc 3.2.1. Previous Comments: [2003-01-24 15:50:47] llaguno at rogers dot com Notes: fix for the libsablot.so compile errors during php-4.3.0 make: [sablotron-0.97 with php-4.3.0 on redhat linux 8.0] 1. rpm -U expat-1.95.5-1.i386.rpm 2. rpm -i sablotron-0.97-1.i386.rpm 3. rpm -i sablotron-devel-0.97-1.i386.rpm 4. rpm -e php //current version 4.2.2 5. remove the packages dependent on php-4.2.2 if preceding command fails because of dependencies 6. install httpd-2.0.44 // this fixes the error related to missing file 'instdso'. note that apache2 7. add following line to /root/.bashrc export LDFLAGS='-lstdc++' // as explained earlier in this bug report, the undefined references are in the stdc++ libraries. Pavel Hlavnicka from Ginger Alliance suggested exporting the c++ compiler flag. 7. cd /usr/local/php/php-4.3.0 8. .configure --with-apxs2=/usr/local/apache2/bin/apxs --with-mysql --with-zlib --with-dom --with-gd --enable-xslt --with-xslt-sablot --with-sablot-js 9. make 10. make install [2003-01-22 23:25:58] llaguno at rogers dot com Compile errors with Sablotron during php make on Redhat linux 8.0 I was just wondering if you can help me figure out the following errors during php make. Note that environment is as follows: expat-1.95.5-1 sablotron-0.97-1 php-4.2.2-8.0.5 (current, want to upgrade to 4.3.0) httpd-2.0.40-8 (redhat linux 8.0) The problem occurs even after I erased the php-4.2 rpm. - > cd /usr/local/php/php-4.3.0 > ./configure --enable-xslt --with-xslt-sablot --with-zlib > make ext/mysql/libmysql/my_tempnam.o: In function `my_tempnam': /usr/local/php/php-4.3.0/ext/mysql/libmysql/my_tempnam.c:103: the use of `tempnam' is dangerous, better use `mkstemp' /usr/local/lib/libsablot.so: undefined reference to `operator new[](unsigned)' /usr/local/lib/libsablot.so: undefined reference to `vtable for __cxxabiv1::__si_class_type_info' /usr/local/lib/libsablot.so: undefined reference to `operator delete(void*)' /usr/local/lib/libsablot.so: undefined reference to `__gxx_personality_v0' /usr/local/lib/libsablot.so: undefined reference to `__cxa_pure_virtual' /usr/local/lib/libsablot.so: undefined reference to `vtable for __cxxabiv1::__class_type_info' /usr/local/lib/libsablot.so: undefined reference to `operator delete[](void*)' /usr/local/lib/libsablot.so: undefined reference to `vtable for __cxxabiv1::__vmi_class_type_info' /usr/local/lib/libsablot.so: undefined reference to `operator new(unsigned)' collect2: ld returned 1 exit status make: *** [sapi/cgi/php] Error 1 > make install --> same results as above I would really appreciate your help. Thanks in advance, Manny [2002-12-27 15:07:38] rwelti at yahoo dot com Just got the first 4.3.0 release and cannot build under Solaris due to "line too long" when attempting make. That is followed, of course, with millions of undefined symbols. my configure: ./configure \ --with-apache=/apa/ \ --with-jpeg-dir=/usr/local \ --with-zlib-dir=/usr/local \ --with-jpeg-dir=/usr/local \ --with-png-dir=/usr/local \ --with-gd \ --with-oci8=/export/home/orahome \ --enable-ftp \ --enable-sockets \ --with-pdflib \ --with-ming >configure.log 2>&1 & all goes fine until attempt "make" (both solaris and gnu makes same) NO DICE. [2002-12-18 11:55:34] [EMAIL PROTECTED] The problem __really__ is, combining gcc3 and gcc2 suite, as outlined in this document: http://fink.sourceforge.net/doc/porting/preparing.php Secondly - if any warnings/errors occur as mentioned in the document above (libtool stuff), the links to patches for those are provided. PHP already has this covered. The following works: 1) configure expat, using gcc2 explicetely: CC=gcc2 \ ./configure \ --prefix=/your/prefix 2) configure libiconv, the same way: CC=gcc2 \ ./configure \ --prefix=/your/prefix 3) configure Sablotron (tested with 0.97RC2) using: CC=gcc2 \ CXX=g++2 \ ./configure \ --prefix=/your/prefix \ --with-expat-p
#22612 [Com]: POST variable names and values are garbled
ID: 22612 Comment by: dreams at apdo dot com Reported By: dave at bcs dot co dot nz Status: Bogus Bug Type: Apache related Operating System: Linux PHP Version: 4.3.2-dev New Comment: I found an error using Apache 2.0.43 with PHP 4.3.1 and the POST method under WinXP SP1: Variables retrieved get corrupted with the variable name! So a line like this: ... $pass=$_POST['pass']; echo $pass; results into a text showing "passwordenteredpass=paswordentered". I got arround this nifty bug especifying into the And now it works. I'm using IE6 win latest updates and is not the first time it happends. Who's fault? PHP? IE? php4apache2.dll ?? hope some one knows... Previous Comments: [2003-03-10 04:40:44] [EMAIL PROTECTED] Not a bug in PHP, but in IE/w2k. [2003-03-09 21:46:35] dave at bcs dot co dot nz It appears to be an IE6 under Win2K problem - MS strikes again... Everything's fine with IE6 under XP - both copies of IE6 have all the latest updates installed. Also fine from various Linux browsers. Try it out at http://www.bcs.co.nz/bug.php [2003-03-09 21:07:51] [EMAIL PROTECTED] Does this happen with any browser? Can you add the output of this command to this report if this happens with any browser: # diff -u php.ini-dist /usr/local/lib/php.ini (provided you even have a php.ini there..) [2003-03-09 20:53:57] dave at bcs dot co dot nz Configuration options are: ./configure --with-apache=/usr/src/apache_1.3.26 --disable-debug \ --enable-trans-sid --with-mysql=/usr/local/mysql --enable-magic-quotes\ --enable-xslt --with-xslt-sablot=/usr/local --with-expat-dir=/usr/local \ --with-gd --enable-gd-native-ttf --with-png-dir=/usr --with-jpeg-dir=/usr \ --with-zlib-dir=/usr --with-freetype-dir=/usr/local \ --with-openssl=/usr/local/ssl --with-imap-ssl=/usr/local/ssl \ --with-gettext --with-xml --with-mcrypt --with-imap=/usr/src/imap-2002b [2003-03-09 19:24:51] [EMAIL PROTECTED] So what was the configure line used? 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/22612 -- Edit this bug report at http://bugs.php.net/?id=22612&edit=1
#21497 [Com]: include() of XML document fails
ID: 21497 Comment by: mike at sydel dot net Reported By: polone at townnews dot com Status: Bogus Bug Type: Scripting Engine problem Operating System: RedHat Linux 6.2 PHP Version: 4.3.0 New Comment: I am also experiencing this problem. Indeed, polone is right that disabling short tags shouldn't be the solution. I say this because a lot of people are already using to simply echo variables. If they for one case also encountered the same problem as we have, then he has to rewrite the code where fail to be loaded. I'm guessing this might have to do with PHP trying to interpret the http://bugs.php.net/?id=21497&edit=1
#22864 [NEW]: FTP error occured 450 write error: No space left on device
From: blkactor at aol dot com Operating system: Mac OS X 10.2.4 PHP version: 4.3.1 PHP Bug Type: FTP related Bug description: FTP error occured 450 write error: No space left on device The user doesn't have permission to create a directory in the default login directory of their remote server. Since there's no FTP call to get a server's time, Dreamweaver must create a directory and read the server's timestamp to establish the time difference. This allows Dreamweaver to complete functions that involve comparing files' timestamps. Solution In order for for Dreamweaver's timestamp-related functions to work correctly, users must have permission (set by the Server Administrator) to create directories in the default login directory. -- Edit bug report at http://bugs.php.net/?id=22864&edit=1 -- Try a CVS snapshot: http://bugs.php.net/fix.php?id=22864&r=trysnapshot Fixed in CVS: http://bugs.php.net/fix.php?id=22864&r=fixedcvs Fixed in release: http://bugs.php.net/fix.php?id=22864&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=22864&r=needtrace Try newer version: http://bugs.php.net/fix.php?id=22864&r=oldversion Not developer issue:http://bugs.php.net/fix.php?id=22864&r=support Expected behavior: http://bugs.php.net/fix.php?id=22864&r=notwrong Not enough info:http://bugs.php.net/fix.php?id=22864&r=notenoughinfo Submitted twice:http://bugs.php.net/fix.php?id=22864&r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=22864&r=globals PHP 3 support discontinued: http://bugs.php.net/fix.php?id=22864&r=php3 Daylight Savings: http://bugs.php.net/fix.php?id=22864&r=dst IIS Stability: http://bugs.php.net/fix.php?id=22864&r=isapi Install GNU Sed:http://bugs.php.net/fix.php?id=22864&r=gnused
#5489 [Com]: Nesting level too deep
ID: 5489 Comment by: mark at hot-mail dot com Reported By: jelmer at nl dot linux dot org Status: Closed Bug Type: Scripting Engine problem Operating System: Debian Linux 2.1 PHP Version: 4.0.1 New Comment: I just played around with apache2 from my distro maker, and then I uninstalled the RPMS for everything - apache, apche2, php, apache2-mod_php, mod_php - rebooted, and now i'm getting this recursion error on everything I have installed (including phpMyAdmin) Previous Comments: [2003-01-09 01:25:42] christopher_sagx at yahoo dot com I'm getting the same error Nesting level too deep - recursive dependency? in Unknown after Inhave installed php 4.3 the latest version ! what may be the cause.. btw Im running ensim.. Chris Director http://www.chrisranjana.com [2000-07-25 07:26:24] [EMAIL PROTECTED] I am pretty sure Zeev has fixed this in the latest CVS. Please grab it or get the latest snapshot from snaps.php.net. If you still have a problem then please repost this bug. Thanks. [2000-07-10 04:05:25] jelmer at nl dot linux dot org I sometimes get a error like this: Warning: Nesting level too deep - recursive dependency? in Unknown on line 0 Fatal error: Cannot redeclare glossaryitems() in layout.php on line 7 I doesn't come up always, only about 1 of 5 requests give this output. There is no recursive dependency anywhere. Pressing reload usually solves the problem - for a moment. My include file is more as 32 Kb, could that be the problem? When the file is first read, the end of the file is not reached(a 'echo' at the end wasn't executed) -- Edit this bug report at http://bugs.php.net/?id=5489&edit=1
#22852 [Opn->Fbk]: Results returned by odbc_exec are not right
ID: 22852
Updated by: [EMAIL PROTECTED]
Reported By: craig at myschoolmates dot com
-Status: Open
+Status: Feedback
Bug Type: ODBC related
Operating System: Win XP Pro
PHP Version: 4.3.1
New Comment:
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
Previous Comments:
[2003-03-24 10:38:11] craig at myschoolmates dot com
I have a standard php installation, latest 1.3 release on a win XP box,
using ODBC to access a Paradox database.
Connection code:
$myDB = odbc_connect("llcs", "", "");
$rs = odbc_exec($myDB, $Property_SQL);
$count = 0;
To show Results, I use:
while (odbc_fetch_into($rs, $my_array)) {
?>
SQL Query example that works:
Select Firstname, Surname, Age from Users where Age=50
Returns alot of records, which is correct. I then take an example of a
record that I got back, eg: Craig, Lister, 50, and then try this SQL:
Select Firstname, Surname, Age from Users where Surname = "Lister"
That returns ONLY the first record. Eg, Andrew, Lister, 27
It seems to be only returning the first record when I search for
strings, but on numerical searches, it works fine.
You can see this at http://land.strand.serverbox.org ... use the
'Electoral Search'.
Thank you,
Craig
--
Edit this bug report at http://bugs.php.net/?id=22852&edit=1
#22851 [Opn->Fbk]: configure stops at "checking whether IMAP works... no"
ID: 22851 Updated by: [EMAIL PROTECTED] Reported By: davidp at oak dot njit dot edu -Status: Open +Status: Feedback Bug Type: IMAP related Operating System: Solaris 8 PHP Version: 4.3.1 New Comment: 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 Previous Comments: [2003-03-24 10:12:37] davidp at oak dot njit dot edu #!/bin/ksh set -o allexport PATH=/usr/local/bin/gnu:$PATH DIR=/afs/cad/solaris/apache.127.proto if [[ -d $DIR/php-4.3.1 ]]; then cd $DIR/php-4.3.1 else print "$DIR/php-4.3.1 does not exist -- exiting..." exit 0 fi ./configure \ --with-apxs=$DIR/apache/bin/apxs \ --with-ldap=/afs/cad/solaris/openldap \ --with-imap=/usr/local/imap \ --with-imap-ssl=/usr/local/ssl \ | tee -a CONFIGURE.log #-- => Configure stops at: checking whether IMAP works... no configure: error: build test failed. Please check the config.log for details. => From config.log: configure:35446: gcc -o conftest -g -O2 -D_POSIX_PTHREAD_SEMANTICS -DSOLARIS2=2 80 -DUSE_EXPAT -R/usr/ucblib -L/usr/ucblib -R/usr/local/lib/gcc-lib/sparc-sun-s olaris2.8/3.2 -L/usr/local/lib/gcc-lib/sparc-sun-solaris2.8/3.2 -R/usr/local/imaplib -L/usr/local/imaplib -R/usr/local/ssl/lib -L/usr/local/ssllib conftest.c -lcrypto -lssl -lc-client -lcrypt -lpam -lcrypt -lresolv -lm -ldl -lnsl -lsoc ket -lgcc -lcrypt 1>&5 Undefined first referenced symbol in file SSL_library_init /usr/local/imap/lib/libc-client.a(osdep.o) . . ERR_get_error /usr/local/imap/lib/libc-client.a(osdep.o) ld: fatal: Symbol referencing errors. No output written to conftest collect2: ld returned 1 exit status configure: failed program was: #line 35421 "configure" #-- => End of CONFIGURE.log: checking for IMAP support... yes checking for pam_start in -lpam... yes checking for crypt in -lcrypt... (cached) yes checking whether SSL libraries are needed for c-client... /usr/local/ssl/lib checking whether IMAP works... no #-- /usr/local/imap/lib/libc-client.a is from Univ. of Washington IMAP imap-2003.DEV.SNAP-0301171021 -- Edit this bug report at http://bugs.php.net/?id=22851&edit=1
#22850 [Opn->Bgs]: php does not work with mod_ssl
ID: 22850 Updated by: [EMAIL PROTECTED] Reported By: tobias dot mattsson at comhem dot com -Status: Open +Status: Bogus Bug Type: Apache related Operating System: Linux RH 8.0 PHP Version: 4.3.1 New Comment: Update mod_ssl to 2.8.14 which fixes some crashes they introduced in 2.8.13.. Previous Comments: [2003-03-24 14:28:47] tobias dot mattsson at comhem dot com The version of mod_ssl is 2.8.13 [2003-03-24 10:41:06] [EMAIL PROTECTED] If I remeber correctly, there was a problem with some mod_ssl version. Check if you got latest one. I might be wrong. [2003-03-24 09:51:02] tobias dot mattsson at comhem dot com ## Environment: Red hat 8.0 Openssl 0.9.7a apache 1.3.27 mod_ssl gcc 3.2 ## Description of the problem: PHP generates a segmentation fault (but no coredump) when the webserver try to execute a .php file with ssl. But if I change the AddType in httpd.conf to .php4 (or anything else), it works fine. It also works fine without SSL. Even if the .php file did not exist, I get a segmentaion fault - not a 404! The browser (mozilla) displays a alert message (document contains no data). It seems to be hung up about the file-extension .php I have not been able to create a core dump with gdb accordning to your instructions at http://bugs.php.net/bugs-generating-backtrace.php >From error_log: [Mon Mar 24 17:16:07 2003] [notice] child pid 10008 exit signal Segmentation fault (11) I have also tried openssl 0.9.6b (from RPM) and the latest CVS snapshot of PHP (php4-STABLE-200303241430) without any change. PHP:s configure line: ./configure --with-mysql --with-openssl=/usr --with-apxs=/usr/local/apache/bin/apxs -- Edit this bug report at http://bugs.php.net/?id=22850&edit=1
#22848 [Opn->Fbk]: inconsistent errors
ID: 22848 Updated by: [EMAIL PROTECTED] Reported By: themarty at hotmail dot com -Status: Open +Status: Feedback Bug Type: Unknown/Other Function Operating System: Linux Redhat PHP Version: 4.3.0 New Comment: 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 Previous Comments: [2003-03-24 07:20:12] themarty at hotmail dot com If a bug is a flaw in the code that will always result in a reproducable error by a certain act, then this is not really bug. It's very annoying nonetheless. This is the problem: Ever since we upgraded to 4.3.0 we are experiencing errors that we can't explain. Two errors are consistent in the fact that they are always the same, but in consistent in the fact that they appear - seemingly - at random. 1. is with an online form. The form consists of 9 pages and i'm using sessions to gather all the data before inserting it into a database. On average 7 people a day fill in this form and on average once every two weeks, there's one person who's data from the first two pages 'gets lost'. 2. i've written a function that will email any 'problem with a query to the database' to me and display an error on the webpage. Since i'm still developping it, i get these emails fairly often. However, sometimes the email is a big garble. I can understand any scepticism towards my programming abilities, but i'll try to make a convincing case by the following illustration: this is the part were the email is being sent to me: [php] mail( '[EMAIL PROTECTED]', 'Error in de Database', $body."\n".$getvalues."\n".$postvalues."\n\n".$computer, "From: Admin <[EMAIL PROTECTED]>\nReply-To: [EMAIL PROTECTED]"); [/php] Whatever happens before and after, i hope you agree that IF the email gets send to me, the subject should be 'Error in de Database'. It can't be different. However, in those cases where the body of my email is a garble, the subject contains fragments of what should be stored in the variable $computer. Also, another very (in my eyes convincing example) is that just 30 minutes ago something strange happened (which triggered me into responding: That Does It!! :) I've created a message system for registered users. When inserting a message into the database it inserts a timestamp generated by php (i have my reasons for not using the DATETIME type column). The timestamp is created by [php] date(YmdHis) [/php] After over 500 correct messages, today one gets inserted as date(Ymdhis). Instead of 13 it got 01 for hours. I hope this bug-report is helpfull and if anyone has experienced similar problems, i would appreciate some feedback. -- Edit this bug report at http://bugs.php.net/?id=22848&edit=1
#22863 [Ver->Bgs]: array_diff works differently than expected
ID: 22863
Updated by: [EMAIL PROTECTED]
Reported By: pieter3d at hotmail dot com
-Status: Verified
+Status: Bogus
Bug Type: Arrays related
Operating System: WinXP
PHP Version: 4.3.1
New Comment:
Oh well the code is bogus, actually the array returned is more like
this:
array(6) {
[0]=>
int(1)
[1]=>
int(2)
[5]=>
int(6)
[6]=>
int(7)
[7]=>
int(8)
[8]=>
int(9)
}
According to:
Keys are preserved! While just stop on your scripts because key 2 isn't
defined. Don't use while for this.
Not a bug, read the documentation -> Bogus.
Previous Comments:
[2003-03-24 19:04:56] [EMAIL PROTECTED]
Verified with PHP-4.3.2RC1 (UNIX and Windows NT).
[2003-03-24 18:59:41] pieter3d at hotmail dot com
When executing this code:
$a = array(1,2,3,4,5,6,7,8,9);
$b = array(3,4,5);
$test=array_diff($a,$b);
$i=0;
while($test[$i])
{
echo "$test[$i]";
$i++;
}
the result is:
1
2
The expected result of course is
1
2
6
7
8
9
--
Edit this bug report at http://bugs.php.net/?id=22863&edit=1
#22863 [Opn->Ver]: array_diff works differently than expected
ID: 22863
Updated by: [EMAIL PROTECTED]
Reported By: pieter3d at hotmail dot com
-Status: Open
+Status: Verified
Bug Type: Arrays related
Operating System: WinXP
PHP Version: 4.3.1
New Comment:
Verified with PHP-4.3.2RC1 (UNIX and Windows NT).
Previous Comments:
[2003-03-24 18:59:41] pieter3d at hotmail dot com
When executing this code:
$a = array(1,2,3,4,5,6,7,8,9);
$b = array(3,4,5);
$test=array_diff($a,$b);
$i=0;
while($test[$i])
{
echo "$test[$i]";
$i++;
}
the result is:
1
2
The expected result of course is
1
2
6
7
8
9
--
Edit this bug report at http://bugs.php.net/?id=22863&edit=1
#22863 [NEW]: array_diff works differently than expected
From: pieter3d at hotmail dot com
Operating system: WinXP
PHP version: 4.3.1
PHP Bug Type: Arrays related
Bug description: array_diff works differently than expected
When executing this code:
$a = array(1,2,3,4,5,6,7,8,9);
$b = array(3,4,5);
$test=array_diff($a,$b);
$i=0;
while($test[$i])
{
echo "$test[$i]";
$i++;
}
the result is:
1
2
The expected result of course is
1
2
6
7
8
9
--
Edit bug report at http://bugs.php.net/?id=22863&edit=1
--
Try a CVS snapshot: http://bugs.php.net/fix.php?id=22863&r=trysnapshot
Fixed in CVS: http://bugs.php.net/fix.php?id=22863&r=fixedcvs
Fixed in release: http://bugs.php.net/fix.php?id=22863&r=alreadyfixed
Need backtrace: http://bugs.php.net/fix.php?id=22863&r=needtrace
Try newer version: http://bugs.php.net/fix.php?id=22863&r=oldversion
Not developer issue:http://bugs.php.net/fix.php?id=22863&r=support
Expected behavior: http://bugs.php.net/fix.php?id=22863&r=notwrong
Not enough info:http://bugs.php.net/fix.php?id=22863&r=notenoughinfo
Submitted twice:http://bugs.php.net/fix.php?id=22863&r=submittedtwice
register_globals: http://bugs.php.net/fix.php?id=22863&r=globals
PHP 3 support discontinued: http://bugs.php.net/fix.php?id=22863&r=php3
Daylight Savings: http://bugs.php.net/fix.php?id=22863&r=dst
IIS Stability: http://bugs.php.net/fix.php?id=22863&r=isapi
Install GNU Sed:http://bugs.php.net/fix.php?id=22863&r=gnused
#22853 [Opn->Csd]: phpinfo() builds invalid XHTML code
ID: 22853 Updated by: [EMAIL PROTECTED] Reported By: rabus at users dot sourceforge dot net -Status: Open +Status: Closed Bug Type: Unknown/Other Function Operating System: Red Hat Linux 8.0 PHP Version: 5CVS-2003-03-24 (dev) New Comment: This bug has been fixed in CVS. In case this was a PHP problem, 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/. In case this was a documentation problem, the fix will show up soon at http://www.php.net/manual/. In case this was a PHP.net website problem, the change will show up on the PHP.net site and on the mirror sites in short time. Thank you for the report, and for helping us make PHP better. Previous Comments: [2003-03-24 11:05:39] rabus at users dot sourceforge dot net I know, this is a rather small bug, but nevertheless php should go with W3C's specifications imho. I compiled php as Apache 2 module. When calling my phpinfo() script, the generated HTML code contains the following line: Apache 2.0 W3C's HTML validator bothers about this line and says, 'value of attribute "name" must be a single token'. As far as I can see, the problem is the whitespace between "module_Apache" and "2.0". Happy fixing :-) -- Edit this bug report at http://bugs.php.net/?id=22853&edit=1
#22805 [Asn->Csd]: Long input fields get truncated when posted (to about 1kb)
ID: 22805 Updated by: [EMAIL PROTECTED] Reported By: M dot Hankus at ce3 dot pl -Status: Assigned +Status: Closed Bug Type: Apache2 related Operating System: Linux PHP Version: 4.3.2RC1 Assigned To: ianh New Comment: This bug has been fixed in CVS. In case this was a PHP problem, 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/. In case this was a documentation problem, the fix will show up soon at http://www.php.net/manual/. In case this was a PHP.net website problem, the change will show up on the PHP.net site and on the mirror sites in short time. Thank you for the report, and for helping us make PHP better. Previous Comments: [2003-03-21 16:36:44] [EMAIL PROTECTED] Ian said he would take a look into this problem in this weekend.. [2003-03-21 00:06:34] [EMAIL PROTECTED] This is a brand-new apache2handler bug. [2003-03-20 17:20:56] [EMAIL PROTECTED] You're sure you don't have that section?? [2003-03-20 09:25:29] M dot Hankus at ce3 dot pl According to bug #18648 my apache is configured correctly. I also compiled php 4.3.1 with apache 2.0.44 and it works fine . Something is wrong only with 4.3.2RC1+ . In 4.3.2RC adding enctype="multipart/form-data" to form solved the problem (like in bug #18648). [2003-03-20 08:04:50] [EMAIL PROTECTED] See bug #18648. That seems due to the misconfigured httpd.conf. 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/22805 -- Edit this bug report at http://bugs.php.net/?id=22805&edit=1
#22773 [Ctl]: posted form variables mixed
ID: 22773 Updated by: [EMAIL PROTECTED] Reported By: joe at mcknight dot de Status: Critical Bug Type: CGI related Operating System: Linux PHP Version: 4.3.2-RC New Comment: That means a command-line test case in tests/basic should fail as well. Previous Comments: [2003-03-24 18:17:01] [EMAIL PROTECTED] It doesn't matter. I tried two different ways, both failed. For example (otherwise default httpd.conf): AddType application/x-httpd-php .php ScriptAlias /php/ "/www/apache/cgi-bin/" Action application/x-httpd-php /php/php-cgi [2003-03-24 18:12:23] [EMAIL PROTECTED] How are you triggering the cgi? ie. what does your Apache config look like? [2003-03-24 18:06:58] [EMAIL PROTECTED] making critical (should really be fixed before 4.3.2 goes gold..) [2003-03-24 17:51:39] [EMAIL PROTECTED] I just tested again this, and could finally reproduce this. (had an old cgi binary which read wrong php.ini, stupid me..) Summary of conditions: - only happens with the regular posts (ie. when rfc1867.c is used, it works fine, or GET method) - register_globals has to be 'On' - The posted value has to be longer than one (1) character - Only the global variable gets mangled, $_POST[] array has the correct value [2003-03-18 15:36:56] joe at mcknight dot de With these pages: test.php: out.php: --- "; echo "Variable \"B1\": $B1"; ?> I get (clicking on the button): Variable "suchstr": abc&B1=OK Variable "B1": OK That means that "suchstr" got mixed with the name and value of Variable B1! Feel free to ask for more information or tell me what I'm doing wrong :-) -- Edit this bug report at http://bugs.php.net/?id=22773&edit=1
#22773 [Ctl]: posted form variables mixed
ID: 22773 Updated by: [EMAIL PROTECTED] Reported By: joe at mcknight dot de Status: Critical Bug Type: CGI related Operating System: Linux PHP Version: 4.3.2-RC New Comment: It doesn't matter. I tried two different ways, both failed. For example (otherwise default httpd.conf): AddType application/x-httpd-php .php ScriptAlias /php/ "/www/apache/cgi-bin/" Action application/x-httpd-php /php/php-cgi Previous Comments: [2003-03-24 18:12:23] [EMAIL PROTECTED] How are you triggering the cgi? ie. what does your Apache config look like? [2003-03-24 18:06:58] [EMAIL PROTECTED] making critical (should really be fixed before 4.3.2 goes gold..) [2003-03-24 17:51:39] [EMAIL PROTECTED] I just tested again this, and could finally reproduce this. (had an old cgi binary which read wrong php.ini, stupid me..) Summary of conditions: - only happens with the regular posts (ie. when rfc1867.c is used, it works fine, or GET method) - register_globals has to be 'On' - The posted value has to be longer than one (1) character - Only the global variable gets mangled, $_POST[] array has the correct value [2003-03-18 15:36:56] joe at mcknight dot de With these pages: test.php: out.php: --- "; echo "Variable \"B1\": $B1"; ?> I get (clicking on the button): Variable "suchstr": abc&B1=OK Variable "B1": OK That means that "suchstr" got mixed with the name and value of Variable B1! Feel free to ask for more information or tell me what I'm doing wrong :-) -- Edit this bug report at http://bugs.php.net/?id=22773&edit=1
#22773 [Ctl]: posted form variables mixed
ID: 22773 Updated by: [EMAIL PROTECTED] Reported By: joe at mcknight dot de Status: Critical Bug Type: CGI related Operating System: Linux PHP Version: 4.3.2-RC New Comment: How are you triggering the cgi? ie. what does your Apache config look like? Previous Comments: [2003-03-24 18:06:58] [EMAIL PROTECTED] making critical (should really be fixed before 4.3.2 goes gold..) [2003-03-24 17:51:39] [EMAIL PROTECTED] I just tested again this, and could finally reproduce this. (had an old cgi binary which read wrong php.ini, stupid me..) Summary of conditions: - only happens with the regular posts (ie. when rfc1867.c is used, it works fine, or GET method) - register_globals has to be 'On' - The posted value has to be longer than one (1) character - Only the global variable gets mangled, $_POST[] array has the correct value [2003-03-18 15:36:56] joe at mcknight dot de With these pages: test.php: out.php: --- "; echo "Variable \"B1\": $B1"; ?> I get (clicking on the button): Variable "suchstr": abc&B1=OK Variable "B1": OK That means that "suchstr" got mixed with the name and value of Variable B1! Feel free to ask for more information or tell me what I'm doing wrong :-) -- Edit this bug report at http://bugs.php.net/?id=22773&edit=1
#22854 [Opn->Fbk]: ibase_query complains that number of read/write doesn't equal count values
ID: 22854 Updated by: [EMAIL PROTECTED] Reported By: al2925 at mail dot ru -Status: Open +Status: Feedback Bug Type: InterBase related Operating System: Windows 2000 Server SP3 PHP Version: 4.3.0 New Comment: 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 Previous Comments: [2003-03-24 11:16:16] al2925 at mail dot ru I get such warning: PHP Warning: ibase_query(): Dynamic SQL Error SQL error code = -804 Count of read-write columns does not equal count of values in c:\gentle\php_includes\IbaseConnection.php(86) : runtime-created function on line 1 The query looks like ibase_query($link, 'INSERT INTO tableName (cols, ..) VALUES (cols, ?, ?, ?)', $blob0, $blob1, $blob2); All parameters are BLOBs. This happens only if the count of parameters is more than one. I'm running Firebird Superserver for Windows version 1.0.2.908 The error began to occur after I upgraded from PHP 4.3.2 Please, feel free to contact me via e-mail. -- Edit this bug report at http://bugs.php.net/?id=22854&edit=1
#22855 [Opn->Bgs]: Memory corruption when dealing with cyclic references between objects
ID: 22855
Updated by: [EMAIL PROTECTED]
Reported By: knizhnik at garret dot ru
-Status: Open
+Status: Bogus
Bug Type: Zend Engine 2 problem
Operating System: Windows and Linux
PHP Version: 4.3.1
New Comment:
Please do not submit the same bug more than once. An existing
bug report already describes this very problem. Even if you feel
that your issue is somewhat different, the resolution is likely
to be the same. Because of this, we hope you add your comments
to the existing bug instead.
Thank you for your interest in PHP.
There are at least 3 or 4 reports similar or about exactly the same
issue..so please search the bug database first.
Previous Comments:
[2003-03-24 12:06:38] knizhnik at garret dot ru
PHP is using reference counter garbage collection so it is not able to
deallocate objects with cyclic references. But
it should not be a reason for corrupting memory. The following example
cause either loosing value of object property either segmentation fault
at PHP 4.3.1 and PHP-4.3.2RC1. The fault takes place after inserting
65533
objects (0xfffd - looks like somewhere short type is used:).
In first case after inserting about 65k of objects the system reports
"PHP Notice: Undefined property:" when
accessing "opened" field in storeObject.
objByOidMap = array();
$this->opened = true;
$this->count = 0;
}
function storeObject(&$obj) {
if ($this->opened) {
if ($obj->__oid__ == 0) {
$this->count += 1;
$obj->__oid__ = $this->count;
$obj->__storage__ = &$this;
$this->objByOidMap[$obj->__oid__] = &$obj;
}
}
}
}
class Object {
var $__storage__;
var $__oid__;
}
$storage = &new Storage();
for ($i = 0; $i < 10; $i++) {
print("i=$i\n");
$obj = &new Object();
$storage->storeObject($obj);
}
?>
--
Edit this bug report at http://bugs.php.net/?id=22855&edit=1
#22773 [Ver->Ctl]: posted form variables mixed
ID: 22773 Updated by: [EMAIL PROTECTED] Reported By: joe at mcknight dot de -Status: Verified +Status: Critical Bug Type: CGI related Operating System: Linux PHP Version: 4.3.2-RC New Comment: making critical (should really be fixed before 4.3.2 goes gold..) Previous Comments: [2003-03-24 17:51:39] [EMAIL PROTECTED] I just tested again this, and could finally reproduce this. (had an old cgi binary which read wrong php.ini, stupid me..) Summary of conditions: - only happens with the regular posts (ie. when rfc1867.c is used, it works fine, or GET method) - register_globals has to be 'On' - The posted value has to be longer than one (1) character - Only the global variable gets mangled, $_POST[] array has the correct value [2003-03-18 15:36:56] joe at mcknight dot de With these pages: test.php: out.php: --- "; echo "Variable \"B1\": $B1"; ?> I get (clicking on the button): Variable "suchstr": abc&B1=OK Variable "B1": OK That means that "suchstr" got mixed with the name and value of Variable B1! Feel free to ask for more information or tell me what I'm doing wrong :-) -- Edit this bug report at http://bugs.php.net/?id=22773&edit=1
#22857 [Opn->Fbk]: OCIExecute Hangs
ID: 22857 Updated by: [EMAIL PROTECTED] Reported By: dean at vipersoft dot co dot uk -Status: Open +Status: Feedback Bug Type: OCI8 related Operating System: Linux 2.4 PHP Version: 4.3.1 New Comment: 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 First of all, those putenv()'s are useless, you need to set them in the environment before starting Apache / running CLI. It might help if you tried debugging this with gdb. # gdb /opt/php/bin/php (gdb) run yourtest.php And do that as many times as required to get it fail.. Previous Comments: [2003-03-24 14:06:01] dean at vipersoft dot co dot uk Using the sample code below to submit a number of queries to an Oracle database - about every 1 in 10 executions causes the OCIExecute function to simple "hang" for about 10 minutes before timing out. If more information is needed or any sorts of debugging is required, I will follow up to this bug with the requested information. Thanks Dean #!/opt/php/bin/php -q sample output from above when "hung" . . . Iteration 2671 before execute after execute Iteration 2672 before execute after execute Iteration 2673 before execute Notes: * Doesn't happen every time * Happens about 1 in every 10 runs of the above code * Happens from both the CLI php and through Apache * Eventually times out without finishing off its iteration -- Edit this bug report at http://bugs.php.net/?id=22857&edit=1
#21513 [Com]: shutdown functions not executed if timed out
ID: 21513 Comment by: prac1 at dynawest dot cz Reported By: ceeam at mail dot ru Status: Verified Bug Type: Scripting Engine problem Operating System: windows (only) PHP Version: 4.3.0 New Comment: The bug appears for both timeouts - by set_time_limit() and php.ini's max_execution_time. Previous Comments: [2003-03-24 17:18:23] prac1 at dynawest dot cz I have Win2000 SP2, Apache 1.3.27, PHP 4.2.2 and 4.3.0, and using this the problem appears too. [2003-02-02 15:33:25] [EMAIL PROTECTED] tests/func/005a.phpt also failed with latestest win32 snap on W2k server. [2003-01-22 22:44:36] [EMAIL PROTECTED] I can not reproduce this with PHP CGI/CLI/Apache DSO, but Steph tested the script under windows and got the same results as [EMAIL PROTECTED] did so this is definately a windows-only bug. [2003-01-22 02:09:49] ceeam at mail dot ru [EMAIL PROTECTED]: > This script works just fine for me (using CLI): > [skipped] I tested your script. The output is: PHP Fatal error: Maximum execution time of 1 second exceeded in c:\exp.php on line 16 PHP Fatal error: Maximum execution time of 1 second exceeded in c:\exp.php on line 7 "test.log" contains only one "Start" line. I tried with both my own (pretty much cleaned up) php.ini and "recommended" php.ini. I suspect it is only Windows-related problem. [2003-01-20 22:47:06] [EMAIL PROTECTED] And this is related to http://bugs.php.net/bug.php?id=14542 (and maybe to http://bugs.php.net/bug.php?id=14251 ?) 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/21513 -- Edit this bug report at http://bugs.php.net/?id=21513&edit=1
#22773 [Bgs->Ver]: posted form variables mixed
ID: 22773 Updated by: [EMAIL PROTECTED] Reported By: joe at mcknight dot de -Status: Bogus +Status: Verified Bug Type: CGI related Operating System: Linux PHP Version: 4.3.2-RC New Comment: I just tested again this, and could finally reproduce this. (had an old cgi binary which read wrong php.ini, stupid me..) Summary of conditions: - only happens with the regular posts (ie. when rfc1867.c is used, it works fine, or GET method) - register_globals has to be 'On' - The posted value has to be longer than one (1) character - Only the global variable gets mangled, $_POST[] array has the correct value Previous Comments: [2003-03-24 14:46:17] joe at mcknight dot de Hi, which of the other components involved do you think is responsible for the bug? I just need some information (a guess of you is fairly okay) in order to know where to dig further. Why don't you think that it is php related? It works with php 4.0.6 and doesn't work with at least php 4.3.1 up. That's why I thought it was a php bug. Thanks again. [2003-03-24 03:43:19] [EMAIL PROTECTED] It definately not is any PHP bug. [2003-03-23 18:54:36] joe at mcknight dot de Hi, I did another test with php 4.0.6 (cgi and --disable-all as well) and the configuration posted before. It works if I just change the php binary... Can anybody tell me if this is a PHP bug or one from apache? Thanks, Joachim [2003-03-19 18:43:36] joe at mcknight dot de Okay, this might really be an apache error. I have a small configuration that seems to be able to reproduce it for me. I see it on 4 machines now: It's one SuSE 7.3 and 3 Debian woody/testing machines. I have the following httpd.conf and no other configuration files. The configuration assumes that there is a php4.cgi in /var/www/php-cgi/. This might be a php binary compiled with --disable-all. Could somebody please test it, just to have someone who encounters this as well? Just rename your existing configuration and move my httpd.conf in. Put the scripts below in /var/www and put the php cgi binary to /var/www/php-cgi. You'll also need to set register_globals = On in the php.ini. That was sufficient for me. On test.php, enter just a single character and click on the OK button, don't hit return but use the button... Here's my httpd configuration: ServerType standalone ServerRoot /etc/apache LockFile /var/lock/apache.lock PidFile /var/run/apache.pid LoadModule config_log_module /usr/lib/apache/1.3/mod_log_config.so LoadModule mime_module /usr/lib/apache/1.3/mod_mime.so LoadModule cgi_module /usr/lib/apache/1.3/mod_cgi.so LoadModule action_module /usr/lib/apache/1.3/mod_actions.so Port 80 User www-data Group www-data AddHandler cgi-script .cgi .sh .pl DocumentRoot/var/www AddHandler php-script .php .php3 .php4 .phtml Action php-script /php-cgi/php4.cgi ErrorLog /var/log/apache/web-error.log CustomLog /var/log/apache/web-transfer.log combined Options +ExecCGI Thank you very much [2003-03-19 16:09:49] [EMAIL PROTECTED] Okay, you're pulling my leg now. I don't believe this is a real bug report at all. NOBODY else can reproduce this. So even if this was real, it's just your system that has it. The remainder of the comments for this report are too long. To view the rest of the comments, please view the bug report online at http://bugs.php.net/22773 -- Edit this bug report at http://bugs.php.net/?id=22773&edit=1
#22796 [Opn->Fbk]: -r option: no error messages unless display_startup_errors = On
ID: 22796 Updated by: [EMAIL PROTECTED] Reported By: gk at proliberty dot com -Status: Open +Status: Feedback Bug Type: CGI related Operating System: linux RH 7.2 PHP Version: 4CVS-2003-03-19 (stable) Assigned To: helly New Comment: 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 I absolutely cannot replicate the problem you've described using the latest sources. Previous Comments: [2003-03-24 16:59:21] gk at proliberty dot com OK. Now this is starting to make some sense, thanks to michael's last comment: >The message starting with "Fatal error:" goes to stdout, the other two to stderr. The whole issue here now is php.ini config. It is confusing in this particular example since there are THREE different errors for the same code input, two generated at startup, one later; two go to /dev/stderr, one to /dev/stdout. The issue is further complicated with the precedence of -c and -d options on the command line I think, but that will be discussed elsewhere [EMAIL PROTECTED] php4-STABLE-200303241830]# sapi/cli/php -c $(pwd)/php.ini-recommended -r 'f();' PHP Fatal error: Call to undefined function: f() in Command line code on line 1 The above error is generated with .ini file settings: display_startup_errors = Off display_errors = Off log_errors = On ;error_log = filename So the error_log file must default to /dev/stderr Hence, this bug should be CLOSED now since the error IS displayed, if log_erros = On. The other error messages below appear to be startup errors, require display_startup_errors=On [EMAIL PROTECTED] php4-STABLE-200303241830]# sapi/cli/php -c $(pwd)/php.ini-dist -r 'f();' [EMAIL PROTECTED] php4-STABLE-200303241830]# sapi/cli/php -c $(pwd)/php.ini-dist -i|grep php.ini Configuration File (php.ini) Path => /usr/local/src/php4-STABLE-200303241830/php.ini-dist [EMAIL PROTECTED] php4-STABLE-200303241830]# sapi/cli/php -d log_errors=1 -d error_log=/dev/stderr -d display_startup_errors=On -r 'f();' [24-Mar-2003 14:34:21] PHP Fatal error: Call to undefined function: f() in Command line code on line 1 [EMAIL PROTECTED] php4-STABLE-200303241830]# sapi/cli/php -d log_errors=1 -d error_log=/dev/stderr -d display_startup_errors=On -r 'f();' 2>/dev/null [EMAIL PROTECTED] php4-STABLE-200303241830]# sapi/cli/php -d log_errors=1 -d error_log=/dev/stderr -d display_startup_errors=1 -r 'f();' 2>/dev/null Fatal error: Call to undefined function: f() in Command line code on line 1 [EMAIL PROTECTED] php4-STABLE-200303241830]# [2003-03-24 10:37:37] michael dot mauch at gmx dot de With php4-STABLE-200303241430 (and with 4.3.1), I can get even three error messages for the same error. # sapi/cli/php -c php.ini-dist -r 'f();' Command line code(1) : Fatal error - Call to undefined function: f() # sapi/cli/php -c php.ini-recommended -r 'f();' PHP Fatal error: Call to undefined function: f() in Command line code on line 1 Command line code(1) : Fatal error - Call to undefined function: f() # sed 's/\(display_.*errors = \)Off/\1On/' php.ini-display-errors # sapi/cli/php -c php.ini-display-errors -r 'f();' PHP Fatal error: Call to undefined function: f() in Command line code on line 1 Command line code(1) : Fatal error - Call to undefined function: f() Fatal error: Call to undefined function: f() in Command line code on line 1 This last php.ini is with display_errors and display_startup_errors = On. The message starting with "Fatal error:" goes to stdout, the other two to stderr. [2003-03-24 04:12:26] [EMAIL PROTECTED] And get first the latest stable snapshot again. [2003-03-24 04:11:54] [EMAIL PROTECTED] # php -r "f();" Command line code(1) : Fatal error - Call to undefined function: f() This is what I get when using the php.ini-dist from the latest stable CVS snapshot. As you can see, we get totally different style of error messages too. Please try with the plain, unmodified php.ini-dist instead of your current php.ini. [2003-03-24 02:11:34] gk at proliberty dot com I split this bug into two; changed the title to better reflect what I have learned: it is possible to work around this bug by changing the default value of display_startup_errors in php.ini: --- #default value #display_startup_errors = Off display_startup_errors = On --- Now I get the proper error message: [EMAIL PROTECTED] php4-STABLE-200303210630]# sapi/cli/php -r "f();" Fatal error: Call to undefined function: f() in Command line code on line Fol
#22858 [Opn->Fbk]: file function fails to open relative file names...
ID: 22858
Updated by: [EMAIL PROTECTED]
Reported By: excalibur at hub dot org
-Status: Open
+Status: Feedback
Bug Type: Filesystem function related
Operating System: FreeBSD 4.8-RC
PHP Version: 4.3.1
New Comment:
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
Previous Comments:
[2003-03-24 14:38:34] excalibur at hub dot org
Hi Guy's,
Got an issue that appears to be related to some other functions but as
this one is specific to a function I figured it's due it's own bug
posting. Ran into an issue where file() does not open relative file
names, for instance:
$words_file = "./config/filter.txt";
if (@is_readable($words_file)) {
/* Read the file and iterate through the lines. */
$lines = file($words_file);
foreach ($lines as $line) {
print $line."";
}
}
I get:
Warning: file(./config/filter.txt) [function.file]: failed to create
stream: No such file or directory in
/usr/local/www/test.com/horde/lib/Text.php on line 41
Warning: Invalid argument supplied for foreach() in
/usr/local/www/test.com/horde/lib/Text.php on line 42
Yet if I specify the full path to the very same file, it works fine:
$words_file = "/usr/local/www/test.com/horde/imp/config/filter.txt";
if (@is_readable($words_file)) {
/* Read the file and iterate through the lines. */
$lines = file($words_file);
foreach ($lines as $line) {
print $line."";
}
}
The is_readable sees the file fine, but file itself fails.
--
Edit this bug report at http://bugs.php.net/?id=22858&edit=1
#22844 [Opn->Csd]: text boolean ini options set with -d do not work (on/off)
ID: 22844 Updated by: [EMAIL PROTECTED] Reported By: gk at proliberty dot com -Status: Open +Status: Closed Bug Type: CGI related Operating System: linux RH 7.2 PHP Version: 4.3.2-RC New Comment: This bug has been fixed in CVS. In case this was a PHP problem, 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/. In case this was a documentation problem, the fix will show up soon at http://www.php.net/manual/. In case this was a PHP.net website problem, the change will show up on the PHP.net site and on the mirror sites in short time. Thank you for the report, and for helping us make PHP better. sapi/cli/php -d log_errors=1 -d error_log=/dev/stderr -d display_startup_errors=On -r 'f();' 2>/dev/null Fatal error: Call to undefined function: f() in Command line code on line 1 is what I get with latest CVS meaning that the problem is indeed fixed. Previous Comments: [2003-03-24 17:08:19] gk at proliberty dot com This problem appears fixed only half way. This code example is a little bit subtle because there are two startup errors generated: one to STDOUT and one to STDERR. In the case of the STDERR message, the problem is fixed. But in the case of the STDOUT message, it is not: THIS WORKS: -d display_startup_errors=1 THIS DOESN'T: -d display_startup_errors=On [EMAIL PROTECTED] php4-STABLE-200303241830]# sapi/cli/php -d log_errors=1 -d error_log=/dev/stderr -d display_startup_errors=On -r 'f();' [24-Mar-2003 14:34:21] PHP Fatal error: Call to undefined function: f() in Command line code on line 1 [EMAIL PROTECTED] php4-STABLE-200303241830]# sapi/cli/php -d log_errors=1 -d error_log=/dev/stderr -d display_startup_errors=On -r 'f();' 2>/dev/null [EMAIL PROTECTED] php4-STABLE-200303241830]# sapi/cli/php -d log_errors=1 -d error_log=/dev/stderr -d display_startup_errors=1 -r 'f();' 2>/dev/null Fatal error: Call to undefined function: f() in Command line code on line 1 [EMAIL PROTECTED] php4-STABLE-200303241830]# [2003-03-24 13:52:27] gk at proliberty dot com This problem, as I originally posted, is more general what sniper is focusing on: it is not limited to -d option; problem is reproducible with ini_set(). Perhaps we should change the title again to: "On/Off" ini options do not work for display_error or display_startup_errors? I'm not sure if the issue applies to other options than these. sniper, have you verified the same behavior I saw with ini_set()? [2003-03-24 07:58:34] [EMAIL PROTECTED] Forgot to close ;) [2003-03-24 07:58:17] [EMAIL PROTECTED] This bug has been fixed in CVS. In case this was a PHP problem, 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/. In case this was a documentation problem, the fix will show up soon at http://www.php.net/manual/. In case this was a PHP.net website problem, the change will show up on the PHP.net site and on the mirror sites in short time. Thank you for the report, and for helping us make PHP better. [2003-03-24 05:05:13] [EMAIL PROTECTED] This is actually real bug: # php -d display_errors=1 -r "f();" <-- this works # php -d display_errors=On -r "f();" <-- this is same as setting it to 0 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/22844 -- Edit this bug report at http://bugs.php.net/?id=22844&edit=1
#22860 [Opn->Fbk]: odbc_longreadlen() corruption problem
ID: 22860 Updated by: [EMAIL PROTECTED] Reported By: truth at ichaos dot com -Status: Open +Status: Feedback Bug Type: ODBC related Operating System: SuSE 8.0 PHP Version: 4.3.0 New Comment: 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 Previous Comments: [2003-03-24 15:01:56] truth at ichaos dot com When odbc.defaultlrl is set to 4096 in the php.ini file, and I call odbc_longreadlen($result, 200); in my script, the data returned for that $result is padded at the end with garbage (prolly from memory). When the odbc.defaultlrl is set to 200 in the php.ini file, and I call odbc_longreadlen($result, 200); in my script, the data returned for that $result is not padded at the end with garbage, and is just fine. -- Edit this bug report at http://bugs.php.net/?id=22860&edit=1
#21513 [Com]: shutdown functions not executed if timed out
ID: 21513 Comment by: prac1 at dynawest dot cz Reported By: ceeam at mail dot ru Status: Verified Bug Type: Scripting Engine problem Operating System: windows (only) PHP Version: 4.3.0 New Comment: I have Win2000 SP2, Apache 1.3.27, PHP 4.2.2 and 4.3.0, and using this the problem appears too. Previous Comments: [2003-02-02 15:33:25] [EMAIL PROTECTED] tests/func/005a.phpt also failed with latestest win32 snap on W2k server. [2003-01-22 22:44:36] [EMAIL PROTECTED] I can not reproduce this with PHP CGI/CLI/Apache DSO, but Steph tested the script under windows and got the same results as [EMAIL PROTECTED] did so this is definately a windows-only bug. [2003-01-22 02:09:49] ceeam at mail dot ru [EMAIL PROTECTED]: > This script works just fine for me (using CLI): > [skipped] I tested your script. The output is: PHP Fatal error: Maximum execution time of 1 second exceeded in c:\exp.php on line 16 PHP Fatal error: Maximum execution time of 1 second exceeded in c:\exp.php on line 7 "test.log" contains only one "Start" line. I tried with both my own (pretty much cleaned up) php.ini and "recommended" php.ini. I suspect it is only Windows-related problem. [2003-01-20 22:47:06] [EMAIL PROTECTED] And this is related to http://bugs.php.net/bug.php?id=14542 (and maybe to http://bugs.php.net/bug.php?id=14251 ?) [2003-01-20 22:44:38] [EMAIL PROTECTED] This script works just fine for me (using CLI): In test.log I have now: cut Start Shutdown - function 'foo' cut Which is the expected output. Can you try this 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/21513 -- Edit this bug report at http://bugs.php.net/?id=21513&edit=1
#22844 [Csd->Opn]: text boolean ini options set with -d do not work (on/off)
ID: 22844 User updated by: gk at proliberty dot com Reported By: gk at proliberty dot com -Status: Closed +Status: Open Bug Type: CGI related Operating System: linux RH 7.2 PHP Version: 4.3.2-RC New Comment: This problem appears fixed only half way. This code example is a little bit subtle because there are two startup errors generated: one to STDOUT and one to STDERR. In the case of the STDERR message, the problem is fixed. But in the case of the STDOUT message, it is not: THIS WORKS: -d display_startup_errors=1 THIS DOESN'T: -d display_startup_errors=On [EMAIL PROTECTED] php4-STABLE-200303241830]# sapi/cli/php -d log_errors=1 -d error_log=/dev/stderr -d display_startup_errors=On -r 'f();' [24-Mar-2003 14:34:21] PHP Fatal error: Call to undefined function: f() in Command line code on line 1 [EMAIL PROTECTED] php4-STABLE-200303241830]# sapi/cli/php -d log_errors=1 -d error_log=/dev/stderr -d display_startup_errors=On -r 'f();' 2>/dev/null [EMAIL PROTECTED] php4-STABLE-200303241830]# sapi/cli/php -d log_errors=1 -d error_log=/dev/stderr -d display_startup_errors=1 -r 'f();' 2>/dev/null Fatal error: Call to undefined function: f() in Command line code on line 1 [EMAIL PROTECTED] php4-STABLE-200303241830]# Previous Comments: [2003-03-24 13:52:27] gk at proliberty dot com This problem, as I originally posted, is more general what sniper is focusing on: it is not limited to -d option; problem is reproducible with ini_set(). Perhaps we should change the title again to: "On/Off" ini options do not work for display_error or display_startup_errors? I'm not sure if the issue applies to other options than these. sniper, have you verified the same behavior I saw with ini_set()? [2003-03-24 07:58:34] [EMAIL PROTECTED] Forgot to close ;) [2003-03-24 07:58:17] [EMAIL PROTECTED] This bug has been fixed in CVS. In case this was a PHP problem, 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/. In case this was a documentation problem, the fix will show up soon at http://www.php.net/manual/. In case this was a PHP.net website problem, the change will show up on the PHP.net site and on the mirror sites in short time. Thank you for the report, and for helping us make PHP better. [2003-03-24 05:05:13] [EMAIL PROTECTED] This is actually real bug: # php -d display_errors=1 -r "f();" <-- this works # php -d display_errors=On -r "f();" <-- this is same as setting it to 0 [2003-03-24 04:55:07] gk at proliberty dot com In my php.ini file, I have: display_errors=On display_startup_errors=On In Bug #22796, I noted that display_startup_errors=On is required for proper error display using -r option; however this is a separate problem: errors not displayed if display_startup_error or display_errors is set to ANY value, with ini_set() or on the command line I demonstrate below with -d switch: [EMAIL PROTECTED] junk]$ php -d display_startup_errors=On -r "f();" [EMAIL PROTECTED] junk]$ php -d display_startup_errors=Off -r "f();" [EMAIL PROTECTED] junk]$ php -r "f();" Fatal error: Call to undefined function: f() in Command line code on line 1 [EMAIL PROTECTED] junk]$ php -d display_errors=Off -r "f();" [EMAIL PROTECTED] junk]$ php -d display_errors=On -r "f();" The same problem occurs if call ini_set() instead of using -d option: #FILE: junk.php Now, if you use boolean value instead of On/Off, it appears that if EITHER variable is set to 1, errors work but if EITHER is set to 0, they don't: [EMAIL PROTECTED] junk]$ php -d display_errors=0 -r "f();" [EMAIL PROTECTED] junk]$ php -d display_errors=1 -r "f();" Fatal error: Call to undefined function: f() in Command line code on line 1 [EMAIL PROTECTED] junk]$ php -d display_errors=On -r "f();" [EMAIL PROTECTED] junk]$ php -d display_startup_errors=1 -r "f();" Fatal error: Call to undefined function: f() in Command line code on line 1 [EMAIL PROTECTED] junk]$ php -d display_startup_errors=0 -r "f();" [EMAIL PROTECTED] junk]$ -- Edit this bug report at http://bugs.php.net/?id=22844&edit=1
#22862 [Csd->Bgs]: var_export() always prints to screen
ID: 22862 Updated by: [EMAIL PROTECTED] Reported By: valery at inbox dot ru -Status: Closed +Status: Bogus Bug Type: Variables related Operating System: Windows 2000 PHP Version: 4.3.1 New Comment: user error -> bogus. Previous Comments: [2003-03-24 16:43:22] valery at inbox dot ru sorry, i forgot to use second parameter 'true' [2003-03-24 16:34:30] valery at inbox dot ru var_export() always prints to screen regardless of the variable passed. similar to bug report #17874 but ALWAYS in opposite to it. -- Edit this bug report at http://bugs.php.net/?id=22862&edit=1
#22796 [Fbk->Opn]: -r option: no error messages unless display_startup_errors = On
ID: 22796 User updated by: gk at proliberty dot com Reported By: gk at proliberty dot com -Status: Feedback +Status: Open Bug Type: CGI related Operating System: linux RH 7.2 PHP Version: 4CVS-2003-03-19 (stable) Assigned To: helly New Comment: OK. Now this is starting to make some sense, thanks to michael's last comment: >The message starting with "Fatal error:" goes to stdout, the other two to stderr. The whole issue here now is php.ini config. It is confusing in this particular example since there are THREE different errors for the same code input, two generated at startup, one later; two go to /dev/stderr, one to /dev/stdout. The issue is further complicated with the precedence of -c and -d options on the command line I think, but that will be discussed elsewhere [EMAIL PROTECTED] php4-STABLE-200303241830]# sapi/cli/php -c $(pwd)/php.ini-recommended -r 'f();' PHP Fatal error: Call to undefined function: f() in Command line code on line 1 The above error is generated with .ini file settings: display_startup_errors = Off display_errors = Off log_errors = On ;error_log = filename So the error_log file must default to /dev/stderr Hence, this bug should be CLOSED now since the error IS displayed, if log_erros = On. The other error messages below appear to be startup errors, require display_startup_errors=On [EMAIL PROTECTED] php4-STABLE-200303241830]# sapi/cli/php -c $(pwd)/php.ini-dist -r 'f();' [EMAIL PROTECTED] php4-STABLE-200303241830]# sapi/cli/php -c $(pwd)/php.ini-dist -i|grep php.ini Configuration File (php.ini) Path => /usr/local/src/php4-STABLE-200303241830/php.ini-dist [EMAIL PROTECTED] php4-STABLE-200303241830]# sapi/cli/php -d log_errors=1 -d error_log=/dev/stderr -d display_startup_errors=On -r 'f();' [24-Mar-2003 14:34:21] PHP Fatal error: Call to undefined function: f() in Command line code on line 1 [EMAIL PROTECTED] php4-STABLE-200303241830]# sapi/cli/php -d log_errors=1 -d error_log=/dev/stderr -d display_startup_errors=On -r 'f();' 2>/dev/null [EMAIL PROTECTED] php4-STABLE-200303241830]# sapi/cli/php -d log_errors=1 -d error_log=/dev/stderr -d display_startup_errors=1 -r 'f();' 2>/dev/null Fatal error: Call to undefined function: f() in Command line code on line 1 [EMAIL PROTECTED] php4-STABLE-200303241830]# Previous Comments: [2003-03-24 10:37:37] michael dot mauch at gmx dot de With php4-STABLE-200303241430 (and with 4.3.1), I can get even three error messages for the same error. # sapi/cli/php -c php.ini-dist -r 'f();' Command line code(1) : Fatal error - Call to undefined function: f() # sapi/cli/php -c php.ini-recommended -r 'f();' PHP Fatal error: Call to undefined function: f() in Command line code on line 1 Command line code(1) : Fatal error - Call to undefined function: f() # sed 's/\(display_.*errors = \)Off/\1On/' php.ini-display-errors # sapi/cli/php -c php.ini-display-errors -r 'f();' PHP Fatal error: Call to undefined function: f() in Command line code on line 1 Command line code(1) : Fatal error - Call to undefined function: f() Fatal error: Call to undefined function: f() in Command line code on line 1 This last php.ini is with display_errors and display_startup_errors = On. The message starting with "Fatal error:" goes to stdout, the other two to stderr. [2003-03-24 04:12:26] [EMAIL PROTECTED] And get first the latest stable snapshot again. [2003-03-24 04:11:54] [EMAIL PROTECTED] # php -r "f();" Command line code(1) : Fatal error - Call to undefined function: f() This is what I get when using the php.ini-dist from the latest stable CVS snapshot. As you can see, we get totally different style of error messages too. Please try with the plain, unmodified php.ini-dist instead of your current php.ini. [2003-03-24 02:11:34] gk at proliberty dot com I split this bug into two; changed the title to better reflect what I have learned: it is possible to work around this bug by changing the default value of display_startup_errors in php.ini: --- #default value #display_startup_errors = Off display_startup_errors = On --- Now I get the proper error message: [EMAIL PROTECTED] php4-STABLE-200303210630]# sapi/cli/php -r "f();" Fatal error: Call to undefined function: f() in Command line code on line Following sniper's advice of using -n to prevent reading php.ini has the same effect for me as display_startup_errors = Off; apparently it doesn't have the same result for sniper. Odd. [2003-03-21 20:09:38] gk at proliberty dot com I built it again, per your instructions and get the same r
#22861 [Opn->Bgs]: sessions don't destroy
ID: 22861
Updated by: [EMAIL PROTECTED]
Reported By: notepad at codewalkers dot com
-Status: Open
+Status: Bogus
Bug Type: Session related
Operating System: winxp pro IIS
PHP Version: 4.3.1
New Comment:
this is not a bug in php
marking as bogus
Previous Comments:
[2003-03-24 16:32:02] notepad at codewalkers dot com
i'm so sorry.. my login function is the problem - as it's last return
value is false (blank line) i'd delete this if i knew how.. sorry
[2003-03-24 16:26:09] notepad at codewalkers dot com
i couldn't get sessions to destroy in PHP v4.3.1. - it seemed to set
the variable $_SESSION['valid_user'] even when the login form is left
blank (allowing you to login as anyone). so i made login a seperate
function, and now the login function won't return true even if it's a
valid attempt.. craziness
i was thinkin that maybe my approach is wrong, but, then nobody else
seems to be able to tell me why it doesn't work. my apologies if i'm
just blind
testdb.txt example:
myuserid|mypass
sessiontest.php example:
$value)
{
$divide = explode('|', $value);
if(($divide[0] == "$id") && ($divide[1] == "$pass"))
return true;
else
return false;
}
}
if(@login($data, $userid, $password))
{
$_SESSION['valid_user'] = $userid;
$olduser = $_SESSION['valid_user'];
$oldid = session_id();
$_COOKIE = array();
$_SESSION = array();
$_REQUEST = array();
session_destroy();
echo '';
echo 'you are logged in as '.$olduser.' : '.$oldid.'';
echo 'logout';
}
elseif(isset($userid))
echo 'could not log you in';
else
echo 'you are not logged in';
?>
userid:
password:
--
Edit this bug report at http://bugs.php.net/?id=22861&edit=1
#22862 [Opn->Csd]: var_export() always prints to screen
ID: 22862 User updated by: valery at inbox dot ru Reported By: valery at inbox dot ru -Status: Open +Status: Closed Bug Type: Variables related Operating System: Windows 2000 PHP Version: 4.3.1 New Comment: sorry, i forgot to use second parameter 'true' Previous Comments: [2003-03-24 16:34:30] valery at inbox dot ru var_export() always prints to screen regardless of the variable passed. similar to bug report #17874 but ALWAYS in opposite to it. -- Edit this bug report at http://bugs.php.net/?id=22862&edit=1
#22862 [NEW]: var_export() always prints to screen
From: valery at inbox dot ru Operating system: Windows 2000 PHP version: 4.3.1 PHP Bug Type: Variables related Bug description: var_export() always prints to screen var_export() always prints to screen regardless of the variable passed. similar to bug report #17874 but ALWAYS in opposite to it. -- Edit bug report at http://bugs.php.net/?id=22862&edit=1 -- Try a CVS snapshot: http://bugs.php.net/fix.php?id=22862&r=trysnapshot Fixed in CVS: http://bugs.php.net/fix.php?id=22862&r=fixedcvs Fixed in release: http://bugs.php.net/fix.php?id=22862&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=22862&r=needtrace Try newer version: http://bugs.php.net/fix.php?id=22862&r=oldversion Not developer issue:http://bugs.php.net/fix.php?id=22862&r=support Expected behavior: http://bugs.php.net/fix.php?id=22862&r=notwrong Not enough info:http://bugs.php.net/fix.php?id=22862&r=notenoughinfo Submitted twice:http://bugs.php.net/fix.php?id=22862&r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=22862&r=globals PHP 3 support discontinued: http://bugs.php.net/fix.php?id=22862&r=php3 Daylight Savings: http://bugs.php.net/fix.php?id=22862&r=dst IIS Stability: http://bugs.php.net/fix.php?id=22862&r=isapi Install GNU Sed:http://bugs.php.net/fix.php?id=22862&r=gnused
#22861 [Opn]: sessions don't destroy
ID: 22861
User updated by: notepad at codewalkers dot com
Reported By: notepad at codewalkers dot com
Status: Open
Bug Type: Session related
Operating System: winxp pro IIS
PHP Version: 4.3.1
New Comment:
i'm so sorry.. my login function is the problem - as it's last return
value is false (blank line) i'd delete this if i knew how.. sorry
Previous Comments:
[2003-03-24 16:26:09] notepad at codewalkers dot com
i couldn't get sessions to destroy in PHP v4.3.1. - it seemed to set
the variable $_SESSION['valid_user'] even when the login form is left
blank (allowing you to login as anyone). so i made login a seperate
function, and now the login function won't return true even if it's a
valid attempt.. craziness
i was thinkin that maybe my approach is wrong, but, then nobody else
seems to be able to tell me why it doesn't work. my apologies if i'm
just blind
testdb.txt example:
myuserid|mypass
sessiontest.php example:
$value)
{
$divide = explode('|', $value);
if(($divide[0] == "$id") && ($divide[1] == "$pass"))
return true;
else
return false;
}
}
if(@login($data, $userid, $password))
{
$_SESSION['valid_user'] = $userid;
$olduser = $_SESSION['valid_user'];
$oldid = session_id();
$_COOKIE = array();
$_SESSION = array();
$_REQUEST = array();
session_destroy();
echo '';
echo 'you are logged in as '.$olduser.' : '.$oldid.'';
echo 'logout';
}
elseif(isset($userid))
echo 'could not log you in';
else
echo 'you are not logged in';
?>
userid:
password:
--
Edit this bug report at http://bugs.php.net/?id=22861&edit=1
#22861 [NEW]: sessions don't destroy
From: notepad at codewalkers dot com
Operating system: winxp pro IIS
PHP version: 4.3.1
PHP Bug Type: Session related
Bug description: sessions don't destroy
i couldn't get sessions to destroy in PHP v4.3.1. - it seemed to set the
variable $_SESSION['valid_user'] even when the login form is left blank
(allowing you to login as anyone). so i made login a seperate function,
and now the login function won't return true even if it's a valid
attempt.. craziness
i was thinkin that maybe my approach is wrong, but, then nobody else seems
to be able to tell me why it doesn't work. my apologies if i'm just blind
testdb.txt example:
myuserid|mypass
sessiontest.php example:
$value)
{
$divide = explode('|', $value);
if(($divide[0] == "$id") && ($divide[1] == "$pass"))
return true;
else
return false;
}
}
if(@login($data, $userid, $password))
{
$_SESSION['valid_user'] = $userid;
$olduser = $_SESSION['valid_user'];
$oldid = session_id();
$_COOKIE = array();
$_SESSION = array();
$_REQUEST = array();
session_destroy();
echo '';
echo 'you are logged in as '.$olduser.' : '.$oldid.'';
echo 'logout';
}
elseif(isset($userid))
echo 'could not log you in';
else
echo 'you are not logged in';
?>
userid:
password:
--
Edit bug report at http://bugs.php.net/?id=22861&edit=1
--
Try a CVS snapshot: http://bugs.php.net/fix.php?id=22861&r=trysnapshot
Fixed in CVS: http://bugs.php.net/fix.php?id=22861&r=fixedcvs
Fixed in release: http://bugs.php.net/fix.php?id=22861&r=alreadyfixed
Need backtrace: http://bugs.php.net/fix.php?id=22861&r=needtrace
Try newer version: http://bugs.php.net/fix.php?id=22861&r=oldversion
Not developer issue:http://bugs.php.net/fix.php?id=22861&r=support
Expected behavior: http://bugs.php.net/fix.php?id=22861&r=notwrong
Not enough info:http://bugs.php.net/fix.php?id=22861&r=notenoughinfo
Submitted twice:http://bugs.php.net/fix.php?id=22861&r=submittedtwice
register_globals: http://bugs.php.net/fix.php?id=22861&r=globals
PHP 3 support discontinued: http://bugs.php.net/fix.php?id=22861&r=php3
Daylight Savings: http://bugs.php.net/fix.php?id=22861&r=dst
IIS Stability: http://bugs.php.net/fix.php?id=22861&r=isapi
Install GNU Sed:http://bugs.php.net/fix.php?id=22861&r=gnused
#22381 [Opn->Bgs]: undefined reference to `__canary_death_handler'
ID: 22381 Updated by: [EMAIL PROTECTED] Reported By: alahaye at wanadoo dot fr -Status: Open +Status: Bogus Bug Type: IMAP related Operating System: ReadHat 7.2 PHP Version: 4.3.1 New Comment: As this is not PHP bug at all -> bogus. CC=/path/to/working/gcc ./configure ..and your options.. Previous Comments: [2003-03-24 16:08:56] alahaye at wanadoo dot fr >>Note: You can override this more easily by just setting >>the CC environment variable to point to the correct gcc.. How to ? [2003-03-24 16:07:04] [EMAIL PROTECTED] Note: You can override this more easily by just setting the CC environment variable to point to the correct gcc.. [2003-03-24 15:13:22] the_systech at yahoo dot com **UPDATE** **UPDATE** **UPDATE** I managed to fix the issue on my raq 550. This fix might be useful for others running into this same issue. ON the Raq 550 imap and other binaries have been compiled using "Stackguard" which causes these "canary_death_handler" errors when you try to compile anything referencing these libraries with anything other than the stackguard gcc compiler. In the case of the raq 550 the stackguard gcc compiler is located in /usr/sg/bin/ In order to get php to compile properly on this raq 550 I had to hand edit configure searching for where it looks for gcc and change this first reference to /usr/sg/bin/gcc then all worked wonderfully. I assume that this also has the added benifit of then being protected by stackguard's system. [2003-03-24 13:49:20] the_systech at yahoo dot com I can confirm the same problem. I would guess that this is likely on a Cobalt Raq 550 as, this is the setup where I am experiencing the issue and I know that the Raq 550's have "most" of their binaries compiled with stackguard. I can compile with 4.2.3 just fine, but with 4.3.1 configure dies with the "testing IMAP" section and the config.log is more or less identical to what was posted by the original bug submittor. [2003-03-09 19:08:39] [EMAIL PROTECTED] No feedback was provided. The bug is being suspended because we assume that you are no longer experiencing the problem. If this is not the case and you are able to provide the information that was requested earlier, please do so and change the status of the bug back to "Open". Thank you. 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/22381 -- Edit this bug report at http://bugs.php.net/?id=22381&edit=1
#16263 [Com]: session.start() create new empty session file and not resume existing session
ID: 16263 Comment by: roland at lichti dot de Reported By: kur at natur dot cuni dot cz Status: No Feedback Bug Type: Session related Operating System: ANY PHP Version: 4.3.0-dev New Comment: Sorry for this rant, but I'm really pissed off: the session handling problem is reported several times and every time closed as "bogus" or "no feedback". I really think that the programming team has no clue where to look at and should reimplement the whole code related to session handling. It's going on now for at least 1 year and there is no solution in sight :-((( Previous Comments: [2003-03-10 02:39:09] kasei999 at hotmail dot com Same here, after 3 non-sleeping days and nights I found this forum. I am using win XP with php 4.3.1 + apache 1.3.27 now switching to IIS 5, the problem still exists. Would anyone please try to help? [2003-03-04 11:58:25] zorman at pina dot info same problems over here ... i'm experiencing this problem only when I redirect the page using header after the authentication is done ... it works fine on my linux computer (php 4.3.0) but fails on win2k with the same distribution ... very annoying ... [2003-02-08 14:31:45] jmaldonado at webehosting dot biz I just upgraded my servers to 4.3.0 from 4.1.2 and am now experiencing this problemSessions are behaving unpredictably in that I can no longer count on the variables I set in the session from one page load to the next... [2002-11-14 15:18:28] murray dot rennie at ec dot gc dot ca As an addendum...I put the session_start() command, along with session control code, in an include file, and included that in all scripts that required it. [2002-11-14 14:42:28] murray dot rennie at ec dot gc dot ca Redhat 7.2 or 7.3. PhP 4.1.2, Apache 1.3.23. I get something similar to this when I change session.cookie_lifetime to something other than zero, and only when connecting with IE (my version 5.5). PHP generates two session files, one has all the info I initialized with, the second just has the sessionId in it. It's as if it ignores the first session it created and makes a new one. Netscape 4.79 works properly, and when I set session.cookie_lifetime to 0 the problem goes away on IE. 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/16263 -- Edit this bug report at http://bugs.php.net/?id=16263&edit=1
#22381 [NoF->Opn]: undefined reference to `__canary_death_handler'
ID: 22381 User updated by: alahaye at wanadoo dot fr Reported By: alahaye at wanadoo dot fr -Status: No Feedback +Status: Open Bug Type: IMAP related Operating System: ReadHat 7.2 PHP Version: 4.3.1 New Comment: >>Note: You can override this more easily by just setting >>the CC environment variable to point to the correct gcc.. How to ? Previous Comments: [2003-03-24 16:07:04] [EMAIL PROTECTED] Note: You can override this more easily by just setting the CC environment variable to point to the correct gcc.. [2003-03-24 15:13:22] the_systech at yahoo dot com **UPDATE** **UPDATE** **UPDATE** I managed to fix the issue on my raq 550. This fix might be useful for others running into this same issue. ON the Raq 550 imap and other binaries have been compiled using "Stackguard" which causes these "canary_death_handler" errors when you try to compile anything referencing these libraries with anything other than the stackguard gcc compiler. In the case of the raq 550 the stackguard gcc compiler is located in /usr/sg/bin/ In order to get php to compile properly on this raq 550 I had to hand edit configure searching for where it looks for gcc and change this first reference to /usr/sg/bin/gcc then all worked wonderfully. I assume that this also has the added benifit of then being protected by stackguard's system. [2003-03-24 13:49:20] the_systech at yahoo dot com I can confirm the same problem. I would guess that this is likely on a Cobalt Raq 550 as, this is the setup where I am experiencing the issue and I know that the Raq 550's have "most" of their binaries compiled with stackguard. I can compile with 4.2.3 just fine, but with 4.3.1 configure dies with the "testing IMAP" section and the config.log is more or less identical to what was posted by the original bug submittor. [2003-03-09 19:08:39] [EMAIL PROTECTED] No feedback was provided. The bug is being suspended because we assume that you are no longer experiencing the problem. If this is not the case and you are able to provide the information that was requested earlier, please do so and change the status of the bug back to "Open". Thank you. [2003-02-23 17:35:39] [EMAIL PROTECTED] First of all, don't try outsmarting our bug system and give the feedback using the http://bugs.php.net/?id=22381&edit=2 url and your password. Second: imap-2000c is really too old, update it first. I have no idea where you have got that version which seems to be compiled using this: http://immunix.org/stackguard.html 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/22381 -- Edit this bug report at http://bugs.php.net/?id=22381&edit=1
#22381 [NoF]: undefined reference to `__canary_death_handler'
ID: 22381 Updated by: [EMAIL PROTECTED] Reported By: alahaye at wanadoo dot fr Status: No Feedback Bug Type: IMAP related Operating System: ReadHat 7.2 PHP Version: 4.3.1 New Comment: Note: You can override this more easily by just setting the CC environment variable to point to the correct gcc.. Previous Comments: [2003-03-24 15:13:22] the_systech at yahoo dot com **UPDATE** **UPDATE** **UPDATE** I managed to fix the issue on my raq 550. This fix might be useful for others running into this same issue. ON the Raq 550 imap and other binaries have been compiled using "Stackguard" which causes these "canary_death_handler" errors when you try to compile anything referencing these libraries with anything other than the stackguard gcc compiler. In the case of the raq 550 the stackguard gcc compiler is located in /usr/sg/bin/ In order to get php to compile properly on this raq 550 I had to hand edit configure searching for where it looks for gcc and change this first reference to /usr/sg/bin/gcc then all worked wonderfully. I assume that this also has the added benifit of then being protected by stackguard's system. [2003-03-24 13:49:20] the_systech at yahoo dot com I can confirm the same problem. I would guess that this is likely on a Cobalt Raq 550 as, this is the setup where I am experiencing the issue and I know that the Raq 550's have "most" of their binaries compiled with stackguard. I can compile with 4.2.3 just fine, but with 4.3.1 configure dies with the "testing IMAP" section and the config.log is more or less identical to what was posted by the original bug submittor. [2003-03-09 19:08:39] [EMAIL PROTECTED] No feedback was provided. The bug is being suspended because we assume that you are no longer experiencing the problem. If this is not the case and you are able to provide the information that was requested earlier, please do so and change the status of the bug back to "Open". Thank you. [2003-02-23 17:35:39] [EMAIL PROTECTED] First of all, don't try outsmarting our bug system and give the feedback using the http://bugs.php.net/?id=22381&edit=2 url and your password. Second: imap-2000c is really too old, update it first. I have no idea where you have got that version which seems to be compiled using this: http://immunix.org/stackguard.html [2003-02-23 06:32:02] alahaye at wanadoo dot Fr Hi, I try with --enable-libgcc and get same error. Here my complete compilation line ./configure --prefix=/usr --with-apxs=/usr/sbin/apxs --enable-safe-mode --with-config-file-path=/etc/httpd/4.3.1 --with-exec-dir=/usr/bin --with-zlib --enable-magic-quotes --with-regex=system --enable-track-vars --with-iconv --enable-xml --disable-debug --with-gd --enable-mbstring --enable-mbstring --enable-exif --with-mcrypt=shared --with-interbase=shared --with-mysql=shared --with-pgsql=shared --with-ldap --with-imap --with-openssl=/usr --with-jpeg-dir=/usr --with-png-dir=/usr --with-gettext=shared --with-imap-ssl --disable-mbstr-enc-trans --enable-sockets --enable-ftp --enable-bcmath --enable-libgcc iliaa, you can notice that i have both --with-imap and --with-imap-ssl. This configuration line works great with PHP4.2.3 but not for PHP4.3.1 The c-client was the REDHAT Package (see my config.log) /usr/src/redhat/BUILD/imap-2000c/c-client/mail.c Same bug is report on bug 22353 on Solaris 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/22381 -- Edit this bug report at http://bugs.php.net/?id=22381&edit=1
#22833 [Csd]: Limitations of deprecating call time pass by reference
ID: 22833
Updated by: [EMAIL PROTECTED]
Reported By: rainmaker at omenmedia dot com
Status: Closed
Bug Type: Feature/Change Request
Operating System: Windows 2000
PHP Version: 4.3.1
New Comment:
Yes, it won't be fixed in ZE1.
Previous Comments:
[2003-03-24 15:30:28] rainmaker at omenmedia dot com
Just for clarification there (for anyone else reading this report), I
believe sniper is saying it's fixed in 5.0.0-dev aka PHP5 aka Zend
Engine 2. So we still have no idea when ZE2 will be ready... and no
chance of having this fixed in ZE1?
[2003-03-24 03:45:10] [EMAIL PROTECTED]
It already is fixed, AFAIK.
[2003-03-23 20:55:32] rainmaker at omenmedia dot com
Ok, after doing some research it appears that this is a fixed
limitation of Zend Engine 1, correct? I've seen info saying that this
will be fixed in Zend Engine 2... any ideas when that will be ready?
[2003-03-23 19:57:32] rainmaker at omenmedia dot com
Actually, what I neglected to mention before was that whereas there are
possible ways around this problem when using functions or methods, it
is the *constructor* function of a class where the most potential
problems are encountered.
[2003-03-23 18:24:22] rainmaker at omenmedia dot com
Firstly, I'll apologise in advance if this issue has been raised
before, but I think I have a valid point here, please hear me out...
When testing some code on another server the other day, I was presented
with quite a few errors relating to call time pass by reference. I
have never seen these errors when developing locally as the server I
use has allow_call_time_pass_reference set to on (as part of the dist
PHP ini).
Going through my code I found the problems it was referring to: a
couple of occasions where I was passing in a value by reference into a
function, where the function definition did not explicitly specify the
argument to be passed by reference. I went about correcting this,
however discovered some limitations with function definition references
and the current PHP engine.
These limitations relate primarily to the fact that you cannot specify
a default value for a reference argument in a function definition,
thereby making the argument *required* and non-optional. This is a
huge issue.
For example, I have a class called StringWriter which takes one
argument (a string) through the constructor. Now, this argument is
*supposed* to be optional, however it also could be (and indeed often
is) a reference to a string somewhere else. If I recode this class to
satisfy the deprecated call time reference passing requirements, more
problems are created:
With call time references, this is all fine:
$writer = new StringWriter();
$writer = new StringWriter("string");
$writer = new StringWriter($aString);
$writer = new StringWriter(&$anotherString);
However without them:
$writer = new StringWriter(); // ERROR, argument required
$writer = new StringWriter("string"); // Fine
$writer = new StringWriter($aString); // Fine
$writer = new StringWriter(&$anotherString); // ERROR (obviously)
In this case, where the argument could equally be a reference or a
non-reference, the user is forced to create the object like this:
$writer = new StringWriter("");
...to avoid an error, which is a PITA if you ask me. Surely the fact
that we are now 'forced' to code without using call time references,
and yet cannot under any circumstances specify that a reference
argument is optional (with a default value) is a huge limitation?
And also, doesn't it make *more* sense to allow the developer to decide
whether they want to pass a value or a reference? I'm not sure of the
technical issues (i.e. zend engine) surrounding call time passed
references, but to me, unless function definition reference arguments
can be made optional, call time passed references just seem to make a
whole lot more sense.
Because some of my code under the current circumstances *requires* call
time passed references, I'm pretty much forced to inform anybody who
uses my code that they must modify their ini to allow them... not good.
Please don't "bogus" this report because I feel this is a huge issue
that need to be addressed.
Thanks.
--
Edit this bug report at http://bugs.php.net/?id=22833&edit=1
#17516 [Csd->Opn]: overriding constants in config.w32.h.in
ID: 17516
Updated by: [EMAIL PROTECTED]
Reported By: [EMAIL PROTECTED]
-Status: Closed
+Status: Open
-Bug Type: Feature/Change Request
+Bug Type: *Configuration Issues
Operating System: Windows
PHP Version: 4.0CVS-2002-05-29
Assigned To: ssb
New Comment:
Reopened, should maybe be marked as critical:
Setting the environment variables has no effect or strange effects) on
PHP constants on Win32. This might be the main cause for pear
installations failing on windows if php is not installed in c:\php4
(and for PEAR BETA status on Win32).
In the following test script
- PHP_BINDIR is set in the environment
- The setting does not get reflected in the PHP constant
- Mistriously it's not read correctly by getenv()
test script (dos shell):
set PHP_BINDIR="my_php_bindir"
set PHP_BINDIR
cli\php -r "echo PHP_BINDIR;"
cli\php -r "echo getenv('PHP_BINDIR');"
Previous Comments:
[2002-10-07 20:15:40] [EMAIL PROTECTED]
This bug has been fixed in CVS.
In case this was a PHP problem, 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/.
In case this was a documentation problem, the fix will show up soon at
http://www.php.net/manual/.
In case this was a PHP.net website problem, the change will show
up on the PHP.net site and on the mirror sites in short time.
Thank you for the report, and for helping us make PHP better.
Here's the new code. If you have MSVC installed, please try building
and test if you can actually set these PHP constants through
environment.
#define CONDENV(ev,def) (getenv(ev)!=NULL?getenv(ev):def)
#define CONFIGURATION_FILE_PATH "php.ini"
#define PEAR_INSTALLDIR CONDENV("PEAR_INSTALLDIR",
"c:\\php4\\pear")
#define PHP_BINDIR CONDENV("PHP_BINDIR", "c:\\php4")
#define PHP_CONFIG_FILE_PATH CONDENV("SystemRoot", "")
#define PHP_CONFIG_FILE_SCAN_DIR CONDENV("PHP_CONFIG_FILE_SCAN_DIR",
"")
#define PHP_DATADIR CONDENV("PHP_DATADIR", "c:\\php4")
#define PHP_EXTENSION_DIRCONDENV("PHP_EXTENSION_DIR",
"c:\\php4")
#define PHP_INCLUDE_PATH CONDENV("PHP_INCLUDE_PATH",
".;c:\\php4\\pear")
#define PHP_LIBDIR CONDENV("PHP_LIBDIR", "c:\\php4")
#define PHP_LOCALSTATEDIRCONDENV("PHP_LOCALSTATEDIR",
"c:\\php4")
#define PHP_PREFIX CONDENV("PHP_PREFIX", "c:\\php4")
#define PHP_SYSCONFDIR CONDENV("PHP_SYSCONFDIR", "c:\\php4")
[2002-05-29 16:52:31] [EMAIL PROTECTED]
While working with PEAR installer it occurred that the pear.ini setting
file got placed in a newly created directory c:\php4. This dir is
hardcoded in:
http://cvs.php.net/co.php/php4/main/config.w32.h.in
To respect other php installations like in c:\php or c:\programme\php
one need a feature to override the constants given by the php core:
http://www.php.net/manual/en/reserved.constants.core.php
Since scripts in PEAR are designed using these constants, and constants
are not variable, there is probably only one way to override these
values in config.w32.h.in e.g. like:
#define PHP_SYSCONFDIR ( (getenv("PHP_SYSCONFDIR") != "c:\\php4" ) ?
getenv("PHP_SYSCONFDIR" ) : "c:\\php4" )
This allows the user to configure its paths by hand through setting the
environment variables like:
c:\>set PHP_SYSCONFDIR=c:\php
I propose to do this switch for all path related constants in
config.w32.h.in [DIRECTORY_SEPARATOR, PHP_SYSCONFDIR,
DEFAULT_INCLUDE_PATH, PEAR_INSTALL_DIR, PEAR_EXTENSION_DIR,
PHP_EXTENSION_DIR, PHP_BINDIR, PHP_LIBDIR, PHP_DATADIR, PHP_SYSCONFDIR,
PHP_LOCALSTATEDIR, PHP_CONFIG_FILE_PATH].
-urs
--
Edit this bug report at http://bugs.php.net/?id=17516&edit=1
#22833 [Csd]: Limitations of deprecating call time pass by reference
ID: 22833
User updated by: rainmaker at omenmedia dot com
Reported By: rainmaker at omenmedia dot com
Status: Closed
Bug Type: Feature/Change Request
Operating System: Windows 2000
-PHP Version: 5.0.0-dev
+PHP Version: 4.3.1
New Comment:
Just for clarification there (for anyone else reading this report), I
believe sniper is saying it's fixed in 5.0.0-dev aka PHP5 aka Zend
Engine 2. So we still have no idea when ZE2 will be ready... and no
chance of having this fixed in ZE1?
Previous Comments:
[2003-03-24 03:45:10] [EMAIL PROTECTED]
It already is fixed, AFAIK.
[2003-03-23 20:55:32] rainmaker at omenmedia dot com
Ok, after doing some research it appears that this is a fixed
limitation of Zend Engine 1, correct? I've seen info saying that this
will be fixed in Zend Engine 2... any ideas when that will be ready?
[2003-03-23 19:57:32] rainmaker at omenmedia dot com
Actually, what I neglected to mention before was that whereas there are
possible ways around this problem when using functions or methods, it
is the *constructor* function of a class where the most potential
problems are encountered.
[2003-03-23 18:24:22] rainmaker at omenmedia dot com
Firstly, I'll apologise in advance if this issue has been raised
before, but I think I have a valid point here, please hear me out...
When testing some code on another server the other day, I was presented
with quite a few errors relating to call time pass by reference. I
have never seen these errors when developing locally as the server I
use has allow_call_time_pass_reference set to on (as part of the dist
PHP ini).
Going through my code I found the problems it was referring to: a
couple of occasions where I was passing in a value by reference into a
function, where the function definition did not explicitly specify the
argument to be passed by reference. I went about correcting this,
however discovered some limitations with function definition references
and the current PHP engine.
These limitations relate primarily to the fact that you cannot specify
a default value for a reference argument in a function definition,
thereby making the argument *required* and non-optional. This is a
huge issue.
For example, I have a class called StringWriter which takes one
argument (a string) through the constructor. Now, this argument is
*supposed* to be optional, however it also could be (and indeed often
is) a reference to a string somewhere else. If I recode this class to
satisfy the deprecated call time reference passing requirements, more
problems are created:
With call time references, this is all fine:
$writer = new StringWriter();
$writer = new StringWriter("string");
$writer = new StringWriter($aString);
$writer = new StringWriter(&$anotherString);
However without them:
$writer = new StringWriter(); // ERROR, argument required
$writer = new StringWriter("string"); // Fine
$writer = new StringWriter($aString); // Fine
$writer = new StringWriter(&$anotherString); // ERROR (obviously)
In this case, where the argument could equally be a reference or a
non-reference, the user is forced to create the object like this:
$writer = new StringWriter("");
...to avoid an error, which is a PITA if you ask me. Surely the fact
that we are now 'forced' to code without using call time references,
and yet cannot under any circumstances specify that a reference
argument is optional (with a default value) is a huge limitation?
And also, doesn't it make *more* sense to allow the developer to decide
whether they want to pass a value or a reference? I'm not sure of the
technical issues (i.e. zend engine) surrounding call time passed
references, but to me, unless function definition reference arguments
can be made optional, call time passed references just seem to make a
whole lot more sense.
Because some of my code under the current circumstances *requires* call
time passed references, I'm pretty much forced to inform anybody who
uses my code that they must modify their ini to allow them... not good.
Please don't "bogus" this report because I feel this is a huge issue
that need to be addressed.
Thanks.
--
Edit this bug report at http://bugs.php.net/?id=22833&edit=1
#22381 [Com]: undefined reference to `__canary_death_handler'
ID: 22381 Comment by: the_systech at yahoo dot com Reported By: alahaye at wanadoo dot fr Status: No Feedback Bug Type: IMAP related Operating System: ReadHat 7.2 PHP Version: 4.3.1 New Comment: **UPDATE** **UPDATE** **UPDATE** I managed to fix the issue on my raq 550. This fix might be useful for others running into this same issue. ON the Raq 550 imap and other binaries have been compiled using "Stackguard" which causes these "canary_death_handler" errors when you try to compile anything referencing these libraries with anything other than the stackguard gcc compiler. In the case of the raq 550 the stackguard gcc compiler is located in /usr/sg/bin/ In order to get php to compile properly on this raq 550 I had to hand edit configure searching for where it looks for gcc and change this first reference to /usr/sg/bin/gcc then all worked wonderfully. I assume that this also has the added benifit of then being protected by stackguard's system. Previous Comments: [2003-03-24 13:49:20] the_systech at yahoo dot com I can confirm the same problem. I would guess that this is likely on a Cobalt Raq 550 as, this is the setup where I am experiencing the issue and I know that the Raq 550's have "most" of their binaries compiled with stackguard. I can compile with 4.2.3 just fine, but with 4.3.1 configure dies with the "testing IMAP" section and the config.log is more or less identical to what was posted by the original bug submittor. [2003-03-09 19:08:39] [EMAIL PROTECTED] No feedback was provided. The bug is being suspended because we assume that you are no longer experiencing the problem. If this is not the case and you are able to provide the information that was requested earlier, please do so and change the status of the bug back to "Open". Thank you. [2003-02-23 17:35:39] [EMAIL PROTECTED] First of all, don't try outsmarting our bug system and give the feedback using the http://bugs.php.net/?id=22381&edit=2 url and your password. Second: imap-2000c is really too old, update it first. I have no idea where you have got that version which seems to be compiled using this: http://immunix.org/stackguard.html [2003-02-23 06:32:02] alahaye at wanadoo dot Fr Hi, I try with --enable-libgcc and get same error. Here my complete compilation line ./configure --prefix=/usr --with-apxs=/usr/sbin/apxs --enable-safe-mode --with-config-file-path=/etc/httpd/4.3.1 --with-exec-dir=/usr/bin --with-zlib --enable-magic-quotes --with-regex=system --enable-track-vars --with-iconv --enable-xml --disable-debug --with-gd --enable-mbstring --enable-mbstring --enable-exif --with-mcrypt=shared --with-interbase=shared --with-mysql=shared --with-pgsql=shared --with-ldap --with-imap --with-openssl=/usr --with-jpeg-dir=/usr --with-png-dir=/usr --with-gettext=shared --with-imap-ssl --disable-mbstr-enc-trans --enable-sockets --enable-ftp --enable-bcmath --enable-libgcc iliaa, you can notice that i have both --with-imap and --with-imap-ssl. This configuration line works great with PHP4.2.3 but not for PHP4.3.1 The c-client was the REDHAT Package (see my config.log) /usr/src/redhat/BUILD/imap-2000c/c-client/mail.c Same bug is report on bug 22353 on Solaris [2003-02-22 22:41:26] [EMAIL PROTECTED] 1. Try adding '--enable-libgcc' to your configure line 2. Did you compile libc-client.a yourself? 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/22381 -- Edit this bug report at http://bugs.php.net/?id=22381&edit=1
#22860 [NEW]: odbc_longreadlen() corruption problem
From: truth at ichaos dot com Operating system: SuSE 8.0 PHP version: 4.3.0 PHP Bug Type: ODBC related Bug description: odbc_longreadlen() corruption problem When odbc.defaultlrl is set to 4096 in the php.ini file, and I call odbc_longreadlen($result, 200); in my script, the data returned for that $result is padded at the end with garbage (prolly from memory). When the odbc.defaultlrl is set to 200 in the php.ini file, and I call odbc_longreadlen($result, 200); in my script, the data returned for that $result is not padded at the end with garbage, and is just fine. -- Edit bug report at http://bugs.php.net/?id=22860&edit=1 -- Try a CVS snapshot: http://bugs.php.net/fix.php?id=22860&r=trysnapshot Fixed in CVS: http://bugs.php.net/fix.php?id=22860&r=fixedcvs Fixed in release: http://bugs.php.net/fix.php?id=22860&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=22860&r=needtrace Try newer version: http://bugs.php.net/fix.php?id=22860&r=oldversion Not developer issue:http://bugs.php.net/fix.php?id=22860&r=support Expected behavior: http://bugs.php.net/fix.php?id=22860&r=notwrong Not enough info:http://bugs.php.net/fix.php?id=22860&r=notenoughinfo Submitted twice:http://bugs.php.net/fix.php?id=22860&r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=22860&r=globals PHP 3 support discontinued: http://bugs.php.net/fix.php?id=22860&r=php3 Daylight Savings: http://bugs.php.net/fix.php?id=22860&r=dst IIS Stability: http://bugs.php.net/fix.php?id=22860&r=isapi Install GNU Sed:http://bugs.php.net/fix.php?id=22860&r=gnused
#22859 [NEW]: Too many extensions in php.ini-dist and php.ini-recommended
From: cg at gordimer dot net Operating system: Win32 PHP version: 4.3.2RC1 PHP Bug Type: PHP options/info functions Bug description: Too many extensions in php.ini-dist and php.ini-recommended The following extensions are not/no more in the windows distribution but appear in php.ini: ;extension=php_fbsql.dll ;extension=php_gd.dll --> replaced by php_gd2.dll ;extension=php_iisfunc.dll ;extension=php_printer.dll The following extension does crash on windows (and should be removed or repaired - see post on php.qa from today): ;extension=php_fdf.dll Christoph -- Edit bug report at http://bugs.php.net/?id=22859&edit=1 -- Try a CVS snapshot: http://bugs.php.net/fix.php?id=22859&r=trysnapshot Fixed in CVS: http://bugs.php.net/fix.php?id=22859&r=fixedcvs Fixed in release: http://bugs.php.net/fix.php?id=22859&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=22859&r=needtrace Try newer version: http://bugs.php.net/fix.php?id=22859&r=oldversion Not developer issue:http://bugs.php.net/fix.php?id=22859&r=support Expected behavior: http://bugs.php.net/fix.php?id=22859&r=notwrong Not enough info:http://bugs.php.net/fix.php?id=22859&r=notenoughinfo Submitted twice:http://bugs.php.net/fix.php?id=22859&r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=22859&r=globals PHP 3 support discontinued: http://bugs.php.net/fix.php?id=22859&r=php3 Daylight Savings: http://bugs.php.net/fix.php?id=22859&r=dst IIS Stability: http://bugs.php.net/fix.php?id=22859&r=isapi Install GNU Sed:http://bugs.php.net/fix.php?id=22859&r=gnused
#22773 [Bgs]: posted form variables mixed
ID: 22773 User updated by: joe at mcknight dot de Reported By: joe at mcknight dot de Status: Bogus Bug Type: CGI related Operating System: Linux PHP Version: 4.3.2-RC New Comment: Hi, which of the other components involved do you think is responsible for the bug? I just need some information (a guess of you is fairly okay) in order to know where to dig further. Why don't you think that it is php related? It works with php 4.0.6 and doesn't work with at least php 4.3.1 up. That's why I thought it was a php bug. Thanks again. Previous Comments: [2003-03-24 03:43:19] [EMAIL PROTECTED] It definately not is any PHP bug. [2003-03-23 18:54:36] joe at mcknight dot de Hi, I did another test with php 4.0.6 (cgi and --disable-all as well) and the configuration posted before. It works if I just change the php binary... Can anybody tell me if this is a PHP bug or one from apache? Thanks, Joachim [2003-03-19 18:43:36] joe at mcknight dot de Okay, this might really be an apache error. I have a small configuration that seems to be able to reproduce it for me. I see it on 4 machines now: It's one SuSE 7.3 and 3 Debian woody/testing machines. I have the following httpd.conf and no other configuration files. The configuration assumes that there is a php4.cgi in /var/www/php-cgi/. This might be a php binary compiled with --disable-all. Could somebody please test it, just to have someone who encounters this as well? Just rename your existing configuration and move my httpd.conf in. Put the scripts below in /var/www and put the php cgi binary to /var/www/php-cgi. You'll also need to set register_globals = On in the php.ini. That was sufficient for me. On test.php, enter just a single character and click on the OK button, don't hit return but use the button... Here's my httpd configuration: ServerType standalone ServerRoot /etc/apache LockFile /var/lock/apache.lock PidFile /var/run/apache.pid LoadModule config_log_module /usr/lib/apache/1.3/mod_log_config.so LoadModule mime_module /usr/lib/apache/1.3/mod_mime.so LoadModule cgi_module /usr/lib/apache/1.3/mod_cgi.so LoadModule action_module /usr/lib/apache/1.3/mod_actions.so Port 80 User www-data Group www-data AddHandler cgi-script .cgi .sh .pl DocumentRoot/var/www AddHandler php-script .php .php3 .php4 .phtml Action php-script /php-cgi/php4.cgi ErrorLog /var/log/apache/web-error.log CustomLog /var/log/apache/web-transfer.log combined Options +ExecCGI Thank you very much [2003-03-19 16:09:49] [EMAIL PROTECTED] Okay, you're pulling my leg now. I don't believe this is a real bug report at all. NOBODY else can reproduce this. So even if this was real, it's just your system that has it. [2003-03-19 16:07:26] joe at mcknight dot de I get the same error: phpinfo() says: Configure Command './configure' '--disable-all' '--disable-cli' Server API CGI Virtual Directory Support disabled Configuration File (php.ini) Path /usr/local/lib/php.ini PHP API 20020918 PHP Extension 20020429 Zend Extension 20021010 /usr/local/lib/php.ini contains just the single line: register_globals = On What next ? :-) 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/22773 -- Edit this bug report at http://bugs.php.net/?id=22773&edit=1
#22858 [NEW]: file function fails to open relative file names...
From: excalibur at hub dot org
Operating system: FreeBSD 4.8-RC
PHP version: 4.3.1
PHP Bug Type: Filesystem function related
Bug description: file function fails to open relative file names...
Hi Guy's,
Got an issue that appears to be related to some other functions but as
this one is specific to a function I figured it's due it's own bug
posting. Ran into an issue where file() does not open relative file names,
for instance:
$words_file = "./config/filter.txt";
if (@is_readable($words_file)) {
/* Read the file and iterate through the lines. */
$lines = file($words_file);
foreach ($lines as $line) {
print $line."";
}
}
I get:
Warning: file(./config/filter.txt) [function.file]: failed to create
stream: No such file or directory in
/usr/local/www/test.com/horde/lib/Text.php on line 41
Warning: Invalid argument supplied for foreach() in
/usr/local/www/test.com/horde/lib/Text.php on line 42
Yet if I specify the full path to the very same file, it works fine:
$words_file = "/usr/local/www/test.com/horde/imp/config/filter.txt";
if (@is_readable($words_file)) {
/* Read the file and iterate through the lines. */
$lines = file($words_file);
foreach ($lines as $line) {
print $line."";
}
}
The is_readable sees the file fine, but file itself fails.
--
Edit bug report at http://bugs.php.net/?id=22858&edit=1
--
Try a CVS snapshot: http://bugs.php.net/fix.php?id=22858&r=trysnapshot
Fixed in CVS: http://bugs.php.net/fix.php?id=22858&r=fixedcvs
Fixed in release: http://bugs.php.net/fix.php?id=22858&r=alreadyfixed
Need backtrace: http://bugs.php.net/fix.php?id=22858&r=needtrace
Try newer version: http://bugs.php.net/fix.php?id=22858&r=oldversion
Not developer issue:http://bugs.php.net/fix.php?id=22858&r=support
Expected behavior: http://bugs.php.net/fix.php?id=22858&r=notwrong
Not enough info:http://bugs.php.net/fix.php?id=22858&r=notenoughinfo
Submitted twice:http://bugs.php.net/fix.php?id=22858&r=submittedtwice
register_globals: http://bugs.php.net/fix.php?id=22858&r=globals
PHP 3 support discontinued: http://bugs.php.net/fix.php?id=22858&r=php3
Daylight Savings: http://bugs.php.net/fix.php?id=22858&r=dst
IIS Stability: http://bugs.php.net/fix.php?id=22858&r=isapi
Install GNU Sed:http://bugs.php.net/fix.php?id=22858&r=gnused
#22834 [Asn->Fbk]: type mismatch in mbstring extension
ID: 22834 Updated by: [EMAIL PROTECTED] Reported By: fnjordy at cus dot org dot uk -Status: Assigned +Status: Feedback Bug Type: Compile Failure Operating System: Solaris 8 PHP Version: 4.3.2RC1 Assigned To: moriyoshi New Comment: 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 Previous Comments: [2003-03-24 14:16:53] [EMAIL PROTECTED] I've been aware of this issue. [2003-03-23 21:47:17] fnjordy at cus dot org dot uk Only appears when building with Sun Forte's C++ compiler CC, not the C compiler cc. I'm building an extension that uses a C++ library and hence the change. "/local/src/php-4.3.2RC1/ext/mbstring/mbfilter.c", line 2957: Error: Cannot assign const char* to const unsigned char*. "/local/src/php-4.3.2RC1/ext/mbstring/mbfilter.c", line 2974: Error: Cannot assign const char* to const unsigned char*. "/local/src/php-4.3.2RC1/ext/mbstring/mbfilter.c", line 7742: Error: Cannot assign unsigned* to int*. cal/src/php-4.3.2RC1/ext/mbstring/mbstring.c", line 1045: Error: Formal argument no_language of type mbfl_no_language in call to mbfl_no_language2name(mbfl_no_language) is being passed int. "/local/src/php-4.3.2RC1/ext/mbstring/mbstring.c", line 1076: Error: Formal argument no_encoding of type mbfl_no_encoding in call to mbfl_no_encoding2name(mbfl_no_encoding) is being passed int. "/local/src/php-4.3.2RC1/ext/mbstring/mbstring.c", line 1139: Error: Formal argument no_encoding of type mbfl_no_encoding in call to mbfl_no_encoding2name(mbfl_no_encoding) is being passed int. "/local/src/php-4.3.2RC1/ext/mbstring/mbstring.c", line 1141: Warning: The variable name has not yet been assigned a value. "/local/src/php-4.3.2RC1/ext/mbstring/mbstring.c", line 1154: Error: Formal argument no_encoding of type mbfl_no_encoding in call to mbfl_no_encoding2name(mbfl_no_encoding) is being passed int. "/local/src/php-4.3.2RC1/ext/mbstring/mbstring.c", line 1185: Error: Formal argument no_encoding of type mbfl_no_encoding in call to mbfl_no_encoding2name(mbfl_no_encoding) is being passed int. "/local/src/php-4.3.2RC1/ext/mbstring/mbstring.c", line ... Build environment: * Sun Forte 6 Update 2 * Autoconf 2.57 * Automake 1.5 * m4 1.4 * libtool 1.4.3 fyi: Autoconf 2.13 doesn't detect functions in libraries with Forte CC. -- Edit this bug report at http://bugs.php.net/?id=22834&edit=1
#22850 [Opn]: php does not work with mod_ssl
ID: 22850 User updated by: tobias dot mattsson at comhem dot com Reported By: tobias dot mattsson at comhem dot com Status: Open Bug Type: Apache related Operating System: Linux RH 8.0 PHP Version: 4.3.1 New Comment: The version of mod_ssl is 2.8.13 Previous Comments: [2003-03-24 10:41:06] [EMAIL PROTECTED] If I remeber correctly, there was a problem with some mod_ssl version. Check if you got latest one. I might be wrong. [2003-03-24 09:51:02] tobias dot mattsson at comhem dot com ## Environment: Red hat 8.0 Openssl 0.9.7a apache 1.3.27 mod_ssl gcc 3.2 ## Description of the problem: PHP generates a segmentation fault (but no coredump) when the webserver try to execute a .php file with ssl. But if I change the AddType in httpd.conf to .php4 (or anything else), it works fine. It also works fine without SSL. Even if the .php file did not exist, I get a segmentaion fault - not a 404! The browser (mozilla) displays a alert message (document contains no data). It seems to be hung up about the file-extension .php I have not been able to create a core dump with gdb accordning to your instructions at http://bugs.php.net/bugs-generating-backtrace.php >From error_log: [Mon Mar 24 17:16:07 2003] [notice] child pid 10008 exit signal Segmentation fault (11) I have also tried openssl 0.9.6b (from RPM) and the latest CVS snapshot of PHP (php4-STABLE-200303241430) without any change. PHP:s configure line: ./configure --with-mysql --with-openssl=/usr --with-apxs=/usr/local/apache/bin/apxs -- Edit this bug report at http://bugs.php.net/?id=22850&edit=1
#22856 [Opn->Fbk]: zlib make error
ID: 22856 Updated by: [EMAIL PROTECTED] Reported By: mv24 at canada dot com -Status: Open +Status: Feedback Bug Type: Compile Failure Operating System: Linux PHP Version: 4.3.1 New Comment: 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 Previous Comments: [2003-03-24 13:54:45] mv24 at canada dot com apache_1.3.27 php-4.3.2RC1 zlib-1.1.4 Configured with the following options without warnigs: ./configure \ --with-apache=/usr/local/apache_1.3.27 \ --with-config-file-path=/usr/local/apache/conf \ --with-mysql=/usr/local/mysql \ --enable-track-vars \ --enable-trans-sid \ --enable-bcmath \ --with-curl=/usr/local/curl \ --with-curlwrappers \ --with-pdflib \ --enable-static-pdflib \ --enable-gd-imgstrttf \ --with-gd=/usr/local/gd \ --with-tiff-dir=/usr/local/tiff--enable-gd-native-ttf \ --with-freetype-dir=/usr/local/include/freetype2 \ --with-jpeg-dir=/usr/local/jpeg-6b \ --with-png-dir=/usr/local/libpng \ --with-zlib Make result (in full): [EMAIL PROTECTED] php]# make gcc -Iext/zlib/ -I/usr/local/php/ext/zlib/ -DPHP_ATOM_INC -I/usr/local/php/include -I/usr/local/php/main -I/usr/local/php -I/usr/local/php/Zend -I/usr/local/curl/include -I/usr/local/include -I/usr/local/include/freetype2 -I/usr/local/gd/ -I/usr/local/mysql/include -I/usr/local/php/ext/xml/expat -I/usr/local/php/TSRM -g -O2 -c /usr/local/php/ext/zlib/zlib.c -o ext/zlib/zlib.o && echo > ext/zlib/zlib.lo In file included from /usr/local/php/ext/standard/php_standard.h:21, from /usr/local/php/ext/zlib/zlib.c:48: /usr/local/php/ext/standard/basic_functions.h:126: #error Need type which holds 32 bits make: *** [ext/zlib/zlib.lo] Error 1 The same error was reproduced on php-4.3.0, php-4.3.2RC1, php-4.5. Tried the following: 1. Configure with-zlib and/or with-zlib-dir=/dir/zlib in combinations 2. rm f config.cache; ./buildconf; make distclean; Another try: ./configure \ --with-apache=/usr/local/apache_1.3.27 \ --with-config-file-path=/usr/local/apache/conf \ --with-mysql=/usr/local/mysql \ --enable-track-vars \ --enable-trans-sid \ --enable-bcmath \ --with-curl=/usr/local/curl \ --with-curlwrappers Configures without errors or warnings. Make stops by error again: In file included from /usr/local/php/ext/standard/md5.h:48, from /usr/local/php/ext/session/session.c:40: /usr/local/php/ext/standard/basic_functions.h:126: #error Need type which holds 32 bits make: *** [ext/session/session.lo] Error 1 config.log did not revile any problems What it could be? Thank you for your time and effort. -- Edit this bug report at http://bugs.php.net/?id=22856&edit=1
#22834 [Opn->Asn]: type mismatch in mbstring extension
ID: 22834 Updated by: [EMAIL PROTECTED] Reported By: fnjordy at cus dot org dot uk -Status: Open +Status: Assigned Bug Type: Compile Failure Operating System: Solaris 8 PHP Version: 4.3.2RC1 -Assigned To: +Assigned To: moriyoshi New Comment: I've been aware of this issue. Previous Comments: [2003-03-23 21:47:17] fnjordy at cus dot org dot uk Only appears when building with Sun Forte's C++ compiler CC, not the C compiler cc. I'm building an extension that uses a C++ library and hence the change. "/local/src/php-4.3.2RC1/ext/mbstring/mbfilter.c", line 2957: Error: Cannot assign const char* to const unsigned char*. "/local/src/php-4.3.2RC1/ext/mbstring/mbfilter.c", line 2974: Error: Cannot assign const char* to const unsigned char*. "/local/src/php-4.3.2RC1/ext/mbstring/mbfilter.c", line 7742: Error: Cannot assign unsigned* to int*. cal/src/php-4.3.2RC1/ext/mbstring/mbstring.c", line 1045: Error: Formal argument no_language of type mbfl_no_language in call to mbfl_no_language2name(mbfl_no_language) is being passed int. "/local/src/php-4.3.2RC1/ext/mbstring/mbstring.c", line 1076: Error: Formal argument no_encoding of type mbfl_no_encoding in call to mbfl_no_encoding2name(mbfl_no_encoding) is being passed int. "/local/src/php-4.3.2RC1/ext/mbstring/mbstring.c", line 1139: Error: Formal argument no_encoding of type mbfl_no_encoding in call to mbfl_no_encoding2name(mbfl_no_encoding) is being passed int. "/local/src/php-4.3.2RC1/ext/mbstring/mbstring.c", line 1141: Warning: The variable name has not yet been assigned a value. "/local/src/php-4.3.2RC1/ext/mbstring/mbstring.c", line 1154: Error: Formal argument no_encoding of type mbfl_no_encoding in call to mbfl_no_encoding2name(mbfl_no_encoding) is being passed int. "/local/src/php-4.3.2RC1/ext/mbstring/mbstring.c", line 1185: Error: Formal argument no_encoding of type mbfl_no_encoding in call to mbfl_no_encoding2name(mbfl_no_encoding) is being passed int. "/local/src/php-4.3.2RC1/ext/mbstring/mbstring.c", line ... Build environment: * Sun Forte 6 Update 2 * Autoconf 2.57 * Automake 1.5 * m4 1.4 * libtool 1.4.3 fyi: Autoconf 2.13 doesn't detect functions in libraries with Forte CC. -- Edit this bug report at http://bugs.php.net/?id=22834&edit=1
#22857 [NEW]: OCIExecute Hangs
From: dean at vipersoft dot co dot uk Operating system: Linux 2.4 PHP version: 4.3.1 PHP Bug Type: OCI8 related Bug description: OCIExecute Hangs Using the sample code below to submit a number of queries to an Oracle database - about every 1 in 10 executions causes the OCIExecute function to simple "hang" for about 10 minutes before timing out. If more information is needed or any sorts of debugging is required, I will follow up to this bug with the requested information. Thanks Dean #!/opt/php/bin/php -q sample output from above when "hung" . . . Iteration 2671 before execute after execute Iteration 2672 before execute after execute Iteration 2673 before execute Notes: * Doesn't happen every time * Happens about 1 in every 10 runs of the above code * Happens from both the CLI php and through Apache * Eventually times out without finishing off its iteration -- Edit bug report at http://bugs.php.net/?id=22857&edit=1 -- Try a CVS snapshot: http://bugs.php.net/fix.php?id=22857&r=trysnapshot Fixed in CVS: http://bugs.php.net/fix.php?id=22857&r=fixedcvs Fixed in release: http://bugs.php.net/fix.php?id=22857&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=22857&r=needtrace Try newer version: http://bugs.php.net/fix.php?id=22857&r=oldversion Not developer issue:http://bugs.php.net/fix.php?id=22857&r=support Expected behavior: http://bugs.php.net/fix.php?id=22857&r=notwrong Not enough info:http://bugs.php.net/fix.php?id=22857&r=notenoughinfo Submitted twice:http://bugs.php.net/fix.php?id=22857&r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=22857&r=globals PHP 3 support discontinued: http://bugs.php.net/fix.php?id=22857&r=php3 Daylight Savings: http://bugs.php.net/fix.php?id=22857&r=dst IIS Stability: http://bugs.php.net/fix.php?id=22857&r=isapi Install GNU Sed:http://bugs.php.net/fix.php?id=22857&r=gnused
#22856 [NEW]: zlib make error
From: mv24 at canada dot com Operating system: Linux PHP version: 4.3.1 PHP Bug Type: Compile Failure Bug description: zlib make error apache_1.3.27 php-4.3.2RC1 zlib-1.1.4 Configured with the following options without warnigs: ./configure \ --with-apache=/usr/local/apache_1.3.27 \ --with-config-file-path=/usr/local/apache/conf \ --with-mysql=/usr/local/mysql \ --enable-track-vars \ --enable-trans-sid \ --enable-bcmath \ --with-curl=/usr/local/curl \ --with-curlwrappers \ --with-pdflib \ --enable-static-pdflib \ --enable-gd-imgstrttf \ --with-gd=/usr/local/gd \ --with-tiff-dir=/usr/local/tiff--enable-gd-native-ttf \ --with-freetype-dir=/usr/local/include/freetype2 \ --with-jpeg-dir=/usr/local/jpeg-6b \ --with-png-dir=/usr/local/libpng \ --with-zlib Make result (in full): [EMAIL PROTECTED] php]# make gcc -Iext/zlib/ -I/usr/local/php/ext/zlib/ -DPHP_ATOM_INC -I/usr/local/php/include -I/usr/local/php/main -I/usr/local/php -I/usr/local/php/Zend -I/usr/local/curl/include -I/usr/local/include -I/usr/local/include/freetype2 -I/usr/local/gd/ -I/usr/local/mysql/include -I/usr/local/php/ext/xml/expat -I/usr/local/php/TSRM -g -O2 -c /usr/local/php/ext/zlib/zlib.c -o ext/zlib/zlib.o && echo > ext/zlib/zlib.lo In file included from /usr/local/php/ext/standard/php_standard.h:21, from /usr/local/php/ext/zlib/zlib.c:48: /usr/local/php/ext/standard/basic_functions.h:126: #error Need type which holds 32 bits make: *** [ext/zlib/zlib.lo] Error 1 The same error was reproduced on php-4.3.0, php-4.3.2RC1, php-4.5. Tried the following: 1. Configure with-zlib and/or with-zlib-dir=/dir/zlib in combinations 2. rm f config.cache; ./buildconf; make distclean; Another try: ./configure \ --with-apache=/usr/local/apache_1.3.27 \ --with-config-file-path=/usr/local/apache/conf \ --with-mysql=/usr/local/mysql \ --enable-track-vars \ --enable-trans-sid \ --enable-bcmath \ --with-curl=/usr/local/curl \ --with-curlwrappers Configures without errors or warnings. Make stops by error again: In file included from /usr/local/php/ext/standard/md5.h:48, from /usr/local/php/ext/session/session.c:40: /usr/local/php/ext/standard/basic_functions.h:126: #error Need type which holds 32 bits make: *** [ext/session/session.lo] Error 1 config.log did not revile any problems What it could be? Thank you for your time and effort. -- Edit bug report at http://bugs.php.net/?id=22856&edit=1 -- Try a CVS snapshot: http://bugs.php.net/fix.php?id=22856&r=trysnapshot Fixed in CVS: http://bugs.php.net/fix.php?id=22856&r=fixedcvs Fixed in release: http://bugs.php.net/fix.php?id=22856&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=22856&r=needtrace Try newer version: http://bugs.php.net/fix.php?id=22856&r=oldversion Not developer issue:http://bugs.php.net/fix.php?id=22856&r=support Expected behavior: http://bugs.php.net/fix.php?id=22856&r=notwrong Not enough info:http://bugs.php.net/fix.php?id=22856&r=notenoughinfo Submitted twice:http://bugs.php.net/fix.php?id=22856&r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=22856&r=globals PHP 3 support discontinued: http://bugs.php.net/fix.php?id=22856&r=php3 Daylight Savings: http://bugs.php.net/fix.php?id=22856&r=dst IIS Stability: http://bugs.php.net/fix.php?id=22856&r=isapi Install GNU Sed:http://bugs.php.net/fix.php?id=22856&r=gnused
#22844 [Csd]: text boolean ini options set with -d do not work (on/off)
ID: 22844 User updated by: gk at proliberty dot com Reported By: gk at proliberty dot com Status: Closed Bug Type: CGI related Operating System: linux RH 7.2 PHP Version: 4.3.2-RC New Comment: This problem, as I originally posted, is more general what sniper is focusing on: it is not limited to -d option; problem is reproducible with ini_set(). Perhaps we should change the title again to: "On/Off" ini options do not work for display_error or display_startup_errors? I'm not sure if the issue applies to other options than these. sniper, have you verified the same behavior I saw with ini_set()? Previous Comments: [2003-03-24 07:58:34] [EMAIL PROTECTED] Forgot to close ;) [2003-03-24 07:58:17] [EMAIL PROTECTED] This bug has been fixed in CVS. In case this was a PHP problem, 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/. In case this was a documentation problem, the fix will show up soon at http://www.php.net/manual/. In case this was a PHP.net website problem, the change will show up on the PHP.net site and on the mirror sites in short time. Thank you for the report, and for helping us make PHP better. [2003-03-24 05:05:13] [EMAIL PROTECTED] This is actually real bug: # php -d display_errors=1 -r "f();" <-- this works # php -d display_errors=On -r "f();" <-- this is same as setting it to 0 [2003-03-24 04:55:07] gk at proliberty dot com In my php.ini file, I have: display_errors=On display_startup_errors=On In Bug #22796, I noted that display_startup_errors=On is required for proper error display using -r option; however this is a separate problem: errors not displayed if display_startup_error or display_errors is set to ANY value, with ini_set() or on the command line I demonstrate below with -d switch: [EMAIL PROTECTED] junk]$ php -d display_startup_errors=On -r "f();" [EMAIL PROTECTED] junk]$ php -d display_startup_errors=Off -r "f();" [EMAIL PROTECTED] junk]$ php -r "f();" Fatal error: Call to undefined function: f() in Command line code on line 1 [EMAIL PROTECTED] junk]$ php -d display_errors=Off -r "f();" [EMAIL PROTECTED] junk]$ php -d display_errors=On -r "f();" The same problem occurs if call ini_set() instead of using -d option: #FILE: junk.php Now, if you use boolean value instead of On/Off, it appears that if EITHER variable is set to 1, errors work but if EITHER is set to 0, they don't: [EMAIL PROTECTED] junk]$ php -d display_errors=0 -r "f();" [EMAIL PROTECTED] junk]$ php -d display_errors=1 -r "f();" Fatal error: Call to undefined function: f() in Command line code on line 1 [EMAIL PROTECTED] junk]$ php -d display_errors=On -r "f();" [EMAIL PROTECTED] junk]$ php -d display_startup_errors=1 -r "f();" Fatal error: Call to undefined function: f() in Command line code on line 1 [EMAIL PROTECTED] junk]$ php -d display_startup_errors=0 -r "f();" [EMAIL PROTECTED] junk]$ -- Edit this bug report at http://bugs.php.net/?id=22844&edit=1
#22381 [Com]: undefined reference to `__canary_death_handler'
ID: 22381 Comment by: the_systech at yahoo dot com Reported By: alahaye at wanadoo dot fr Status: No Feedback Bug Type: IMAP related Operating System: ReadHat 7.2 PHP Version: 4.3.1 New Comment: I can confirm the same problem. I would guess that this is likely on a Cobalt Raq 550 as, this is the setup where I am experiencing the issue and I know that the Raq 550's have "most" of their binaries compiled with stackguard. I can compile with 4.2.3 just fine, but with 4.3.1 configure dies with the "testing IMAP" section and the config.log is more or less identical to what was posted by the original bug submittor. Previous Comments: [2003-03-09 19:08:39] [EMAIL PROTECTED] No feedback was provided. The bug is being suspended because we assume that you are no longer experiencing the problem. If this is not the case and you are able to provide the information that was requested earlier, please do so and change the status of the bug back to "Open". Thank you. [2003-02-23 17:35:39] [EMAIL PROTECTED] First of all, don't try outsmarting our bug system and give the feedback using the http://bugs.php.net/?id=22381&edit=2 url and your password. Second: imap-2000c is really too old, update it first. I have no idea where you have got that version which seems to be compiled using this: http://immunix.org/stackguard.html [2003-02-23 06:32:02] alahaye at wanadoo dot Fr Hi, I try with --enable-libgcc and get same error. Here my complete compilation line ./configure --prefix=/usr --with-apxs=/usr/sbin/apxs --enable-safe-mode --with-config-file-path=/etc/httpd/4.3.1 --with-exec-dir=/usr/bin --with-zlib --enable-magic-quotes --with-regex=system --enable-track-vars --with-iconv --enable-xml --disable-debug --with-gd --enable-mbstring --enable-mbstring --enable-exif --with-mcrypt=shared --with-interbase=shared --with-mysql=shared --with-pgsql=shared --with-ldap --with-imap --with-openssl=/usr --with-jpeg-dir=/usr --with-png-dir=/usr --with-gettext=shared --with-imap-ssl --disable-mbstr-enc-trans --enable-sockets --enable-ftp --enable-bcmath --enable-libgcc iliaa, you can notice that i have both --with-imap and --with-imap-ssl. This configuration line works great with PHP4.2.3 but not for PHP4.3.1 The c-client was the REDHAT Package (see my config.log) /usr/src/redhat/BUILD/imap-2000c/c-client/mail.c Same bug is report on bug 22353 on Solaris [2003-02-22 22:41:26] [EMAIL PROTECTED] 1. Try adding '--enable-libgcc' to your configure line 2. Did you compile libc-client.a yourself? [2003-02-22 19:34:52] [EMAIL PROTECTED] Try adding --with-imap-ssl to your configure line. 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/22381 -- Edit this bug report at http://bugs.php.net/?id=22381&edit=1
#21990 [Opn->WFx]: switch() compare using ===
ID: 21990 Updated by: [EMAIL PROTECTED] Reported By: renota at earthgaming dot com -Status: Open +Status: Wont fix Bug Type: Feature/Change Request Operating System: Linux PHP Version: 4.2.2 New Comment: It's a feature and will not change. Previous Comments: [2003-01-31 16:09:05] renota at earthgaming dot com Hi, I was doing some developing and noticed that switch() only does a == compare and not a === compare (e.g. case -7:). I would like to request it (if it's not aleady done). Thank you for your time. -- Edit this bug report at http://bugs.php.net/?id=21990&edit=1
#22855 [NEW]: Memory corruption when dealing with cyclic references between objects
From: knizhnik at garret dot ru
Operating system: Windows and Linux
PHP version: 4.3.1
PHP Bug Type: Zend Engine 2 problem
Bug description: Memory corruption when dealing with cyclic references between objects
PHP is using reference counter garbage collection so it is not able to
deallocate objects with cyclic references. But
it should not be a reason for corrupting memory. The following example
cause either loosing value of object property either segmentation fault at
PHP 4.3.1 and PHP-4.3.2RC1. The fault takes place after inserting 65533
objects (0xfffd - looks like somewhere short type is used:).
In first case after inserting about 65k of objects the system reports "PHP
Notice: Undefined property:" when
accessing "opened" field in storeObject.
objByOidMap = array();
$this->opened = true;
$this->count = 0;
}
function storeObject(&$obj) {
if ($this->opened) {
if ($obj->__oid__ == 0) {
$this->count += 1;
$obj->__oid__ = $this->count;
$obj->__storage__ = &$this;
$this->objByOidMap[$obj->__oid__] = &$obj;
}
}
}
}
class Object {
var $__storage__;
var $__oid__;
}
$storage = &new Storage();
for ($i = 0; $i < 10; $i++) {
print("i=$i\n");
$obj = &new Object();
$storage->storeObject($obj);
}
?>
--
Edit bug report at http://bugs.php.net/?id=22855&edit=1
--
Try a CVS snapshot: http://bugs.php.net/fix.php?id=22855&r=trysnapshot
Fixed in CVS: http://bugs.php.net/fix.php?id=22855&r=fixedcvs
Fixed in release: http://bugs.php.net/fix.php?id=22855&r=alreadyfixed
Need backtrace: http://bugs.php.net/fix.php?id=22855&r=needtrace
Try newer version: http://bugs.php.net/fix.php?id=22855&r=oldversion
Not developer issue:http://bugs.php.net/fix.php?id=22855&r=support
Expected behavior: http://bugs.php.net/fix.php?id=22855&r=notwrong
Not enough info:http://bugs.php.net/fix.php?id=22855&r=notenoughinfo
Submitted twice:http://bugs.php.net/fix.php?id=22855&r=submittedtwice
register_globals: http://bugs.php.net/fix.php?id=22855&r=globals
PHP 3 support discontinued: http://bugs.php.net/fix.php?id=22855&r=php3
Daylight Savings: http://bugs.php.net/fix.php?id=22855&r=dst
IIS Stability: http://bugs.php.net/fix.php?id=22855&r=isapi
Install GNU Sed:http://bugs.php.net/fix.php?id=22855&r=gnused
#22840 [Com]: session file won't be deleted when session_destroy used
ID: 22840
Comment by: notepad at codewalkers dot com
Reported By: chair123 at 163 dot net
Status: Bogus
Bug Type: Session related
Operating System: win2000pro
PHP Version: 4.3.1
New Comment:
i can't get sessions to destroy at all in PHP v4.3.1. - it seems to set
the variable $_SESSION['valid_user'] even when the login form is left
blank. so i made it harder to login, and now the login function won't
return true even if it's a valid attempt.. craziness
testdb.txt example:
myuserid|mypass
sessiontest.php example:
$value)
{
$divide = explode('|', $value);
if(($divide[0] == "$id") && ($divide[1] == "$pass"))
{
//echo 'yes: '.$id.':'.$pass.'';
return true;
}
else
{
//echo 'no: '.$id.':'.$pass.'';
return false;
}
}
}
if(@login($userid, $password, $data))
{
@$_SESSION['valid_user'] = $userid;
$olduser = $_SESSION['valid_user'];
$oldid = session_id();
//setcookie(session_name());
$_COOKIE = array();
$_SESSION = array();
$_REQUEST = array();
session_destroy();
echo '';
echo 'you are logged in as '.$olduser.' : '.$oldid.'';
echo 'logout';
}
else
{
if(isset($userid))
echo 'could not log you in';
else
echo 'you are not logged in';
?>
userid:
password:
Previous Comments:
[2003-03-24 04:57:19] [EMAIL PROTECTED]
Sorry, but your problem does not imply a bug in PHP itself. For a
list of more appropriate places to ask for help using PHP, please
visit http://www.php.net/support.php as this bug system is not the
appropriate forum for asking support questions.
Thank you for your interest in PHP.
header("Location: somefile.php"); is invalid anyway..
[2003-03-24 04:55:35] chair123 at 163 dot net
got the problem...
If I use
echo " window.location.href='chksession.php' ";
instead of header(¡°location: chksession.php"),
that's all right.
It must be a bug in win2000pro
[2003-03-24 02:27:42] chair123 at 163 dot net
session.php
chksession.php
when I type http://127.0.0.1/session.php in IE frist, It's nothing in
the screen. NO session file in directory c:\php\sessiondata.
I typed in second time, it 's "9Chair" in the screen(the same IE).
and sess_7e2ebd21da6d67c7e9f3860ae7c60a6 file in there. and whatever
you chang your php file , the session file never been removed! and I
put the php file in redhat 8.0, all is right. please give me a hand.
--
Edit this bug report at http://bugs.php.net/?id=22840&edit=1
#22836 [Ver]: returning reference to uninitialized variable
ID: 22836
User updated by: brunswim at seas dot upenn dot edu
Reported By: brunswim at seas dot upenn dot edu
Status: Verified
Bug Type: Scripting Engine problem
Operating System: Debian Linux 2.4.18
PHP Version: 4.3.2-RC
New Comment:
This seems similar to bug #22367 but causes problems more globally.
Obviously, this is reproducible with a short script. In the following
similar example, it may be more apparent that global corruption is
taking place.
\n$x";
}
$i =& f1();
$j =& f1();
f2();
?>
The output that I get is:
NULL
bug!
So, after 2 references to uninitialized variables, everything behaves
unpredictably.
It is easy to see how this situation could occur in "real" code. In
our case, we were building objects from a database select query. We
were iterating through the rows and putting data in $a[]. When there
were no rows, $a was never initialized, but it was extremely difficult
to isolate the problem because other functions, across many files, were
misbehaving due to this bug.
Previous Comments:
[2003-03-24 04:29:46] [EMAIL PROTECTED]
This problem has much to do with bug #22367.
Assumed reason: unexpected change of EG(uninitialized_zval_ptr)..
[2003-03-24 03:41:50] [EMAIL PROTECTED]
I get same output plus these leaks:
/usr/src/web/php/php4/Zend/zend_execute.c(436) : Freeing 0x0875A804 (4
bytes), script=t.php
/usr/src/web/php/php4/Zend/zend_variables.c(111) : Actual location
(location was relayed)
/usr/src/web/php/php4/Zend/zend_execute.c(1702) : Freeing 0x0875A6EC
(12 bytes), script=t.php
[2003-03-24 01:45:41] brunswim at seas dot upenn dot edu
For the record, the output I am getting for this script is:
string(3) "foo"
foo
string(3) "foo"
foo
NULL
foo
NULL
foo
NULL
foo
NULL
foo
NULL
foo
NULL
foo
[2003-03-23 22:53:07] brunswim at seas dot upenn dot edu
f() returns a reference to an uninitialized variable $a. In subsequent
calls, this appears to corrupt the local variable $x. The following
script demonstrates the problem.
\n$x\n";
return($a);
}
for ($i = 0; $i < 8; $i++) {
$h =& f();
}
?>
On the third call to f(), $x prints fine but is reported to be NULL by
var_dump(). Operations on $x will subsequently cause unexpected
behavior.
We can change the behavior of $x by adding the line:
$y = "bar";
after the line:
$x = "foo";
If we do this, printing $x returns "bar" but var_dump() still returns
NULL.
--
Edit this bug report at http://bugs.php.net/?id=22836&edit=1
#22854 [NEW]: ibase_query complains that number of read/write doesn't equal count values
From: al2925 at mail dot ru Operating system: Windows 2000 Server SP3 PHP version: 4.3.0 PHP Bug Type: InterBase related Bug description: ibase_query complains that number of read/write doesn't equal count values I get such warning: PHP Warning: ibase_query(): Dynamic SQL Error SQL error code = -804 Count of read-write columns does not equal count of values in c:\gentle\php_includes\IbaseConnection.php(86) : runtime-created function on line 1 The query looks like ibase_query($link, 'INSERT INTO tableName (cols, ..) VALUES (cols, ?, ?, ?)', $blob0, $blob1, $blob2); All parameters are BLOBs. This happens only if the count of parameters is more than one. I'm running Firebird Superserver for Windows version 1.0.2.908 The error began to occur after I upgraded from PHP 4.3.2 Please, feel free to contact me via e-mail. -- Edit bug report at http://bugs.php.net/?id=22854&edit=1 -- Try a CVS snapshot: http://bugs.php.net/fix.php?id=22854&r=trysnapshot Fixed in CVS: http://bugs.php.net/fix.php?id=22854&r=fixedcvs Fixed in release: http://bugs.php.net/fix.php?id=22854&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=22854&r=needtrace Try newer version: http://bugs.php.net/fix.php?id=22854&r=oldversion Not developer issue:http://bugs.php.net/fix.php?id=22854&r=support Expected behavior: http://bugs.php.net/fix.php?id=22854&r=notwrong Not enough info:http://bugs.php.net/fix.php?id=22854&r=notenoughinfo Submitted twice:http://bugs.php.net/fix.php?id=22854&r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=22854&r=globals PHP 3 support discontinued: http://bugs.php.net/fix.php?id=22854&r=php3 Daylight Savings: http://bugs.php.net/fix.php?id=22854&r=dst IIS Stability: http://bugs.php.net/fix.php?id=22854&r=isapi Install GNU Sed:http://bugs.php.net/fix.php?id=22854&r=gnused
#22853 [NEW]: phpinfo() builds invalid XHTML code
From: rabus at users dot sourceforge dot net Operating system: Red Hat Linux 8.0 PHP version: 5CVS-2003-03-24 (dev) PHP Bug Type: Unknown/Other Function Bug description: phpinfo() builds invalid XHTML code I know, this is a rather small bug, but nevertheless php should go with W3C's specifications imho. I compiled php as Apache 2 module. When calling my phpinfo() script, the generated HTML code contains the following line: Apache 2.0 W3C's HTML validator bothers about this line and says, 'value of attribute "name" must be a single token'. As far as I can see, the problem is the whitespace between "module_Apache" and "2.0". Happy fixing :-) -- Edit bug report at http://bugs.php.net/?id=22853&edit=1 -- Try a CVS snapshot: http://bugs.php.net/fix.php?id=22853&r=trysnapshot Fixed in CVS: http://bugs.php.net/fix.php?id=22853&r=fixedcvs Fixed in release: http://bugs.php.net/fix.php?id=22853&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=22853&r=needtrace Try newer version: http://bugs.php.net/fix.php?id=22853&r=oldversion Not developer issue:http://bugs.php.net/fix.php?id=22853&r=support Expected behavior: http://bugs.php.net/fix.php?id=22853&r=notwrong Not enough info:http://bugs.php.net/fix.php?id=22853&r=notenoughinfo Submitted twice:http://bugs.php.net/fix.php?id=22853&r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=22853&r=globals PHP 3 support discontinued: http://bugs.php.net/fix.php?id=22853&r=php3 Daylight Savings: http://bugs.php.net/fix.php?id=22853&r=dst IIS Stability: http://bugs.php.net/fix.php?id=22853&r=isapi Install GNU Sed:http://bugs.php.net/fix.php?id=22853&r=gnused
#22850 [Opn]: php does not work with mod_ssl
ID: 22850 Updated by: [EMAIL PROTECTED] Reported By: tobias dot mattsson at comhem dot com Status: Open Bug Type: Apache related Operating System: Linux RH 8.0 PHP Version: 4.3.1 New Comment: If I remeber correctly, there was a problem with some mod_ssl version. Check if you got latest one. I might be wrong. Previous Comments: [2003-03-24 09:51:02] tobias dot mattsson at comhem dot com ## Environment: Red hat 8.0 Openssl 0.9.7a apache 1.3.27 mod_ssl gcc 3.2 ## Description of the problem: PHP generates a segmentation fault (but no coredump) when the webserver try to execute a .php file with ssl. But if I change the AddType in httpd.conf to .php4 (or anything else), it works fine. It also works fine without SSL. Even if the .php file did not exist, I get a segmentaion fault - not a 404! The browser (mozilla) displays a alert message (document contains no data). It seems to be hung up about the file-extension .php I have not been able to create a core dump with gdb accordning to your instructions at http://bugs.php.net/bugs-generating-backtrace.php >From error_log: [Mon Mar 24 17:16:07 2003] [notice] child pid 10008 exit signal Segmentation fault (11) I have also tried openssl 0.9.6b (from RPM) and the latest CVS snapshot of PHP (php4-STABLE-200303241430) without any change. PHP:s configure line: ./configure --with-mysql --with-openssl=/usr --with-apxs=/usr/local/apache/bin/apxs -- Edit this bug report at http://bugs.php.net/?id=22850&edit=1
#22852 [NEW]: Results returned by odbc_exec are not right
From: craig at myschoolmates dot com
Operating system: Win XP Pro
PHP version: 4.3.1
PHP Bug Type: ODBC related
Bug description: Results returned by odbc_exec are not right
I have a standard php installation, latest 1.3 release on a win XP box,
using ODBC to access a Paradox database.
Connection code:
$myDB = odbc_connect("llcs", "", "");
$rs = odbc_exec($myDB, $Property_SQL);
$count = 0;
To show Results, I use:
while (odbc_fetch_into($rs, $my_array)) {
?>
SQL Query example that works:
Select Firstname, Surname, Age from Users where Age=50
Returns alot of records, which is correct. I then take an example of a
record that I got back, eg: Craig, Lister, 50, and then try this SQL:
Select Firstname, Surname, Age from Users where Surname = "Lister"
That returns ONLY the first record. Eg, Andrew, Lister, 27
It seems to be only returning the first record when I search for strings,
but on numerical searches, it works fine.
You can see this at http://land.strand.serverbox.org ... use the
'Electoral Search'.
Thank you,
Craig
--
Edit bug report at http://bugs.php.net/?id=22852&edit=1
--
Try a CVS snapshot: http://bugs.php.net/fix.php?id=22852&r=trysnapshot
Fixed in CVS: http://bugs.php.net/fix.php?id=22852&r=fixedcvs
Fixed in release: http://bugs.php.net/fix.php?id=22852&r=alreadyfixed
Need backtrace: http://bugs.php.net/fix.php?id=22852&r=needtrace
Try newer version: http://bugs.php.net/fix.php?id=22852&r=oldversion
Not developer issue:http://bugs.php.net/fix.php?id=22852&r=support
Expected behavior: http://bugs.php.net/fix.php?id=22852&r=notwrong
Not enough info:http://bugs.php.net/fix.php?id=22852&r=notenoughinfo
Submitted twice:http://bugs.php.net/fix.php?id=22852&r=submittedtwice
register_globals: http://bugs.php.net/fix.php?id=22852&r=globals
PHP 3 support discontinued: http://bugs.php.net/fix.php?id=22852&r=php3
Daylight Savings: http://bugs.php.net/fix.php?id=22852&r=dst
IIS Stability: http://bugs.php.net/fix.php?id=22852&r=isapi
Install GNU Sed:http://bugs.php.net/fix.php?id=22852&r=gnused
#22796 [Com]: -r option: no error messages unless display_startup_errors = On
ID: 22796
Comment by: michael dot mauch at gmx dot de
Reported By: gk at proliberty dot com
Status: Feedback
Bug Type: CGI related
Operating System: linux RH 7.2
PHP Version: 4CVS-2003-03-19 (stable)
New Comment:
With php4-STABLE-200303241430 (and with 4.3.1), I can get even three
error messages for the same error.
# sapi/cli/php -c php.ini-dist -r 'f();'
Command line code(1) : Fatal error - Call to undefined function: f()
# sapi/cli/php -c php.ini-recommended -r 'f();'
PHP Fatal error: Call to undefined function: f() in Command line code
on line 1
Command line code(1) : Fatal error - Call to undefined function: f()
# sed 's/\(display_.*errors = \)Off/\1On/' php.ini-display-errors
# sapi/cli/php -c php.ini-display-errors -r 'f();'
PHP Fatal error: Call to undefined function: f() in Command line code
on line 1
Command line code(1) : Fatal error - Call to undefined function: f()
Fatal error: Call to undefined function: f() in Command line code on
line 1
This last php.ini is with display_errors and display_startup_errors =
On.
The message starting with "Fatal error:" goes to stdout, the other two
to stderr.
Previous Comments:
[2003-03-24 04:12:26] [EMAIL PROTECTED]
And get first the latest stable snapshot again.
[2003-03-24 04:11:54] [EMAIL PROTECTED]
# php -r "f();"
Command line code(1) : Fatal error - Call to undefined function: f()
This is what I get when using the php.ini-dist from the latest stable
CVS snapshot.
As you can see, we get totally different style of error
messages too.
Please try with the plain, unmodified php.ini-dist instead of your
current php.ini.
[2003-03-24 02:11:34] gk at proliberty dot com
I split this bug into two; changed the title to better reflect what I
have learned:
it is possible to work around this bug by changing the default value of
display_startup_errors in php.ini:
---
#default value
#display_startup_errors = Off
display_startup_errors = On
---
Now I get the proper error message:
[EMAIL PROTECTED] php4-STABLE-200303210630]# sapi/cli/php -r "f();"
Fatal error: Call to undefined function: f() in Command line code on
line
Following sniper's advice of using -n to prevent reading php.ini has
the same effect for me as display_startup_errors = Off; apparently it
doesn't have the same result for sniper. Odd.
[2003-03-21 20:09:38] gk at proliberty dot com
I built it again, per your instructions and get the same result:
[EMAIL PROTECTED] php4-STABLE-200303210630]# sapi/cli/php -n -r
"require('/htdocs/common/test/junk/junk.php');"
begin
[EMAIL PROTECTED] php4-STABLE-200303210630]#
Do I need a more recent snapshot than that?
I'm using the same test file:
/htdocs/common/test/junk/junk.php:
[2003-03-21 17:13:42] [EMAIL PROTECTED]
Try this with latest stable snapshot:
# rm config.cache
# ./configure --disable-all --disable-cgi && make clean && make
# sapi/cli/php -n -r "require('test.php');"
I think you're just doing something wrong / have something
setup very differently in your server..
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/22796
--
Edit this bug report at http://bugs.php.net/?id=22796&edit=1
#22842 [Opn->Csd]: Include problems under Solaris with 4.3.0
ID: 22842
Updated by: [EMAIL PROTECTED]
Reported By: gallou at cict dot fr
-Status: Open
+Status: Closed
Bug Type: Feature/Change Request
Operating System: Solaris
PHP Version: 4.3.0
New Comment:
This bug has been fixed in CVS.
In case this was a PHP problem, 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/.
In case this was a documentation problem, the fix will show up soon at
http://www.php.net/manual/.
In case this was a PHP.net website problem, the change will show
up on the PHP.net site and on the mirror sites in short time.
Thank you for the report, and for helping us make PHP better.
As user reports.
Previous Comments:
[2003-03-24 07:56:33] gallou at cict dot fr
This new release (CVS build 200203241230, 4.3.2) fixes this problem.
Thanks.
Sorry for the disturbance, I should have tested the latest release...
[2003-03-24 05:15:20] [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
[2003-03-24 03:47:25] gallou at cict dot fr
Hi,
I manage a web server with many hosted virtual servers. I am
experiencing problems with includes in PHP 4.3.0 under Solaris, and I
can't upgrade my server from 4.2.1. Most errors are with PHP codes
which include things from the parent directory (..), which is in
'include_path'.
Look at this test:
tests/
|- inc
|- inc.txt include OK
|- mydir/
|- testinclude.php ';
include ('inc/inc.txt'); ?>
I have two httpd working, with the same config file except the port
number (the server on 8088 loads the 4.3.0 version of libphp.so).
Safe_mode is off. Include_path is '.:../:../../' for 4.2.1.
With PHP 4.2.1,
works OK.
With 4.3.0,
gives:
Failed opening 'inc/inc.txt' for inclusion
(include_path='.:../:/usr/local/php-4.3.0/lib/php')
in /usr/local/www/docs/www/tests/mydir/testinclude.php on line 2
This seems related to a change of PHP using getcwd() in this version (I
guess). In this case, getcwd() returns nothing, since a directory is
-rwx--x--x. This is the case for most virtual server document roots.
Unlike Linux, on Solaris, getcwd() needs "r" access to _all_
directories of the path, otherwise you get (from "man getcwd"):
EACCESA parent directory cannot be read to get its name.
(It's not a bug, but a feature; seems strange to me).
"include '../inc/inc.txt'" does not work either. Apart using full
pathnames in includes, the only way I found to get it work in PHP 4.3.0
is "chmod o+r" every component of the dir path (this way, getcwd()
returns the right value, and include works). It looks like PHP 4.3.0
resolves the pathname itself, using getcwd(). Due to this feature of
Solaris, in my opinion, it's not a good idea to rely on this function
to get a real pathname. This does not affect Solaris alone, but any
system where getcwd() needs "r" access, that is HP/UX, Irix, and, I
think, most unixes.
I can't state this is a bug of PHP. But I can't upgrade my server. I
posted a message in php.install which remains unanswered. I can't tell
the webmasters to "chmod o+r" their directories or change their PHP
codes. What else can I do to be able to upgrade my server?
--
Edit this bug report at http://bugs.php.net/?id=22842&edit=1
#17079 [Bgs]: setlocale changes the internal representation of floats
ID: 17079
Updated by: [EMAIL PROTECTED]
Reported By: jonathan at tricolon dot com
Status: Bogus
Bug Type: Scripting Engine problem
Operating System: Red Hat Linux 7.1
PHP Version: 4.3.0 RC2
Assigned To: hholzgra
New Comment:
Related discussion:
http://news.php.net/article.php?group=php.dev&article=95211
Previous Comments:
[2003-01-02 13:58:52] php at zeguigui dot com
I switched to PHP 4.3 (in dev only) and I saw this change in locale
handling. It is not OS dependant as I have the problem with Windows
XP.
In PHP < 4.3.0 I have a MySQL database with floats. To handle those
floats I had to make some convertions (with str_replace) as results
were not locale dependant (I use fr_FR). For instance if I had 1.234
stored in db, $row = mysql mysql_fetch_row($handle) would return in
$row[0] the value "1.234" and $row[0] * 100 would return 100 whereas of
123,4 (if outputed).
In PHP = 4.3.0 I do not need those convertion routines anymore (it was
a workaround in my opinion).
So starting with PHP 4.3:
$a = 1.234 ==> OK whatever locale is
$b = "1.234" ==> OK whatever locale is
$c = "1,234" ==> NOT OK whatever locale is
If I have some user inputs I have to convert from locale representation
to number representation before processing them... it would be great to
have a function that do the job for us (didn't find one, sorry!)... but
maybe that's not the good place to ask for this!
[2003-01-02 10:13:59] martin at mermaidconsulting dot com
I also ran across this problem and have been messing with it for like 3
days before i finally ran across this post.
If you do not consider it a bug I would recommend you at least include
it in the documentation and make it very clear that you cannot perform
calculations using thousands-seperators based on the locale settings.
If you have a look at the following sample you can see that user-inputs
will get totally messed up in case they use thousand-seperators.
";
//
displays the monetary decimal point used for the locale
echo "mon_thousands_sep: {$locale_info["mon_thousands_sep"]}";
//
displays the monetary thousands seperator used for the locale
echo "decimal_point: {$locale_info["decimal_point"]}"; //
displays the
decimal point used for the locale
echo "thousands_sep: {$locale_info["thousands_sep"]}"; //
displays the
thousands seperator used for the locale
// defines 2 variables that should be 100 and 75
$a = "1,000,000";
$b = "750,000";
print "A = $a";
print "B = $b";
// performing a simple calculation that illustrates how PHP handles
the
numbers
print "A * 1 = " . ($a*1) . "";
print "B * 1 = " . ($b*1) . "";
?>
Imho there is no point in having locale settings for currencies and
numeric values if you cannot use it for doing calculations.
Thanks
/Martin
[2002-12-16 19:45:14] [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
If you switch to a locale where the float separator is ',' then when it
comes to output the data back to the user the float decimal point will
be depedant on the specified locale. Internally however it'll always be
'.'.
[2002-12-16 08:56:08] jonathan at tricolon dot com
> You should not use ',' to represent floats
> ALWAYS use '.' regardless of locale.
This is exactly the problem. When the locale is changed to Dutch the
internal representation of floats is changed. The separator used is
changed to ','. This behaviour is incorrect and should be fixed. Check
my initial and second post for a detailed description.
Thanks,
Jonathan
[2002-12-16 08:46:12] [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
You should not use ',' to represent floats ALWAYS use '.' regardless of
locale.
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/17079
--
Edit this bug report at http://bugs.php.net/?id=17079&edit=1
#22851 [NEW]: configure stops at "checking whether IMAP works... no"
From: davidp at oak dot njit dot edu Operating system: Solaris 8 PHP version: 4.3.1 PHP Bug Type: IMAP related Bug description: configure stops at "checking whether IMAP works... no" #!/bin/ksh set -o allexport PATH=/usr/local/bin/gnu:$PATH DIR=/afs/cad/solaris/apache.127.proto if [[ -d $DIR/php-4.3.1 ]]; then cd $DIR/php-4.3.1 else print "$DIR/php-4.3.1 does not exist -- exiting..." exit 0 fi ./configure \ --with-apxs=$DIR/apache/bin/apxs \ --with-ldap=/afs/cad/solaris/openldap \ --with-imap=/usr/local/imap \ --with-imap-ssl=/usr/local/ssl \ | tee -a CONFIGURE.log #-- => Configure stops at: checking whether IMAP works... no configure: error: build test failed. Please check the config.log for details. => From config.log: configure:35446: gcc -o conftest -g -O2 -D_POSIX_PTHREAD_SEMANTICS -DSOLARIS2=2 80 -DUSE_EXPAT -R/usr/ucblib -L/usr/ucblib -R/usr/local/lib/gcc-lib/sparc-sun-s olaris2.8/3.2 -L/usr/local/lib/gcc-lib/sparc-sun-solaris2.8/3.2 -R/usr/local/imaplib -L/usr/local/imaplib -R/usr/local/ssl/lib -L/usr/local/ssllib conftest.c -lcrypto -lssl -lc-client -lcrypt -lpam -lcrypt -lresolv -lm -ldl -lnsl -lsoc ket -lgcc -lcrypt 1>&5 Undefined first referenced symbol in file SSL_library_init /usr/local/imap/lib/libc-client.a(osdep.o) . . ERR_get_error /usr/local/imap/lib/libc-client.a(osdep.o) ld: fatal: Symbol referencing errors. No output written to conftest collect2: ld returned 1 exit status configure: failed program was: #line 35421 "configure" #-- => End of CONFIGURE.log: checking for IMAP support... yes checking for pam_start in -lpam... yes checking for crypt in -lcrypt... (cached) yes checking whether SSL libraries are needed for c-client... /usr/local/ssl/lib checking whether IMAP works... no #-- /usr/local/imap/lib/libc-client.a is from Univ. of Washington IMAP imap-2003.DEV.SNAP-0301171021 -- Edit bug report at http://bugs.php.net/?id=22851&edit=1 -- Try a CVS snapshot: http://bugs.php.net/fix.php?id=22851&r=trysnapshot Fixed in CVS: http://bugs.php.net/fix.php?id=22851&r=fixedcvs Fixed in release: http://bugs.php.net/fix.php?id=22851&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=22851&r=needtrace Try newer version: http://bugs.php.net/fix.php?id=22851&r=oldversion Not developer issue:http://bugs.php.net/fix.php?id=22851&r=support Expected behavior: http://bugs.php.net/fix.php?id=22851&r=notwrong Not enough info:http://bugs.php.net/fix.php?id=22851&r=notenoughinfo Submitted twice:http://bugs.php.net/fix.php?id=22851&r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=22851&r=globals PHP 3 support discontinued: http://bugs.php.net/fix.php?id=22851&r=php3 Daylight Savings: http://bugs.php.net/fix.php?id=22851&r=dst IIS Stability: http://bugs.php.net/fix.php?id=22851&r=isapi Install GNU Sed:http://bugs.php.net/fix.php?id=22851&r=gnused
#22850 [NEW]: php does not work with mod_ssl
From: tobias dot mattsson at comhem dot com Operating system: Linux RH 8.0 PHP version: 4.3.1 PHP Bug Type: Apache related Bug description: php does not work with mod_ssl ## Environment: Red hat 8.0 Openssl 0.9.7a apache 1.3.27 mod_ssl gcc 3.2 ## Description of the problem: PHP generates a segmentation fault (but no coredump) when the webserver try to execute a .php file with ssl. But if I change the AddType in httpd.conf to .php4 (or anything else), it works fine. It also works fine without SSL. Even if the .php file did not exist, I get a segmentaion fault - not a 404! The browser (mozilla) displays a alert message (document contains no data). It seems to be hung up about the file-extension .php I have not been able to create a core dump with gdb accordning to your instructions at http://bugs.php.net/bugs-generating-backtrace.php >From error_log: [Mon Mar 24 17:16:07 2003] [notice] child pid 10008 exit signal Segmentation fault (11) I have also tried openssl 0.9.6b (from RPM) and the latest CVS snapshot of PHP (php4-STABLE-200303241430) without any change. PHP:s configure line: ./configure --with-mysql --with-openssl=/usr --with-apxs=/usr/local/apache/bin/apxs -- Edit bug report at http://bugs.php.net/?id=22850&edit=1 -- Try a CVS snapshot: http://bugs.php.net/fix.php?id=22850&r=trysnapshot Fixed in CVS: http://bugs.php.net/fix.php?id=22850&r=fixedcvs Fixed in release: http://bugs.php.net/fix.php?id=22850&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=22850&r=needtrace Try newer version: http://bugs.php.net/fix.php?id=22850&r=oldversion Not developer issue:http://bugs.php.net/fix.php?id=22850&r=support Expected behavior: http://bugs.php.net/fix.php?id=22850&r=notwrong Not enough info:http://bugs.php.net/fix.php?id=22850&r=notenoughinfo Submitted twice:http://bugs.php.net/fix.php?id=22850&r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=22850&r=globals PHP 3 support discontinued: http://bugs.php.net/fix.php?id=22850&r=php3 Daylight Savings: http://bugs.php.net/fix.php?id=22850&r=dst IIS Stability: http://bugs.php.net/fix.php?id=22850&r=isapi Install GNU Sed:http://bugs.php.net/fix.php?id=22850&r=gnused
#22844 [Opn->Csd]: text boolean ini options set with -d do not work (on/off)
ID: 22844 Updated by: [EMAIL PROTECTED] Reported By: gk at proliberty dot com -Status: Open +Status: Closed Bug Type: CGI related Operating System: linux RH 7.2 PHP Version: 4.3.2-RC New Comment: Forgot to close ;) Previous Comments: [2003-03-24 07:58:17] [EMAIL PROTECTED] This bug has been fixed in CVS. In case this was a PHP problem, 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/. In case this was a documentation problem, the fix will show up soon at http://www.php.net/manual/. In case this was a PHP.net website problem, the change will show up on the PHP.net site and on the mirror sites in short time. Thank you for the report, and for helping us make PHP better. [2003-03-24 05:05:13] [EMAIL PROTECTED] This is actually real bug: # php -d display_errors=1 -r "f();" <-- this works # php -d display_errors=On -r "f();" <-- this is same as setting it to 0 [2003-03-24 04:55:07] gk at proliberty dot com In my php.ini file, I have: display_errors=On display_startup_errors=On In Bug #22796, I noted that display_startup_errors=On is required for proper error display using -r option; however this is a separate problem: errors not displayed if display_startup_error or display_errors is set to ANY value, with ini_set() or on the command line I demonstrate below with -d switch: [EMAIL PROTECTED] junk]$ php -d display_startup_errors=On -r "f();" [EMAIL PROTECTED] junk]$ php -d display_startup_errors=Off -r "f();" [EMAIL PROTECTED] junk]$ php -r "f();" Fatal error: Call to undefined function: f() in Command line code on line 1 [EMAIL PROTECTED] junk]$ php -d display_errors=Off -r "f();" [EMAIL PROTECTED] junk]$ php -d display_errors=On -r "f();" The same problem occurs if call ini_set() instead of using -d option: #FILE: junk.php Now, if you use boolean value instead of On/Off, it appears that if EITHER variable is set to 1, errors work but if EITHER is set to 0, they don't: [EMAIL PROTECTED] junk]$ php -d display_errors=0 -r "f();" [EMAIL PROTECTED] junk]$ php -d display_errors=1 -r "f();" Fatal error: Call to undefined function: f() in Command line code on line 1 [EMAIL PROTECTED] junk]$ php -d display_errors=On -r "f();" [EMAIL PROTECTED] junk]$ php -d display_startup_errors=1 -r "f();" Fatal error: Call to undefined function: f() in Command line code on line 1 [EMAIL PROTECTED] junk]$ php -d display_startup_errors=0 -r "f();" [EMAIL PROTECTED] junk]$ -- Edit this bug report at http://bugs.php.net/?id=22844&edit=1
#22844 [Ver->Opn]: text boolean ini options set with -d do not work (on/off)
ID: 22844 Updated by: [EMAIL PROTECTED] Reported By: gk at proliberty dot com -Status: Verified +Status: Open Bug Type: CGI related Operating System: linux RH 7.2 PHP Version: 4.3.2-RC New Comment: This bug has been fixed in CVS. In case this was a PHP problem, 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/. In case this was a documentation problem, the fix will show up soon at http://www.php.net/manual/. In case this was a PHP.net website problem, the change will show up on the PHP.net site and on the mirror sites in short time. Thank you for the report, and for helping us make PHP better. Previous Comments: [2003-03-24 05:05:13] [EMAIL PROTECTED] This is actually real bug: # php -d display_errors=1 -r "f();" <-- this works # php -d display_errors=On -r "f();" <-- this is same as setting it to 0 [2003-03-24 04:55:07] gk at proliberty dot com In my php.ini file, I have: display_errors=On display_startup_errors=On In Bug #22796, I noted that display_startup_errors=On is required for proper error display using -r option; however this is a separate problem: errors not displayed if display_startup_error or display_errors is set to ANY value, with ini_set() or on the command line I demonstrate below with -d switch: [EMAIL PROTECTED] junk]$ php -d display_startup_errors=On -r "f();" [EMAIL PROTECTED] junk]$ php -d display_startup_errors=Off -r "f();" [EMAIL PROTECTED] junk]$ php -r "f();" Fatal error: Call to undefined function: f() in Command line code on line 1 [EMAIL PROTECTED] junk]$ php -d display_errors=Off -r "f();" [EMAIL PROTECTED] junk]$ php -d display_errors=On -r "f();" The same problem occurs if call ini_set() instead of using -d option: #FILE: junk.php Now, if you use boolean value instead of On/Off, it appears that if EITHER variable is set to 1, errors work but if EITHER is set to 0, they don't: [EMAIL PROTECTED] junk]$ php -d display_errors=0 -r "f();" [EMAIL PROTECTED] junk]$ php -d display_errors=1 -r "f();" Fatal error: Call to undefined function: f() in Command line code on line 1 [EMAIL PROTECTED] junk]$ php -d display_errors=On -r "f();" [EMAIL PROTECTED] junk]$ php -d display_startup_errors=1 -r "f();" Fatal error: Call to undefined function: f() in Command line code on line 1 [EMAIL PROTECTED] junk]$ php -d display_startup_errors=0 -r "f();" [EMAIL PROTECTED] junk]$ -- Edit this bug report at http://bugs.php.net/?id=22844&edit=1
#22842 [Fbk->Opn]: Include problems under Solaris with 4.3.0
ID: 22842
User updated by: gallou at cict dot fr
Reported By: gallou at cict dot fr
-Status: Feedback
+Status: Open
Bug Type: Feature/Change Request
Operating System: Solaris
PHP Version: 4.3.0
New Comment:
This new release (CVS build 200203241230, 4.3.2) fixes this problem.
Thanks.
Sorry for the disturbance, I should have tested the latest release...
Previous Comments:
[2003-03-24 05:15:20] [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
[2003-03-24 03:47:25] gallou at cict dot fr
Hi,
I manage a web server with many hosted virtual servers. I am
experiencing problems with includes in PHP 4.3.0 under Solaris, and I
can't upgrade my server from 4.2.1. Most errors are with PHP codes
which include things from the parent directory (..), which is in
'include_path'.
Look at this test:
tests/
|- inc
|- inc.txt include OK
|- mydir/
|- testinclude.php ';
include ('inc/inc.txt'); ?>
I have two httpd working, with the same config file except the port
number (the server on 8088 loads the 4.3.0 version of libphp.so).
Safe_mode is off. Include_path is '.:../:../../' for 4.2.1.
With PHP 4.2.1,
works OK.
With 4.3.0,
gives:
Failed opening 'inc/inc.txt' for inclusion
(include_path='.:../:/usr/local/php-4.3.0/lib/php')
in /usr/local/www/docs/www/tests/mydir/testinclude.php on line 2
This seems related to a change of PHP using getcwd() in this version (I
guess). In this case, getcwd() returns nothing, since a directory is
-rwx--x--x. This is the case for most virtual server document roots.
Unlike Linux, on Solaris, getcwd() needs "r" access to _all_
directories of the path, otherwise you get (from "man getcwd"):
EACCESA parent directory cannot be read to get its name.
(It's not a bug, but a feature; seems strange to me).
"include '../inc/inc.txt'" does not work either. Apart using full
pathnames in includes, the only way I found to get it work in PHP 4.3.0
is "chmod o+r" every component of the dir path (this way, getcwd()
returns the right value, and include works). It looks like PHP 4.3.0
resolves the pathname itself, using getcwd(). Due to this feature of
Solaris, in my opinion, it's not a good idea to rely on this function
to get a real pathname. This does not affect Solaris alone, but any
system where getcwd() needs "r" access, that is HP/UX, Irix, and, I
think, most unixes.
I can't state this is a bug of PHP. But I can't upgrade my server. I
posted a message in php.install which remains unanswered. I can't tell
the webmasters to "chmod o+r" their directories or change their PHP
codes. What else can I do to be able to upgrade my server?
--
Edit this bug report at http://bugs.php.net/?id=22842&edit=1
#22574 [NoF->Opn]: unsatisfied symbols freeaddrinfo and getaddrinfo
ID: 22574 User updated by: john345 at earthlink dot net Reported By: john345 at earthlink dot net -Status: No Feedback +Status: Open Bug Type: Compile Failure Operating System: SCO OpenServer 5.0.6 PHP Version: 4.3.2-dev New Comment: Sorry for no feedback. I was not here to do any testing. The make still fails with the same two missing symbols. Here are the lines from config.log on either side of "checking for getaddrinfo". configure:14396: checking for vsnprintf configure:14424: gcc -o conftest -g -O2 conftest.c -lm -lsocket 1>&5 configure:14450: checking for getaddrinfo configure:14462: gcc -c -g -O2 conftest.c 1>&5 configure:14485: checking for strlcat configure:14513: gcc -o conftest -g -O2 conftest.c -lm -lsocket 1>&5 Previous Comments: [2003-03-24 04:16:37] [EMAIL PROTECTED] No feedback was provided. The bug is being suspended because we assume that you are no longer experiencing the problem. If this is not the case and you are able to provide the information that was requested earlier, please do so and change the status of the bug back to "Open". Thank you. [2003-03-20 18:36:24] [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 There were some libtool/SCO related changes, please try it out.. [2003-03-18 08:37:48] john345 at earthlink dot net Any ideas yet? [2003-03-13 06:56:06] john345 at earthlink dot net Here are the lines from config.log you requested. configure:14379: checking for vsnprintf configure:14407: gcc -o conftest -g -O2 conftest.c -lm -lsocket 1>&5 configure:14433: checking for getaddrinfo configure:14445: gcc -c -g -O2 conftest.c 1>&5 configure:14468: checking for strlcat [2003-03-11 21:00:38] [EMAIL PROTECTED] Okay, so in configure it's detected correctly, but during compile, it's somehow not found..check your config.log for this: "checking for getaddrinfo" And paste 2 lines before and after that line here. 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/22574 -- Edit this bug report at http://bugs.php.net/?id=22574&edit=1
#22848 [NEW]: inconsistent errors
From: themarty at hotmail dot com Operating system: Linux Redhat PHP version: 4.3.0 PHP Bug Type: Unknown/Other Function Bug description: inconsistent errors If a bug is a flaw in the code that will always result in a reproducable error by a certain act, then this is not really bug. It's very annoying nonetheless. This is the problem: Ever since we upgraded to 4.3.0 we are experiencing errors that we can't explain. Two errors are consistent in the fact that they are always the same, but in consistent in the fact that they appear - seemingly - at random. 1. is with an online form. The form consists of 9 pages and i'm using sessions to gather all the data before inserting it into a database. On average 7 people a day fill in this form and on average once every two weeks, there's one person who's data from the first two pages 'gets lost'. 2. i've written a function that will email any 'problem with a query to the database' to me and display an error on the webpage. Since i'm still developping it, i get these emails fairly often. However, sometimes the email is a big garble. I can understand any scepticism towards my programming abilities, but i'll try to make a convincing case by the following illustration: this is the part were the email is being sent to me: [php] mail( '[EMAIL PROTECTED]', 'Error in de Database', $body."\n".$getvalues."\n".$postvalues."\n\n".$computer, "From: Admin <[EMAIL PROTECTED]>\nReply-To: [EMAIL PROTECTED]"); [/php] Whatever happens before and after, i hope you agree that IF the email gets send to me, the subject should be 'Error in de Database'. It can't be different. However, in those cases where the body of my email is a garble, the subject contains fragments of what should be stored in the variable $computer. Also, another very (in my eyes convincing example) is that just 30 minutes ago something strange happened (which triggered me into responding: That Does It!! :) I've created a message system for registered users. When inserting a message into the database it inserts a timestamp generated by php (i have my reasons for not using the DATETIME type column). The timestamp is created by [php] date(YmdHis) [/php] After over 500 correct messages, today one gets inserted as date(Ymdhis). Instead of 13 it got 01 for hours. I hope this bug-report is helpfull and if anyone has experienced similar problems, i would appreciate some feedback. -- Edit bug report at http://bugs.php.net/?id=22848&edit=1 -- Try a CVS snapshot: http://bugs.php.net/fix.php?id=22848&r=trysnapshot Fixed in CVS: http://bugs.php.net/fix.php?id=22848&r=fixedcvs Fixed in release: http://bugs.php.net/fix.php?id=22848&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=22848&r=needtrace Try newer version: http://bugs.php.net/fix.php?id=22848&r=oldversion Not developer issue:http://bugs.php.net/fix.php?id=22848&r=support Expected behavior: http://bugs.php.net/fix.php?id=22848&r=notwrong Not enough info:http://bugs.php.net/fix.php?id=22848&r=notenoughinfo Submitted twice:http://bugs.php.net/fix.php?id=22848&r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=22848&r=globals PHP 3 support discontinued: http://bugs.php.net/fix.php?id=22848&r=php3 Daylight Savings: http://bugs.php.net/fix.php?id=22848&r=dst IIS Stability: http://bugs.php.net/fix.php?id=22848&r=isapi Install GNU Sed:http://bugs.php.net/fix.php?id=22848&r=gnused
#22838 [Opn->Bgs]: bcpowmod doesn't exist
ID: 22838 Updated by: [EMAIL PROTECTED] Reported By: genewarner at netzero dot net -Status: Open +Status: Bogus Bug Type: BC math related Operating System: Windows XP Pro SP1 PHP Version: 4.3.1 New Comment: Not a bug, the function will appear first in PHP 5. (As said in the manual page for it..) Previous Comments: [2003-03-24 02:11:34] genewarner at netzero dot net All the bcmath functions work except for bcpowmod. Any attempt to use it generates an undefined function error. I just downloaded and installed the Windows 32 binaries. The only changes made to php.ini are to enable Active State's Komodo debugging and background syntax checking. Any thoughts? Thanks. -- Edit this bug report at http://bugs.php.net/?id=22838&edit=1
#22839 [Opn->Bgs]: Error messages go to STDOUT instead of STDERR
ID: 22839 Updated by: [EMAIL PROTECTED] Reported By: gk at proliberty dot com -Status: Open +Status: Bogus Bug Type: CGI related Operating System: linux RH 7.2 PHP Version: 4CVS-2003-03-24 (stable) New Comment: Works fine when you have set it correctly in php.ini: # php -d log_errors=1 -d error_log=/dev/stderr -r "f();" 1>/dev/null Previous Comments: [2003-03-24 02:14:59] gk at proliberty dot com Error messages should go to /dev/stderr instead of /dev/stdout Example: redirect STDOUT to /dev/null; notice error message does not appear below: [EMAIL PROTECTED] php4-STABLE-200303210630]# sapi/cli/php -r "f();" 1>/dev/null [EMAIL PROTECTED] php4-STABLE-200303210630]# This is what you should see on /dev/stderr: [EMAIL PROTECTED] php4-STABLE-200303210630]# sapi/cli/php -r "f();" Fatal error: Call to undefined function: f() in Command line code on line 1 The problem is due to the default error handler; if you install a custom error handler function with set_error_handler() then you can work around the problem for errors except the following which CANNOT be handled with set_error_handler() function: E_ERROR, E_PARSE, E_CORE_ERROR, E_CORE_WARNING, E_COMPILE_ERROR and E_COMPILE_WARNING. -- Edit this bug report at http://bugs.php.net/?id=22839&edit=1
#22837 [Opn->WFx]: stream_set_timeout() does not work on stdin
ID: 22837
Updated by: [EMAIL PROTECTED]
Reported By: gavin at itmerge dot com
-Status: Open
+Status: Wont fix
Bug Type: Filesystem function related
Operating System: Linux Kernel 2.4.18
PHP Version: 4.3.1
New Comment:
This wont be fixed in 4.3.x; you can use stream_select() instead.
PHP5 will have better general support for stream_set_timeout().
Previous Comments:
[2003-03-24 00:59:51] gavin at itmerge dot com
/* in php 4.3 with the CLI interface
STDIN is predefined */
$auth=0;
stream_set_timeout(STDIN,61);
$time=time();
while ($auth==0 && time()<$time+60) {
while(!feof(STDIN) && $auth==0 && time()<$time+60) {
$test=fgets(STDIN,1024);
}
}
if (time()>=$time+60) echo "You have timedout\n";
/* I never get to the above line
because It sits there at fgets never timing out.
i've tried
set_time_limit(60) and ini_set("max_execution_time",60)
but nothing will stop the script from executing.
i'm running this script thru tcpd
if it gets stuck waiting for input i have to manually kill
all the processes, gets very very icky. :(
btw. i've also tried $stdin=fopen("php://stdin","r");
stream_set_timeout($stdin,61);
ps. i know it's new :), i know it says "potentially"
*/
--
Edit this bug report at http://bugs.php.net/?id=22837&edit=1
#22846 [Opn->Fbk]: for fastcgi not check redirect_url
ID: 22846 Updated by: [EMAIL PROTECTED] Reported By: maxes at peterlink dot ru -Status: Open +Status: Feedback Bug Type: CGI related Operating System: FreeBSD-4.7 PHP Version: 4.3.1 New Comment: 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 Previous Comments: [2003-03-24 05:45:39] maxes at peterlink dot ru part of apache 1.3.27 httpd.conf: SetHandler fastcgi-script Options +ExecCGI DocumentRoot /ftp/tst2 ... Alias /f-php4/ /usr/local/php4/bin/ AddType application/x-httpd-fastphp .fphp Action application/x-httpd-fastphp /f-php4/php Binary php4 put in /usr/local/php4/bin/php document root has next file: /ftp/tst2/.htaccess Now call: http://virtualhost/f-php4/php/.htaccess php4 configured with: --enable-fastcgi --enable-force-cgi-redirect solutions: For fastcgi put all enviroment check() after FCGX_Accept_r() b.r. -- Edit this bug report at http://bugs.php.net/?id=22846&edit=1
#22847 [NEW]: Reference don't work in sort callbacks
From: jparneodo at yahoo dot fr
Operating system: RH7.2
PHP version: 4.3.0
PHP Bug Type: Arrays related
Bug description: Reference don't work in sort callbacks
function cmp($a,$b){
global $g;
var_dump($g); // NULL here
if($g[$a]>$g[$b]){
return -1;
}elseif($g[$a]<$g[$b]){
return 1;
}else{
return 0;
}
}
class A {
var $aa=array('B'=>2,'A'=>1,'C'=>3);
function sortme(){
global $g;
$g=&$this->aa;
uksort($g,'cmp');
}
}
$a=new A;
$a->sortme(); // Don't work
$g=&$a->aa;
uksort($g,'cmp'); // Work
--
Edit bug report at http://bugs.php.net/?id=22847&edit=1
--
Try a CVS snapshot: http://bugs.php.net/fix.php?id=22847&r=trysnapshot
Fixed in CVS: http://bugs.php.net/fix.php?id=22847&r=fixedcvs
Fixed in release: http://bugs.php.net/fix.php?id=22847&r=alreadyfixed
Need backtrace: http://bugs.php.net/fix.php?id=22847&r=needtrace
Try newer version: http://bugs.php.net/fix.php?id=22847&r=oldversion
Not developer issue:http://bugs.php.net/fix.php?id=22847&r=support
Expected behavior: http://bugs.php.net/fix.php?id=22847&r=notwrong
Not enough info:http://bugs.php.net/fix.php?id=22847&r=notenoughinfo
Submitted twice:http://bugs.php.net/fix.php?id=22847&r=submittedtwice
register_globals: http://bugs.php.net/fix.php?id=22847&r=globals
PHP 3 support discontinued: http://bugs.php.net/fix.php?id=22847&r=php3
Daylight Savings: http://bugs.php.net/fix.php?id=22847&r=dst
IIS Stability: http://bugs.php.net/fix.php?id=22847&r=isapi
Install GNU Sed:http://bugs.php.net/fix.php?id=22847&r=gnused
#22846 [NEW]: for fastcgi not check redirect_url
From: maxes at peterlink dot ru Operating system: FreeBSD-4.7 PHP version: 4.3.1 PHP Bug Type: CGI related Bug description: for fastcgi not check redirect_url part of apache 1.3.27 httpd.conf: SetHandler fastcgi-script Options +ExecCGI DocumentRoot /ftp/tst2 ... Alias /f-php4/ /usr/local/php4/bin/ AddType application/x-httpd-fastphp .fphp Action application/x-httpd-fastphp /f-php4/php Binary php4 put in /usr/local/php4/bin/php document root has next file: /ftp/tst2/.htaccess Now call: http://virtualhost/f-php4/php/.htaccess php4 configured with: --enable-fastcgi --enable-force-cgi-redirect solutions: For fastcgi put all enviroment check() after FCGX_Accept_r() b.r. -- Edit bug report at http://bugs.php.net/?id=22846&edit=1 -- Try a CVS snapshot: http://bugs.php.net/fix.php?id=22846&r=trysnapshot Fixed in CVS: http://bugs.php.net/fix.php?id=22846&r=fixedcvs Fixed in release: http://bugs.php.net/fix.php?id=22846&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=22846&r=needtrace Try newer version: http://bugs.php.net/fix.php?id=22846&r=oldversion Not developer issue:http://bugs.php.net/fix.php?id=22846&r=support Expected behavior: http://bugs.php.net/fix.php?id=22846&r=notwrong Not enough info:http://bugs.php.net/fix.php?id=22846&r=notenoughinfo Submitted twice:http://bugs.php.net/fix.php?id=22846&r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=22846&r=globals PHP 3 support discontinued: http://bugs.php.net/fix.php?id=22846&r=php3 Daylight Savings: http://bugs.php.net/fix.php?id=22846&r=dst IIS Stability: http://bugs.php.net/fix.php?id=22846&r=isapi Install GNU Sed:http://bugs.php.net/fix.php?id=22846&r=gnused
#14877 [Com]: HTTP_FDF_DATA not available (php_fdf.dll crashes)
ID: 14877 Comment by: rui dot gouveia at elementodigital dot pt Reported By: cg at gordimer dot net Status: Assigned Bug Type: FDF related Operating System: XP Pro PHP Version: 4.3.2-RC Assigned To: hholzgra New Comment: It's true it works with 4.2.3... but... 4.2.3 has another bug (see http://bugs.php.net/bug.php?id=20174) that prevents upload of big files! I'm trapped... I need 4.2.3 to work with FDF... but I need higher than that to work with submission of big FDF´s?!?!?! Somebody help? Thanks Previous Comments: [2003-03-20 14:40:25] cg at gordimer dot net Verified with old binaries: up to 4.07dev the extension works, in 4.1.x it does not, in 4.2.x it does again, in 4.3.x and in PHP5 it does not. Would be cool to see a working extension in 4.3.x - because there will perhaps be a long time until a next stable version... [2003-03-19 17:50:49] jharrell at dlc4me dot com fdftk ... php_fdf.dll works great in and so far only in (with regard to win32 only)... 4.2.3... saved me from creating my own fdf objects... %FDF-1.2 %âãÏÓ 1 0 obj << /FDF << /Fields [2003-03-19 17:04:11] jharrell at dlc4me dot com php_fdf.dll possibly works in: php-4.2.3-Win32 (i have not scripted anything yet but... phpinfo() works...) [2003-03-19 16:44:42] jharrell at dlc4me dot com php_fdf.dll also crashes in: php5-win32-200303191930 [2003-03-19 16:06:06] jharrell at dlc4me dot com I'm getting the same crash with todays snapshot...[php4-win32-STABLE-200303191730] with php_fdf.dll uncommented I cannot get phpinfo() to do anything but crash. I sure hope this gets fixed soon... I moved to linux for a few months to continue with production, but my server runs php/Win2k... :( 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/14877 -- Edit this bug report at http://bugs.php.net/?id=14877&edit=1
#22845 [Opn->Csd]: including file using relative path failed in PHP 4.3.1
ID: 22845 Updated by: [EMAIL PROTECTED] Reported By: horris_tse at aieseccuhk dot net -Status: Open +Status: Closed Bug Type: *General Issues Operating System: Solaris 8 PHP Version: 4.3.1 New Comment: This bug has been fixed in CVS. In case this was a PHP problem, 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/. In case this was a documentation problem, the fix will show up soon at http://www.php.net/manual/. In case this was a PHP.net website problem, the change will show up on the PHP.net site and on the mirror sites in short time. Thank you for the report, and for helping us make PHP better. Previous Comments: [2003-03-24 05:19:08] horris_tse at aieseccuhk dot net (tried listed bug reports but still can't solve this) Configuration: PHP 4.3.1 with mbstring enabled, mysql, apache dynamic module Abstract of the script: 4.0 and the version I just installed is the lastest! Should anyone be able to help me solve this strange problem, it would be very much appreciated. Billions of thanks in advance. -- Edit this bug report at http://bugs.php.net/?id=22845&edit=1
#22841 [Opn->Csd]: README.EXT_SKEL incomplete (Fix included)
ID: 22841 Updated by: [EMAIL PROTECTED] Reported By: php-bugs at martinjansen dot com -Status: Open +Status: Closed Bug Type: *General Issues Operating System: Linux PHP Version: 5CVS-2003-03-24 (dev) New Comment: This bug has been fixed in CVS. In case this was a PHP problem, 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/. In case this was a documentation problem, the fix will show up soon at http://www.php.net/manual/. In case this was a PHP.net website problem, the change will show up on the PHP.net site and on the mirror sites in short time. Thank you for the report, and for helping us make PHP better. Previous Comments: [2003-03-24 03:28:43] php-bugs at martinjansen dot com The documentation in README.EXT_SKEL concerning (g)awk on Debian is incomplete. The included diff "fixes" this. Index: README.EXT_SKEL === RCS file: /repository/php4/README.EXT_SKEL,v retrieving revision 1.10 diff -u -r1.10 README.EXT_SKEL --- README.EXT_SKEL 13 Mar 2003 09:02:13 - 1.10 +++ README.EXT_SKEL 24 Mar 2003 10:21:08 - @@ -20,7 +20,8 @@ [ Note that GNU awk is likely required for this script to work. Debian systems seem to default to using mawk, so you may need to change the -#! line in skeleton/create_stubs to use gawk explicitly. ] +#! line in skeleton/create_stubs and the cat $proto | awk line in +ext_skel to use gawk explicitly. ] If you don't need to test the existence of any external header files, libraries or functions in them, the module is already almost ready to be -- Edit this bug report at http://bugs.php.net/?id=22841&edit=1
#22845 [NEW]: including file using relative path failed in PHP 4.3.1
From: horris_tse at aieseccuhk dot net Operating system: Solaris 8 PHP version: 4.3.1 PHP Bug Type: *General Issues Bug description: including file using relative path failed in PHP 4.3.1 (tried listed bug reports but still can't solve this) Configuration: PHP 4.3.1 with mbstring enabled, mysql, apache dynamic module Abstract of the script: 4.0 and the version I just installed is the lastest! Should anyone be able to help me solve this strange problem, it would be very much appreciated. Billions of thanks in advance. -- Edit bug report at http://bugs.php.net/?id=22845&edit=1 -- Try a CVS snapshot: http://bugs.php.net/fix.php?id=22845&r=trysnapshot Fixed in CVS: http://bugs.php.net/fix.php?id=22845&r=fixedcvs Fixed in release: http://bugs.php.net/fix.php?id=22845&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=22845&r=needtrace Try newer version: http://bugs.php.net/fix.php?id=22845&r=oldversion Not developer issue:http://bugs.php.net/fix.php?id=22845&r=support Expected behavior: http://bugs.php.net/fix.php?id=22845&r=notwrong Not enough info:http://bugs.php.net/fix.php?id=22845&r=notenoughinfo Submitted twice:http://bugs.php.net/fix.php?id=22845&r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=22845&r=globals PHP 3 support discontinued: http://bugs.php.net/fix.php?id=22845&r=php3 Daylight Savings: http://bugs.php.net/fix.php?id=22845&r=dst IIS Stability: http://bugs.php.net/fix.php?id=22845&r=isapi Install GNU Sed:http://bugs.php.net/fix.php?id=22845&r=gnused
#22832 [Opn]: imap_rfc822_write_address returns extra "" when no personal
ID: 22832
User updated by: marko at oblo dot com
Reported By: marko at oblo dot com
Status: Open
Bug Type: IMAP related
Operating System: FreeBSD 4.7-RELEASE-p6
PHP Version: 4.3.1
New Comment:
ps. oh and if i'm right, that nothing has changed between the two
versions and the call goes out of php, then go ahead and close the bug.
Previous Comments:
[2003-03-24 05:16:59] marko at oblo dot com
cvs version
ok, but won't get a chance to reinstall it for a week or so.
c-client
phpinfo() says:
IMAP c-Client Version 2001
maybe i should try changing c-client version, since looking at the
source this morning, i couldn't see anything changed in the function
between 4.2.3 and 4.3.1, so it must be something outside php. the call
rfc822_write_address() towards the end i presume goes to the c-client?
thanks
marko
[2003-03-24 03:21:42] [EMAIL PROTECTED]
And it pretty much depends on the c-client version used too..
[2003-03-23 19:22:06] [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
In latest CVS snapshot it appears to return just: [EMAIL PROTECTED]
[2003-03-23 15:42:50] marko at oblo dot com
In php 4.3.1 the imap_rfc822_write_address() function seems to return
extra double quotes "" when there is no personal value.
For example:
imap_rfc822_write_address('marko', 'oblo.com', '')
would output:
"" <[EMAIL PROTECTED]>
when in php 4.2.3 it would rightly only output:
<[EMAIL PROTECTED]>
Regards,
Marko
--
Edit this bug report at http://bugs.php.net/?id=22832&edit=1
#22832 [Opn->Bgs]: imap_rfc822_write_address returns extra "" when no personal
ID: 22832
Updated by: [EMAIL PROTECTED]
Reported By: marko at oblo dot com
-Status: Open
+Status: Bogus
Bug Type: IMAP related
Operating System: FreeBSD 4.7-RELEASE-p6
PHP Version: 4.3.1
New Comment:
Yes, the PHP side of the code hasn't changed for a long time.
So it's definately c-client problem and not PHP problem.
Previous Comments:
[2003-03-24 05:18:38] [EMAIL PROTECTED]
Yes, the PHP side of the code hasn't changed for a long time.
So it's definately c-client problem and not PHP problem.
[2003-03-24 05:16:59] marko at oblo dot com
cvs version
ok, but won't get a chance to reinstall it for a week or so.
c-client
phpinfo() says:
IMAP c-Client Version 2001
maybe i should try changing c-client version, since looking at the
source this morning, i couldn't see anything changed in the function
between 4.2.3 and 4.3.1, so it must be something outside php. the call
rfc822_write_address() towards the end i presume goes to the c-client?
thanks
marko
[2003-03-24 03:21:42] [EMAIL PROTECTED]
And it pretty much depends on the c-client version used too..
[2003-03-23 19:22:06] [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
In latest CVS snapshot it appears to return just: [EMAIL PROTECTED]
[2003-03-23 15:42:50] marko at oblo dot com
In php 4.3.1 the imap_rfc822_write_address() function seems to return
extra double quotes "" when there is no personal value.
For example:
imap_rfc822_write_address('marko', 'oblo.com', '')
would output:
"" <[EMAIL PROTECTED]>
when in php 4.2.3 it would rightly only output:
<[EMAIL PROTECTED]>
Regards,
Marko
--
Edit this bug report at http://bugs.php.net/?id=22832&edit=1
#22832 [Fbk->Opn]: imap_rfc822_write_address returns extra "" when no personal
ID: 22832
User updated by: marko at oblo dot com
Reported By: marko at oblo dot com
-Status: Feedback
+Status: Open
Bug Type: IMAP related
Operating System: FreeBSD 4.7-RELEASE-p6
PHP Version: 4.3.1
New Comment:
cvs version
ok, but won't get a chance to reinstall it for a week or so.
c-client
phpinfo() says:
IMAP c-Client Version 2001
maybe i should try changing c-client version, since looking at the
source this morning, i couldn't see anything changed in the function
between 4.2.3 and 4.3.1, so it must be something outside php. the call
rfc822_write_address() towards the end i presume goes to the c-client?
thanks
marko
Previous Comments:
[2003-03-24 03:21:42] [EMAIL PROTECTED]
And it pretty much depends on the c-client version used too..
[2003-03-23 19:22:06] [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
In latest CVS snapshot it appears to return just: [EMAIL PROTECTED]
[2003-03-23 15:42:50] marko at oblo dot com
In php 4.3.1 the imap_rfc822_write_address() function seems to return
extra double quotes "" when there is no personal value.
For example:
imap_rfc822_write_address('marko', 'oblo.com', '')
would output:
"" <[EMAIL PROTECTED]>
when in php 4.2.3 it would rightly only output:
<[EMAIL PROTECTED]>
Regards,
Marko
--
Edit this bug report at http://bugs.php.net/?id=22832&edit=1
#22842 [Opn->Fbk]: Include problems under Solaris with 4.3.0
ID: 22842
Updated by: [EMAIL PROTECTED]
Reported By: gallou at cict dot fr
-Status: Open
+Status: Feedback
Bug Type: Feature/Change Request
Operating System: Solaris
PHP Version: 4.3.0
New Comment:
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
Previous Comments:
[2003-03-24 03:47:25] gallou at cict dot fr
Hi,
I manage a web server with many hosted virtual servers. I am
experiencing problems with includes in PHP 4.3.0 under Solaris, and I
can't upgrade my server from 4.2.1. Most errors are with PHP codes
which include things from the parent directory (..), which is in
'include_path'.
Look at this test:
tests/
|- inc
|- inc.txt include OK
|- mydir/
|- testinclude.php ';
include ('inc/inc.txt'); ?>
I have two httpd working, with the same config file except the port
number (the server on 8088 loads the 4.3.0 version of libphp.so).
Safe_mode is off. Include_path is '.:../:../../' for 4.2.1.
With PHP 4.2.1,
works OK.
With 4.3.0,
gives:
Failed opening 'inc/inc.txt' for inclusion
(include_path='.:../:/usr/local/php-4.3.0/lib/php')
in /usr/local/www/docs/www/tests/mydir/testinclude.php on line 2
This seems related to a change of PHP using getcwd() in this version (I
guess). In this case, getcwd() returns nothing, since a directory is
-rwx--x--x. This is the case for most virtual server document roots.
Unlike Linux, on Solaris, getcwd() needs "r" access to _all_
directories of the path, otherwise you get (from "man getcwd"):
EACCESA parent directory cannot be read to get its name.
(It's not a bug, but a feature; seems strange to me).
"include '../inc/inc.txt'" does not work either. Apart using full
pathnames in includes, the only way I found to get it work in PHP 4.3.0
is "chmod o+r" every component of the dir path (this way, getcwd()
returns the right value, and include works). It looks like PHP 4.3.0
resolves the pathname itself, using getcwd(). Due to this feature of
Solaris, in my opinion, it's not a good idea to rely on this function
to get a real pathname. This does not affect Solaris alone, but any
system where getcwd() needs "r" access, that is HP/UX, Irix, and, I
think, most unixes.
I can't state this is a bug of PHP. But I can't upgrade my server. I
posted a message in php.install which remains unanswered. I can't tell
the webmasters to "chmod o+r" their directories or change their PHP
codes. What else can I do to be able to upgrade my server?
--
Edit this bug report at http://bugs.php.net/?id=22842&edit=1
#22843 [Opn->Bgs]: non-workable XML and XLST functions
ID: 22843 Updated by: [EMAIL PROTECTED] Reported By: chros at freemail dot hu -Status: Open +Status: Bogus Bug Type: *XML functions Operating System: Windows XP build2600 PHP Version: 4.3.1 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. Thank you for your interest in PHP. Ask such questions elsewhere. None of these are bugs. Previous Comments: [2003-03-24 03:50:49] chros at freemail dot hu I'm new to XML ... I've tried several scipts, but nothing worked (Expat method). For example: the script in PHP manual in the XML section: 1st example, with this small xml file: We Were Soldiers http://www.hollywood.com";>Vietnam movie staring Mel Gibson 1st error: XML error: syntax error at line 1 column 14 (if I delete the 1. row, it's OK.) 2nd error: XML error: not well-formed (invalid token) at line 3 column 16 (something goes wrong with the attributes ..., if I delete this, it's OK.) I have tried this on Linux, and everything goes well: Linux (2.4.16) PHP 4.1.2 Apache 1.3.23 I'have tried the xlst_create() function too: Undefined functuin ... (but I have copied all the dll files from distribution dir to windows/system32 ) System: WinXP build2600 PHP 4.3.1 win32 (zipped file) Apache 1.3.27 win32 ABIT KT7A motherboard AMD Thunderbird 1.3GHz CPU -- Edit this bug report at http://bugs.php.net/?id=22843&edit=1
#22844 [Bgs->Ver]: text boolean ini options set with -d do not work (on/off)
ID: 22844 Updated by: [EMAIL PROTECTED] -Summary: errors not displayed if display_startup_error or display_errors is set to ANY v Reported By: gk at proliberty dot com -Status: Bogus +Status: Verified Bug Type: CGI related Operating System: linux RH 7.2 -PHP Version: 4CVS-2003-03-24 (stable) +PHP Version: 4.3.2-RC New Comment: This is actually real bug: # php -d display_errors=1 -r "f();" <-- this works # php -d display_errors=On -r "f();" <-- this is same as setting it to 0 Previous Comments: [2003-03-24 05:00:47] [EMAIL PROTECTED] Please do not submit the same bug more than once. An existing bug report already describes this very problem. Even if you feel that your issue is somewhat different, the resolution is likely to be the same. Because of this, we hope you add your comments to the existing bug instead. Thank you for your interest in PHP. No need for another report about same issue. [2003-03-24 04:55:07] gk at proliberty dot com In my php.ini file, I have: display_errors=On display_startup_errors=On In Bug #22796, I noted that display_startup_errors=On is required for proper error display using -r option; however this is a separate problem: errors not displayed if display_startup_error or display_errors is set to ANY value, with ini_set() or on the command line I demonstrate below with -d switch: [EMAIL PROTECTED] junk]$ php -d display_startup_errors=On -r "f();" [EMAIL PROTECTED] junk]$ php -d display_startup_errors=Off -r "f();" [EMAIL PROTECTED] junk]$ php -r "f();" Fatal error: Call to undefined function: f() in Command line code on line 1 [EMAIL PROTECTED] junk]$ php -d display_errors=Off -r "f();" [EMAIL PROTECTED] junk]$ php -d display_errors=On -r "f();" The same problem occurs if call ini_set() instead of using -d option: #FILE: junk.php Now, if you use boolean value instead of On/Off, it appears that if EITHER variable is set to 1, errors work but if EITHER is set to 0, they don't: [EMAIL PROTECTED] junk]$ php -d display_errors=0 -r "f();" [EMAIL PROTECTED] junk]$ php -d display_errors=1 -r "f();" Fatal error: Call to undefined function: f() in Command line code on line 1 [EMAIL PROTECTED] junk]$ php -d display_errors=On -r "f();" [EMAIL PROTECTED] junk]$ php -d display_startup_errors=1 -r "f();" Fatal error: Call to undefined function: f() in Command line code on line 1 [EMAIL PROTECTED] junk]$ php -d display_startup_errors=0 -r "f();" [EMAIL PROTECTED] junk]$ -- Edit this bug report at http://bugs.php.net/?id=22844&edit=1
#22774 [Com]: PHP crashes when exiting (long XML doc)
ID: 22774 Comment by: rrichards at digarc dot com Reported By: fgarcia at uef dot es Status: Open Bug Type: DOM XML related Operating System: Windows 2000 PHP Version: 4.3.2RC1 New Comment: Am not able to reproduce in Win 2K. Ran it for 10,000 and 20,000 iterations without a problem. Finally ran it for 1,000,000 iterations until the machine ran out of memory (was over a Gig of used memory at that point). Once getting a fatal emalloc error memory returned back to normal (exact amount used prior to running). Tested against latest cvs code as well as a php4-3.0-dev build from jun 2002. using libxml2-2.4.22 Previous Comments: [2003-03-21 05:43:43] [EMAIL PROTECTED] looks like a mem-leak linux normally doesn't segfault on memleaks. Windows does... that's the difference ;) I try to look at it [2003-03-21 04:31:56] fgarcia at uef dot es If you see DrWatson output there is the function zend_timeout I don't know if that matchs something. [2003-03-21 04:28:48] fgarcia at uef dot es I've updated to 4.3.2-RC1 version, and updated php4ts.dll on winnt/system Same bug. php -v: PHP 4.3.2-RC (cgi-fcgi), Copyright (c) 1997-2003 The PHP Group Zend Engine v1.3.0, Copyright (c) 1998-2003 Zend Technologies [2003-03-20 17:47:43] [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 And make sure you really update it. Especially the php4ts.dll file. [2003-03-20 11:32:41] fgarcia at uef dot es DrWatson output: (in spanish, sorry) Excepción de aplicación ocurrida: Aplicación: (pid=2100) Fecha y hora: 20/03/2003 a las 18:32:17.205 Número de excepción: c005 (infracción de acceso) *> Información del sistema <* Nombre de equipo: UP086817 Nombre de usuario: UF265250 Número de procesadores: 1 Tipo de procesador: x86 Family 6 Model 8 Stepping 6 Versión de Windows 2000 : 5.0 Versión actual: 2195 Service Pack: 1 Tipo actual: Uniprocessor Free Organización registrada: Unión Fenosa Propietario registrado: Unión Fenosa *> Lista de tareas <* 0 Idle.exe 8 System.exe 140 SMSS.exe 164 csrss.exe 184 WINLOGON.exe 212 services.exe 224 LSASS.exe 388 svchost.exe 416 SPOOLSV.exe 504 svchost.exe 588 regsvc.exe 604 mstask.exe 616 trcboot.exe 668 WinMgmt.exe 764 pcs_agnt.exe 752 naimas32.exe 1828 wpctrl.exe 1776 naimag32.exe 1804 editplus.exe 680 CMD.exe 1796 taskmgr.exe 1232 CMD.exe 532 NLNOTES.exe 1876 msaccess.exe 488 Avsynmgr.exe 696 VSStat.exe 804 vshwin32.exe 892 Mcshield.exe 880 Avconsol.exe 1696 notepad.exe 684 ExamDiff.exe 2072 msaccess.exe 1020 explorer.exe 1012 netadmin.exe 1268 netadmin.exe 1560 hh.exe 2192 winhlp32.exe 2124 DRWTSN32.exe 2016 DRWTSN32.exe 2100 php.exe 196 DRWTSN32.exe 0 _Total.exe (0040 - 00405000) (77F8 - 7800) (1000 - 10127000) (77E8 - 77F3F000) (77E1 - 77E74000) (77F4 - 77F7C000) (7500 - 75009000) (74FE - 74FF4000) (7800 - 78046000) (77DB - 77E0A000) (77D4 - 77DB) (74FD - 74FD8000) (77A5 - 77B45000) (779B - 77A45000) (1F7D - 1F804000) (76B1 - 76B4D000) (77C7 - 77CBA000) (77B5 - 77BD9000) (7759 - 777D8000) (1F8C - 1F8D8000) (00FD - 0102C000) (0103 - 01043000) Muestra de estado para identificador de subproceso 0x808 eax=0118ee78 ebx=00862518 ecx=0001 edx=0012fb54 esi=00e18ec8 edi=00862518 eip=00fd1bc7 esp=0012fb3c ebp=00df5778 iopl=0 nv up ei pl nz na po nc cs=001b ss=0023 ds=0023 es=0023 fs=0038 gs= efl=0206 función: 00fd1bb9 5e pop esi 00fd1bba c3 ret 00fd1bbb 90 nop 00fd1bbc 90 nop 00fd1bbd 90 nop 00fd1bbe 90 nop 00fd1bbf 90 nop 00fd1bc0 8b442404 mov eax,[esp+0x4] ss:00bfd113= 00fd1bc4 56 pushesi 00fd1bc5 8b30 mov esi,[eax] ds:0118ee78=00e18ec8 ERROR -> 00fd1bc7 8b4614 mov eax,[esi+0x14] ds:018e649e= 00fd1bca 85c0 testeax,eax 00fd1bcc 751a jnz 00fda6e8 00fd1bce 8b4e0c mov ecx,[esi+0xc] ds:018e649e= 00fd1bd1 51 pushecx 00fd1bd2 e879ff c
#22844 [Opn->Bgs]: errors not displayed if display_startup_error or display_errors is set to ANY v
ID: 22844 Updated by: [EMAIL PROTECTED] Reported By: gk at proliberty dot com -Status: Open +Status: Bogus Bug Type: CGI related Operating System: linux RH 7.2 PHP Version: 4CVS-2003-03-24 (stable) New Comment: Please do not submit the same bug more than once. An existing bug report already describes this very problem. Even if you feel that your issue is somewhat different, the resolution is likely to be the same. Because of this, we hope you add your comments to the existing bug instead. Thank you for your interest in PHP. No need for another report about same issue. Previous Comments: [2003-03-24 04:55:07] gk at proliberty dot com In my php.ini file, I have: display_errors=On display_startup_errors=On In Bug #22796, I noted that display_startup_errors=On is required for proper error display using -r option; however this is a separate problem: errors not displayed if display_startup_error or display_errors is set to ANY value, with ini_set() or on the command line I demonstrate below with -d switch: [EMAIL PROTECTED] junk]$ php -d display_startup_errors=On -r "f();" [EMAIL PROTECTED] junk]$ php -d display_startup_errors=Off -r "f();" [EMAIL PROTECTED] junk]$ php -r "f();" Fatal error: Call to undefined function: f() in Command line code on line 1 [EMAIL PROTECTED] junk]$ php -d display_errors=Off -r "f();" [EMAIL PROTECTED] junk]$ php -d display_errors=On -r "f();" The same problem occurs if call ini_set() instead of using -d option: #FILE: junk.php Now, if you use boolean value instead of On/Off, it appears that if EITHER variable is set to 1, errors work but if EITHER is set to 0, they don't: [EMAIL PROTECTED] junk]$ php -d display_errors=0 -r "f();" [EMAIL PROTECTED] junk]$ php -d display_errors=1 -r "f();" Fatal error: Call to undefined function: f() in Command line code on line 1 [EMAIL PROTECTED] junk]$ php -d display_errors=On -r "f();" [EMAIL PROTECTED] junk]$ php -d display_startup_errors=1 -r "f();" Fatal error: Call to undefined function: f() in Command line code on line 1 [EMAIL PROTECTED] junk]$ php -d display_startup_errors=0 -r "f();" [EMAIL PROTECTED] junk]$ -- Edit this bug report at http://bugs.php.net/?id=22844&edit=1
#22840 [Opn->Bgs]: session file won't be deleted when session_destroy used
ID: 22840
Updated by: [EMAIL PROTECTED]
Reported By: chair123 at 163 dot net
-Status: Open
+Status: Bogus
Bug Type: Session related
Operating System: win2000pro
PHP Version: 4.3.1
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.
Thank you for your interest in PHP.
header("Location: somefile.php"); is invalid anyway..
Previous Comments:
[2003-03-24 04:55:35] chair123 at 163 dot net
got the problem...
If I use
echo " window.location.href='chksession.php' ";
instead of header(¡°location: chksession.php"),
that's all right.
It must be a bug in win2000pro
[2003-03-24 02:27:42] chair123 at 163 dot net
session.php
chksession.php
when I type http://127.0.0.1/session.php in IE frist, It's nothing in
the screen. NO session file in directory c:\php\sessiondata.
I typed in second time, it 's "9Chair" in the screen(the same IE).
and sess_7e2ebd21da6d67c7e9f3860ae7c60a6 file in there. and whatever
you chang your php file , the session file never been removed! and I
put the php file in redhat 8.0, all is right. please give me a hand.
--
Edit this bug report at http://bugs.php.net/?id=22840&edit=1
#22840 [Opn]: session file won't be deleted when session_destroy used
ID: 22840 User updated by: chair123 at 163 dot net Reported By: chair123 at 163 dot net Status: Open Bug Type: Session related Operating System: win2000pro PHP Version: 4.3.1 New Comment: got the problem... If I use echo " window.location.href='chksession.php' "; instead of header(¡°location: chksession.php"), that's all right. It must be a bug in win2000pro Previous Comments: [2003-03-24 02:27:42] chair123 at 163 dot net session.php chksession.php when I type http://127.0.0.1/session.php in IE frist, It's nothing in the screen. NO session file in directory c:\php\sessiondata. I typed in second time, it 's "9Chair" in the screen(the same IE). and sess_7e2ebd21da6d67c7e9f3860ae7c60a6 file in there. and whatever you chang your php file , the session file never been removed! and I put the php file in redhat 8.0, all is right. please give me a hand. -- Edit this bug report at http://bugs.php.net/?id=22840&edit=1
