#20801 [Opn-Fbk]: undefined symbol: xml_utf8_decode
ID: 20801 Updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] -Status: Open +Status: Feedback Bug Type: Apache related Operating System: Linux/Debian PHP Version: 4.2.3 New Comment: Please try using this CVS snapshot: http://snaps.php.net/php4-latest.tar.gz For Windows: http://snaps.php.net/win32/php4-win32-latest.zip Previous Comments: [2002-12-03 16:06:59] [EMAIL PROTECTED] I've compiled PHP 4.2.3, patched to work with GD2, as an apache module. I'm using apache-ssl, and when I try to start it, it gives me the following error: Starting web server: apache-sslSyntax error on line 243 of /etc/apache-ssl/httpd.conf: Cannot load /usr/lib/apache/1.3/libphp4.so into server: /usr/lib/apache/1.3/libphp4.so: undefined symbol: xml_utf8_decode failed compiled with: ./configure --prefix=/usr --with-regex=php --with-config-file-path=/etc/php4/apache --with-apxs=/usr/bin/apxs --disable-rpath --disable-debug --enable-memory-limit --enable-calendar --enable-sysvsem --enable-sysvshm --enable-track-vars --enable-trans-sid --enable-bcmath --with-bz2 --enable-ctype --with-db2 --with-iconv --with-ndbm --enable-exif --enable-filepro --enable-ftp --with-gettext --enable-mbstring --with-pcre-regex=/usr --enable-shmop --enable-sockets --enable-wddx --with-xml=/usr --with-expat-dir=/usr --enable-yp --with-zlib --without-pgsql --disable-static --with-layout=GNU --with-curl=shared,/usr --with-dom=shared,/usr --with-zlib-dir=/usr --with-gd=shared,/usr --with-jpeg-dir=shared,/usr --with-png-dir=shared,/usr --with-freetype-dir=shared,/usr --with-ldap=shared,/usr --with-mcal=shared,/usr --with-mhash=shared,/usr --with-mm --with-mysql=shared --without-unixODBC --with-recode=shared,/usr --enable-xslt --with-xslt-sablot=shared,/usr --with-snmp=shared --enable-ucd-snmp-hack --without-sybase-ct --with-ttf=shared,/usr --with-t1lib=shared,/usr -- Edit this bug report at http://bugs.php.net/?id=20801edit=1
#20803 [Opn-Bgs]: running autoconf gives error
ID: 20803 Updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] -Status: Open +Status: Bogus Bug Type: *Configuration Issues Operating System: Linux Gentoo PHP Version: 4.3.0RC2 New Comment: Yes, we know. The next RC/release will be generated with correct autoconf friends. (this really isn't a bug in that sense. You can always grab the latest STABLE snapshot too) Previous Comments: [2002-12-03 17:37:17] [EMAIL PROTECTED] taking the tarbal 4.3.0RC2 and running autoconf on it give an error. $ tar zxf devsource/php-4.3.0RC2.tar.gz $ cd php-4.3.0RC2 ; autoconf configure.in:520: warning: AC_TRY_RUN called without default to allow cross compiling configure.in:556: AC_ARG_ARRAY has been removed; don't do unportable things with arguments To fix it, regenerate aclocal.m4 or delete it from the tarball $ rm aclocal.m4 $ ./buildconf using default Zend directory buildconf: checking installation... buildconf: autoconf version 2.13 (ok) buildconf: automake version 1.4-p5 (ok) buildconf: libtool version 1.4.1 (ok) rebuilding configure rebuilding main/php_config.h.in -- Edit this bug report at http://bugs.php.net/?id=20803edit=1
#20805 [Opn-Fbk]: day of the Month output incorrect
ID: 20805 Updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] -Status: Open +Status: Feedback Bug Type: Date/time related Operating System: Windows 2000 SP3 PHP Version: 4.2.2 New Comment: Not enough information was provided for us to be able to handle this bug. Please re-read the instructions at http://bugs.php.net/how-to-report.php If you can provide more information, feel free to add it to this bug and change the status back to Open. Thank you for your interest in PHP. Previous Comments: [2002-12-04 01:22:25] [EMAIL PROTECTED] A stored value from time() in a mysql varchar field, put into a date time array with getdate() the date time array outputs an incorrect day of the month (less by one day in my tests). Environment Apache 1.3 mysql 3.23.51-max-nt country Australia, Melbourne Time example scripts echo time(); cut and pasted output into mysql field of type varchar (14). (why? because I am still building data input section, verified that time was actually correct in database using strftime() ) used this line to retrive date :- $date_time_array = getdate ($myrow[NEWS_DATE]); used this function to output data :- $date_time_array[ wday] this produced the incorrect date, date was incorrect by one day (less), when replaced with this function :- strftime (%d ,$myrow[NEWS_DATE]) the correct time was output. Sorry if my explanation was not satisfactory or I am entirely wrong. I didnt want to waste your time but I didnt see anything in the bug section about it. -- Edit this bug report at http://bugs.php.net/?id=20805edit=1
#18600 [Fbk-Csd]: Unable to create Java Virtual Machine
ID: 18600 Updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] -Status: Feedback +Status: Closed Bug Type: Java related Operating System: Windows 2000 PHP Version: 4.2.3 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: [2002-12-02 05:11:03] [EMAIL PROTECTED] Hi, I'm reporting the same error using: Win2k Server apache_2.0.36-win32-x86-no_ssl.msi php4-win32-latest.zip (PHP Version 4.2.3) j2sdk-1_4_1_01-windows-i586.exe or (jdk-1_2_2_014-windows-i586.exe) ... I've got periods of errors and periods of success when instantiating $system = new Java(java.lang.System); from within PHP. Error message is: Fatal error: Unable to create Java Virtual Machine in ... I see a lot of such bug reports around but still no solution ;-(. Any ideas? Thanx Alberto [2002-11-28 07:19:46] [EMAIL PROTECTED] Hi I'm asking it again: Is anyone using sablotron (ext/xslt) together with the java extension, then you're in bad luck, because: sablotron 0.97 and jdk = 1.3 does not work together. Sablotron 0.97 is not out yet, but there is an RC1 in their CVS (didn't find a link to download it), which should solve the problem.. try not loading the sablotron extension and see if it solves the problem unix people which have problem with even starting up, should try the symlink trick: make a symlink from java.so to libphp_java.so and see if that works. chregu [2002-11-05 05:43:54] [EMAIL PROTECTED] I am also seeing this bug, unfortunatly I'm running apache 1.x on Solaris 8. Works fine for a little while, then stops working after a number of requests. I can stop the symtoms by turning off keep-alive in apache or by reducing the requests per child to a very low number. Of course, none of these solutions are acceptable. I am trying to test 4.3.0pre2 just now but having compilation errors. More later. [2002-10-31 08:51:16] [EMAIL PROTECTED] Yeah the only real issue I can see here is that this is a Windows specific issue. I've looked through the the DSP file, and read up on specific linking issues in Windows... everything looks right from the end of PHP. I'm guessing this can be one of (or possibly all of) these things: A) specific to a JVM version - in which case we'd need to find out which one works, and then update the specific hooks into PHP to use the newer versions. B) Windows not liking Java at all - not much we can do about that. C) specific to PHP alone - in which case someone with more Windows dev experience will have to take a look at this. As I don't see any real issue with the way we're linking and calling things (beyond the really resource intensive comments). [2002-10-31 07:44:50] [EMAIL PROTECTED] I found this problem using Apache 1.x on Win2k. PHP 4.2.3 causes the JVM create failure (although I couldn't get any access violations). Under IIS4 , the access violation causes some serious problems, albeit intermittently. I found that starting small with Java-inclusive scripts allowed some java work to be done (such as retrieving JVM versions, etc). However, when I started some more serious Java work with some custom classes I got both the JVM create failure and an access violation which crashed IIS. A reboot was necessary to bring IIS back up (Win2k wouldn't even let me force kill the process!!). I took a look at the latest snapshot posted below, but this caused an immediate crash in Apache upon starting the service. Any other suggestions? 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/18600 -- Edit this bug report at http://bugs.php.net/?id=18600edit=1
#15702 [Fbk-Csd]: Segmentation fault (using jdk1.4 with php 4.2.3)
ID: 15702 Updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] -Status: Feedback +Status: Closed Bug Type: Java related Operating System: Red Hat Linux 7.1 PHP Version: 4.2.3 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: [2002-12-03 11:13:17] [EMAIL PROTECTED] your backtrace is not of much use, but it looks like apache2 does backtraces differently than apache1.3 (or you didn't use --enable-debug or you're using threaded mpms within apache2, I have no experience with apache2...) but, as I said in my last comment: sablotron 0.97 and jdk = 1.3 does not work together. Sablotron 0.97 is not out yet, but there is an RC1 in their CVS (didn't find a link to download it), which should solve the problem.. you're obviously (at least it's written in your ./configure lines) using sablotron. And sablotron =0.96 does not work together with jdk = 1.3... please try your installation without sablotron and see if that works. chregu [2002-12-03 09:22:01] [EMAIL PROTECTED] http://bugs.php.net/bug.php?id=15702edit=2 is not accepting my password. I don't know why so I am posting this as comment I think above you meant from java.so to libphp_java.so. Yes I did create a symbolic link libphp_java.so to java.so. It again resulted inSegmentation fault. Here is the gdb output. # export LD_LIBRARY_PATH=/usr/java/j2sdk1.4.0/jre/lib/i386:/usr/java/j2sdk1.4.0/jre/lib/i386/client # gdb /wwwroot/bin/httpd GNU gdb 5.0rh-5 Red Hat Linux 7.1 Copyright 2001 Free Software Foundation, Inc. GDB is free software, covered by the GNU General Public License, and you are welcome to change it and/or distribute copies of it under certain conditions. Type show copying to see the conditions. There is absolutely no warranty for GDB. Type show warranty for details. This GDB was configured as i386-redhat-linux... (gdb) run -X Starting program: /wwwroot/bin/httpd -X [New Thread 1024 (LWP 852)] [New Thread 2049 (LWP 857)] Delayed SIGSTOP caught for LWP 857. [New Thread 1026 (LWP 858)] Delayed SIGSTOP caught for LWP 858. [New Thread 2051 (LWP 859)] Delayed SIGSTOP caught for LWP 859. [New Thread 3076 (LWP 860)] Delayed SIGSTOP caught for LWP 860. [New Thread 4101 (LWP 861)] [New Thread 5126 (LWP 862)] Delayed SIGSTOP caught for LWP 862. [New Thread 6151 (LWP 863)] Delayed SIGSTOP caught for LWP 863. [New Thread 7176 (LWP 864)] Delayed SIGSTOP caught for LWP 864. Program received signal SIGSEGV, Segmentation fault. [Switching to Thread 7176 (LWP 864)] __pthread_mutex_lock (mutex=0x89110898) at mutex.c:99 99 mutex.c: No such file or directory. in mutex.c (gdb) [2002-11-28 07:08:06] [EMAIL PROTECTED] first. you have to make a symlink from to libphp_java.so not php_java.so... second. sablotron 0.97 and jdk = 1.3 does not work together. Sablotron 0.97 is not out yet, but there is an RC1 in their CVS (didn't find a link to download it), which should solve the problem.. chregu [2002-11-11 09:41:56] [EMAIL PROTECTED] As you suggested above changing the extension=php_java.so without creating a symbolic link doesn't even load the extension. So I tried it by creating a symbolic link to /wwwroot/php/lib/php/extensions/no-debug-zts-20020429/java.so as /wwwroot/php/lib/php/extensions/no-debug-zts-20020429/php_java.so and used the following setting in php.ini: [Java] extension_dir = /wwwroot/php/lib/php/extensions/no-debug-zts-20020429 java.class.path = /wwwroot/php/lib/php/php_java.jar extension=php_java.so ;java.home = /usr/java/j2sdk1.4.0 ;java.library = /usr/java/j2sdk1.4.0/jre/lib/i386/client/libjvm.so ;java.library = /usr/java/j2sdk1.4.0/jre/lib/i386/libjava.so java.library.path = /wwwroot/php/lib/php/extensions/no-debug-zts-20020429 PHP loaded the java extension but it still displayed: Fatal error: java.lang.UnsatisfiedLinkError: no php_java in java.library.path in /wwwroot/htdocs/jver.php on line 4 I don't know what it isn't able to find php_java.jar or php_java.so? PHP is able to find java.so thats why it loads the extension. I also want to know what is the purpose of java.library.path? What should
#20270 [Fbk-Csd]: Apache processes don't clean up
ID: 20270 Updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] -Status: Feedback +Status: Closed Bug Type: Java related Operating System: RHL7.3 PHP Version: 4.3.0-pre2 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: [2002-11-28 07:10:08] [EMAIL PROTECTED] Do you have xslt support enabled, then sablotron 0.97 and jdk = 1.3 does not work together. Sablotron 0.97 is not out yet, but there is an RC1 in their CVS (didn't find a link to download it), which should solve the problem.. chregu [2002-11-22 13:11:07] [EMAIL PROTECTED] I get the same result using: Linux 2.4.19 glibc 2.3.1 pthread 0.10 php 4.3.0RC1 apache 1.3.27 Sun's j2sdk1.4.0_03 [2002-11-14 08:57:14] [EMAIL PROTECTED] There seems to be a problem with the way threads are handled between php and java that keeps the apache child process from cleaning up after itself. If MaxRequestsPerChild is set to anything other than 1, a number of threads are started by a httpd child and are never reused. It also appears that the httpd child process that spawns these threads can not be reused by apache and the httpd controlling process never starts another child process to take the place of the disabled one. My testing setup is: Linux 2.4.18 glibc 2.2.5 apache 1.3.27 libpthread 0.9 php 4.2.3 Blackdown JDK 1.3.1, IBM JDK 1.3..1, Blackdown JDK 1.4.1b2 all produce the same results. It should be noted that apache is stable if MaxRequestsPerChild is set to 1, but there's quite a performance hit involved. [2002-11-05 18:20:09] [EMAIL PROTECTED] I have tried to use the Java extension with JDK1.4.1 and PHP 4.2.3 and 4.3.0-pre2. Each time a page with embedded Java runs, the Apache (1.3.27) spawns MaxSpareServers processes, which never seem to get cleaned up. The tests I conducted with 4.2.3 ended up crashing after a few runs, being unable to run the JVM. This version also had trouble reading php.ini class path settings. The 4.3.0-pre2 seems to stop spawning processes after reaching about 90 httpds (not sure what this number is related to). The execution time of the code is much faster after the spawning stops also - probably the JVMs are loaded for all httpds? Is there a way to control this process spawning and to get the whole thing more stable? -- Edit this bug report at http://bugs.php.net/?id=20270edit=1
#20777 [Bgs]: will not find apache2 apxs
ID: 20777 Updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] Status: Bogus Bug Type: Apache2 related Operating System: Solaris 8 PHP Version: 4.3.0RC2 New Comment: Tell us what this says: /www2/bin/apxs -q INCLUDEDIR Previous Comments: [2002-12-04 01:57:32] [EMAIL PROTECTED] This works just fine here. Must be something wrong in your apache2 install. (update it, it's most likely too old or you're really trying to configure with apache1) [2002-12-03 14:48:19] [EMAIL PROTECTED] Sorry I typed the message wrong it is /www2/bin/apxs [2002-12-02 18:52:24] [EMAIL PROTECTED] You're using /www/bin/apxs but showing the output of /www2/bin/apxs, so which one is the right one? [2002-12-02 18:49:52] [EMAIL PROTECTED] ./configure --with-apxs2=/www/bin/apxs just testing Configuring SAPI modules checking for AOLserver support... no checking for Apache 1.x module support via DSO through APXS... no checking for Apache 1.x module support... no checking for mod_charset compatibility option... no checking for Apache 2.0 module support via DSO through APXS... Sorry, I cannot run apxs. Possible reasons follow: 1. Perl is not installed 2. apxs was not found. Try to pass the path using --with-apxs2=/path/to/apxs 3. Apache was not built using --enable-so (the apxs usage page is displayed) The output of /www2/bin/apxs follows: Usage: apxs -g [-S var=val] -n modname apxs -q [-S var=val] query ... apxs -c [-S var=val] [-o dsofile] [-D name[=value]] [-I incdir] [-L libdir] [-l libname] [-Wc,flags] [-Wl,flags] files ... apxs -i [-S var=val] [-a] [-A] [-n modname] dsofile ... apxs -e [-S var=val] [-a] [-A] [-n modname] dsofile ... configure: error: Aborting bash-2.05# perl asdf ^C bash-2.05# perl -v This is perl, v5.6.1 built for sun4-solaris Copyright 1987-2001, Larry Wall Perl may be copied only under the terms of either the Artistic License or the GNU General Public License, which may be found in the Perl 5 source kit. Complete documentation for Perl, including FAQ lists, should be found on this system using `man perl' or `perldoc perl'. If you have access to the Internet, point your browser at http://www.perl.com/, the Perl Home Page. bash-2.05# -- Edit this bug report at http://bugs.php.net/?id=20777edit=1
#20776 [Fbk-Opn]: Login only possible from page where login is required.
ID: 20776 User updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] -Status: Feedback +Status: Open Bug Type: Session related Operating System: Win2K Server PHP Version: 4.2.3 New Comment: Sniper, I have spent hours cutting out 90% of this program, removing libraries called, writing a script to autoinstall the tiny test database, written installation instructions and supplied two different versions of the main page - one which works, one which does not - and cut the whole thing down to six actual php files. Not twenty or even ten. And I finished doing that at 5:00am today, as you know. Some problems can't be reduced to 12 lines of code. In this case, the login has to come from two different pages and go to another one, that makes at least three files. The fourth is a library, which you can safely ignore. The fifth is a logout script, without which you can only test it once. The sixth is a file included globally in each of the others to cut down verbosity. If this is too complex, perhaps you expect me to actually fix your bugs for you. Sorry, I charge AU$100 an hour for that nowadays, having already paid my dues on a number of large GPL projects. Keep the bug, I don't mind. Previous Comments: [2002-12-04 01:51:01] [EMAIL PROTECTED] And DO NOT REPLY TO THIS EMAIL!! And especially: DO NOT email me! You can put such long examples somewhere in the net and add an URL here so that other people see it too.. [2002-12-04 01:49:45] [EMAIL PROTECTED] I did mean _SHORT_ example script, one that is max 10-20 lines long..not some 10-20 files! [2002-12-03 12:00:23] [EMAIL PROTECTED] OK, I've sent a cutdown of the program, hope that helps. [2002-12-03 07:31:53] [EMAIL PROTECTED] I've already reported a crashing bug against 4.3.0RC2 so I won't be trying any CVS snapshots just yet. See what I can do about a sample script, but it may be a couple days since I'm working in about 6 hrs. [2002-12-03 02:34:40] [EMAIL PROTECTED] Please provide a short but complete example script which can be used to reproduce this. Also note that PHP 4.3.0-dev (the latest stable CVS snapshot) has some fixes regarding session issues so you should try it out too, from: http://snaps.php.net/ 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/20776 -- Edit this bug report at http://bugs.php.net/?id=20776edit=1
#20800 [Fbk-Opn]: ob_and_clean crash
ID: 20800 User updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] -Status: Feedback +Status: Open Bug Type: Output Control Operating System: Redhat 7.0 PHP Version: 4.3.0RC2 New Comment: The server doesn't create any core dump, it simply exit, as in bug #20802, there is no segmentation fault. Previous Comments: [2002-12-04 00:34:12] [EMAIL PROTECTED] Thank you for this bug report. To properly diagnose the problem, we need a backtrace to see what is happening behind the scenes. To find out how to generate a backtrace, please read http://bugs.php.net/bugs-generating-backtrace.php Once you have generated a backtrace, please submit it to this bug report and change the status back to Open. Thank you for helping us make PHP better. [2002-12-03 15:54:33] [EMAIL PROTECTED] If I try to run this script I receive a blank page (no output): ? ob_end_clean(); echo a; ? If I try to run from the command line it works. Server configuration: Linux Redhat 7.0 Apache 1.3.22 PHP 4.3.0RC2 Zend Optimizer 2.0.3 Mysql 4.0.5 ini: output_buffering On output_handler ob_gzhandler Configure: './configure' '--enable-track-vars' '--prefix=/usr' '--exec-prefix=/usr' '--libexecdir=/usr/lib/apache' '--bindir=/usr/bin' '--sbindir=/usr/sbin' '--datadir=/home/httpd' '--sysconfdir=/etc/httpd/conf' '--localstatedir=/var' '--libdir=/usr/lib/apache' '--includedir=/usr/include/apache' '--mandir=/usr/man' '--with-mysql=/usr' '--enable-memory-limit' '--with-config-file-path=/usr/local/Zend/etc' '--with-apxs' '--with-zlib' -- Edit this bug report at http://bugs.php.net/?id=20800edit=1
#20806 [NEW]: display of rows in browse incorrect due to field names
From: [EMAIL PROTECTED] Operating system: NT4 PHP version: 4.2.3 PHP Bug Type: *General Issues Bug description: display of rows in browse incorrect due to field names I have created a table with the field names as numerical values from 1-10 (i.e. field is named 1 and is a tinyint[2]). Preceeding these numerical fields I have a text[255] field. When browsing the db the text field displays the number 1 instead of its correct text. Changing the value of field named 1 corrects this issue. e.g. this is how it should look. +==+=+ |text field|1| +==+=+ | text |1| +--+-+ and this is how it looks. +==+=+ |text field|1| +==+=+ | 1|1| +--+-+ -- Edit bug report at http://bugs.php.net/?id=20806edit=1 -- Try a CVS snapshot: http://bugs.php.net/fix.php?id=20806r=trysnapshot Fixed in CVS: http://bugs.php.net/fix.php?id=20806r=fixedcvs Fixed in release: http://bugs.php.net/fix.php?id=20806r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=20806r=needtrace Try newer version: http://bugs.php.net/fix.php?id=20806r=oldversion Not developer issue:http://bugs.php.net/fix.php?id=20806r=support Expected behavior: http://bugs.php.net/fix.php?id=20806r=notwrong Not enough info:http://bugs.php.net/fix.php?id=20806r=notenoughinfo Submitted twice:http://bugs.php.net/fix.php?id=20806r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=20806r=globals PHP 3 support discontinued: http://bugs.php.net/fix.php?id=20806r=php3 Daylight Savings: http://bugs.php.net/fix.php?id=20806r=dst IIS Stability: http://bugs.php.net/fix.php?id=20806r=isapi
#20776 [Opn]: Login only possible from page where login is required.
ID: 20776 Updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] Status: Open Bug Type: Session related Operating System: Win2K Server PHP Version: 4.2.3 New Comment: hmm... maybe Sniper should start charging for support then; he would make a very decent living out out it with all the time he spends on verifying bugs and trying to help people with bugs. Previous Comments: [2002-12-04 04:52:02] [EMAIL PROTECTED] Sniper, I have spent hours cutting out 90% of this program, removing libraries called, writing a script to autoinstall the tiny test database, written installation instructions and supplied two different versions of the main page - one which works, one which does not - and cut the whole thing down to six actual php files. Not twenty or even ten. And I finished doing that at 5:00am today, as you know. Some problems can't be reduced to 12 lines of code. In this case, the login has to come from two different pages and go to another one, that makes at least three files. The fourth is a library, which you can safely ignore. The fifth is a logout script, without which you can only test it once. The sixth is a file included globally in each of the others to cut down verbosity. If this is too complex, perhaps you expect me to actually fix your bugs for you. Sorry, I charge AU$100 an hour for that nowadays, having already paid my dues on a number of large GPL projects. Keep the bug, I don't mind. [2002-12-04 01:51:01] [EMAIL PROTECTED] And DO NOT REPLY TO THIS EMAIL!! And especially: DO NOT email me! You can put such long examples somewhere in the net and add an URL here so that other people see it too.. [2002-12-04 01:49:45] [EMAIL PROTECTED] I did mean _SHORT_ example script, one that is max 10-20 lines long..not some 10-20 files! [2002-12-03 12:00:23] [EMAIL PROTECTED] OK, I've sent a cutdown of the program, hope that helps. [2002-12-03 07:31:53] [EMAIL PROTECTED] I've already reported a crashing bug against 4.3.0RC2 so I won't be trying any CVS snapshots just yet. See what I can do about a sample script, but it may be a couple days since I'm working in about 6 hrs. 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/20776 -- Edit this bug report at http://bugs.php.net/?id=20776edit=1
#20806 [Opn-Bgs]: display of rows in browse incorrect due to field names
ID: 20806 Updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] -Status: Open +Status: Bogus Bug Type: *General Issues Operating System: NT4 PHP Version: 4.2.3 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. Previous Comments: [2002-12-04 05:11:48] [EMAIL PROTECTED] I have created a table with the field names as numerical values from 1-10 (i.e. field is named 1 and is a tinyint[2]). Preceeding these numerical fields I have a text[255] field. When browsing the db the text field displays the number 1 instead of its correct text. Changing the value of field named 1 corrects this issue. e.g. this is how it should look. +==+=+ |text field|1| +==+=+ | text |1| +--+-+ and this is how it looks. +==+=+ |text field|1| +==+=+ | 1|1| +--+-+ -- Edit this bug report at http://bugs.php.net/?id=20806edit=1
#20806 [Bgs-Fbk]: display of rows in browse incorrect due to field names
ID: 20806 Updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] -Status: Bogus +Status: Feedback Bug Type: *General Issues Operating System: NT4 PHP Version: 4.2.3 New Comment: Not enough information was provided for us to be able to handle this bug. Please re-read the instructions at http://bugs.php.net/how-to-report.php If you can provide more information, feel free to add it to this bug and change the status back to Open. Thank you for your interest in PHP. Previous Comments: [2002-12-04 05:13:18] [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. [2002-12-04 05:11:48] [EMAIL PROTECTED] I have created a table with the field names as numerical values from 1-10 (i.e. field is named 1 and is a tinyint[2]). Preceeding these numerical fields I have a text[255] field. When browsing the db the text field displays the number 1 instead of its correct text. Changing the value of field named 1 corrects this issue. e.g. this is how it should look. +==+=+ |text field|1| +==+=+ | text |1| +--+-+ and this is how it looks. +==+=+ |text field|1| +==+=+ | 1|1| +--+-+ -- Edit this bug report at http://bugs.php.net/?id=20806edit=1
#18600 [Csd-Opn]: Unable to create Java Virtual Machine
ID: 18600 User updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] -Status: Closed +Status: Open Bug Type: Java related Operating System: Windows 2000 PHP Version: 4.2.3 New Comment: I tried the php4-win32-STABLE-200212040930 snapshot, but I still got problems with a simple java program (the one in the docs). After some reloads I got a PHP has encountered an Access Violation at 77FCBEE8 After that: Fatal error: Unable to create Java Virtual Machine in c:\inetpub\wwwroot\estatisticos\admin\java.php on line 3 At least the problem occurs only to java applications, not all php pages. Nelio Previous Comments: [2002-12-04 02:18:05] [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. [2002-12-02 05:11:03] [EMAIL PROTECTED] Hi, I'm reporting the same error using: Win2k Server apache_2.0.36-win32-x86-no_ssl.msi php4-win32-latest.zip (PHP Version 4.2.3) j2sdk-1_4_1_01-windows-i586.exe or (jdk-1_2_2_014-windows-i586.exe) ... I've got periods of errors and periods of success when instantiating $system = new Java(java.lang.System); from within PHP. Error message is: Fatal error: Unable to create Java Virtual Machine in ... I see a lot of such bug reports around but still no solution ;-(. Any ideas? Thanx Alberto [2002-11-28 07:19:46] [EMAIL PROTECTED] Hi I'm asking it again: Is anyone using sablotron (ext/xslt) together with the java extension, then you're in bad luck, because: sablotron 0.97 and jdk = 1.3 does not work together. Sablotron 0.97 is not out yet, but there is an RC1 in their CVS (didn't find a link to download it), which should solve the problem.. try not loading the sablotron extension and see if it solves the problem unix people which have problem with even starting up, should try the symlink trick: make a symlink from java.so to libphp_java.so and see if that works. chregu [2002-11-05 05:43:54] [EMAIL PROTECTED] I am also seeing this bug, unfortunatly I'm running apache 1.x on Solaris 8. Works fine for a little while, then stops working after a number of requests. I can stop the symtoms by turning off keep-alive in apache or by reducing the requests per child to a very low number. Of course, none of these solutions are acceptable. I am trying to test 4.3.0pre2 just now but having compilation errors. More later. [2002-10-31 08:51:16] [EMAIL PROTECTED] Yeah the only real issue I can see here is that this is a Windows specific issue. I've looked through the the DSP file, and read up on specific linking issues in Windows... everything looks right from the end of PHP. I'm guessing this can be one of (or possibly all of) these things: A) specific to a JVM version - in which case we'd need to find out which one works, and then update the specific hooks into PHP to use the newer versions. B) Windows not liking Java at all - not much we can do about that. C) specific to PHP alone - in which case someone with more Windows dev experience will have to take a look at this. As I don't see any real issue with the way we're linking and calling things (beyond the really resource intensive comments). 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/18600 -- Edit this bug report at http://bugs.php.net/?id=18600edit=1
#20807 [NEW]: 'make install' failed on cygwin
From: [EMAIL PROTECTED] Operating system: winXP PHP version: 4CVS-2002-12-04 (dev) PHP Bug Type: Compile Failure Bug description: 'make install' failed on cygwin here: Installing PHP SAPI module chmod: changing permissions of `/usr/local/bin/#INST@3220#': No such file or directory make: *** [install-sapi] Error - -- Edit bug report at http://bugs.php.net/?id=20807edit=1 -- Try a CVS snapshot: http://bugs.php.net/fix.php?id=20807r=trysnapshot Fixed in CVS: http://bugs.php.net/fix.php?id=20807r=fixedcvs Fixed in release: http://bugs.php.net/fix.php?id=20807r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=20807r=needtrace Try newer version: http://bugs.php.net/fix.php?id=20807r=oldversion Not developer issue:http://bugs.php.net/fix.php?id=20807r=support Expected behavior: http://bugs.php.net/fix.php?id=20807r=notwrong Not enough info:http://bugs.php.net/fix.php?id=20807r=notenoughinfo Submitted twice:http://bugs.php.net/fix.php?id=20807r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=20807r=globals PHP 3 support discontinued: http://bugs.php.net/fix.php?id=20807r=php3 Daylight Savings: http://bugs.php.net/fix.php?id=20807r=dst IIS Stability: http://bugs.php.net/fix.php?id=20807r=isapi
#20807 [Com]: 'make install' failed on cygwin
ID: 20807 Comment by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] Status: Open Bug Type: Compile Failure Operating System: winXP PHP Version: 4CVS-2002-12-04 (dev) New Comment: make along is ok.. Previous Comments: [2002-12-04 07:17:46] [EMAIL PROTECTED] here: Installing PHP SAPI module chmod: changing permissions of `/usr/local/bin/#INST@3220#': No such file or directory make: *** [install-sapi] Error - -- Edit this bug report at http://bugs.php.net/?id=20807edit=1
#20798 [Com]: use_trans_sid produces unvalid html
ID: 20798 Comment by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] Status: Bogus Bug Type: Session related Operating System: RH7.2 PHP Version: 4.2.3 New Comment: Woops, my fault. Havent noticed that before. Maybe amp; should be default? Previous Comments: [2002-12-03 14:57:50] [EMAIL PROTECTED] Read your php.ini closely, and pay attention to the arg_seperator.output setting. Not a bug - bogus [2002-12-03 14:56:44] [EMAIL PROTECTED] When a PHP option session.use_trans_sid is set on, and user has cookies disabled, every URL in page is altered by PHP to include the SID in them. However possible amp-signs in urls are not produced as valid html (according to w3c). Heres an example: A page has a link similiar to: -- HREF=/some.php?a=bamp;c=d after adding SID it becomes: -- HREF=/some.php?a=bamp;c=dSID=WHATEVER Should be: -- HREF=/some.php?a=bamp;c=damp;SID=WHATEVER am I right? Or didn't I just notice something? And btw, bug search system doesn like amp; as a search word, says that I'm a bad cracker :| -- Edit this bug report at http://bugs.php.net/?id=20798edit=1
#20798 [Com]: use_trans_sid produces unvalid html
ID: 20798 Comment by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] Status: Bogus Bug Type: Session related Operating System: RH7.2 PHP Version: 4.2.3 New Comment: +1 from here. It wont break anything and complies with present standards. Previous Comments: [2002-12-04 07:34:19] [EMAIL PROTECTED] Woops, my fault. Havent noticed that before. Maybe amp; should be default? [2002-12-03 14:57:50] [EMAIL PROTECTED] Read your php.ini closely, and pay attention to the arg_seperator.output setting. Not a bug - bogus [2002-12-03 14:56:44] [EMAIL PROTECTED] When a PHP option session.use_trans_sid is set on, and user has cookies disabled, every URL in page is altered by PHP to include the SID in them. However possible amp-signs in urls are not produced as valid html (according to w3c). Heres an example: A page has a link similiar to: -- HREF=/some.php?a=bamp;c=d after adding SID it becomes: -- HREF=/some.php?a=bamp;c=dSID=WHATEVER Should be: -- HREF=/some.php?a=bamp;c=damp;SID=WHATEVER am I right? Or didn't I just notice something? And btw, bug search system doesn like amp; as a search word, says that I'm a bad cracker :| -- Edit this bug report at http://bugs.php.net/?id=20798edit=1
#20798 [Bgs]: use_trans_sid produces unvalid html
ID: 20798 Updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] Status: Bogus Bug Type: Session related Operating System: RH7.2 PHP Version: 4.2.3 New Comment: Search the archives, this is not going to happen until there are browsers which don't work without this. Previous Comments: [2002-12-04 07:51:49] [EMAIL PROTECTED] +1 from here. It wont break anything and complies with present standards. [2002-12-04 07:34:19] [EMAIL PROTECTED] Woops, my fault. Havent noticed that before. Maybe amp; should be default? [2002-12-03 14:57:50] [EMAIL PROTECTED] Read your php.ini closely, and pay attention to the arg_seperator.output setting. Not a bug - bogus [2002-12-03 14:56:44] [EMAIL PROTECTED] When a PHP option session.use_trans_sid is set on, and user has cookies disabled, every URL in page is altered by PHP to include the SID in them. However possible amp-signs in urls are not produced as valid html (according to w3c). Heres an example: A page has a link similiar to: -- HREF=/some.php?a=bamp;c=d after adding SID it becomes: -- HREF=/some.php?a=bamp;c=dSID=WHATEVER Should be: -- HREF=/some.php?a=bamp;c=damp;SID=WHATEVER am I right? Or didn't I just notice something? And btw, bug search system doesn like amp; as a search word, says that I'm a bad cracker :| -- Edit this bug report at http://bugs.php.net/?id=20798edit=1
#20808 [NEW]: configure script has a lines joined
From: [EMAIL PROTECTED] Operating system: Solaris 2.6 sparc PHP version: 4.3.0RC2 PHP Bug Type: *Compile Issues Bug description: configure script has a lines joined The area round line 53644 in configure looks like: #include stdlib.h #ifdef __cplusplus extern C #endif Unfortunately the #ifdef line is joined with the extern line with 70 spaces or so, so that it wraps nicely and hides this. This was already there in 4.2.3 (as I discovered today). Paul Slootman -- Edit bug report at http://bugs.php.net/?id=20808edit=1 -- Try a CVS snapshot: http://bugs.php.net/fix.php?id=20808r=trysnapshot Fixed in CVS: http://bugs.php.net/fix.php?id=20808r=fixedcvs Fixed in release: http://bugs.php.net/fix.php?id=20808r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=20808r=needtrace Try newer version: http://bugs.php.net/fix.php?id=20808r=oldversion Not developer issue:http://bugs.php.net/fix.php?id=20808r=support Expected behavior: http://bugs.php.net/fix.php?id=20808r=notwrong Not enough info:http://bugs.php.net/fix.php?id=20808r=notenoughinfo Submitted twice:http://bugs.php.net/fix.php?id=20808r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=20808r=globals PHP 3 support discontinued: http://bugs.php.net/fix.php?id=20808r=php3 Daylight Savings: http://bugs.php.net/fix.php?id=20808r=dst IIS Stability: http://bugs.php.net/fix.php?id=20808r=isapi
#20809 [NEW]: iconv() options
From: [EMAIL PROTECTED] Operating system: All PHP version: 4.3.0RC2 PHP Bug Type: Feature/Change Request Bug description: iconv() options It will be very useful to have support for -c and -s options available for iconv command-line tool as optional arguments for iconv() function. And also it will be specially useful for XML related code to have an option to convert all unconvertable characters into numeric entities. Thank you all for your job! -- Edit bug report at http://bugs.php.net/?id=20809edit=1 -- Try a CVS snapshot: http://bugs.php.net/fix.php?id=20809r=trysnapshot Fixed in CVS: http://bugs.php.net/fix.php?id=20809r=fixedcvs Fixed in release: http://bugs.php.net/fix.php?id=20809r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=20809r=needtrace Try newer version: http://bugs.php.net/fix.php?id=20809r=oldversion Not developer issue:http://bugs.php.net/fix.php?id=20809r=support Expected behavior: http://bugs.php.net/fix.php?id=20809r=notwrong Not enough info:http://bugs.php.net/fix.php?id=20809r=notenoughinfo Submitted twice:http://bugs.php.net/fix.php?id=20809r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=20809r=globals PHP 3 support discontinued: http://bugs.php.net/fix.php?id=20809r=php3 Daylight Savings: http://bugs.php.net/fix.php?id=20809r=dst IIS Stability: http://bugs.php.net/fix.php?id=20809r=isapi
#18600 [Com]: Unable to create Java Virtual Machine
ID: 18600 Comment by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] Status: Open Bug Type: Java related Operating System: Windows 2000 PHP Version: 4.2.3 New Comment: Hi, many thanks Sebastian for the response. I've downloaded php4-win32-200212041130.zip from snaps.php.net, but after PHP update Apache didn't start and configuration test detected following problem: Syntax error on line 174 of C:/Program Files/Apache Group/Apache2/conf/httpd.conf: Cannot load C:/PHP/sapi/php4apache2.dll into server: The specified procedure could not be found. httpd.conf has on the line 174: LoadModule php4_module c:/php/sapi/php4apache2.dll Question is what is the recomended version of Win32 Apache2 to work corectly with latest PHP 4.4.x-dev? Thank you, Alberto Previous Comments: [2002-12-04 06:20:14] [EMAIL PROTECTED] I tried the php4-win32-STABLE-200212040930 snapshot, but I still got problems with a simple java program (the one in the docs). After some reloads I got a PHP has encountered an Access Violation at 77FCBEE8 After that: Fatal error: Unable to create Java Virtual Machine in c:\inetpub\wwwroot\estatisticos\admin\java.php on line 3 At least the problem occurs only to java applications, not all php pages. Nelio [2002-12-04 02:18:05] [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. [2002-12-02 05:11:03] [EMAIL PROTECTED] Hi, I'm reporting the same error using: Win2k Server apache_2.0.36-win32-x86-no_ssl.msi php4-win32-latest.zip (PHP Version 4.2.3) j2sdk-1_4_1_01-windows-i586.exe or (jdk-1_2_2_014-windows-i586.exe) ... I've got periods of errors and periods of success when instantiating $system = new Java(java.lang.System); from within PHP. Error message is: Fatal error: Unable to create Java Virtual Machine in ... I see a lot of such bug reports around but still no solution ;-(. Any ideas? Thanx Alberto [2002-11-28 07:19:46] [EMAIL PROTECTED] Hi I'm asking it again: Is anyone using sablotron (ext/xslt) together with the java extension, then you're in bad luck, because: sablotron 0.97 and jdk = 1.3 does not work together. Sablotron 0.97 is not out yet, but there is an RC1 in their CVS (didn't find a link to download it), which should solve the problem.. try not loading the sablotron extension and see if it solves the problem unix people which have problem with even starting up, should try the symlink trick: make a symlink from java.so to libphp_java.so and see if that works. chregu [2002-11-05 05:43:54] [EMAIL PROTECTED] I am also seeing this bug, unfortunatly I'm running apache 1.x on Solaris 8. Works fine for a little while, then stops working after a number of requests. I can stop the symtoms by turning off keep-alive in apache or by reducing the requests per child to a very low number. Of course, none of these solutions are acceptable. I am trying to test 4.3.0pre2 just now but having compilation errors. More later. 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/18600 -- Edit this bug report at http://bugs.php.net/?id=18600edit=1
#20720 [Com]: ps_files_cleanup_dir
ID: 20720 Comment by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] Status: Feedback Bug Type: Session related Operating System: Windows 2000 Server PHP Version: 4.2.3 New Comment: I've got the same symptoms, only system is diffrent. I'm using PLD Linux 1.0 (kernel 2.4.19) with PHP 4.2.3 Info displayed on my page (it is shown only ocassionaly, not every time): Notice: ps_files_cleanup_dir: opendir(/var/run/php) failed: Permission denied (13) in /home/php-include/default/ThLogin.inc on line 55 Line 55 contains a session_start(); only. Below are some infos generated by phpInfo: (maybe this will help somebody) SystemLinux ep09 2.2.21 #1 SMP Mon Aug 19 22:15:18 UTC 2002 i686 Pentium_III_(Coppermine) unknown PLD Linux Build DateOct 21 2002 15:26:41 Configure Command './configure' 'LDFLAGS=-s' 'CFLAGS=-O2 -march=i686 -DEAPI=1 -I/usr/X11R6/include' 'CXXFLAGS=-O2 -march=i686' 'FFLAGS=-O2 -march=i686' 'CPPFLAGS=' 'CC=i686-pld-linux-gcc' 'CXX=g++' '--build=i686-pld-linux' '--prefix=/usr' '--exec-prefix=/usr' '--bindir=/usr/bin' '--sbindir=/usr/sbin' '--sysconfdir=/etc/php' '--datadir=/usr/share' '--includedir=/usr/include' '--libdir=/usr/lib' '--libexecdir=/usr/lib' '--localstatedir=/var' '--sharedstatedir=/usr/com' '--mandir=/usr/share/man' '--infodir=/usr/share/info' '--with-apxs=/usr/sbin/apxs' '--with-config-file-path=/etc/php' '--with-exec-dir=/usr/bin' '--disable-debug' '--enable-bcmath=shared' '--enable-calendar=shared' '--disable-cli' '--enable-ctype=shared' '--enable-dba=shared' '--enable-dbx=shared' '--enable-dio=shared' '--enable-exif=shared' '--enable-ftp=shared' '--enable-gd-native-ttf' '--enable-magic-quotes' '--enable-mbstring=shared' '--disable-mbstr-enc-trans' '--enable-mbregex' '--enable-overload=shared' '--disable-pcntl' '--enable-posix=shared' '--enable-session' '--enable-shared' '--enable-shmop=shared' '--enable-sysvsem=shared' '--enable-sysvshm=shared' '--enable-track-vars' '--enable-trans-sid' '--enable-safe-mode' '--enable-sockets=shared' '--enable-ucd-snmp-hack' '--enable-wddx=shared' '--enable-xml=shared' '--enable-xslt=shared' '--enable-yp=shared' '--with-bz2=shared' '--with-cpdflib=shared' '--with-crack=shared' '--with-curl=shared' '--without-db2' '--with-db3' '--with-dbase=shared' '--with-dom=shared' '--with-dom-xslt=shared' '--with-dom-exslt=shared' '--with-expat-dir=shared,/usr' '--with-iconv=shared' '--with-filepro=shared' '--with-freetype-dir=shared' '--with-gettext=shared' '--with-gd=shared' '--with-gdbm' '--with-gmp=shared' '--with-hyperwave=shared' '--with-imap=shared' '--with-imap-ssl' '--with-jpeg-dir=shared,/usr' '--with-ldap=shared' '--with-mcal=shared,/usr' '--with-mcrypt=shared' '--with-mhash=shared' '--with-ming=shared' '--with-mm' '--with-mnogosearch=shared,/usr' '--with-msession=shared' '--with-mysql=shared,/usr' '--with-mysql-sock=/var/lib/mysql/mysql.sock' '--with-openssl=shared' '--with-pcre-regex=shared' '--with-pdflib=shared' '--with-pear=/usr/share/pear' '--with-pgsql=shared,/usr' '--with-png-dir=shared,/usr' '--with-pspell=shared' '--with-recode=shared' '--with-regex=php' '--with-sablot-js=shared,no' '--with-snmp=shared' '--with-sybase-ct=shared,/usr' '--with-t1lib=shared' '--with-tiff-dir=shared,/usr' '--with-unixODBC=shared' '--with-xmlrpc=shared,/usr' '--with-xslt-sablot=shared' '--with-yaz=shared' '--with-zip=shared' '--with-zlib=shared' '--with-zlib-dir=shared' Previous Comments: [2002-11-29 06:29:02] [EMAIL PROTECTED] Please try using this CVS snapshot: http://snaps.php.net/php4-latest.tar.gz For Windows: http://snaps.php.net/win32/php4-win32-latest.zip [2002-11-29 06:19:12] [EMAIL PROTECTED] I a simple script i got the following error notice. Notice: ps_files_cleanup_dir: opendir(F:\php\sessions) failed: Invalid argument (22) in ... on line 11 On line eleven in this script only a session_start() is called. The permissions are set correctly, because the script is able to write, edit and delete the session files with the filesystem functions. I asked in the german php newsgroup and they told me, that this could be a bug. Systeminformation: -- PHP-Version : 4.2.3 Operatingsystem : Windows 2000 Advanced Server WebServer : IIS 5.0 Sessionsettings: -- session.save_handler = files session.save_path = F:\php\sessions session.use_cookies = 1 session.name = sid session.auto_start= 0 session.cookie_lifetime = 0 session.cookie_path = / session.cookie_domain = session.serialize_handler = php session.gc_probability= 1 session.gc_maxlifetime= 1440 session.referer_check = session.entropy_length= 0 session.entropy_file = session.cache_limiter = nocache
#20810 [NEW]: truncated field name
From: [EMAIL PROTECTED] Operating system: SUSE PHP version: 4.2.3 PHP Bug Type: MSSQL related Bug description: truncated field name I have column username_calling_centr_operators I make request select username_calling_centr_operators from tablename; In SQLConsole all is ok. In php name of column truncated, and I get Array ( [username_calling_centr_operato] = ps ) -- Edit bug report at http://bugs.php.net/?id=20810edit=1 -- Try a CVS snapshot: http://bugs.php.net/fix.php?id=20810r=trysnapshot Fixed in CVS: http://bugs.php.net/fix.php?id=20810r=fixedcvs Fixed in release: http://bugs.php.net/fix.php?id=20810r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=20810r=needtrace Try newer version: http://bugs.php.net/fix.php?id=20810r=oldversion Not developer issue:http://bugs.php.net/fix.php?id=20810r=support Expected behavior: http://bugs.php.net/fix.php?id=20810r=notwrong Not enough info:http://bugs.php.net/fix.php?id=20810r=notenoughinfo Submitted twice:http://bugs.php.net/fix.php?id=20810r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=20810r=globals PHP 3 support discontinued: http://bugs.php.net/fix.php?id=20810r=php3 Daylight Savings: http://bugs.php.net/fix.php?id=20810r=dst IIS Stability: http://bugs.php.net/fix.php?id=20810r=isapi
#20811 [NEW]: var_dump($GLOBALS) exits with fatal error
From: [EMAIL PROTECTED] Operating system: linux debian PHP version: 4.2.3 PHP Bug Type: *General Issues Bug description: var_dump($GLOBALS) exits with fatal error br / bFatal error/b: Nesting level too deep - recursive dependency? in b/home/web/hybrid.kahncentral.net/CVSROOT/loginfo.php/b on line b3/bbr / #!/usr/bin/php4 -q ?php var_dump($GLOBALS); ? somehow the crash here shouldnt be right, correct? -- Edit bug report at http://bugs.php.net/?id=20811edit=1 -- Try a CVS snapshot: http://bugs.php.net/fix.php?id=20811r=trysnapshot Fixed in CVS: http://bugs.php.net/fix.php?id=20811r=fixedcvs Fixed in release: http://bugs.php.net/fix.php?id=20811r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=20811r=needtrace Try newer version: http://bugs.php.net/fix.php?id=20811r=oldversion Not developer issue:http://bugs.php.net/fix.php?id=20811r=support Expected behavior: http://bugs.php.net/fix.php?id=20811r=notwrong Not enough info:http://bugs.php.net/fix.php?id=20811r=notenoughinfo Submitted twice:http://bugs.php.net/fix.php?id=20811r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=20811r=globals PHP 3 support discontinued: http://bugs.php.net/fix.php?id=20811r=php3 Daylight Savings: http://bugs.php.net/fix.php?id=20811r=dst IIS Stability: http://bugs.php.net/fix.php?id=20811r=isapi
#20811 [Opn-Csd]: var_dump($GLOBALS) exits with fatal error
ID: 20811 Updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] -Status: Open +Status: Closed Bug Type: *General Issues Operating System: linux debian PHP Version: 4.2.3 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: [2002-12-04 09:19:34] [EMAIL PROTECTED] br / bFatal error/b: Nesting level too deep - recursive dependency? in b/home/web/hybrid.kahncentral.net/CVSROOT/loginfo.php/b on line b3/bbr / #!/usr/bin/php4 -q ?php var_dump($GLOBALS); ? somehow the crash here shouldnt be right, correct? -- Edit this bug report at http://bugs.php.net/?id=20811edit=1
#20812 [NEW]: ftp_get returns FALSE in case of success
From: [EMAIL PROTECTED] Operating system: Linux 2.2 / SuSE 6.3 PHP version: 4.3.0RC2 PHP Bug Type: FTP related Bug description: ftp_get returns FALSE in case of success The PHPFTP-script running fine with PHP 4.2.3 won't work with PHP 4.3.0RC2 because ftp_get returns false in spite of doing its work correctly. DB -- Edit bug report at http://bugs.php.net/?id=20812edit=1 -- Try a CVS snapshot: http://bugs.php.net/fix.php?id=20812r=trysnapshot Fixed in CVS: http://bugs.php.net/fix.php?id=20812r=fixedcvs Fixed in release: http://bugs.php.net/fix.php?id=20812r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=20812r=needtrace Try newer version: http://bugs.php.net/fix.php?id=20812r=oldversion Not developer issue:http://bugs.php.net/fix.php?id=20812r=support Expected behavior: http://bugs.php.net/fix.php?id=20812r=notwrong Not enough info:http://bugs.php.net/fix.php?id=20812r=notenoughinfo Submitted twice:http://bugs.php.net/fix.php?id=20812r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=20812r=globals PHP 3 support discontinued: http://bugs.php.net/fix.php?id=20812r=php3 Daylight Savings: http://bugs.php.net/fix.php?id=20812r=dst IIS Stability: http://bugs.php.net/fix.php?id=20812r=isapi
#20812 [Opn]: ftp_get returns FALSE in case of success
ID: 20812 User updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] Status: Open Bug Type: FTP related Operating System: Linux 2.2 / SuSE 6.3 PHP Version: 4.3.0RC2 New Comment: I forgot: we use ProFTPD 1.2.6 Previous Comments: [2002-12-04 09:28:42] [EMAIL PROTECTED] The PHPFTP-script running fine with PHP 4.2.3 won't work with PHP 4.3.0RC2 because ftp_get returns false in spite of doing its work correctly. DB -- Edit this bug report at http://bugs.php.net/?id=20812edit=1
#15198 [Com]: unexpected error 'OCI8 Recursive call!'
ID: 15198 Comment by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] Status: Closed Bug Type: OCI8 related Operating System: Redhat Linux 6.1 PHP Version: 4.1.1 Assigned To: thies New Comment: I've narrowed down a cause of this error to a lockwait on one or more rows that a query is trying to modify. This is the simplest way to reproduce: 1) in sqlplus: update table_name set column_2 = column_2_val where column_1 = column_1_val; (do not commit) 2) run the same query from php 3) immediately run this query from another session (a client with a GUI is best for viewing results of this query). Pay attention to the lockwait column, it will not be null: select count(*) instances, se.machine, se.osuser, sa.executions, se.lockwait, sa.sql_text from v$sqlarea sa, v$session se where sa.address = se.sql_address and sa.hash_value = se.sql_hash_value and sa.executions 0 and se.status = 'ACTIVE' group by se.machine, se.osuser, sa.executions, se.lockwait, sa.sql_text order by instances desc; 4) after a while your php script will come back with OCI8 Recursive call! 5) don't forget to rollback your update in sqlplus! This is the most simple scenario causing the bug. The problem also happens on queries I use that operate (DML) on the same data and take a while. Possible causes of this are users clicking multiple times on links to pages that execute DML queries. However, sometimes I get this error when there is only one query with a non-null lockwait value.. very strange. I've tried registering shutdown functions and wrapping the queries that most often produce this error with checks on connection_status() to prevent running the query if user has abandoned the request. None of these measures have helped the problem. It's disturbing that the entire apache process has to die because of this. Any suggestions are welome. Previous Comments: [2002-04-13 09:07:32] [EMAIL PROTECTED] No feedback was provided for this bug, so it is being suspended. If you are able to provide the information that was requested, please do so and change the status of the bug back to Open. if this itches you too badly you can just take out the exit(-1) call from oci8.c and recompile. but it might kill your oracle MTS [2002-02-28 13:31:40] [EMAIL PROTECTED] I've also got a PHP application that suffered from the OCI8 Recursive call! error after an upgrade to PHP 4.1.1. It worked fine with PHP 4.0.x, but with 4.1.x it randomly chokes with that error. There is nothing special going on. I'm not using bindings, I've just got scripts that logon, parse, execute, insert, delete, logoff, etc. Because of this, I'm forced to stick with the 4.0.x tree. I'd give you more debugging information, but it is a deployed system and I don't want to introduce the bugs into it. [2002-02-05 05:07:25] [EMAIL PROTECTED] are you sure that you are not hitting the time_limit? reverting to 4.0.6 is not a smartthimg (tm) to do as a recursive oci call might kill your oracle MTS (if you use it). that's the only reason this catch got implemented. maybe useing ociinternaldebug(1) and sending me the output (and just the output of the oci module) would help. [2002-02-05 03:30:24] [EMAIL PROTECTED] Well, I have investigated the situation a bit more: I have a script which takes a long time (a maintenance script that runs at night, using php cgi binary), so I have set set_time_limit(7200) (which is two hours!) In the script, there's a complex query that takes 3 minutes to run. During this query, I get this OCI8 Recursive Call error and the script fails, even though the time limit has not been reached yet. Is there some internal timeout in the OCI calls? I now have to downgrade to 4.0.6 to prevent the problem. [2002-01-25 10:40:07] [EMAIL PROTECTED] this happens when an oci-call gets interrupted by a signal. this should only happen in 2 stituations: - you script hits max_execution_time (bad) - you did an apachectrl restart instead of apachectrl graceful the message recursive call is consitered a fatal-error and the apache child that generated that message will be terminated by the php oci-driveri. this is cause i've seen oracle MTS servers crashing when a client tried to call the oci* stuff in a reentrant way. i currently know no better way to save my unbreakable oracle from crashing;-)
#11442 [Com]: Random Warnig: Failed opening on any php file
ID: 11442 Comment by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] Status: No Feedback Bug Type: iPlanet related Operating System: Solaris 7 PHP Version: 4.1 New Comment: We are running PHP 4.2.3 with iPlanet Enterprise Web Server 6.0 SP4. We have the same php module used by several server instances, one of which works perfectly. The php module in other instances seems to freeze randomly: one minute the page works, next all we have is an empty page containing nothing more than htmlbody/body/html tags. Previous Comments: [2002-09-26 20:04:33] [EMAIL PROTECTED] Please try using this CVS snapshot: http://snaps.php.net/php4-latest.tar.gz For Windows: http://snaps.php.net/win32/php4-win32-latest.zip [2002-09-09 10:36:57] [EMAIL PROTECTED] Please try using this CVS snapshot: http://snaps.php.net/php4-latest.tar.gz For Windows: http://snaps.php.net/win32/php4-win32-latest.zip I know I've said it before, but there was a bug fix in 4.2.3 that dealt with a timing issue. Wondering if this helps any for your systems. [2002-09-05 10:10:57] [EMAIL PROTECTED] I have the same problem under Debian/apache/PHP 4.2.2 Warning: Failed opening '/var/www/HTTP/index.php' for inclusion .. I have read that include_path in php.ini should be set to ., then that include_path shoul be commented, but nothing helps... [2002-08-29 10:13:08] [EMAIL PROTECTED] I'm experimenting exactly the same problem reported by [EMAIL PROTECTED], but I'm using PHP 4.1.2 and Iplanet WebServer 4.1sp9 over sparc solaris 8. This is a heavy load web server. [2002-08-23 07:10:22] [EMAIL PROTECTED] I have same problem after using virtual web servers. But the problem does not appear random it apperas since I installed the virtual web servers. Operating System is Solaris 5.7 HTTP Server ist iPlanet 4 PHP Version is 4.0.4 (because LDAP support does not work with iPlanet in other PHP Releases under 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/11442 -- Edit this bug report at http://bugs.php.net/?id=11442edit=1
#20807 [Opn-Bgs]: 'make install' failed on cygwin
ID: 20807 Updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] -Status: Open +Status: Bogus Bug Type: Compile Failure Operating System: winXP PHP Version: 4CVS-2002-12-04 (dev) New Comment: This is a bug in the autotools for Cygwin, which as far as I know has been addressed. If you are using the latest buildtools, try removing configure and executing 'buildconf'. If that still doesn't work, re-open the bug report. Basically - the tempname created is created with '.exe' extension, but returned to the shell var without it. Not a bug in PHP - bogus Previous Comments: [2002-12-04 07:18:48] [EMAIL PROTECTED] make along is ok.. [2002-12-04 07:17:46] [EMAIL PROTECTED] here: Installing PHP SAPI module chmod: changing permissions of `/usr/local/bin/#INST@3220#': No such file or directory make: *** [install-sapi] Error - -- Edit this bug report at http://bugs.php.net/?id=20807edit=1
#20777 [Bgs]: will not find apache2 apxs
ID: 20777 User updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] Status: Bogus Bug Type: Apache2 related Operating System: Solaris 8 PHP Version: 4.3.0RC2 New Comment: You are right I reinstalled apache and everything works now strange.. Previous Comments: [2002-12-04 03:24:01] [EMAIL PROTECTED] Tell us what this says: /www2/bin/apxs -q INCLUDEDIR [2002-12-04 01:57:32] [EMAIL PROTECTED] This works just fine here. Must be something wrong in your apache2 install. (update it, it's most likely too old or you're really trying to configure with apache1) [2002-12-03 14:48:19] [EMAIL PROTECTED] Sorry I typed the message wrong it is /www2/bin/apxs [2002-12-02 18:52:24] [EMAIL PROTECTED] You're using /www/bin/apxs but showing the output of /www2/bin/apxs, so which one is the right one? [2002-12-02 18:49:52] [EMAIL PROTECTED] ./configure --with-apxs2=/www/bin/apxs just testing Configuring SAPI modules checking for AOLserver support... no checking for Apache 1.x module support via DSO through APXS... no checking for Apache 1.x module support... no checking for mod_charset compatibility option... no checking for Apache 2.0 module support via DSO through APXS... Sorry, I cannot run apxs. Possible reasons follow: 1. Perl is not installed 2. apxs was not found. Try to pass the path using --with-apxs2=/path/to/apxs 3. Apache was not built using --enable-so (the apxs usage page is displayed) The output of /www2/bin/apxs follows: Usage: apxs -g [-S var=val] -n modname apxs -q [-S var=val] query ... apxs -c [-S var=val] [-o dsofile] [-D name[=value]] [-I incdir] [-L libdir] [-l libname] [-Wc,flags] [-Wl,flags] files ... apxs -i [-S var=val] [-a] [-A] [-n modname] dsofile ... apxs -e [-S var=val] [-a] [-A] [-n modname] dsofile ... configure: error: Aborting bash-2.05# perl asdf ^C bash-2.05# perl -v This is perl, v5.6.1 built for sun4-solaris Copyright 1987-2001, Larry Wall Perl may be copied only under the terms of either the Artistic License or the GNU General Public License, which may be found in the Perl 5 source kit. Complete documentation for Perl, including FAQ lists, should be found on this system using `man perl' or `perldoc perl'. If you have access to the Internet, point your browser at http://www.perl.com/, the Perl Home Page. bash-2.05# -- Edit this bug report at http://bugs.php.net/?id=20777edit=1
#3672 [Com]: httpd crashes if MySQL-support is enabled
ID: 3672 Comment by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] Status: Closed Bug Type: Reproducible Crash Operating System: Linux Red Hat 6.1 i686/SMP PHP Version: 3.0.15 New Comment: bug occurs with and without mysql support, reason is somewhere in getservbyname (try to compile use php's getservbyname, it crashes too!) which is a libc item. seems to be a libc bug or something, nothing special about php. if you need fast help with this: go to /ext/mysql, edit php_mysql.c, search for OnMySQLPort, and comment out 3 lines starting with the lines if ((serv_ptr = getservbyname... moritz Previous Comments: [2001-02-10 15:28:55] [EMAIL PROTECTED] closing. broken packages aren't our problem. [2000-02-29 20:34:41] [EMAIL PROTECTED] Compiling MySQL from a source tarball (mysql-3.22.32.tar.gz) cures the problem. I haven't changed status to closed because I think that the situation needs to be solved somehow: Package based system administration is _very_ important in some organizations (preventing massive confusion if sysadm gets a new job...). I wonder why is this only a problem with PHP 3.0.15 and not 3.0.13? [2000-02-29 19:03:57] [EMAIL PROTECTED] Problem summary: Apache instantly crashes. Note: No problem with PHP 3.0.13 (everything else being equal). Base system: Red Hat 6.1. Kernel upgraded to Red Hat Rawhide's 2.2.14-1.1.0 glibc, gd, egcs as Red Hat 6.1 default Hardware: i686SMP (two equally clocked CPUs) MySQL versions tried: 3.22.30 3.22.32 (both gave segfault) Apache-version: apache-mod_ssl (Apache 1.3.12, modssl 2.6.0.) openssl version 0.9.5 Ordinary (non-modssl) Apache not tried. Starting Apache with either (httpd or httpd -DSSL makes no difference). PHP configure options: --with-apxs \ --prefix=/usr \ --with-config-file-path=/etc/httpd/conf \ --with-mysql \ --with-system-regex \ --with-memory-limit \ --with-gd \ --enable-url-includes \ --with-xml Removing --with-mysql cures the problem. Compiler optimization flags tried (trouble with both sets of options): -O3 -march=pentiumpro -mcpu=pentiumpro -malign-loops=2 -malign-jumps=2 -malign-functions=2 -O2 -m486 Backtrace: [root@developer SPECS]# httpd -X Segmentation fault (core dumped) [root@developer SPECS]# gdb /usr/sbin/httpd core GNU gdb 4.18 Copyright 1998 Free Software Foundation, Inc. GDB is free software, covered by the GNU General Public License, and you are welcome to change it and/or distribute copies of it under certain conditions. Type show copying to see the conditions. There is absolutely no warranty for GDB. Type show warranty for details. This GDB was configured as i386-redhat-linux...(no debugging symbols found)... Core was generated by `httpd -X'. Program terminated with signal 11, Segmentation fault. Reading symbols from /lib/libm.so.6...done. Reading symbols from /lib/libcrypt.so.1...done. Reading symbols from /lib/libdb.so.3...done. Reading symbols from /lib/libdl.so.2...done. Reading symbols from /lib/libc.so.6...done. Reading symbols from /lib/ld-linux.so.2...done. Reading symbols from /lib/libnss_files.so.2...done. Reading symbols from /usr/lib/apache/mod_mmap_static.so...done. Reading symbols from /usr/lib/apache/mod_vhost_alias.so...done. Reading symbols from /usr/lib/apache/mod_env.so...done. Reading symbols from /usr/lib/apache/mod_define.so...done. Reading symbols from /usr/lib/apache/mod_log_config.so...done. Reading symbols from /usr/lib/apache/mod_mime_magic.so...done. Reading symbols from /usr/lib/apache/mod_mime.so...done. Reading symbols from /usr/lib/apache/mod_negotiation.so...done. Reading symbols from /usr/lib/apache/mod_status.so...done. Reading symbols from /usr/lib/apache/mod_info.so...done. Reading symbols from /usr/lib/apache/mod_include.so...done. Reading symbols from /usr/lib/apache/mod_autoindex.so...done. Reading symbols from /usr/lib/apache/mod_dir.so...done. Reading symbols from /usr/lib/apache/mod_cgi.so...done. Reading symbols from /usr/lib/apache/mod_asis.so...done. Reading symbols from /usr/lib/apache/mod_imap.so...done. Reading symbols from /usr/lib/apache/mod_actions.so...done. Reading symbols from /usr/lib/apache/mod_userdir.so...done. Reading symbols from /usr/lib/apache/mod_alias.so...done. Reading symbols from /usr/lib/apache/mod_rewrite.so...done. Reading symbols from /usr/lib/apache/mod_access.so...done. Reading symbols from /usr/lib/apache/mod_auth.so...done. Reading symbols from /usr/lib/apache/mod_digest.so...done. Reading symbols from /usr/lib/apache/mod_cern_meta.so...done. Reading symbols from
#20813 [NEW]: opendir() returns errno22 with UNC path
From: [EMAIL PROTECTED]
Operating system: NT4SP6 IIS
PHP version: 4.2.3
PHP Bug Type: Directory function related
Bug description: opendir() returns errno22 with UNC path
if ($handle = opendir(//server/share)) {
while ($file = readdir($handle)) {
echo $filebr;
}
closedir($handle);
}
produces:
Warning: OpenDir: Invalid argument (errno 22)
I have tried setting the UNC share permissions to both Everyone - Read and
Everyone - Full Control and it does not matter.
--
Edit bug report at http://bugs.php.net/?id=20813edit=1
--
Try a CVS snapshot: http://bugs.php.net/fix.php?id=20813r=trysnapshot
Fixed in CVS: http://bugs.php.net/fix.php?id=20813r=fixedcvs
Fixed in release: http://bugs.php.net/fix.php?id=20813r=alreadyfixed
Need backtrace: http://bugs.php.net/fix.php?id=20813r=needtrace
Try newer version: http://bugs.php.net/fix.php?id=20813r=oldversion
Not developer issue:http://bugs.php.net/fix.php?id=20813r=support
Expected behavior: http://bugs.php.net/fix.php?id=20813r=notwrong
Not enough info:http://bugs.php.net/fix.php?id=20813r=notenoughinfo
Submitted twice:http://bugs.php.net/fix.php?id=20813r=submittedtwice
register_globals: http://bugs.php.net/fix.php?id=20813r=globals
PHP 3 support discontinued: http://bugs.php.net/fix.php?id=20813r=php3
Daylight Savings: http://bugs.php.net/fix.php?id=20813r=dst
IIS Stability: http://bugs.php.net/fix.php?id=20813r=isapi
#6445 [Com]: problem with opendir
ID: 6445 Comment by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] Status: Closed Bug Type: Filesystem function related Operating System: Windows NT 4 sp 6a PHP Version: 4.0.1pl2 New Comment: I am still having this problem on the same platform, newer PHP. Reference bug # 20813. Previous Comments: [2001-02-20 08:01:06] [EMAIL PROTECTED] No feedback, considered fixed. --Jani [2001-01-06 01:35:34] [EMAIL PROTECTED] does this problem still exist in PHP 4.0.4? [2000-08-30 13:30:33] [EMAIL PROTECTED] I am using NT 4 sp 6a with PHP 4.01 pl2 on IIS 4. When I use the opendir command (or the dir object) it works fine as long as I try to open drive c (c:/). If I try to view the directory on any other drive, it fails. The drive can be a second hard drive (d:/), a mapped drive, a cdrom, etc. Here is the code and error: Warning: OpenDir: Invalid argument (errno 22) in C:\Inetpub\wwwroot\trinityweb\test.php on line 12 here is the offending code: chdir(f:/); $dir = dir(f:/); // have also tried $dir= dir(.); I have verified that I have full permissions to f:/. I can also read the f:/. file from that directory ok to verify in php that the drive exists. Please let me know as soon as this is fixed. Scott -- Edit this bug report at http://bugs.php.net/?id=6445edit=1
#7220 [Opn]: Error Report on Function Arguments
ID: 7220
Updated by: [EMAIL PROTECTED]
Reported By: [EMAIL PROTECTED]
Status: Open
Bug Type: Feature/Change Request
-Operating System: HP-UX / Linux / FreeBSD
+Operating System: all
-PHP Version: 4.0.3
+PHP Version: 4.3.0
New Comment:
This sounds like a decent request, how about having the error report
both locations?
Previous Comments:
[2001-02-24 12:38:22] [EMAIL PROTECTED]
Not really a bug.. its the expected behaviour. Changing to feature
request.
James
[2000-10-15 11:38:02] [EMAIL PROTECTED]
function bob($arg1, $arg2) {
;
}
bob(4);
bob(5,2);
i.e., PHP will falselpy report the error with bob(4) in funcion Bob
(i.e., line 1)
instead of bob(4) i.e., line 5.
This is quite annoying when tracking down function calls that have an
incorrect number of arguments
--
Edit this bug report at http://bugs.php.net/?id=7220edit=1
#7535 [Ana]: Entities missing in get_html_translation_table ( HTML_ENTITIES );
ID: 7535 Updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] Status: Analyzed Bug Type: Feature/Change Request Operating System: FreeBSD PHP Version: 4.0.3pl1 New Comment: Can someone explain this a bit in laymens terms so it can be documented? Previous Comments: [2002-04-27 18:58:16] [EMAIL PROTECTED] yuml; and euro; are implemented. (euro; when using the iso-8859-15 charset.) the other entities are not included because htmlentities() does not handle entities outside of the 8-bit character range. [2000-10-30 13:26:39] [EMAIL PROTECTED] These are the entities not listed in this function. Character entity references in HTML 4 (http://www.w3.org/TR/html4/sgml/entities.html) yuml; = #255; fnof; = #402; Alpha; = #913; Beta; = #914; Gamma; = #915; Delta; = #916; Epsilon; = #917; Zeta; = #918; Eta; = #919; Theta; = #920; Iota; = #921; Kappa; = #922; Lambda; = #923; Mu; = #924; Nu; = #925; Xi; = #926; Omicron; = #927; Pi; = #928; Rho; = #929; Sigma; = #931; Tau; = #932; Upsilon; = #933; Phi; = #934; Chi; = #935; Psi; = #936; Omega; = #937; alpha; = #945; beta; = #946; gamma; = #947; delta; = #948; epsilon; = #949; zeta; = #950; eta; = #951; theta; = #952; iota; = #953; kappa; = #954; lambda; = #955; mu; = #956; nu; = #957; xi; = #958; omicron; = #959; pi; = #960; rho; = #961; sigmaf; = #962; sigma; = #963; tau; = #964; upsilon; = #965; phi; = #966; chi; = #967; psi; = #968; omega; = #969; thetasym; = #977; upsih; = #978; piv; = #982; bull; = #8226; hellip; = #8230; prime; = #8242; Prime; = #8243; oline; = #8254; frasl; = #8260; weierp; = #8472; image; = #8465; real; = #8476; trade; = #8482; alefsym; = #8501; larr; = #8592; uarr; = #8593; rarr; = #8594; darr; = #8595; harr; = #8596; crarr; = #8629; lArr; = #8656; uArr; = #8657; rArr; = #8658; dArr; = #8659; hArr; = #8660; forall; = #8704; part; = #8706; exist; = #8707; empty; = #8709; nabla; = #8711; isin; = #8712; notin; = #8713; ni; = #8715; prod; = #8719; sum; = #8721; minus; = #8722; lowast; = #8727; radic; = #8730; prop; = #8733; infin; = #8734; ang; = #8736; and; = #8743; or; = #8744; cap; = #8745; cup; = #8746; int; = #8747; there4; = #8756; sim; = #8764; cong; = #8773; asymp; = #8776; ne; = #8800; equiv; = #8801; le; = #8804; ge; = #8805; sub; = #8834; sup; = #8835; nsub; = #8836; sube; = #8838; supe; = #8839; oplus; = #8853; otimes; = #8855; perp; = #8869; sdot; = #8901; lceil; = #8968; rceil; = #8969; lfloor; = #8970; rfloor; = #8971; lang; = #9001; rang; = #9002; loz; = #9674; spades; = #9824; clubs; = #9827; hearts; = #9829; diams; = #9830; OElig; = #338; oelig; = #339; Scaron; = #352; scaron; = #353; Yuml; = #376; circ; = #710; tilde; = #732; ensp; = #8194; emsp; = #8195; thinsp; = #8201; zwnj; = #8204; zwj; = #8205; lrm; = #8206; rlm; = #8207; ndash; = #8211; mdash; = #8212; lsquo; = #8216; rsquo; = #8217; sbquo; = #8218; ldquo; = #8220; rdquo; = #8221; bdquo; = #8222; dagger; = #8224; Dagger; = #8225; permil; = #8240; lsaquo; = #8249; rsaquo; = #8250; euro; = #8364; -- Edit this bug report at http://bugs.php.net/?id=7535edit=1
#20813 [Opn]: opendir() returns errno22 with UNC path
ID: 20813
User updated by: [EMAIL PROTECTED]
Reported By: [EMAIL PROTECTED]
Status: Open
Bug Type: Directory function related
Operating System: NT4SP6 IIS
PHP Version: 4.2.3
New Comment:
Bug #9354 also produces same result
Bug #6445 is the same problem
Bug #12699 is the same problem
Bug #12524 is the same problem
Is this only NT4???
Previous Comments:
[2002-12-04 10:34:08] [EMAIL PROTECTED]
if ($handle = opendir(//server/share)) {
while ($file = readdir($handle)) {
echo $filebr;
}
closedir($handle);
}
produces:
Warning: OpenDir: Invalid argument (errno 22)
I have tried setting the UNC share permissions to both Everyone - Read
and Everyone - Full Control and it does not matter.
--
Edit this bug report at http://bugs.php.net/?id=20813edit=1
#12776 [Sus-Csd]: 4.0.7RC1: array_walk crash
ID: 12776
Updated by: [EMAIL PROTECTED]
Reported By: [EMAIL PROTECTED]
-Status: Suspended
+Status: Closed
Bug Type: Reproducible crash
Operating System: Linux
PHP Version: 4.0.6
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:
[2002-01-27 05:25:51] [EMAIL PROTECTED]
Hi sander,
I know this problem exists and this bug cannot be fixed easily
Status = SUSPENDED
TO PHP USERS: *ONLY* change parameter passed! *Never* change array or
array elements in walk funciton.
[2002-01-27 05:19:57] [EMAIL PROTECTED]
No feedback.
[2002-01-06 07:37:36] [EMAIL PROTECTED]
Does this problem still occur with 4.1.1?
[2001-08-16 17:25:58] [EMAIL PROTECTED]
On my machine, this will crash it:
function test($val,$key) {
global $globalArray;
$globalArray[]=$key;
}
$arr=array('k'='v');
array_walk($arr,'test');
echo testing.$globalArray[0];
Changing the last line to:
echo test.$globalArray[0];
makes it work. Uh?
bt:
#0 0x4013913e in memcpy () from /lib/i686/libc.so.6
#1 0xbfffe3b0 in ?? ()
#2 0x080f2550 in execute (op_array=0x816c334) at
./zend_execute.c:1105
#3 0x080da832 in zend_execute_scripts (type=8, file_count=3) at
zend.c:806
#4 0x0805faab in php_execute_script (primary_file=0xb8d0) at
main.c:1310
[2001-08-16 17:22:29] [EMAIL PROTECTED]
Oops, never mind, it is not fixed in CVS. It just morphed slightly.
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/12776
--
Edit this bug report at http://bugs.php.net/?id=12776edit=1
#20773 [Com]: will not compile with iplanet ldap 5.0.sp1
ID: 20773 Comment by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] Status: Closed Bug Type: LDAP related Operating System: Solaris 8 PHP Version: 4.3.0RC2 New Comment: Well, I compiled the 200212041430 version and haven't been able to reproduce the error so I guess it's fixed. BTW, I wasn't able to debug httpd anyways; I followed the info about generating a non core backtrace and httpd seemed to start but I couldn't contact it. Thanx a lot, Peder Previous Comments: [2002-12-03 11:25:28] [EMAIL PROTECTED] I fixed the problem in CVS but I guess the snapshot was already generated before that. Anyway, good to hear it works now. About that mysql segfault..please provide a backtrace of it. [2002-12-03 09:27:29] [EMAIL PROTECTED] I tried the php snapshot to compile against Sun One Directory/iPlanet SDK 5.08 on linux/apache This is my debug.log: CONFIGURE: './configure' '--with-apxs=/usr/sbin/apxs' '--enable-debug=no' '--prefix=/opt/php-4_snap' '--with-config-file-path=/etc/php' '--enable-shmop' '--enable-sysvshm' '--enable-versioning' '--with-jpeg-dir=/usr/local' '--with-gd' '--enable-gd-native-tt' '--disable-static' '--disable-debug' '--disable-rpath' '--with-png-dir=/usr' '--with-zlib-dir=/usr' '-with-freetype-dir=/usr' '--with-t1lib=/usr' '--enable-track-vars' '--enable-trans-sid' '--with-mysql' '--with-ldap=/usr/local' CC: gcc CFLAGS: -O3 -march=pentium2 CPPFLAGS:-DLINUX=22 -DDEV_RANDOM=/dev/random -DEAPI -DEAPI_MM CXX: CXXFLAGS: INCLUDES:-I$(top_builddir)/Zend -I/usr/local/include -I/usr/include/freetype2 LDFLAGS: -Wl,-rpath,/usr/local/lib -L/usr/local/lib LIBS: -lssldap50 -lplds4 -lplc4 -lnspr4 -lt1 -lfreetype -lpng -lz -ljpeg -lz -lcrypt -lresolv -lm -ldl -lnsl -lcrypt DLIBS: SAPI: apache PHP_RPATHS: /usr/local/lib uname -a: Linux localhost 2.4.19 #6 SMP Fri Sep 6 16:06:31 CEST 2002 i686 unknown gcc -o conftest -O3 -march=pentium2 -DLINUX=22 -DDEV_RANDOM=/dev/random -DEAPI -DEAPI_MM -Wl,-rpath,/usr/local/lib -L/usr/local/lib conftest.c -lssldap50 -lplds4 -lplc4 -lnspr4 -lt1 -lfreetype -lpng -lz -ljpeg -lz -lcrypt -lresolv -lm -ldl -lnsl -lcrypt 15 /usr/local/lib/libssldap50.so: undefined reference to `SSL_ImportFD' /usr/local/lib/libssldap50.so: undefined reference to `prldap_get_session_info' /usr/local/lib/libssldap50.so: undefined reference to `SSL_OptionSetDefault' /usr/local/lib/libssldap50.so: undefined reference to `prldap_set_session_info' /usr/local/lib/libssldap50.so: undefined reference to `PK11_FindCertFromNickname' /usr/local/lib/libssldap50.so: undefined reference to `NSS_Initialize' /usr/local/lib/libssldap50.so: undefined reference to `CERT_VerifyCertName' /usr/local/lib/libssldap50.so: undefined reference to `ldap_unbind' /usr/local/lib/libssldap50.so: undefined reference to `SSL_AuthCertificateHook' /usr/local/lib/libssldap50.so: undefined reference to `ldap_set_lderrno' /usr/local/lib/libssldap50.so: undefined reference to `SSL_RevealURL /usr/local/lib/libssldap50.so: undefined reference to `CERT_VerifyCertNow' /usr/local/lib/libssldap50.so: undefined reference to `NSS_Init' /usr/local/lib/libssldap50.so: undefined reference to `prldap_get_socket_info' /usr/local/lib/libssldap50.so: undefined reference to `PK11_SetPasswordFunc' /usr/local/lib/libssldap50.so: undefined reference to `PK11_FindKeyByAnyCert' /usr/local/lib/libssldap50.so: undefined reference to `ldap_get_option' /usr/local/lib/libssldap50.so: undefined reference to `ldap_set_option' /usr/local/lib/libssldap50.so: undefined reference to `PORT_SetError' /usr/local/lib/libssldap50.so: undefined reference to `PK11_ConfigurePKCS11' /usr/local/lib/libssldap50.so: undefined reference to `SSL_GetClientAuthDataHook' /usr/local/lib/libssldap50.so: undefined reference to `SSL_OptionSet' /usr/local/lib/libssldap50.so: undefined reference to `prldap_install_routines' /usr/local/lib/libssldap50.so: undefined reference to `CERT_DestroyCertificate' /usr/local/lib/libssldap50.so: undefined reference to `NSS_SetDomesticPolicy' /usr/local/lib/libssldap50.so: undefined reference to `prldap_set_socket_info' /usr/local/lib/libssldap50.so: undefined reference to `SECKEY_DestroyPrivateKey' /usr/local/lib/libssldap50.so: undefined reference to `SSL_PeerCertificate' /usr/local/lib/libssldap50.so: undefined reference to `SSL_ResetHandshake' /usr/local/lib/libssldap50.so: undefined reference to `ldap_init' /usr/local/lib/libssldap50.so: undefined reference to `CERT_GetDefaultCertDB' /usr/local/lib/libssldap50.so: undefined reference to `SSL_SetURL' I had to fix this for php4-200212031030 to please configure: --- configure.org Tue Dec 3 11:30:09 2002 +++ configure Tue Dec 3 15:48:49 2002 @@ -42264,7
#20814 [NEW]: reproducable, freaky parse error in 'here document' structure
From: [EMAIL PROTECTED] Operating system: several PHP version: 4.2.3 PHP Bug Type: Scripting Engine problem Bug description: reproducable, freaky parse error in 'here document' structure I've tested this on PHP 4.2.3 for OSX, Open BSD, Linux... If you leave any whitespace after the closing tag of a here document structure (not sure if that's what it is called, like in Perl) a parse error will occur but never for the correct line. This seems like a bug to me because a semi- colon should terminate the code allowing the programmer to put comments or whatever after the semi-colon. Here is an example: $variable = variable; $someVariable = hereDocument html body btext text $variable testing here document/b /body /html hereDocument; // closing comment or just whitespace echo $someVariable; After the closing hereDocument; if you leave any whitespace (other than a carriage return) or text, a parse error is generated but the line number never leads you to the right place. This can be very confusing if you are working on a large class (like I was) and you left a tab or space after a closing tag. I'm not sure how consciously supported the here document structure is but this is worth addressing since here documents can be very useful for storing large variables containing HTML code with double and single quotes, for example. While I'm submitting this bug, I might as well point -- Edit bug report at http://bugs.php.net/?id=20814edit=1 -- Try a CVS snapshot: http://bugs.php.net/fix.php?id=20814r=trysnapshot Fixed in CVS: http://bugs.php.net/fix.php?id=20814r=fixedcvs Fixed in release: http://bugs.php.net/fix.php?id=20814r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=20814r=needtrace Try newer version: http://bugs.php.net/fix.php?id=20814r=oldversion Not developer issue:http://bugs.php.net/fix.php?id=20814r=support Expected behavior: http://bugs.php.net/fix.php?id=20814r=notwrong Not enough info:http://bugs.php.net/fix.php?id=20814r=notenoughinfo Submitted twice:http://bugs.php.net/fix.php?id=20814r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=20814r=globals PHP 3 support discontinued: http://bugs.php.net/fix.php?id=20814r=php3 Daylight Savings: http://bugs.php.net/fix.php?id=20814r=dst IIS Stability: http://bugs.php.net/fix.php?id=20814r=isapi
#20814 [Opn]: reproducable, freaky parse error in 'here document' structure
ID: 20814 User updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] Status: Open Bug Type: Scripting Engine problem Operating System: several PHP Version: 4.2.3 New Comment: [quick on the trigger]... scratch that last sentence ... I was going to point out that the closing tag has to be flush left but I think that is not a bug. Previous Comments: [2002-12-04 11:04:39] [EMAIL PROTECTED] I've tested this on PHP 4.2.3 for OSX, Open BSD, Linux... If you leave any whitespace after the closing tag of a here document structure (not sure if that's what it is called, like in Perl) a parse error will occur but never for the correct line. This seems like a bug to me because a semi- colon should terminate the code allowing the programmer to put comments or whatever after the semi-colon. Here is an example: $variable = variable; $someVariable = hereDocument html body btext text $variable testing here document/b /body /html hereDocument; // closing comment or just whitespace echo $someVariable; After the closing hereDocument; if you leave any whitespace (other than a carriage return) or text, a parse error is generated but the line number never leads you to the right place. This can be very confusing if you are working on a large class (like I was) and you left a tab or space after a closing tag. I'm not sure how consciously supported the here document structure is but this is worth addressing since here documents can be very useful for storing large variables containing HTML code with double and single quotes, for example. While I'm submitting this bug, I might as well point -- Edit this bug report at http://bugs.php.net/?id=20814edit=1
#20801 [Fbk-Csd]: undefined symbol: xml_utf8_decode
ID: 20801 User updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] -Status: Feedback +Status: Closed Bug Type: Apache related Operating System: Linux/Debian PHP Version: 4.2.3 New Comment: Today's CVS snapshot works perfectly. Previous Comments: [2002-12-04 02:05:48] [EMAIL PROTECTED] Please try using this CVS snapshot: http://snaps.php.net/php4-latest.tar.gz For Windows: http://snaps.php.net/win32/php4-win32-latest.zip [2002-12-03 16:06:59] [EMAIL PROTECTED] I've compiled PHP 4.2.3, patched to work with GD2, as an apache module. I'm using apache-ssl, and when I try to start it, it gives me the following error: Starting web server: apache-sslSyntax error on line 243 of /etc/apache-ssl/httpd.conf: Cannot load /usr/lib/apache/1.3/libphp4.so into server: /usr/lib/apache/1.3/libphp4.so: undefined symbol: xml_utf8_decode failed compiled with: ./configure --prefix=/usr --with-regex=php --with-config-file-path=/etc/php4/apache --with-apxs=/usr/bin/apxs --disable-rpath --disable-debug --enable-memory-limit --enable-calendar --enable-sysvsem --enable-sysvshm --enable-track-vars --enable-trans-sid --enable-bcmath --with-bz2 --enable-ctype --with-db2 --with-iconv --with-ndbm --enable-exif --enable-filepro --enable-ftp --with-gettext --enable-mbstring --with-pcre-regex=/usr --enable-shmop --enable-sockets --enable-wddx --with-xml=/usr --with-expat-dir=/usr --enable-yp --with-zlib --without-pgsql --disable-static --with-layout=GNU --with-curl=shared,/usr --with-dom=shared,/usr --with-zlib-dir=/usr --with-gd=shared,/usr --with-jpeg-dir=shared,/usr --with-png-dir=shared,/usr --with-freetype-dir=shared,/usr --with-ldap=shared,/usr --with-mcal=shared,/usr --with-mhash=shared,/usr --with-mm --with-mysql=shared --without-unixODBC --with-recode=shared,/usr --enable-xslt --with-xslt-sablot=shared,/usr --with-snmp=shared --enable-ucd-snmp-hack --without-sybase-ct --with-ttf=shared,/usr --with-t1lib=shared,/usr -- Edit this bug report at http://bugs.php.net/?id=20801edit=1
#20814 [Opn]: reproducable, freaky parse error in 'here document' structure
ID: 20814 Updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] Status: Open Bug Type: Scripting Engine problem -Operating System: several +Operating System: all -PHP Version: 4.2.3 +PHP Version: 4.4.0-dev New Comment: To clarify a few points: a) This is known and is both documented and is a current feature request: http://bugs.php.net/bug.php?id=8685 http://www.php.net/language.types.string#language.types.string.syntax.heredoc b) The error that's reported is odd, and looks something like this: Parse error: parse error, unexpected $ in test.php on line 42 Where 42 is, for example, on the last line of test.php even when the error is elsewhere. This error sorta makes sense in most cases (like a missing quote or closing brace) but IMHO not here. Maybe someone can briefly explain what PHP is thinking. c) Many have attempted to fix this and many more have reported it (a) but it appears to be almost impossible to fix and remains a feature request. Again, it is documented with a big fat warning. Am leaving as open as this mentions the strange error too (b), not just the known feature request. Previous Comments: [2002-12-04 11:23:05] [EMAIL PROTECTED] [quick on the trigger]... scratch that last sentence ... I was going to point out that the closing tag has to be flush left but I think that is not a bug. [2002-12-04 11:04:39] [EMAIL PROTECTED] I've tested this on PHP 4.2.3 for OSX, Open BSD, Linux... If you leave any whitespace after the closing tag of a here document structure (not sure if that's what it is called, like in Perl) a parse error will occur but never for the correct line. This seems like a bug to me because a semi- colon should terminate the code allowing the programmer to put comments or whatever after the semi-colon. Here is an example: $variable = variable; $someVariable = hereDocument html body btext text $variable testing here document/b /body /html hereDocument; // closing comment or just whitespace echo $someVariable; After the closing hereDocument; if you leave any whitespace (other than a carriage return) or text, a parse error is generated but the line number never leads you to the right place. This can be very confusing if you are working on a large class (like I was) and you left a tab or space after a closing tag. I'm not sure how consciously supported the here document structure is but this is worth addressing since here documents can be very useful for storing large variables containing HTML code with double and single quotes, for example. While I'm submitting this bug, I might as well point -- Edit this bug report at http://bugs.php.net/?id=20814edit=1
#14736 [Opn-]: about error_reporting for $_GET
ID: 14736 Updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] -Status: Open +Status: Won\'t fix Bug Type: Feature/Change Request Operating System: all PHP Version: 4.1.1 New Comment: This is already possible with @. print @$_GET['id']; Regardless, autoglobals should still report undefined indices, I don't see any advantage in not reporting them but only the introduction of inconsistencies. This will never change, marking as Won\'t fix. See also: array_key_exists(). Previous Comments: [2001-12-28 10:58:15] [EMAIL PROTECTED] suggest that it should be possible to turn off warnning of undefined index of $_GET ans $_POST and so on.. example: such as: url: http://www.domain.com/index.php code: ?php echo $_GET['id']; ? would cause warnning 'Undefined index' unless the user must type in http://www.domain.com/index.php?id=123 or the code should be changed into: ?php if (!empty($_GET['id'])) print $_GET['id']; ? or maybe: ?php $id = empty($_GET['id'])?0:$_GET['id']; // just like register_global ? . echo id is: $id; // 'no warnning' for use here ? of cause, we can turn off warnning for a running website. buthow can the web developers bear it when developing ? it's a 'terrible' warnning message that we don't want, we should have our attentions to those warnning about variables like $foo['bar'] not $_GET['id'] nor $_POST['username'] -- Edit this bug report at http://bugs.php.net/?id=14736edit=1
#10571 [Com]: blank browser with Xitami
ID: 10571 Comment by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] Status: Closed Bug Type: Other web server Operating System: win2000 PHP Version: 4.0.4pl1 New Comment: I followed Tito's advice and finally I got PHP running with Xitami, but not in the way I want it to: PHP files can only be run whith XITAMI\WEBPAGES\ as document root directory (setting doc_root doesn't work) My Xitami is installed on D:\Xitami, my webfiles are on D:\web-filez. Now I have to move all PHP content from D:\web-filez to D:\xitami\webpages in order to make them work :o( so I guess this is still a BUG and will be fixed in the future. Chau, JM. Previous Comments: [2002-10-01 13:32:52] [EMAIL PROTECTED] I had the same problem. This is how I solved. If your PHP has been compiled with FORCE_CGI_DIRECT, you have to leave blank doc_root in php.ini and uncomment the line: cgi.force_redirect=1 In php.ini set cgi.redirect_status_env to an environment variable name, eg PHPON. cgi.redirect_status_env=PHPON; In autoexec.bat set the environment var to any value. eg add the line: set PHPON yes Also in autoexec.bat remember to add your PHP installation (eg c:\php) to the path. tito [2001-07-23 18:38:05] [EMAIL PROTECTED] no feedback after 30 days. [2001-06-23 14:55:41] [EMAIL PROTECTED] Does this happen with PHP 4.0.6 ? [2001-05-01 01:04:17] [EMAIL PROTECTED] I am running a Xitami (v2.4c1) server on win2000. I used the install shield to install PHP 4.0.4. All the filters and stuff seem to be set up right in Xitami. I have installed and used PHP 3 with the same server and followed the same steps to configure it for PHP 4. I have set the doc_root in the php.ini file to C:\Nigel\VWS. However, when I run a script nothing happens: I get a blank browser screen. Setting the display_startup_errors in the php.ini file I get the message: Fatal error: Unable to open C:\Nigel\VWS\ in Unknown on line 0 I tried commenting out the doc_root setting in the php.ini file and I get the same error only it's pointing to the cgi-bin directory of Xitami (even though I have told it to use c:\Nigel\VSM\ for files). I tried pointing the doc_root to the complete path of the php script file including it's filename and that worked and processed the file normally... every time the server started up php for any page. I really am stumped. Thanks in advance. [2001-05-01 01:02:02] [EMAIL PROTECTED] I am running a Xitami (v2.4c1) server on win2000. I used the install shield to install PHP 4.0.4. All the filters and stuff seem to be set up right in Xitami. I have installed and used PHP 3 with the same server and followed the same steps to configure it for PHP 4. I have set the doc_root in the php.ini file to C:\Nigel\VWS. However, when I run a script nothing happens: I get a blank browser screen. Setting the display_startup_errors in the php.ini file I get the message: Fatal error: Unable to open C:\Nigel\VWS\ in Unknown on line 0 I tried commenting out the doc_root setting in the php.ini file and I get the same error only it's pointing to the cgi-bin directory of Xitami (even though I have told it to use c:\Nigel\VSM\ for files). I tried pointing the doc_root to the complete path of the php script file including it's filename and that worked and processed the file normally... every time the server started up php for any page. I really am stumped. Thanks in advance. 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/10571 -- Edit this bug report at http://bugs.php.net/?id=10571edit=1
#20815 [NEW]: /main/reentrancy.c:192: too few arguments to function `readdir_r'
From: [EMAIL PROTECTED] Operating system: Linux 2.4.18 i686 GNU PHP version: 4.3.0RC2 PHP Bug Type: Compile Failure Bug description: /main/reentrancy.c:192: too few arguments to function `readdir_r' $./configure ... $./make ... .../main/reentrancy.c:192: In function `readdir_r': .../main/reentrancy.c:192: too few arguments to function `readdir_r' make: *** [reentrancy.lo] Error 1 It was the last version. Please, ¿Could someone fix it in the next version? I will send the report until then. Thanks. -- Edit bug report at http://bugs.php.net/?id=20815edit=1 -- Try a CVS snapshot: http://bugs.php.net/fix.php?id=20815r=trysnapshot Fixed in CVS: http://bugs.php.net/fix.php?id=20815r=fixedcvs Fixed in release: http://bugs.php.net/fix.php?id=20815r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=20815r=needtrace Try newer version: http://bugs.php.net/fix.php?id=20815r=oldversion Not developer issue:http://bugs.php.net/fix.php?id=20815r=support Expected behavior: http://bugs.php.net/fix.php?id=20815r=notwrong Not enough info:http://bugs.php.net/fix.php?id=20815r=notenoughinfo Submitted twice:http://bugs.php.net/fix.php?id=20815r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=20815r=globals PHP 3 support discontinued: http://bugs.php.net/fix.php?id=20815r=php3 Daylight Savings: http://bugs.php.net/fix.php?id=20815r=dst IIS Stability: http://bugs.php.net/fix.php?id=20815r=isapi
#20812 [Opn-Fbk]: ftp_get returns FALSE in case of success
ID: 20812 Updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] -Status: Open +Status: Feedback Bug Type: FTP related Operating System: Linux 2.2 / SuSE 6.3 PHP Version: 4.3.0RC2 New Comment: Not enough information was provided for us to be able to handle this bug. Please re-read the instructions at http://bugs.php.net/how-to-report.php If you can provide more information, feel free to add it to this bug and change the status back to Open. Thank you for your interest in PHP. Previous Comments: [2002-12-04 09:31:48] [EMAIL PROTECTED] I forgot: we use ProFTPD 1.2.6 [2002-12-04 09:28:42] [EMAIL PROTECTED] The PHPFTP-script running fine with PHP 4.2.3 won't work with PHP 4.3.0RC2 because ftp_get returns false in spite of doing its work correctly. DB -- Edit this bug report at http://bugs.php.net/?id=20812edit=1
#15018 [Opn]: opendir() not affected by safe_mode
ID: 15018 Updated by: [EMAIL PROTECTED] -Summary: readdir() not affected by safe_mode Reported By: [EMAIL PROTECTED] Status: Open -Bug Type: Feature/Change Request +Bug Type: Filesystem function related Operating System: Debian Linux -PHP Version: 4.1.0 +PHP Version: 4.3.0-RC2 New Comment: With: safe_mode = On safe_mode_gid = On The code below can browse any directory/file on the system. This mentions openbase_dir but one (at least I) would think Safe Mode would have more power. Safe mode is strict in some regards but super loose in others it seems. In the very least please explain this a bit so it can be documented. And btw, the following is in the _php_do_opendir code but what does it do? dirp = php_stream_opendir(Z_STRVAL_PP(arg), ENFORCE_SAFE_MODE|REPORT_ERRORS, NULL); Also AFICT this was suppose to be fixed: http://marc.theaimsgroup.com/?l=php-devm=101518887024304 Previous Comments: [2002-01-14 10:27:42] [EMAIL PROTECTED] Danielsan is right... i have had a short look into the sourcecode (ext/standard/dir.c) and compared chdir-function with opendir-function. In PHP_FUNCTION(chdir) i found this three-liner which seems to be a safe_mode-Check: - if (PG(safe_mode) !php_checkuid((*arg)-value.str.val, NULL, CHECKUI$ RETURN_FALSE; } - PHP_FUNCTION(opendir) (or _php_do_opendir() to which this function refers) does not have such a check, just a short open_basedir-Check. Oh, btw, it seems for me that chdir doesn't do a open_basedir-Check but i may be wrong. cu, Roland PS: All what i said is just 'imho' and 'afaik' because i do not have many expiences with C! [2002-01-14 08:55:06] [EMAIL PROTECTED] i did not test it, but 'looking at the source code' (TM) seems you need to use open_basedir to limit opendir() directory range. [2002-01-14 08:25:55] [EMAIL PROTECTED] On the same system (=same configuration) chdir() IS limited by safe_mode, opendir() are readdir() are NOT. This is either a bug, or if it isn't, I'll make it a feature request. Either way, it should be fixed, I think. Kind Regards, Daniel Lorch [2002-01-13 15:31:47] [EMAIL PROTECTED] Sorry for the bogus. Would you care to elaborate? I seem to be misunderstanding something. I just don't understand why - with the same configuration - chdir() cares about the UID, and opendir/readdir don't. chdir raises a SAFE MODE Restriction in effect whereas readdir() and opendir() let me browse through all directories where I have apache allowed to. Thanks for your help. Kind Regards, Daniel Lorch [2002-01-13 14:50:47] [EMAIL PROTECTED] Like I mentioned on the mailing list, opendir() is the function that would be relevant here. It is analogous to saying that mysql_query() should block you from accessing data in a database as opposed to this access restriction being placed on the mysql_connect() call. If the perms on the dir are such that opendir() can read the directory under safe-mode, then readdir() is going to give you a list of the files in that dir. Whether you can actually open and read those individual files themselves is of course another issue and any such access would be subject to a safe-mode check. But an individual readdir() call does not have any safe-mode implications. 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/15018 -- Edit this bug report at http://bugs.php.net/?id=15018edit=1
#20449 [Opn]: sessions randomly fail
ID: 20449 Updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] Status: Open Bug Type: Session related Operating System: redhat 7.3 PHP Version: 4.4.0-dev New Comment: Hmm.. I'm going to see if I can't reproduce this bug in some form, starting from the serialize() function... it's possible that serialize() isn't doing things correctly. Is this just a array problem? Or has someone also found this error in objects that don't use arrays? I'm going to write up some test scripts and see if I can break serialize()... I'll post my results here. Previous Comments: [2002-12-02 07:17:26] [EMAIL PROTECTED] [General Message - Not Bug Specific] In the past 12 months, I've raised a number of bugs relating to session problems that could not be reproduced consistently with the standard reply of 'its been fixed in CVS/Try CVS version'. I've tried the new CVS version and problems still continue (but still erratically). Over time, I've noticed a lot of developers problems (bugs) seem to be related to the global $_SESSION variable and I personally feel that the most stable session module is still in PHP version 4.0.6 before introduction in the 4.1 series. I'm not a hardened programmer, so this is a call to the current and previous developers/maintainers to consider a complete design and code walkthrough of the 'session related' code. Personally, I feel sessions is one of the key feature areas of PHP and something that needs to be highlighted to both Zend and the community to be made 'rock-solid'. Thanks Nick [2002-11-25 18:22:39] [EMAIL PROTECTED] After a good weekend we are having an incredible Monday. My code in place now uses serialize/unserialize. I also convert my arrays to strings with implode/explode before the serialization/unserialization process. I don't see any missing information anymore in my session table. I really think the session serialize code is at fault for this bug. Specifically I think it simply doesn't handle arrays. (perhaps objects but my object simply had the array in it. Removing the array from the object and not using objects did not work) This is an extremely serious bug that was costing us on average of about 30-50 orders a day. I am honestly not exaggerating on this figure. I tried the CVS version as late as 11-15-2002 and it still had the bug in it. Before that I was using the latest 4.2.3 version. I'd like a little feedback from the developers to at least say they are looking into it. I will try to assist in any way I can. However, as I have said before, it was very random and I myself never saw my session disappear. Also important to note is that I do not rely on Session Cookies so it is not related to cookies. Also, I tried doing the reset(arrayvar) after each session restoration as suggested on one of the session man pages. That too did not work. I hesitate to say but I really think it would be important to make note to people that the session code is not reliable. Perhaps in the man pages. I won't go to such length though as to warn them myself though I feel some duty to do so. Perhaps the bug only comes into play on high traffic servers. Either which way, not relying on the internal session code has made a huge difference. That in itself should prove something. [2002-11-25 11:46:34] [EMAIL PROTECTED] This seems to be exactly the same problem we are having with one particular visitor to one of my websites. He always has this problem, every time he logs in his session expires. I have gone through his client PC configuration very carefully, and cannot find anything unusual. What's more odd is that he used to be able to use my site without problems. Would this problem manifest itself at random, or would it affect specific PCs? I had assumed the problem was at his end until I read this message thread, and it looked strangely familiar. Jolyon [2002-11-22 16:20:08] [EMAIL PROTECTED] Just thought I'd add that we are having what - seems to be - the same problem. We are running on Solaris 8 and our sessions are being held in a tmpfs mount that's balanced across 4 sun 220's. PHP Version 4.2.2 and Apache 1.3.26 compiled staticly. We've been moving the session store method around thinking I/O was the issue but it hasn't helped. We've done NFS mounted share, local-only share on 1 220 (limiting the load-balancing for one site to only that box) and now tmpfs. Our sessions are rather large (at least for me) normally around 11,316 bytes with objects and arrays w/ members that are serialized objects. It's probably important to note that we are avoiding automatic
#20800 [Opn-Ver]: ob_and_clean crash
ID: 20800 Updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] -Status: Open +Status: Verified Bug Type: Output Control Operating System: Redhat 7.0 PHP Version: 4.3.0RC2 New Comment: I just assumed you meant segfaults by the word crash :-) Okay, Verified in HEAD, both with apache and with apache2. Previous Comments: [2002-12-04 05:01:10] [EMAIL PROTECTED] The server doesn't create any core dump, it simply exit, as in bug #20802, there is no segmentation fault. [2002-12-04 00:34:12] [EMAIL PROTECTED] Thank you for this bug report. To properly diagnose the problem, we need a backtrace to see what is happening behind the scenes. To find out how to generate a backtrace, please read http://bugs.php.net/bugs-generating-backtrace.php Once you have generated a backtrace, please submit it to this bug report and change the status back to Open. Thank you for helping us make PHP better. [2002-12-03 15:54:33] [EMAIL PROTECTED] If I try to run this script I receive a blank page (no output): ? ob_end_clean(); echo a; ? If I try to run from the command line it works. Server configuration: Linux Redhat 7.0 Apache 1.3.22 PHP 4.3.0RC2 Zend Optimizer 2.0.3 Mysql 4.0.5 ini: output_buffering On output_handler ob_gzhandler Configure: './configure' '--enable-track-vars' '--prefix=/usr' '--exec-prefix=/usr' '--libexecdir=/usr/lib/apache' '--bindir=/usr/bin' '--sbindir=/usr/sbin' '--datadir=/home/httpd' '--sysconfdir=/etc/httpd/conf' '--localstatedir=/var' '--libdir=/usr/lib/apache' '--includedir=/usr/include/apache' '--mandir=/usr/man' '--with-mysql=/usr' '--enable-memory-limit' '--with-config-file-path=/usr/local/Zend/etc' '--with-apxs' '--with-zlib' -- Edit this bug report at http://bugs.php.net/?id=20800edit=1
#20813 [Opn]: opendir() returns errno22 with UNC path
ID: 20813
User updated by: [EMAIL PROTECTED]
Reported By: [EMAIL PROTECTED]
Status: Open
Bug Type: Directory function related
Operating System: NT4SP6 IIS
PHP Version: 4.2.3
New Comment:
Just installed fresh 4.2.3 ISAPI on Win2000 and still produces same
error. Does this have something to do with the target UNC?
Previous Comments:
[2002-12-04 10:44:27] [EMAIL PROTECTED]
Bug #9354 also produces same result
Bug #6445 is the same problem
Bug #12699 is the same problem
Bug #12524 is the same problem
Is this only NT4???
[2002-12-04 10:34:08] [EMAIL PROTECTED]
if ($handle = opendir(//server/share)) {
while ($file = readdir($handle)) {
echo $filebr;
}
closedir($handle);
}
produces:
Warning: OpenDir: Invalid argument (errno 22)
I have tried setting the UNC share permissions to both Everyone - Read
and Everyone - Full Control and it does not matter.
--
Edit this bug report at http://bugs.php.net/?id=20813edit=1
#20816 [NEW]: imagecopyresampled turn white into yellow
From: [EMAIL PROTECTED] Operating system: WinXP PHP version: 4CVS-2002-12-04 (dev) PHP Bug Type: GD related Bug description: imagecopyresampled turn white into yellow The function imagecopyresampled() takes a white area (255,255,255) and turns it yellow (255,255,2). This does not happen with imagecopyresize(). I think the problem is in the GD library, because the problem disappears when I use the php_gd2.dll from PHP4.2.3 instead of the one that came bundled with 4.4.0-dev. What phpinfo() says: 4.4.0-dev (both broken and working cases) GD 2.0 (bundled) BROKEN case GD 2.0 or higher WORKING case -- Edit bug report at http://bugs.php.net/?id=20816edit=1 -- Try a CVS snapshot: http://bugs.php.net/fix.php?id=20816r=trysnapshot Fixed in CVS: http://bugs.php.net/fix.php?id=20816r=fixedcvs Fixed in release: http://bugs.php.net/fix.php?id=20816r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=20816r=needtrace Try newer version: http://bugs.php.net/fix.php?id=20816r=oldversion Not developer issue:http://bugs.php.net/fix.php?id=20816r=support Expected behavior: http://bugs.php.net/fix.php?id=20816r=notwrong Not enough info:http://bugs.php.net/fix.php?id=20816r=notenoughinfo Submitted twice:http://bugs.php.net/fix.php?id=20816r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=20816r=globals PHP 3 support discontinued: http://bugs.php.net/fix.php?id=20816r=php3 Daylight Savings: http://bugs.php.net/fix.php?id=20816r=dst IIS Stability: http://bugs.php.net/fix.php?id=20816r=isapi
#20273 [Com]: Undefined symbol: core_globals
ID: 20273 Comment by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] Status: Bogus Bug Type: Apache related Operating System: Linux PHP Version: 4.2.3 New Comment: latest snapshot worked for me as well. Can someone please comment on why? Previous Comments: [2002-11-07 20:22:38] [EMAIL PROTECTED] Trying the latest snapshot worked! Thank you! [2002-11-07 17:26:35] [EMAIL PROTECTED] This is not any bug in PHP. Try searching the bug database with the 'Undefined symbol: core_globals' string and you'll find couple of reasons for this to happen. (and solutions how to get it work) [2002-11-06 08:19:44] [EMAIL PROTECTED] Please try using this CVS snapshot: http://snaps.php.net/php4-latest.tar.gz For Windows: http://snaps.php.net/win32/php4-win32-latest.zip [2002-11-05 22:16:10] [EMAIL PROTECTED] Sorry, that's --with-mysql not --with-sql [2002-11-05 22:14:17] [EMAIL PROTECTED] After compiling PHP 4.2.3 as a DSO, I've received the following message on running httpd version 1.3.26 (binary supplied with Slackware 8.1): Cannot load /usr/libexec/libphp4.so into server: /usr/libexec/libphp4.so: undefined symbol: core_globals Here are the following options I used in the PHP4 build: --with-sql --with-apxs --enable-mbstring --enable-mbstr-enc-trans --enable-mbregex I've looked all over the Web for a solution to this. Looking at various mailing lists, it seems that several people have encountered the same problem, but I have not yet seen a solution presented in response. If there's a solution to this, could you please email it to me? -- Edit this bug report at http://bugs.php.net/?id=20273edit=1
#10969 [Com]: apache don't start, cannot load php4apache.dll
ID: 10969 Comment by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] Status: Bogus Bug Type: Apache related Operating System: Win 98 PHP Version: 4.0.5 New Comment: Hi I have this problem too with apache 1.3.27, php 4.2.3 (win98) apache works alone but not apache+php missing dll to make php4apache.dll working it says and so php4apache.dll don't get loaded. when trying to open php.exe I had the following message: missing odbc32.dll I only have odbcjt32.dll on my computer, I'll to look for odbc32.dll, not found yet on internet. Previous Comments: [2001-05-23 16:29:25] [EMAIL PROTECTED] I found what the error was: Apache could not find odbc32.dll. After I installed this library the server started normally. [2001-05-21 09:36:13] [EMAIL PROTECTED] I don't see any sintax error there. Please send detailed info. I think scripting engine classifies this as a sintax error but indeed there are another kind of a problem. By the way, the full message I see in my console window is: Syntax error on line 979 of k:/apache/apache/conf/httpd.conf: Cannot load k:/apache/apache/modules/mod_php4/sapi/php4apache.dll into server: (1157) Cannot load dinamic library: The last sentence was written in russian, in accordance with OS-specific regional settings and then translated by me in English. That's why I omitted this message in the first edition of this bug report. [2001-05-19 10:50:01] [EMAIL PROTECTED] Bogus [2001-05-19 10:44:27] [EMAIL PROTECTED] This is not a bug in PHP. You have made a mistake in your httpd.conf on line 979. fix this syntax error and try again. [2001-05-19 10:14:54] [EMAIL PROTECTED] When I try to start apache, it says: Syntax error on line 979 of k:/apache/apache/conf/httpd.conf: Cannot load k:/apache/apache/modules/mod_php4/sapi/php4apache.dll into server: ( 1157) Added lines in apache.conf are: ---CUT HERE # for the apache module LoadModule php4_module modules/mod_php4/sapi/php4apache.dll AddType application/x-httpd-php .php4 #for the cgi binary (you can use that one compiled with force cgi redirect too) ScriptAlias /php4/ k:/apache/apache/modules/mod_php4/ Action application/x-httpd-php4 /php4/php.exe AddType application/x-httpd-php4 .php ---CUT HERE -- Edit this bug report at http://bugs.php.net/?id=10969edit=1
#20449 [Com]: sessions randomly fail
ID: 20449 Comment by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] Status: Open Bug Type: Session related Operating System: redhat 7.3 PHP Version: 4.4.0-dev New Comment: Our objects are fairly complex. Objects w/ local (as much as they can be) objects and plenty of our friend - the assoc. array. I was unable to reproduce this issue on my own (maybe you will have better luck) even though on a normal day I can watch syslog chime out unserialize errors. I'd be more then happy to send a session, class definitions, etc. if needed. Shoot me an e-mail if you need anything. Previous Comments: [2002-12-04 12:26:50] [EMAIL PROTECTED] Hmm.. I'm going to see if I can't reproduce this bug in some form, starting from the serialize() function... it's possible that serialize() isn't doing things correctly. Is this just a array problem? Or has someone also found this error in objects that don't use arrays? I'm going to write up some test scripts and see if I can break serialize()... I'll post my results here. [2002-12-02 07:17:26] [EMAIL PROTECTED] [General Message - Not Bug Specific] In the past 12 months, I've raised a number of bugs relating to session problems that could not be reproduced consistently with the standard reply of 'its been fixed in CVS/Try CVS version'. I've tried the new CVS version and problems still continue (but still erratically). Over time, I've noticed a lot of developers problems (bugs) seem to be related to the global $_SESSION variable and I personally feel that the most stable session module is still in PHP version 4.0.6 before introduction in the 4.1 series. I'm not a hardened programmer, so this is a call to the current and previous developers/maintainers to consider a complete design and code walkthrough of the 'session related' code. Personally, I feel sessions is one of the key feature areas of PHP and something that needs to be highlighted to both Zend and the community to be made 'rock-solid'. Thanks Nick [2002-11-25 18:22:39] [EMAIL PROTECTED] After a good weekend we are having an incredible Monday. My code in place now uses serialize/unserialize. I also convert my arrays to strings with implode/explode before the serialization/unserialization process. I don't see any missing information anymore in my session table. I really think the session serialize code is at fault for this bug. Specifically I think it simply doesn't handle arrays. (perhaps objects but my object simply had the array in it. Removing the array from the object and not using objects did not work) This is an extremely serious bug that was costing us on average of about 30-50 orders a day. I am honestly not exaggerating on this figure. I tried the CVS version as late as 11-15-2002 and it still had the bug in it. Before that I was using the latest 4.2.3 version. I'd like a little feedback from the developers to at least say they are looking into it. I will try to assist in any way I can. However, as I have said before, it was very random and I myself never saw my session disappear. Also important to note is that I do not rely on Session Cookies so it is not related to cookies. Also, I tried doing the reset(arrayvar) after each session restoration as suggested on one of the session man pages. That too did not work. I hesitate to say but I really think it would be important to make note to people that the session code is not reliable. Perhaps in the man pages. I won't go to such length though as to warn them myself though I feel some duty to do so. Perhaps the bug only comes into play on high traffic servers. Either which way, not relying on the internal session code has made a huge difference. That in itself should prove something. [2002-11-25 11:46:34] [EMAIL PROTECTED] This seems to be exactly the same problem we are having with one particular visitor to one of my websites. He always has this problem, every time he logs in his session expires. I have gone through his client PC configuration very carefully, and cannot find anything unusual. What's more odd is that he used to be able to use my site without problems. Would this problem manifest itself at random, or would it affect specific PCs? I had assumed the problem was at his end until I read this message thread, and it looked strangely familiar. Jolyon [2002-11-22 16:20:08] [EMAIL PROTECTED] Just thought I'd add that we are having what - seems to be - the same problem. We are running on Solaris 8 and our sessions are being held in a tmpfs mount that's balanced
#20800 [Ver-]: ob_and_clean crash
ID: 20800 Updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] -Status: Verified +Status: Won\'t fix Bug Type: Output Control Operating System: Redhat 7.0 PHP Version: 4.3.0RC2 New Comment: As discussed in the past, this behaviour is supposed to be expected. Do not use ob_end_flush() without preceding ob_start() when gzip output handler is enabled. Previous Comments: [2002-12-04 12:53:49] [EMAIL PROTECTED] I just assumed you meant segfaults by the word crash :-) Okay, Verified in HEAD, both with apache and with apache2. [2002-12-04 05:01:10] [EMAIL PROTECTED] The server doesn't create any core dump, it simply exit, as in bug #20802, there is no segmentation fault. [2002-12-04 00:34:12] [EMAIL PROTECTED] Thank you for this bug report. To properly diagnose the problem, we need a backtrace to see what is happening behind the scenes. To find out how to generate a backtrace, please read http://bugs.php.net/bugs-generating-backtrace.php Once you have generated a backtrace, please submit it to this bug report and change the status back to Open. Thank you for helping us make PHP better. [2002-12-03 15:54:33] [EMAIL PROTECTED] If I try to run this script I receive a blank page (no output): ? ob_end_clean(); echo a; ? If I try to run from the command line it works. Server configuration: Linux Redhat 7.0 Apache 1.3.22 PHP 4.3.0RC2 Zend Optimizer 2.0.3 Mysql 4.0.5 ini: output_buffering On output_handler ob_gzhandler Configure: './configure' '--enable-track-vars' '--prefix=/usr' '--exec-prefix=/usr' '--libexecdir=/usr/lib/apache' '--bindir=/usr/bin' '--sbindir=/usr/sbin' '--datadir=/home/httpd' '--sysconfdir=/etc/httpd/conf' '--localstatedir=/var' '--libdir=/usr/lib/apache' '--includedir=/usr/include/apache' '--mandir=/usr/man' '--with-mysql=/usr' '--enable-memory-limit' '--with-config-file-path=/usr/local/Zend/etc' '--with-apxs' '--with-zlib' -- Edit this bug report at http://bugs.php.net/?id=20800edit=1
#20814 [Opn]: reproducable, freaky parse error in 'here document' structure
ID: 20814 Updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] Status: Open Bug Type: Scripting Engine problem Operating System: all PHP Version: 4.4.0-dev New Comment: To clarify the line mismatch: AFAIK it's the same as a missing '}' in if/else. It will report on the __last__ expected '}', while the error will intuitively start on the __first__ unclosed '}'. The '$' is 'end' as in regexps. Previous Comments: [2002-12-04 11:24:55] [EMAIL PROTECTED] To clarify a few points: a) This is known and is both documented and is a current feature request: http://bugs.php.net/bug.php?id=8685 http://www.php.net/language.types.string#language.types.string.syntax.heredoc b) The error that's reported is odd, and looks something like this: Parse error: parse error, unexpected $ in test.php on line 42 Where 42 is, for example, on the last line of test.php even when the error is elsewhere. This error sorta makes sense in most cases (like a missing quote or closing brace) but IMHO not here. Maybe someone can briefly explain what PHP is thinking. c) Many have attempted to fix this and many more have reported it (a) but it appears to be almost impossible to fix and remains a feature request. Again, it is documented with a big fat warning. Am leaving as open as this mentions the strange error too (b), not just the known feature request. [2002-12-04 11:23:05] [EMAIL PROTECTED] [quick on the trigger]... scratch that last sentence ... I was going to point out that the closing tag has to be flush left but I think that is not a bug. [2002-12-04 11:04:39] [EMAIL PROTECTED] I've tested this on PHP 4.2.3 for OSX, Open BSD, Linux... If you leave any whitespace after the closing tag of a here document structure (not sure if that's what it is called, like in Perl) a parse error will occur but never for the correct line. This seems like a bug to me because a semi- colon should terminate the code allowing the programmer to put comments or whatever after the semi-colon. Here is an example: $variable = variable; $someVariable = hereDocument html body btext text $variable testing here document/b /body /html hereDocument; // closing comment or just whitespace echo $someVariable; After the closing hereDocument; if you leave any whitespace (other than a carriage return) or text, a parse error is generated but the line number never leads you to the right place. This can be very confusing if you are working on a large class (like I was) and you left a tab or space after a closing tag. I'm not sure how consciously supported the here document structure is but this is worth addressing since here documents can be very useful for storing large variables containing HTML code with double and single quotes, for example. While I'm submitting this bug, I might as well point -- Edit this bug report at http://bugs.php.net/?id=20814edit=1
#20816 [Opn-Fbk]: register_global and scoping vars
ID: 20816 Updated by: [EMAIL PROTECTED] -Summary: imagecopyresampled turn white into yellow -Reported By: [EMAIL PROTECTED] +Reported By: [EMAIL PROTECTED] -Status: Open +Status: Feedback Bug Type: GD related -Operating System: WinXP +Operating System: Slackware Linux -PHP Version: 4CVS-2002-12-04 (dev) +PHP Version: 4.2.2 New Comment: Could you please show the complete script and if possible the source image you are using. So far, I was able to replicate the problem if I created the destination image using imagecreatetruecolor(). However, if I use imagecreate() it works correctly. Previous Comments: [2002-12-04 13:24:58] [EMAIL PROTECTED] The function imagecopyresampled() takes a white area (255,255,255) and turns it yellow (255,255,2). This does not happen with imagecopyresize(). I think the problem is in the GD library, because the problem disappears when I use the php_gd2.dll from PHP4.2.3 instead of the one that came bundled with 4.4.0-dev. What phpinfo() says: 4.4.0-dev (both broken and working cases) GD 2.0 (bundled) BROKEN case GD 2.0 or higher WORKING case -- Edit this bug report at http://bugs.php.net/?id=20816edit=1
#20771 [Opn-Csd]: imagettftext() fails without errors
ID: 20771 Updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] -Status: Open +Status: Closed Bug Type: GD related Operating System: RH 8.0 PHP Version: 4.2.2 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. This bug was fixed in latest CVS as was indicated by Derick, please do not re-open it unless it does not work in latest CVS. Previous Comments: [2002-12-03 15:50:16] [EMAIL PROTECTED] I was afraid you'd say that. I'll have to try that on a dev box... I'm trying to stick with Redhat up2date on my live servers. Do you think it's a problem with 4.2.2 ? [2002-12-02 14:49:23] [EMAIL PROTECTED] Please try using this CVS snapshot: http://snaps.php.net/php4-latest.tar.gz For Windows: http://snaps.php.net/win32/php4-win32-latest.zip [2002-12-02 14:48:45] [EMAIL PROTECTED] This works on 4.0.4pl1 and 4.0.5 but not on my new RH 8.0 build with 4.4.2: phpinfo() is at http://www.resiteit.com/phpinfo.php $im = imagecreate (400, 30); $black = imagecolorallocate ($im, 0, 0, 0); $white = imagecolorallocate ($im, 255, 255, 255); imagettftext ($im, 20, 0, 10, 20, $white, ../fonts/arialbd.ttf, Testing...Omega: #937;); imagepng ($im); imagedestroy ($im); On the new build, I just get the black bar. Unfortunately no errors. Interesting to note that the function doesn't return the bounding box array either. Any ideas? -- Thanks! -- Edit this bug report at http://bugs.php.net/?id=20771edit=1
#20817 [NEW]: configure hands checking flex version
From: [EMAIL PROTECTED] Operating system: Solaris 2.8 ( sparc ) PHP version: 4.3.0RC2 PHP Bug Type: *Compile Issues Bug description: configure hands checking flex version running configure as follows hangs checking flex version. Note, flex is not installed on this system: ./configure --prefix=/usr/local/php-3.0RC2 --with-apxs=/usr/local/apache_internal/bin/apxs --with-oci8=/opt/app/oracle/product/8.1.7 --with-zlib checking for working sed... sed checking build system type... sparc-sun-solaris2.8 checking host system type... sparc-sun-solaris2.8 checking for gcc... gcc checking for C compiler default output... a.out checking whether the C compiler works... yes checking whether we are cross compiling... no checking for suffix of executables... checking for suffix of object files... o checking whether we are using the GNU C compiler... yes checking whether gcc accepts -g... yes checking whether gcc and cc understand -c and -o together... yes checking how to run the C preprocessor... gcc -E checking for AIX... no checking if compiler supports -R... yes checking for ranlib... ranlib checking whether ln -s works... yes checking for gawk... no checking for mawk... no checking for nawk... nawk checking for bison... no checking for byacc... no configure: WARNING: You will need bison if you want to regenerate the PHP parsers. checking for flex... no checking for lex... lex checking for yywrap in -lfl... no checking for yywrap in -ll... yes checking lex output file root... lex.yy checking whether yytext is a pointer... no checking for gcc option to accept ANSI C... none needed checking for an ANSI C-conforming const... yes checking flex version... lex: Software Generation Utilities (SGU) Solaris-ELF (4.0) Exiting ( Control-C ) continues with the following output: ^CAWK=nawk BASH=/bin/bash BASH_VERSINFO=([0]=2 [1]=03 [2]=0 [3]=1 [4]=release [5]=sparc-sun-solaris) BASH_VERSION='2.03.0(1)-release' CC=gcc CFLAGS='-g -O2' CONFIGURE_COMMAND=' '\''./configure'\'' '\''--prefix=/usr/local/php-3.0RC2'\'' '\''--with-apxs=/usr/local/apache_internal/bin/apxs'\'' '\''--with-oci8=/opt/app/oracle/product/8.1.7'\'' '\''--with-zlib'\''' CONFIG_SHELL=/bin/bash CONFIG_SITE='/usr/local/php-3.0RC2/share/config.site /usr/local/php-3.0RC2/etc/config.site' CPP='gcc -E' DIRSTACK=() ECHO=echo ECHO_C= ECHO_N=-n ECHO_T= EUID=1800 EXEEXT= EXTRA_VERSION=RC2 GCC=yes GROUPS=() HOME=/home/asautins HOSTNAME=dev450.veripost.net HOSTTYPE=sparc IFS=' ' LANG=C LANGUAGE=C LC_ALL=C LC_COLLATE=C LC_CTYPE=C LC_MESSAGES=C LC_NUMERIC=C LC_TIME=C LD_LIBRARY_PATH=/usr/lib:/usr/local/lib LEX=lex LEXLIB=-ll LEX_CFLAGS=-DYY_USE_CONST LEX_OUTPUT_ROOT=lex.yy LIBS= LINENO=3791 LN_S='ln -s' LOGNAME=asautins MACHTYPE=sparc-sun-solaris MAIL=/var/mail//asautins MAJOR_VERSION=4 MAKEFLAGS= MANPATH=/usr/share/man:/usr/local/man MFLAGS= MINOR_VERSION=3 OBJEXT=o OPTERR=1 OPTIND=1 OSTYPE=solaris PACKAGE_BUGREPORT= PACKAGE_NAME= PACKAGE_STRING= PACKAGE_TARNAME= PACKAGE_VERSION= PATH=/usr/bin:/usr/sbin:/usr/ucb:/usr/dt/bin:/usr/openwin/bin:/usr/local/bin:/usr/ccs/bin:/sbin:/local/ActiveTcl/bin PATH_SEPARATOR=: PHP_VAR_SUBST=' SED' PHP_VERSION=4.3.0RC2 PIPESTATUS=([0]=0) POSIXLY_CORRECT=y PPID=7071 PS4='+ ' PWD=/home/asautins/webbuild/php-4.3.0RC2 RANDOM=26830 RANLIB=ranlib RELEASE_VERSION=0 SAVE_LIBS= SED=sed SHELL=/bin/bash SHELLOPTS=braceexpand:hashall:interactive-comments:posix SHLVL=2 SSH_CLIENT='10.0.2.64 4558 22' SSH_TTY=/dev/pts/2 SSL_BASE=/usr/local/openssl TERM=vt100 TMPDIR=/tmp TZ=US/Mountain T_MD='' T_ME='' UID=1800 UNAME=SunOS USER=asautins VERSION=4.3.0RC2 YACC=yacc _='checking flex version... ' _count=8 _max=8 _sed=sed abs_builddir=/home/asautins/webbuild/php-4.3.0RC2 abs_srcdir=/home/asautins/webbuild/php-4.3.0RC2 ac_arg= ac_aux_dir=. ac_c_preproc_warn_flag= ac_cache_corrupted=false ac_cc=gcc ac_check_lib_save_LIBS= ac_clean_files= ac_clean_files_save= ac_compile='$CC -c $CFLAGS $CPPFLAGS conftest.$ac_ext 5' ac_compiler='$CC' ac_compiler_gnu=yes ac_confdir=. ac_config_guess='/bin/bash ./config.guess' ac_config_headers=' main/php_config.h' ac_config_sub='/bin/bash ./config.sub' ac_configure='/bin/bash ./configure' ac_configure_args=''\''--prefix=/usr/local/php-3.0RC2'\'' '\''--with-apxs=/usr/local/apache_internal/bin/apxs'\'' '\''--with-oci8=/opt/app/oracle/product/8.1.7'\'' '\''--with-zlib'\''' ac_cpp='$CPP $CPPFLAGS' ac_cpp_err=yes ac_ct_CC=gcc ac_ct_RANLIB=ranlib ac_cv_build=sparc-sun-solaris2.8 ac_cv_build_alias=sparc-sun-solaris2.8 ac_cv_c_compiler_gnu=yes ac_cv_c_const=yes ac_cv_env_CC_set= ac_cv_env_CC_value= ac_cv_env_CFLAGS_set= ac_cv_env_CFLAGS_value= ac_cv_env_CPPFLAGS_set= ac_cv_env_CPPFLAGS_value= ac_cv_env_CPP_set= ac_cv_env_CPP_value= ac_cv_env_CXXCPP_set= ac_cv_env_CXXCPP_value= ac_cv_env_CXXFLAGS_set= ac_cv_env_CXXFLAGS_value= ac_cv_env_CXX_set=
#20817 [Opn-Csd]: configure hands checking flex version
ID: 20817 Updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] -Status: Open +Status: Closed Bug Type: *Compile Issues Operating System: Solaris 2.8 ( sparc ) PHP Version: 4.3.0RC2 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: [2002-12-04 16:15:34] [EMAIL PROTECTED] running configure as follows hangs checking flex version. Note, flex is not installed on this system: ./configure --prefix=/usr/local/php-3.0RC2 --with-apxs=/usr/local/apache_internal/bin/apxs --with-oci8=/opt/app/oracle/product/8.1.7 --with-zlib checking for working sed... sed checking build system type... sparc-sun-solaris2.8 checking host system type... sparc-sun-solaris2.8 checking for gcc... gcc checking for C compiler default output... a.out checking whether the C compiler works... yes checking whether we are cross compiling... no checking for suffix of executables... checking for suffix of object files... o checking whether we are using the GNU C compiler... yes checking whether gcc accepts -g... yes checking whether gcc and cc understand -c and -o together... yes checking how to run the C preprocessor... gcc -E checking for AIX... no checking if compiler supports -R... yes checking for ranlib... ranlib checking whether ln -s works... yes checking for gawk... no checking for mawk... no checking for nawk... nawk checking for bison... no checking for byacc... no configure: WARNING: You will need bison if you want to regenerate the PHP parsers. checking for flex... no checking for lex... lex checking for yywrap in -lfl... no checking for yywrap in -ll... yes checking lex output file root... lex.yy checking whether yytext is a pointer... no checking for gcc option to accept ANSI C... none needed checking for an ANSI C-conforming const... yes checking flex version... lex: Software Generation Utilities (SGU) Solaris-ELF (4.0) Exiting ( Control-C ) continues with the following output: ^CAWK=nawk BASH=/bin/bash BASH_VERSINFO=([0]=2 [1]=03 [2]=0 [3]=1 [4]=release [5]=sparc-sun-solaris) BASH_VERSION='2.03.0(1)-release' CC=gcc CFLAGS='-g -O2' CONFIGURE_COMMAND=' '\''./configure'\'' '\''--prefix=/usr/local/php-3.0RC2'\'' '\''--with-apxs=/usr/local/apache_internal/bin/apxs'\'' '\''--with-oci8=/opt/app/oracle/product/8.1.7'\'' '\''--with-zlib'\''' CONFIG_SHELL=/bin/bash CONFIG_SITE='/usr/local/php-3.0RC2/share/config.site /usr/local/php-3.0RC2/etc/config.site' CPP='gcc -E' DIRSTACK=() ECHO=echo ECHO_C= ECHO_N=-n ECHO_T= EUID=1800 EXEEXT= EXTRA_VERSION=RC2 GCC=yes GROUPS=() HOME=/home/asautins HOSTNAME=dev450.veripost.net HOSTTYPE=sparc IFS=' ' LANG=C LANGUAGE=C LC_ALL=C LC_COLLATE=C LC_CTYPE=C LC_MESSAGES=C LC_NUMERIC=C LC_TIME=C LD_LIBRARY_PATH=/usr/lib:/usr/local/lib LEX=lex LEXLIB=-ll LEX_CFLAGS=-DYY_USE_CONST LEX_OUTPUT_ROOT=lex.yy LIBS= LINENO=3791 LN_S='ln -s' LOGNAME=asautins MACHTYPE=sparc-sun-solaris MAIL=/var/mail//asautins MAJOR_VERSION=4 MAKEFLAGS= MANPATH=/usr/share/man:/usr/local/man MFLAGS= MINOR_VERSION=3 OBJEXT=o OPTERR=1 OPTIND=1 OSTYPE=solaris PACKAGE_BUGREPORT= PACKAGE_NAME= PACKAGE_STRING= PACKAGE_TARNAME= PACKAGE_VERSION= PATH=/usr/bin:/usr/sbin:/usr/ucb:/usr/dt/bin:/usr/openwin/bin:/usr/local/bin:/usr/ccs/bin:/sbin:/local/ActiveTcl/bin PATH_SEPARATOR=: PHP_VAR_SUBST=' SED' PHP_VERSION=4.3.0RC2 PIPESTATUS=([0]=0) POSIXLY_CORRECT=y PPID=7071 PS4='+ ' PWD=/home/asautins/webbuild/php-4.3.0RC2 RANDOM=26830 RANLIB=ranlib RELEASE_VERSION=0 SAVE_LIBS= SED=sed SHELL=/bin/bash SHELLOPTS=braceexpand:hashall:interactive-comments:posix SHLVL=2 SSH_CLIENT='10.0.2.64 4558 22' SSH_TTY=/dev/pts/2 SSL_BASE=/usr/local/openssl TERM=vt100 TMPDIR=/tmp TZ=US/Mountain T_MD='' T_ME='' UID=1800 UNAME=SunOS USER=asautins VERSION=4.3.0RC2 YACC=yacc _='checking flex version... ' _count=8 _max=8 _sed=sed abs_builddir=/home/asautins/webbuild/php-4.3.0RC2 abs_srcdir=/home/asautins/webbuild/php-4.3.0RC2 ac_arg= ac_aux_dir=. ac_c_preproc_warn_flag= ac_cache_corrupted=false ac_cc=gcc ac_check_lib_save_LIBS= ac_clean_files= ac_clean_files_save= ac_compile='$CC -c $CFLAGS $CPPFLAGS conftest.$ac_ext 5' ac_compiler='$CC' ac_compiler_gnu=yes ac_confdir=. ac_config_guess='/bin/bash ./config.guess' ac_config_headers=' main/php_config.h' ac_config_sub='/bin/bash ./config.sub'
#20818 [NEW]: weird page outputs (scrambled parts of html on pages)
From: [EMAIL PROTECTED] Operating system: WinXP Pro (IIS5.1) PHP version: 4.2.3 PHP Bug Type: Unknown/Other Function Bug description: weird page outputs (scrambled parts of html on pages) I have been using apache with the php module for quite some time (which works excelent of coarse) on a win2k pro machine. this server is temporarily down untill after christmas when i plan to upgrade it I have recently set up IIS in winxp, because it was a quick thing to install, for some small tasks that are just easier for me with iis, like naitive frontpage and asp support, which my father wanted so he can work on a site and test it for a company we are starting... I still wanted to have php on this machine as well so i installed the cgi. the problem i am having is a strange one i have never seen before. I did a bug search here but could not find anything that seemed to be helpful, perhaps i am jsut wording my search wrong but anyways: every so often any php page seems to have some part of the code get scrambled up as if the html tags are not being closed almost (espetially in forums like phpbb2) its not a earth shattering error but its something that has been bothering me a bit and i can't seem to figure it out myself. is this a xp/iis bug? will installing the non-cgi version of php in iis fix it? any explanations would be greatly appreciated. -Andrew -- Edit bug report at http://bugs.php.net/?id=20818edit=1 -- Try a CVS snapshot: http://bugs.php.net/fix.php?id=20818r=trysnapshot Fixed in CVS: http://bugs.php.net/fix.php?id=20818r=fixedcvs Fixed in release: http://bugs.php.net/fix.php?id=20818r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=20818r=needtrace Try newer version: http://bugs.php.net/fix.php?id=20818r=oldversion Not developer issue:http://bugs.php.net/fix.php?id=20818r=support Expected behavior: http://bugs.php.net/fix.php?id=20818r=notwrong Not enough info:http://bugs.php.net/fix.php?id=20818r=notenoughinfo Submitted twice:http://bugs.php.net/fix.php?id=20818r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=20818r=globals PHP 3 support discontinued: http://bugs.php.net/fix.php?id=20818r=php3 Daylight Savings: http://bugs.php.net/fix.php?id=20818r=dst IIS Stability: http://bugs.php.net/fix.php?id=20818r=isapi
#20819 [NEW]: max_execution_time ignored when waiting for open socket read
From: [EMAIL PROTECTED] Operating system: Linux 2.2.20 (Debian) PHP version: 4.2.3 PHP Bug Type: PHP options/info functions Bug description: max_execution_time ignored when waiting for open socket read When PHP is waiting for a socket read the max_exection_time parameter is ignored. I was trying to use PHP scripts to monitor server response times but when there is a problem the script does not kill itself. It does not matter how I specify the max_execution_time. For instance like this: php4 -d max_execution_time 5 This behaviour was already in all previous versions I used. -- Edit bug report at http://bugs.php.net/?id=20819edit=1 -- Try a CVS snapshot: http://bugs.php.net/fix.php?id=20819r=trysnapshot Fixed in CVS: http://bugs.php.net/fix.php?id=20819r=fixedcvs Fixed in release: http://bugs.php.net/fix.php?id=20819r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=20819r=needtrace Try newer version: http://bugs.php.net/fix.php?id=20819r=oldversion Not developer issue:http://bugs.php.net/fix.php?id=20819r=support Expected behavior: http://bugs.php.net/fix.php?id=20819r=notwrong Not enough info:http://bugs.php.net/fix.php?id=20819r=notenoughinfo Submitted twice:http://bugs.php.net/fix.php?id=20819r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=20819r=globals PHP 3 support discontinued: http://bugs.php.net/fix.php?id=20819r=php3 Daylight Savings: http://bugs.php.net/fix.php?id=20819r=dst IIS Stability: http://bugs.php.net/fix.php?id=20819r=isapi
#20808 [Opn-Fbk]: configure script has a lines joined
ID: 20808 Updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] -Status: Open +Status: Feedback Bug Type: *Compile Issues Operating System: Solaris 2.6 sparc PHP Version: 4.3.0RC2 New Comment: Please try using this CVS snapshot: http://snaps.php.net/php4-latest.tar.gz For Windows: http://snaps.php.net/win32/php4-win32-latest.zip Previous Comments: [2002-12-04 07:53:01] [EMAIL PROTECTED] The area round line 53644 in configure looks like: #include stdlib.h #ifdef __cplusplus extern C #endif Unfortunately the #ifdef line is joined with the extern line with 70 spaces or so, so that it wraps nicely and hides this. This was already there in 4.2.3 (as I discovered today). Paul Slootman -- Edit this bug report at http://bugs.php.net/?id=20808edit=1
#20810 [Opn-Fbk]: truncated field name
ID: 20810 Updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] -Status: Open +Status: Feedback Bug Type: MSSQL related Operating System: SUSE PHP Version: 4.2.3 New Comment: Please try using this CVS snapshot: http://snaps.php.net/php4-latest.tar.gz For Windows: http://snaps.php.net/win32/php4-win32-latest.zip Previous Comments: [2002-12-04 09:06:07] [EMAIL PROTECTED] I have column username_calling_centr_operators I make request select username_calling_centr_operators from tablename; In SQLConsole all is ok. In php name of column truncated, and I get Array ( [username_calling_centr_operato] = ps ) -- Edit this bug report at http://bugs.php.net/?id=20810edit=1
#20813 [Opn-Fbk]: opendir() returns errno22 with UNC path
ID: 20813
Updated by: [EMAIL PROTECTED]
Reported By: [EMAIL PROTECTED]
-Status: Open
+Status: Feedback
Bug Type: Directory function related
Operating System: NT4SP6 IIS
PHP Version: 4.2.3
New Comment:
Please try using this CVS snapshot:
http://snaps.php.net/php4-latest.tar.gz
For Windows:
http://snaps.php.net/win32/php4-win32-latest.zip
Previous Comments:
[2002-12-04 13:12:41] [EMAIL PROTECTED]
Just installed fresh 4.2.3 ISAPI on Win2000 and still produces same
error. Does this have something to do with the target UNC?
[2002-12-04 10:44:27] [EMAIL PROTECTED]
Bug #9354 also produces same result
Bug #6445 is the same problem
Bug #12699 is the same problem
Bug #12524 is the same problem
Is this only NT4???
[2002-12-04 10:34:08] [EMAIL PROTECTED]
if ($handle = opendir(//server/share)) {
while ($file = readdir($handle)) {
echo $filebr;
}
closedir($handle);
}
produces:
Warning: OpenDir: Invalid argument (errno 22)
I have tried setting the UNC share permissions to both Everyone - Read
and Everyone - Full Control and it does not matter.
--
Edit this bug report at http://bugs.php.net/?id=20813edit=1
#20551 [Fbk-Opn]: Output compression causes segfaults (ob_gzhandler)
ID: 20551 Updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] -Status: Feedback +Status: Open Bug Type: Output Control Operating System: RedHat 7.2 -PHP Version: 4.2.3 +PHP Version: 4.3.0RC2 New Comment: status - open, updated version. (please, don't use 'Add Comment' when you edit your own submission..use 'Edit Submission') Previous Comments: [2002-12-04 11:36:49] [EMAIL PROTECTED] Yes, the problem occurs without the Zend addon. Zend Accelerator won't work with PHP 4.3 anyhow, so I turned it off. In the other message I proved myself to be a bad typist. :( I meant to say _without_ Zend Accelerator... [2002-12-04 00:38:50] [EMAIL PROTECTED] Does the crash still occur when you disable Zend Accelerator? Derick [2002-12-03 20:41:29] [EMAIL PROTECTED] I tried with 4.3RC2. Bug still exists, crashing at least 13 times in the couple of minutes the server was able to run with Zend accelerator... I HATE this bug. Grr. I case I can take the time to do a walkthrough since it still exists... [2002-11-29 15:24:13] [EMAIL PROTECTED] Please try using this CVS snapshot: http://snaps.php.net/php4-latest.tar.gz For Windows: http://snaps.php.net/win32/php4-win32-latest.zip [2002-11-29 10:34:32] [EMAIL PROTECTED] In 4.3 zlib.output_compression will be PHP_INI_ALL and you can change the value if the headers are not sent. Also images won't be compressed automatically. 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/20551 -- Edit this bug report at http://bugs.php.net/?id=20551edit=1
#20815 [Opn-Bgs]: /main/reentrancy.c:192: too few arguments to function `readdir_r'
ID: 20815 Updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] -Status: Open +Status: Bogus Bug Type: Compile Failure Operating System: Linux 2.4.18 i686 GNU PHP Version: 4.3.0RC2 New Comment: Not enough information and most likely user error / broken system includes. Previous Comments: [2002-12-04 11:37:22] [EMAIL PROTECTED] $./configure ... $./make ... .../main/reentrancy.c:192: In function `readdir_r': .../main/reentrancy.c:192: too few arguments to function `readdir_r' make: *** [reentrancy.lo] Error 1 It was the last version. Please, ¿Could someone fix it in the next version? I will send the report until then. Thanks. -- Edit this bug report at http://bugs.php.net/?id=20815edit=1
#20816 [Fbk]: imagecopyresampled turn white into yellow
ID: 20816 Updated by: [EMAIL PROTECTED] -Summary: register_global and scoping vars Reported By: [EMAIL PROTECTED] Status: Feedback Bug Type: GD related -Operating System: Slackware Linux +Operating System: WinXP -PHP Version: 4.2.2 +PHP Version: 4.4.0-dev New Comment: restored the correct info.. Previous Comments: [2002-12-04 15:26:36] [EMAIL PROTECTED] Could you please show the complete script and if possible the source image you are using. So far, I was able to replicate the problem if I created the destination image using imagecreatetruecolor(). However, if I use imagecreate() it works correctly. [2002-12-04 13:24:58] [EMAIL PROTECTED] The function imagecopyresampled() takes a white area (255,255,255) and turns it yellow (255,255,2). This does not happen with imagecopyresize(). I think the problem is in the GD library, because the problem disappears when I use the php_gd2.dll from PHP4.2.3 instead of the one that came bundled with 4.4.0-dev. What phpinfo() says: 4.4.0-dev (both broken and working cases) GD 2.0 (bundled) BROKEN case GD 2.0 or higher WORKING case -- Edit this bug report at http://bugs.php.net/?id=20816edit=1
#20819 [Opn-Bgs]: max_execution_time ignored when waiting for open socket read
ID: 20819 Updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] -Status: Open +Status: Bogus Bug Type: PHP options/info functions Operating System: Linux 2.2.20 (Debian) PHP Version: 4.2.3 New Comment: Thank you for taking the time to write to us, but this is not a bug. Please double-check the documentation available at http://www.php.net/manual/ and the instructions on how to report a bug at http://bugs.php.net/how-to-report.php Use stream_set_timeout() to set the socket read timeouts, since socket reads don't take cpu time, which is what max_execution_time is referring to. While your script is sitting on a socket waiting for data, it does not use any CPU time. Previous Comments: [2002-12-04 17:21:32] [EMAIL PROTECTED] When PHP is waiting for a socket read the max_exection_time parameter is ignored. I was trying to use PHP scripts to monitor server response times but when there is a problem the script does not kill itself. It does not matter how I specify the max_execution_time. For instance like this: php4 -d max_execution_time 5 This behaviour was already in all previous versions I used. -- Edit this bug report at http://bugs.php.net/?id=20819edit=1
#20820 [NEW]: Session Variables are not passed using URL refresh
From: [EMAIL PROTECTED] Operating system: Linux PHP version: 4.2.2 PHP Bug Type: Session related Bug description: Session Variables are not passed using URL refresh Hello, I recognized the following problem on the server of my provider using PHP 4.2.2: I register session varibles in my script and use URL-refresh to link to the next php-script. URL refresh in html: meta http-equiv=refresh content=0; URL=http://www.test.com/test.php; The same error occurs using onLoad and link via JavaScript. What happened? The session was not passed to the next script, but it works fine with normal hyperreferences. I haven't seen this problem before! I run PHP 4.2.1 in the office on Win and IIS with the same session configurations in PHP and it works fine. Is this a problem of PHP 4.2.2 in general? Thank you! Best regards, Rudolf -- Edit bug report at http://bugs.php.net/?id=20820edit=1 -- Try a CVS snapshot: http://bugs.php.net/fix.php?id=20820r=trysnapshot Fixed in CVS: http://bugs.php.net/fix.php?id=20820r=fixedcvs Fixed in release: http://bugs.php.net/fix.php?id=20820r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=20820r=needtrace Try newer version: http://bugs.php.net/fix.php?id=20820r=oldversion Not developer issue:http://bugs.php.net/fix.php?id=20820r=support Expected behavior: http://bugs.php.net/fix.php?id=20820r=notwrong Not enough info:http://bugs.php.net/fix.php?id=20820r=notenoughinfo Submitted twice:http://bugs.php.net/fix.php?id=20820r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=20820r=globals PHP 3 support discontinued: http://bugs.php.net/fix.php?id=20820r=php3 Daylight Savings: http://bugs.php.net/fix.php?id=20820r=dst IIS Stability: http://bugs.php.net/fix.php?id=20820r=isapi
#20818 [Opn-Fbk]: weird page outputs (scrambled parts of html on pages)
ID: 20818 Updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] -Status: Open +Status: Feedback -Bug Type: Unknown/Other Function +Bug Type: IIS related Operating System: WinXP Pro (IIS5.1) PHP Version: 4.2.3 New Comment: Please try using this CVS snapshot: http://snaps.php.net/php4-latest.tar.gz For Windows: http://snaps.php.net/win32/php4-win32-latest.zip Previous Comments: [2002-12-04 16:34:00] [EMAIL PROTECTED] I have been using apache with the php module for quite some time (which works excelent of coarse) on a win2k pro machine. this server is temporarily down untill after christmas when i plan to upgrade it I have recently set up IIS in winxp, because it was a quick thing to install, for some small tasks that are just easier for me with iis, like naitive frontpage and asp support, which my father wanted so he can work on a site and test it for a company we are starting... I still wanted to have php on this machine as well so i installed the cgi. the problem i am having is a strange one i have never seen before. I did a bug search here but could not find anything that seemed to be helpful, perhaps i am jsut wording my search wrong but anyways: every so often any php page seems to have some part of the code get scrambled up as if the html tags are not being closed almost (espetially in forums like phpbb2) its not a earth shattering error but its something that has been bothering me a bit and i can't seem to figure it out myself. is this a xp/iis bug? will installing the non-cgi version of php in iis fix it? any explanations would be greatly appreciated. -Andrew -- Edit this bug report at http://bugs.php.net/?id=20818edit=1
#20820 [Opn-Bgs]: Session Variables are not passed using URL refresh
ID: 20820 Updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] -Status: Open +Status: Bogus Bug Type: Session related Operating System: Linux PHP Version: 4.2.2 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. Previous Comments: [2002-12-04 18:10:53] [EMAIL PROTECTED] Hello, I recognized the following problem on the server of my provider using PHP 4.2.2: I register session varibles in my script and use URL-refresh to link to the next php-script. URL refresh in html: meta http-equiv=refresh content=0; URL=http://www.test.com/test.php; The same error occurs using onLoad and link via JavaScript. What happened? The session was not passed to the next script, but it works fine with normal hyperreferences. I haven't seen this problem before! I run PHP 4.2.1 in the office on Win and IIS with the same session configurations in PHP and it works fine. Is this a problem of PHP 4.2.2 in general? Thank you! Best regards, Rudolf -- Edit this bug report at http://bugs.php.net/?id=20820edit=1
#15316 [Fbk-NoF]: Segmentation fault on Interbase blob creation
ID: 15316 Updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] -Status: Feedback +Status: No Feedback Bug Type: InterBase related Operating System: Linux 2.4.17-xfs PHP Version: 4.1.1 New Comment: 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. Previous Comments: [2002-11-24 23:20:18] [EMAIL PROTECTED] Please try using this CVS snapshot: http://snaps.php.net/php4-latest.tar.gz For Windows: http://snaps.php.net/win32/php4-win32-latest.zip [2002-10-27 19:48:08] [EMAIL PROTECTED] I wonder if this could be related to a problem I ran into, detailed at http://bugs.php.net/bug.php?id=18744 Basically, I discovered that if you tried to use ibase_blob_add to add 64k of data to a blob at any one time, the data would be truncated. Wonder if some variation of this bug causes a core dump? Are your images 64k in size? [2002-08-09 13:26:10] [EMAIL PROTECTED] I am using php 4.2.2 on freebsd 4.6 and it core dumps whenever I try to insert ot update a blob in an interbase db as well. (not running from apache running the cgi version from a shell). [2002-03-11 20:26:44] [EMAIL PROTECTED] Does any of this information help? I see that there are now others reporting this bug, so perhaps it can be combined with those. [2002-02-21 20:46:50] [EMAIL PROTECTED] Well, I got pretty close to getting a backtrace, but ran across what appears to be a bug in gdb. Either that, or I am just not finding the proper documentation. I can get a gdb attached to the proper thread, via: /usr/sbin/apache.dbg gdb /usr/sbin/apache.dbg (gdb) attach pid (gdb) continue but when I continue it, it gives me a message like Cannot find thread 2049: invalid thread handle. Now, I may be doing something wrong, but I sure can't tell what. 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/15316 -- Edit this bug report at http://bugs.php.net/?id=15316edit=1
#20772 [Opn]: fpassthru() loads entire file in RAM
ID: 20772
Updated by: [EMAIL PROTECTED]
Reported By: [EMAIL PROTECTED]
Status: Open
Bug Type: Filesystem function related
Operating System: redhat 7.0
PHP Version: 4.3.0RC2
New Comment:
The lack of the memory limit error message is directly related to bug
#20802.
Previous Comments:
[2002-12-03 16:40:09] [EMAIL PROTECTED]
I have changed this bug report to analyze simply the fpassthru() bug
and I have opened to other bug reports regarding ob_end_clean and
memory limit problems.
These seem to be independent bugs.
[2002-12-03 15:38:46] [EMAIL PROTECTED]
Because the problem seems to be a fpassthru problem, I have changed
the category from output control to filesystem function
[2002-12-03 12:26:57] [EMAIL PROTECTED]
Using php4.3.0RC2:
Now I have put a .htaccess file with
--
php_flag output_buffering Off
--
and added
ini_set('memory_limit','100M');
at the beginning of the script
and now it works but the script is using 40Mbyte RAM, why?
The
fpassthru($fd)
function seems to load the complete file in memory but in version 4.2.3
it sent it directly to the output without loading it in memory.
[2002-12-03 06:43:53] [EMAIL PROTECTED]
to add to the summary:
php 4.3.0RC2 without output buffering : unable to
find the server error.
[2002-12-03 06:41:46] [EMAIL PROTECTED]
Errata corridge:
The script works well adding the ob_end_clean() function only if I
use php 4.2.3.
Using php 4.3.0RC2 the script give me a blank document.
I have tried to set
---
php_flag output_buffering Off
---
in .htaccess and to comment the ob_and_clean() but the script give me
a unable to find the server error now (this is also the error that
the script gave me with output buffering activated and no
ob_end_clean in php 4.2.3)
Summary:
php 4.3.0RC2 + output buffering on (without ob_end_clean()): unable
to find the server error.
php 4.3.0RC2 + output buffering on (with ob_end_clean()): document
contains no data error.
php 4.2.3 + output buffering on (without ob_end_clean()): unable to
find the server error.
php 4.2.3 + output buffering on (with ob_end_clean()): all is ok.
I have experienced the same document contains no data in other
scripts in which i used the ob_end_clean() function to deactivate the
output buffering (when I cannot use .htaccess) but these scripts worked
well with php 4.2.3.
Andrea Busia
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/20772
--
Edit this bug report at http://bugs.php.net/?id=20772edit=1
#15587 [Fbk-NoF]: basic_functions.c and dns.c fail to compile due to incompatible parameters
ID: 15587
Updated by: [EMAIL PROTECTED]
Reported By: [EMAIL PROTECTED]
-Status: Feedback
+Status: No Feedback
Bug Type: Compile Failure
Operating System: Irix 6.5.15m
PHP Version: 4.1.1, 4.3.0-dev
New Comment:
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.
Previous Comments:
[2002-11-24 23:23:15] [EMAIL PROTECTED]
Please try using this CVS snapshot:
http://snaps.php.net/php4-latest.tar.gz
For Windows:
http://snaps.php.net/win32/php4-win32-latest.zip
[2002-08-29 21:48:29] [EMAIL PROTECTED]
updated versions.
[2002-08-29 16:58:36] [EMAIL PROTECTED]
Too soon. This snapshot also fails on Zend/zend_language_scanner.c
cc-1200 cc: ERROR File = Zend/zend_language_scanner.c, Line = 4186
The depth of macro recursion exceed the maximum allowed.
if (yy_start_stack_ptr) {
^
cc-1131 cc: ERROR File = Zend/zend_language_scanner.c, Line = 4186
Expected a field name.
if (yy_start_stack_ptr) {
This repeats on lines 5719 5723, 5724, 5726, 5727, 5730, etc
[2002-08-29 16:43:22] [EMAIL PROTECTED]
Tried a make with php4-200208290900. Error is still on the same
location and message is identical. Compilation fails.
Again; compiling with EXTRA-CFLAGS set to -cckr results in a succesful
build. Version php-4.1.1 ran stable this way.
[2002-08-08 07:51:03] [EMAIL PROTECTED]
Set to feedback.
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/15587
--
Edit this bug report at http://bugs.php.net/?id=15587edit=1
#17540 [Fbk-NoF]: CDATA incorrect for non block elements
ID: 17540 Updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] -Status: Feedback +Status: No Feedback Bug Type: XML related Operating System: Win 2K Pro PHP Version: 4.2.1 New Comment: 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. Previous Comments: [2002-11-24 23:30:39] [EMAIL PROTECTED] Please try using this CVS snapshot: http://snaps.php.net/php4-latest.tar.gz For Windows: http://snaps.php.net/win32/php4-win32-latest.zip [2002-05-31 02:08:23] [EMAIL PROTECTED] Running PHP 4.2.1 with Apache 2.0.36 on Windows 2000 Profrofessional. PHP is running as an Apache module. XML extension enabled XSLT extension enabled For some reason when parsing documents that like: doc paraSome text test / rest of para text/para /doc The CDATA that is returned through the xml_set_character_data_handler seems to return the rest of the para CDATA instead of nothing. After the data handler has been called, then it calls the element handler to close the test/ tag. An easy way to test is to keep track of the current tag that the parser is on (by setting it in the open element handler) and then running strlen over the CDATA has it hits the test tag. Logically it should close the tag, then process the CDATA or at least return blank CDATA for the test tag. -- Edit this bug report at http://bugs.php.net/?id=17540edit=1
#18523 [Fbk-NoF]: httpd Memory consumption with new PHP
ID: 18523 Updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] -Status: Feedback +Status: No Feedback Bug Type: Apache related Operating System: BSDI 4.1 PHP Version: 4.2.2 New Comment: 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. Previous Comments: [2002-11-24 23:35:07] [EMAIL PROTECTED] Please try using this CVS snapshot: http://snaps.php.net/php4-latest.tar.gz For Windows: http://snaps.php.net/win32/php4-win32-latest.zip [2002-09-28 22:57:02] [EMAIL PROTECTED] su# ls libs/ libphp4.a libphp4.la su# ls .libs/ libphp4.a libphp4.la libphp4.lai [2002-09-28 22:47:48] [EMAIL PROTECTED] Is there anything in .libs/ or libs/ directory? [2002-09-27 01:42:25] [EMAIL PROTECTED] Did not work; didn't generate the .so su# make install Installing PHP SAPI module [activating module `php4' in /usr/local/web/apache/conf/httpd.conf] cp libs/libphp4.so /usr/local/web/apache/libexec/libphp4.so cp: libs/libphp4.so: No such file or directory apxs:Break: Command failed with rc=1 *** Error code 1 [2002-09-26 19:51:45] [EMAIL PROTECTED] Please try using this CVS snapshot: http://snaps.php.net/php4-latest.tar.gz For Windows: http://snaps.php.net/win32/php4-win32-latest.zip The remainder of the comments for this report are too long. To view the rest of the comments, please view the bug report online at http://bugs.php.net/18523 -- Edit this bug report at http://bugs.php.net/?id=18523edit=1
#20302 [Fbk-NoF]: Leaked Descriptors
ID: 20302 Updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] -Status: Feedback +Status: No Feedback Bug Type: Scripting Engine problem Operating System: Linux 2.4.18 PHP Version: 4.2.2 New Comment: 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. Previous Comments: [2002-11-23 16:37:43] [EMAIL PROTECTED] Please try using this CVS snapshot: http://snaps.php.net/php4-latest.tar.gz For Windows: http://snaps.php.net/win32/php4-win32-latest.zip [2002-11-07 12:20:30] [EMAIL PROTECTED] Upon investigating the php engine as shipped by RedHat 8.0 with the env_audit program, I have found that php is leaking descriptors (above and beyond what apache is leaking). One descriptor is the php webpage being executed, and 2 copies of the socket returned from accept appear to be leaked. The env_audit program is listed at freshmeat.net, it comes with instructions to audit php. The fix is to add a fcntl(fd, FD_CLOEXEC) after accept and after opening the page. -- Edit this bug report at http://bugs.php.net/?id=20302edit=1
#20476 [Fbk-NoF]: Apache cannot load libphp4.so into server. Undefined symbol IS_SLASH_P
ID: 20476 Updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] -Status: Feedback +Status: No Feedback Bug Type: Apache related Operating System: ASPLinux 7.2 PHP Version: 4.4.0-dev New Comment: 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. Previous Comments: [2002-11-23 16:42:52] [EMAIL PROTECTED] Does the php-cli (/usr/local/bin/php) work properly? [2002-11-19 03:05:02] [EMAIL PROTECTED] This is my config.nice: [root@www src]# cat config.nice #! /bin/sh # # Created by configure './configure' \ '--with-pgsql=/usr/local/pgsql' \ '--with-zlib' \ '--with-layout=GNU' \ '--with-ssl' \ '--with-dom=/usr/local/lib' \ '--without-mysql' \ '--with-xslt-sablot' \ '--enable-xslt' \ '--with-iconv=/usr/local/lib/' \ '--with-curl=../curl-7.9.7/' \ '--with-apxs=/usr/sbin/apxs' \ '--enable-calendar' \ '--with-gettext=/bin' \ '--with-java=/usr/local/jdk1.3.1_04' \ '--with-ming=/usr/lib' \ '--with-gd' \ '--enable-gd-native-ttf' \ '--with-png-dir=/usr' \ '--with-jpeg-dir=/usr' \ '--with-freetype-dir=/usr/local' \ $@ And i'am sure that libphp4.so is one, i just compiled. [2002-11-18 10:45:49] [EMAIL PROTECTED] Exactly how did you configure PHP? And are you sure your libphp4.so is the one that you compiled? [2002-11-18 08:48:11] [EMAIL PROTECTED] So, this latest php cvs snapshot isn't working to. Message IS_SLASH_P undefined appears again. May be this is a bug... [2002-11-18 07:11:37] [EMAIL PROTECTED] This version of php requires curl-7.10.2, but in download section of http://curl.sourceforge.net avaible only 7.10.1:=( May be this is a mistake? Or some? 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/20476 -- Edit this bug report at http://bugs.php.net/?id=20476edit=1
#20525 [Fbk-NoF]: variable references not working correctly
ID: 20525 Updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] -Status: Feedback +Status: No Feedback Bug Type: Variables related Operating System: Windows 2000 PHP Version: 4.2.3 New Comment: 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. Previous Comments: [2002-11-23 09:07:18] [EMAIL PROTECTED] when the output is so self explainatory, I'd like to see how it is produced, hence I have to go through your code. I won't do this, since I am sure you can shorten that to 10-15 LOC. Also, I asked you twice to read the docs on references[1] and you did not reply to that by no means. The '' operator works different in PHP than in C. Make, at first, sure, the 'bug' is due to this confusion, thank you. [1] http://www.php.net/manual/en/language.references.php Jan P.S. I don't want to sound rude as well :) [2002-11-22 10:55:59] [EMAIL PROTECTED] Also, please look at output from bottom up. This will make it easier to understand what is happening. If you want less output, just comment out the print_test functions. I am included the last set of lines from the output and have noted the differences between runs with You will notice that in the proper code, the B_FIRST, B_SECOND and B_THIRD objects are stored properly. In the code using the reference symbol, only the B_THIRD object is stored. It is stored three seperate times. The proper result should be : Test: c_list Object ( [c_list] = Array ( [0] = b Object ( [name] = A_First [list_array] = Array ( [0] = a Object ( [name] = B_First [order] = 1 ) [1] = a Object ( [name] = B_Second [order] = 2 ) [2] = a Object ( [name] = B_Third [order] = 3 ) Output from BAD calls using the reference symbol will look like this: c_list Object ( [c_list] = Array ( [0] = b Object ( [name] = A_Second [list_array] = Array ( [0] = a Object ( [name] = B_Third [order] = 3 ) [1] = a Object ( [name] = B_Third [order] = 3 ) [2] = a Object ( [name] = B_Third [order] = 3 ) Hope this discussion is alieviates some of your time crunch. Thanks for those of us who depend on PHP for our businesses. [2002-11-22 10:31:43] [EMAIL PROTECTED] I don't want to sound rude, but just run the script as is and you will see the problem. This is about as short as I want to get the script so that you see the problem in depth. It will take you no amount of time to cut and paste the section into a new doc and run it. The difference in output will be self explanatory. So if you would,.just run the script provided. [2002-11-21 09:59:11] [EMAIL PROTECTED] Hey, I should have emphesized on 'short', currently I just don't have the passion to go through that code in depth without you showing that you have read the docs. And please come up with a short, self-contained, easy to read and unterstand script, thanks a lot for your interest in PHP! -- Jan [2002-11-21 09:46:28] [EMAIL PROTECTED] Script was already included. Just cut and paste the PHP code into a text editor and save. Then run. The script will
#20532 [Fbk-NoF]: proc_open connection hangs
ID: 20532 Updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] -Status: Feedback +Status: No Feedback Bug Type: Program Execution Operating System: Linux Redhat 7.3 PHP Version: 4.3.0RC1 New Comment: 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. Previous Comments: [2002-11-24 12:54:55] [EMAIL PROTECTED] Please provide a SHORT example that could be used to replicate the problem. [2002-11-20 22:13:21] [EMAIL PROTECTED] The example in the manual that invokes the cli version of php works. But If I try to do the same thing with R (the statistics package at www.r-project.org) it hangs. Almost the same problem with bc -- output is only seen there if the fwrite connection is closed before doing an fread/fget. R buffers its output in non-terminal mode so I have tried modifying the source of R to force line-buffered output -- no joy. I have also tried calling R indirectly via the unbuffer script that comes with expect -- no joy. I have also tried the pty example program from Advanced Programming in the Unix environment -- no joy. -- Edit this bug report at http://bugs.php.net/?id=20532edit=1
#20568 [Fbk-NoF]: Apache2/PHP 4.2.3 File Upload Corruption
ID: 20568 Updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] -Status: Feedback +Status: No Feedback Bug Type: Apache2 related Operating System: Linux PHP Version: 4.2.3 New Comment: 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. Previous Comments: [2002-11-22 07:14:10] [EMAIL PROTECTED] Please try using this CVS snapshot: http://snaps.php.net/php4-latest.tar.gz For Windows: http://snaps.php.net/win32/php4-win32-latest.zip [2002-11-22 05:22:00] [EMAIL PROTECTED] Hi there, I'm seeing odd corruption occurring to JPEG files (others unconfirmed) when uploading using POST. This is a localhost-localhost connection, on a file getting uploaded from the same hard disk that the web server saves it to. Upon downgrading to Apache 1.3.27, the problem went away. At the URL below you can find my configuration details, the code that handles the upload (I'm pretty sure it's not that), and some sample damaged files. I cannot tell what kind of damage is occurring, the file size changes randomly, as does the visible damage to the image. I have tried with both w3m and Mozilla. Sample files, the code, my configuration: http://botanicus.net/dw/tmp/phpbug/ Thanks, Dave. -- Edit this bug report at http://bugs.php.net/?id=20568edit=1
#20598 [Fbk-NoF]: bzip2 doesn't create new files
ID: 20598 Updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] -Status: Feedback +Status: No Feedback Bug Type: Bzip2 Related Operating System: Windows NT 4.0 SP6a PHP Version: 4.2.3 New Comment: 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. Previous Comments: [2002-11-23 13:09:36] [EMAIL PROTECTED] Please try using this CVS snapshot: http://snaps.php.net/php4-latest.tar.gz For Windows: http://snaps.php.net/win32/php4-win32-latest.zip [2002-11-23 13:08:58] [EMAIL PROTECTED] I have tried to test the example 'Small bzip2 Example', but it doesn't work, the function 'bzopen($filename, w)' isn't creating a new file. I get a error 'Warning: bzopen(): Unable to open file in D:\Inetpub\wwwroot\php\smallbzip2.php on line 7'. So I change the code from: -- ?php $filename = D:/TEMP/testfile.bz2; $str = This is a test string.\n; // open file for writing $bz = bzopen($filename, w); . . . ? -- to: -- ?php $filename = D:/TEMP/testfile.bz2; $str = This is a test string.\n; // open file for writing $fp= fopen($filename,w); //--HERE fclose($fp); //- HERE $bz = bzopen($filename, w); . . . ? My configuration is: Windows NT 4.0 SP6a; IIS 4.0; PHP-4.2.3(binary); The system has full control over D:\TEMP; Leandro Campos Sao Vicente - Sao Paulo - Brazil. -- Edit this bug report at http://bugs.php.net/?id=20598edit=1
#20601 [Fbk-NoF]: A simple syntax parse error
ID: 20601
Updated by: [EMAIL PROTECTED]
Reported By: [EMAIL PROTECTED]
-Status: Feedback
+Status: No Feedback
Bug Type: Unknown/Other Function
Operating System: Windows ME
PHP Version: 4.3.0RC1
New Comment:
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.
Previous Comments:
[2002-11-23 14:05:03] [EMAIL PROTECTED]
Not enough information was provided for us to be able
to handle this bug. Please re-read the instructions at
http://bugs.php.net/how-to-report.php
If you can provide more information, feel free to add it
to this bug and change the status back to Open.
Thank you for your interest in PHP.
can you include a short script?
[2002-11-23 14:01:43] [EMAIL PROTECTED]
When using single quotes (i dont know if they will be allowed to show
here) (') inside double quote strings (), a parse error is produced;
Parse error: parse error, unexpected T_ENCAPSED_AND_WHITESPACE,
expecting T_STRING or T_VARIABLE or T_NUM_STRING
This happened on Windows ME, using the latest Apache 1.3, and all
settings in php.ini are default.
This is very annoying, please fix it!
--
Edit this bug report at http://bugs.php.net/?id=20601edit=1
#20604 [Fbk]: PHP CLI exists always with Segmantation Fault
ID: 20604 Updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] Status: Feedback Bug Type: Unknown/Other Function Operating System: Linux Debian Sarge PHP Version: 4CVS-2002-11-24 (dev) New Comment: Please try using this CVS snapshot: http://snaps.php.net/php4-latest.tar.gz For Windows: http://snaps.php.net/win32/php4-win32-latest.zip Previous Comments: [2002-11-24 05:11:18] [EMAIL PROTECTED] i installed now the libc6-dbg package and put /usr/lib/debug in LD_LIBRARY_PATH and now is the error in another function of libc Program received signal SIGSEGV, Segmentation fault. [Switching to Thread 1024 (LWP 26000)] 0x403367d0 in main_arena () from /usr/lib/debug/libc.so.6 (gdb) bt #0 0x403367d0 in main_arena () from /usr/lib/debug/libc.so.6 #1 0x403367c0 in main_arena () from /usr/lib/debug/libc.so.6 #2 0x403367c0 in main_arena () from /usr/lib/debug/libc.so.6 #3 0x403367c8 in main_arena () from /usr/lib/debug/libc.so.6 #4 0x403367b0 in main_arena () from /usr/lib/debug/libc.so.6 #5 0x403367a8 in main_arena () from /usr/lib/debug/libc.so.6 #6 0x403367a0 in main_arena () from /usr/lib/debug/libc.so.6 #7 0x40336798 in main_arena () from /usr/lib/debug/libc.so.6 #8 0x40336790 in main_arena () from /usr/lib/debug/libc.so.6 #9 0x081a4560 in ?? () [2002-11-24 04:49:27] [EMAIL PROTECTED] argh forget the relevant part of this script #!/usr/local/bin/php ? if ($argc 2) die(nothing to do\n); [2002-11-24 04:45:24] [EMAIL PROTECTED] here it is (gdb) run ddns-update.php Starting program: /usr/local/bin/php ddns-update.php [New Thread 1024 (LWP 24022)] nothing to do Program received signal SIGSEGV, Segmentation fault. [Switching to Thread 1024 (LWP 24022)] 0x403357d0 in __morecore () from /lib/libc.so.6 (gdb) bt #0 0x403357d0 in __morecore () from /lib/libc.so.6 #1 0x403357c0 in __morecore () from /lib/libc.so.6 #2 0x403357c0 in __morecore () from /lib/libc.so.6 #3 0x403357c8 in __morecore () from /lib/libc.so.6 #4 0x403357b0 in __morecore () from /lib/libc.so.6 #5 0x403357a8 in __morecore () from /lib/libc.so.6 #6 0x403357a0 in __morecore () from /lib/libc.so.6 #7 0x40335798 in __morecore () from /lib/libc.so.6 #8 0x40335790 in __morecore () from /lib/libc.so.6 #9 0x081a5560 in ?? () [2002-11-24 04:37:31] [EMAIL PROTECTED] ok i just compiled now with my whole standard configure line but without the --with-apxs2 and it had no segmantation fault on the other bug report i can see the problem seems to be also with apache 1.3 --with-apxs line [2002-11-24 04:32:36] [EMAIL PROTECTED] it worked befor with exactly this configure line ./configure --disable-cgi --silent --with-mysql=/usr/local/mysql --enable-trans-sid --enable-inline-optimization --enable-ftp --enable-sockets --without-pear --with-mhash --with-bz2 --with-zlib but when i added the --with-apxs2=/usr/local/apache2/bin/apxs it has the segmantation fault sorry for double post 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/20604 -- Edit this bug report at http://bugs.php.net/?id=20604edit=1
#20607 [Fbk]: function included from parent script gets lost
ID: 20607 Updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] Status: Feedback Bug Type: Scripting Engine problem Operating System: red hat 7.2 PHP Version: 4.2.3 New Comment: Please try using this CVS snapshot: http://snaps.php.net/php4-latest.tar.gz For Windows: http://snaps.php.net/win32/php4-win32-latest.zip Previous Comments: [2002-11-25 00:32:34] [EMAIL PROTECTED] it doesnt matter if I do ini_set(error_reporting, E_WARNING); or ini_set(error_reporting, E_ALL); or include_once / require_once the site comes up with nothing when I set error_reporting [2002-11-25 00:28:02] [EMAIL PROTECTED] ok index.php now reads (on the live site): ? ini_set(error_reporting, E_ALL); //echo Error Level : . ini_get(error_reporting) . br /; require_once it_functions/it_db.php; $a = it_getnextid(table, trjh); ? I dont get any msg at all now, but i should get an echo from it_GetNextID ... ? [2002-11-24 19:27:32] [EMAIL PROTECTED] yep, will do that, but im using other files in the same directory. also what is the function to get/set config options in php via the script? [2002-11-24 12:36:08] [EMAIL PROTECTED] Looks like the include is failing, but the error is not being shown, could you increase your error level to display E_WARNING or change include_once to require_once. [2002-11-24 05:53:35] [EMAIL PROTECTED] the only difference is in index.php: ? include_once it_db.php; $a = it_getnextid(table, trjh); ? 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/20607 -- Edit this bug report at http://bugs.php.net/?id=20607edit=1
#20614 [Fbk-NoF]: HTML tag paremeter is double-quoted automatically
ID: 20614 Updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] -Status: Feedback +Status: No Feedback Bug Type: Output Control Operating System: Win32 PHP Version: 4.2.3 New Comment: 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. Previous Comments: [2002-11-24 22:45:26] [EMAIL PROTECTED] I am guessing you are using sessions and consequently url_rewriter.tags is modifying your HTML. Try removing 'input=src' from url_rewriter.tags inside your php.ini. [2002-11-24 21:54:09] [EMAIL PROTECTED] When I installed PHP 4.2.3 on my PC I found IE returning JavaScripte errors. After reviewing contents of IE page and PHP code I found that whichever HTML parameter value is specified w/o quotes (for example ...input type=hidden... instead of ...input type=hidden... or ...input type='hidden'...) this value is being double quoted automatically (for example if in PHP page there is ...input type=hidden..., when you do View - Source in IE you see ...input type=hidden...). This autocorrection looks very much like new feature that is supposed to be switcheable. At least, if it is an old feature, I just haven't met it before. All tryings to find in documentation how to switch it off didn't give any result. -- Edit this bug report at http://bugs.php.net/?id=20614edit=1
#20821 [Opn-Csd]: Make fails
ID: 20821 Updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] -Status: Open +Status: Closed Bug Type: Compile Failure Operating System: FreeBSD 4.7-STABLE PHP Version: 4CVS-2002-12-04 (stable) 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: [2002-12-04 18:27:29] [EMAIL PROTECTED] I am trying to test the latest build to see if bug #19378 has been fixed. I have downloaded both Stable (4.3.x-dev) and Latest CVS (4.4.x-dev) both built on: Dec 04, 2002 22:30 GMT. Both were configured with... ./configure \ --with-config-file-path=/usr/local/etc/php.standalone \ --disable-pear \ --enable-discard-path \ --with-readline=/usr \ --enable-versioning \ --with-regex=system \ --with-gd=/usr/local \ --enable-gd-native-ttf \ --with-freetype-dir=/usr/local \ --with-jpeg-dir=/usr/local \ --with-png-dir=/usr/local \ --with-zlib \ --with-mysql=/usr/local \ --enable-trans-sid \ --prefix=/usr/local and both fail to compile at the same place. See below. gcc -I/usr/local/include -Iext/gd/ -I/usr/local/src/php4-200212042230/ext/gd/ -DPHP_ATOM_INC -I/usr/local/src/php4-200212042230/include -I/usr/local/src/php4-200212042230/main -I/usr/local/src/php4-200212042230 -I/usr/local/src/php4-200212042230/Zend -I/usr/local/include -I/usr/local/include/freetype2 -I/usr/local/include/mysql -I/usr/local/src/php4-200212042230/ext/xml/expat -I/usr/local/src/php4-200212042230/TSRM -g -O2 -c /usr/local/src/php4-200212042230/ext/gd/gd.c -o ext/gd/gd.o echo ext/gd/gd.lo /usr/local/src/php4-200212042230/ext/gd/gd.c: In function `_php_image_create_from': /usr/local/src/php4-200212042230/ext/gd/gd.c:1426: warning: assignment makes pointer from integer without a cast /usr/local/src/php4-200212042230/ext/gd/gd.c: In function `zif_imagecreatefromxpm': /usr/local/src/php4-200212042230/ext/gd/gd.c:1495: `gdImageCreateFromXpm' undeclared (first use in this function) /usr/local/src/php4-200212042230/ext/gd/gd.c:1495: (Each undeclared identifier is reported only once /usr/local/src/php4-200212042230/ext/gd/gd.c:1495: for each function it appears in.) *** Error code 1 -- Edit this bug report at http://bugs.php.net/?id=20821edit=1
#15316 [NoF-Opn]: Segmentation fault on Interbase blob creation
ID: 15316 User updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] -Status: No Feedback +Status: Open Bug Type: InterBase related Operating System: Linux 2.4.17-xfs PHP Version: 4.1.1 New Comment: Sorry...I meant to reply sooner. I haven't been able to do as you suggest yet. I have pretty much begun migrating off Interbase because of various weird problems integrating with PHP. I have tried newer PHP versions, and the problem seems to be at least partially addressed, although we do see quite a lot of error messages if we do not turn off error reporting. Previous Comments: [2002-12-04 18:15:26] [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. [2002-11-24 23:20:18] [EMAIL PROTECTED] Please try using this CVS snapshot: http://snaps.php.net/php4-latest.tar.gz For Windows: http://snaps.php.net/win32/php4-win32-latest.zip [2002-10-27 19:48:08] [EMAIL PROTECTED] I wonder if this could be related to a problem I ran into, detailed at http://bugs.php.net/bug.php?id=18744 Basically, I discovered that if you tried to use ibase_blob_add to add 64k of data to a blob at any one time, the data would be truncated. Wonder if some variation of this bug causes a core dump? Are your images 64k in size? [2002-08-09 13:26:10] [EMAIL PROTECTED] I am using php 4.2.2 on freebsd 4.6 and it core dumps whenever I try to insert ot update a blob in an interbase db as well. (not running from apache running the cgi version from a shell). [2002-03-11 20:26:44] [EMAIL PROTECTED] Does any of this information help? I see that there are now others reporting this bug, so perhaps it can be combined with those. 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/15316 -- Edit this bug report at http://bugs.php.net/?id=15316edit=1
#15316 [Opn-Fbk]: Segmentation fault on Interbase blob creation
ID: 15316 Updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] -Status: Open +Status: Feedback Bug Type: InterBase related Operating System: Linux 2.4.17-xfs PHP Version: 4.1.1 New Comment: And what are those errors you get? Previous Comments: [2002-12-04 18:46:15] [EMAIL PROTECTED] Sorry...I meant to reply sooner. I haven't been able to do as you suggest yet. I have pretty much begun migrating off Interbase because of various weird problems integrating with PHP. I have tried newer PHP versions, and the problem seems to be at least partially addressed, although we do see quite a lot of error messages if we do not turn off error reporting. [2002-12-04 18:15:26] [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. [2002-11-24 23:20:18] [EMAIL PROTECTED] Please try using this CVS snapshot: http://snaps.php.net/php4-latest.tar.gz For Windows: http://snaps.php.net/win32/php4-win32-latest.zip [2002-10-27 19:48:08] [EMAIL PROTECTED] I wonder if this could be related to a problem I ran into, detailed at http://bugs.php.net/bug.php?id=18744 Basically, I discovered that if you tried to use ibase_blob_add to add 64k of data to a blob at any one time, the data would be truncated. Wonder if some variation of this bug causes a core dump? Are your images 64k in size? [2002-08-09 13:26:10] [EMAIL PROTECTED] I am using php 4.2.2 on freebsd 4.6 and it core dumps whenever I try to insert ot update a blob in an interbase db as well. (not running from apache running the cgi version from a shell). 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/15316 -- Edit this bug report at http://bugs.php.net/?id=15316edit=1
#15316 [Fbk-Opn]: Segmentation fault on Interbase blob creation
ID: 15316 User updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] -Status: Feedback +Status: Open Bug Type: InterBase related Operating System: Linux 2.4.17-xfs PHP Version: 4.1.1 New Comment: I get invalid blob id warnings. Everything seems to work OK, though. Previous Comments: [2002-12-04 18:49:54] [EMAIL PROTECTED] And what are those errors you get? [2002-12-04 18:46:15] [EMAIL PROTECTED] Sorry...I meant to reply sooner. I haven't been able to do as you suggest yet. I have pretty much begun migrating off Interbase because of various weird problems integrating with PHP. I have tried newer PHP versions, and the problem seems to be at least partially addressed, although we do see quite a lot of error messages if we do not turn off error reporting. [2002-12-04 18:15:26] [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. [2002-11-24 23:20:18] [EMAIL PROTECTED] Please try using this CVS snapshot: http://snaps.php.net/php4-latest.tar.gz For Windows: http://snaps.php.net/win32/php4-win32-latest.zip [2002-10-27 19:48:08] [EMAIL PROTECTED] I wonder if this could be related to a problem I ran into, detailed at http://bugs.php.net/bug.php?id=18744 Basically, I discovered that if you tried to use ibase_blob_add to add 64k of data to a blob at any one time, the data would be truncated. Wonder if some variation of this bug causes a core dump? Are your images 64k in size? 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/15316 -- Edit this bug report at http://bugs.php.net/?id=15316edit=1
#20053 [Fbk-Opn]: apachesuexecphp-cgiignore_user_abort - problem with cancelled connections
ID: 20053 User updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] -Status: Feedback +Status: Open Bug Type: Apache related Operating System: linux 2.4.18 -PHP Version: 4.3.0-dev +PHP Version: 4.4.0-dev New Comment: problem still persist :( Previous Comments: [2002-12-03 01:12:13] [EMAIL PROTECTED] Please try the latest cvs as of today. Several significant cgi fixes have been commited. [2002-10-24 12:26:56] [EMAIL PROTECTED] updated version. [2002-10-24 04:27:26] [EMAIL PROTECTED] Exactly the same behaviour as in 4.2.3 :( [2002-10-24 02:42:11] [EMAIL PROTECTED] Please try using this CVS snapshot: http://snaps.php.net/php4-latest.tar.gz For Windows: http://snaps.php.net/win32/php4-win32-latest.zip [2002-10-23 19:40:25] [EMAIL PROTECTED] Under very specific circumstances, php goes in tight infinite loop eating all cpu after request is cancelled. Configuration: php 4.2.3 as cgi apache 1.3.27 php configured with Action directive, (important) using suexec. Conditions for problem to occur in script: 1.ignore_user_abort(true) 2.sending any http header 3.sending any body content AFTER http header 4. connection is aborted before all data are sent to client. Script to reproduce problem: CUT ? ignore_user_abort(true); header(X-Whatever: whatever); ? whatever CUT Problem doesn't exist with mod_php or php-cgi without suexec. It appears that after apache has closed connection php is still trying to write output and loops for unknown reason. I'm not sure if this is fault of php, apache or suexec, but I think it could be fixed in php. -- Edit this bug report at http://bugs.php.net/?id=20053edit=1
#20821 [Csd-Opn]: Make fails
ID: 20821 User updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] -Status: Closed +Status: Open Bug Type: Compile Failure Operating System: FreeBSD 4.7-STABLE -PHP Version: 4CVS-2002-12-04 (stable) +PHP Version: Latest CVS (4.4.x-dev) New Comment: the Latest CVS (4.4.x-dev) Built On: Dec 05, 2002 02:30 GMT fails to compile at gcc -I/usr/local/include -Iext/gd/ -I/usr/local/src/php4-200212050230/ext/gd/ -DPHP_ATOM_INC -I/usr/local/src/php4-200212050230/include -I/usr/local/src/php4-200212050230/main -I/usr/local/src/php4-200212050230 -I/usr/local/src/php4-200212050230/Zend -I/usr/local/include -I/usr/local/include/freetype2 -I/usr/local/include/mysql -I/usr/local/src/php4-200212050230/ext/xml/expat -I/usr/local/src/php4-200212050230/TSRM -g -O2 -c /usr/local/src/php4-200212050230/ext/gd/gd.c -o ext/gd/gd.o echo ext/gd/gd.lo /usr/local/src/php4-200212050230/ext/gd/gd.c: In function `_php_image_create_from': /usr/local/src/php4-200212050230/ext/gd/gd.c:1427: warning: assignment makes pointer from integer without a cast /usr/local/src/php4-200212050230/ext/gd/gd.c: In function `zif_imagecreatefromxpm': /usr/local/src/php4-200212050230/ext/gd/gd.c:1497: `gdImageCreateFromXpm' undeclared (first use in this function) /usr/local/src/php4-200212050230/ext/gd/gd.c:1497: (Each undeclared identifier is reported only once /usr/local/src/php4-200212050230/ext/gd/gd.c:1497: for each function it appears in.) *** Error code 1 Stop in /usr/local/src/php4-200212050230. Previous Comments: [2002-12-04 18:33:57] [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. [2002-12-04 18:27:29] [EMAIL PROTECTED] I am trying to test the latest build to see if bug #19378 has been fixed. I have downloaded both Stable (4.3.x-dev) and Latest CVS (4.4.x-dev) both built on: Dec 04, 2002 22:30 GMT. Both were configured with... ./configure \ --with-config-file-path=/usr/local/etc/php.standalone \ --disable-pear \ --enable-discard-path \ --with-readline=/usr \ --enable-versioning \ --with-regex=system \ --with-gd=/usr/local \ --enable-gd-native-ttf \ --with-freetype-dir=/usr/local \ --with-jpeg-dir=/usr/local \ --with-png-dir=/usr/local \ --with-zlib \ --with-mysql=/usr/local \ --enable-trans-sid \ --prefix=/usr/local and both fail to compile at the same place. See below. gcc -I/usr/local/include -Iext/gd/ -I/usr/local/src/php4-200212042230/ext/gd/ -DPHP_ATOM_INC -I/usr/local/src/php4-200212042230/include -I/usr/local/src/php4-200212042230/main -I/usr/local/src/php4-200212042230 -I/usr/local/src/php4-200212042230/Zend -I/usr/local/include -I/usr/local/include/freetype2 -I/usr/local/include/mysql -I/usr/local/src/php4-200212042230/ext/xml/expat -I/usr/local/src/php4-200212042230/TSRM -g -O2 -c /usr/local/src/php4-200212042230/ext/gd/gd.c -o ext/gd/gd.o echo ext/gd/gd.lo /usr/local/src/php4-200212042230/ext/gd/gd.c: In function `_php_image_create_from': /usr/local/src/php4-200212042230/ext/gd/gd.c:1426: warning: assignment makes pointer from integer without a cast /usr/local/src/php4-200212042230/ext/gd/gd.c: In function `zif_imagecreatefromxpm': /usr/local/src/php4-200212042230/ext/gd/gd.c:1495: `gdImageCreateFromXpm' undeclared (first use in this function) /usr/local/src/php4-200212042230/ext/gd/gd.c:1495: (Each undeclared identifier is reported only once /usr/local/src/php4-200212042230/ext/gd/gd.c:1495: for each function it appears in.) *** Error code 1 -- Edit this bug report at http://bugs.php.net/?id=20821edit=1
#20776 [Opn]: Login only possible from page where login is required.
ID: 20776 User updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] Status: Open Bug Type: Session related Operating System: Win2K Server PHP Version: 4.2.3 New Comment: If a man isn't a socialist at 20, he has no heart; if he is still a socialist at 40, he has no mind. Rob Previous Comments: [2002-12-04 05:12:40] [EMAIL PROTECTED] hmm... maybe Sniper should start charging for support then; he would make a very decent living out out it with all the time he spends on verifying bugs and trying to help people with bugs. [2002-12-04 04:52:02] [EMAIL PROTECTED] Sniper, I have spent hours cutting out 90% of this program, removing libraries called, writing a script to autoinstall the tiny test database, written installation instructions and supplied two different versions of the main page - one which works, one which does not - and cut the whole thing down to six actual php files. Not twenty or even ten. And I finished doing that at 5:00am today, as you know. Some problems can't be reduced to 12 lines of code. In this case, the login has to come from two different pages and go to another one, that makes at least three files. The fourth is a library, which you can safely ignore. The fifth is a logout script, without which you can only test it once. The sixth is a file included globally in each of the others to cut down verbosity. If this is too complex, perhaps you expect me to actually fix your bugs for you. Sorry, I charge AU$100 an hour for that nowadays, having already paid my dues on a number of large GPL projects. Keep the bug, I don't mind. [2002-12-04 01:51:01] [EMAIL PROTECTED] And DO NOT REPLY TO THIS EMAIL!! And especially: DO NOT email me! You can put such long examples somewhere in the net and add an URL here so that other people see it too.. [2002-12-04 01:49:45] [EMAIL PROTECTED] I did mean _SHORT_ example script, one that is max 10-20 lines long..not some 10-20 files! [2002-12-03 12:00:23] [EMAIL PROTECTED] OK, I've sent a cutdown of the program, hope that helps. 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/20776 -- Edit this bug report at http://bugs.php.net/?id=20776edit=1
#20823 [NEW]: form post results in duplicitous $_REQUEST
From: [EMAIL PROTECTED] Operating system: Redhat7.2 PHP version: 4.3.0RC2 PHP Bug Type: Performance problem Bug description: form post results in duplicitous $_REQUEST using: PHP Version 4.3.0RC2 './configure' '--with-mysql=/usr' '--with-apxs2=/usr/local/apache2/bin/apxs' '--with-zlib=yes' '--enable-calendar' '--enable-ctype' '--enable-sysvsem' '--with-bz2' '--with-openssl' Apache2.0.43 php source reads: a href=modifyDuties.php?staffId=?php echo $_REQUEST[staffId]; ?duties/a resulting page reads: a href=modifyDuties.php?staffId=3staffId=3duties/a Why is '$_REQUEST[name]' equal to 'valuename=value'? -- Edit bug report at http://bugs.php.net/?id=20823edit=1 -- Try a CVS snapshot: http://bugs.php.net/fix.php?id=20823r=trysnapshot Fixed in CVS: http://bugs.php.net/fix.php?id=20823r=fixedcvs Fixed in release: http://bugs.php.net/fix.php?id=20823r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=20823r=needtrace Try newer version: http://bugs.php.net/fix.php?id=20823r=oldversion Not developer issue:http://bugs.php.net/fix.php?id=20823r=support Expected behavior: http://bugs.php.net/fix.php?id=20823r=notwrong Not enough info:http://bugs.php.net/fix.php?id=20823r=notenoughinfo Submitted twice:http://bugs.php.net/fix.php?id=20823r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=20823r=globals PHP 3 support discontinued: http://bugs.php.net/fix.php?id=20823r=php3 Daylight Savings: http://bugs.php.net/fix.php?id=20823r=dst IIS Stability: http://bugs.php.net/fix.php?id=20823r=isapi
#20735 [Fbk]: Crashing, when trying to create DB_DataObject Class definitions
ID: 20735 Updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] Status: Feedback Bug Type: Reproducible crash Operating System: Windows 2000 PHP Version: 4.3.0RC2 New Comment: can you try a snapshot release - latest cvs from (snaps.php.net) - I believe there where some fixes to the ms-sql driver in the last few days. Previous Comments: [2002-11-30 09:10:11] [EMAIL PROTECTED] can you try setting the debug = 5 in the ini file This should give you an idea of how far it is getting before crashing. Then just add exit;'s until you locate the line of code that is causing it to die. - my guess is that is a bug with the ms-sql bindings. Unfortunatly I dont have access to ms-sql (or windows 2000) to test this on. Regards Alan [2002-11-30 07:34:41] [EMAIL PROTECTED] can you send me ([EMAIL PROTECTED]) the database create script and your ini file - I'll see if I can reproduce this on linux. [2002-11-30 06:52:06] [EMAIL PROTECTED] When I try to create to DB_DataObject class definition (DB_DataObject 0.6) I get a crash. I give the instruction: d:\php430\php.exe createTables.php D:\work\livo2\etc\dbo_livo.ini The message box (unfortunatly in german) says: Die Anweisung in 0x778cb9b1 verweist auf Speicher in 0x. Der Vorgang written konnte nicht auf dem Speicher durchgeführt werden. Klicken Sie auf OK, um das Programm zu beenden. Klicken Sie auf Abbrechen, um das Programm zu debuggen. (The instruction in 0x778cb9b1 refers to memory at 0x. The task written could not be processed. (...)). Contact me for screenshots and more, if you want. Regards, Peter Hopfgartner -- Edit this bug report at http://bugs.php.net/?id=20735edit=1
#20821 [Opn-Fbk]: Make fails
ID: 20821 Updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] -Status: Open +Status: Feedback Bug Type: Compile Failure Operating System: FreeBSD 4.7-STABLE PHP Version: Latest CVS (4.4.x-dev) New Comment: Check main/php_config.h for line with HAVE_GD_XPM. Is it '#define HAVE_GD_XPM 1' ?? Previous Comments: [2002-12-04 20:35:43] [EMAIL PROTECTED] the Latest CVS (4.4.x-dev) Built On: Dec 05, 2002 02:30 GMT fails to compile at gcc -I/usr/local/include -Iext/gd/ -I/usr/local/src/php4-200212050230/ext/gd/ -DPHP_ATOM_INC -I/usr/local/src/php4-200212050230/include -I/usr/local/src/php4-200212050230/main -I/usr/local/src/php4-200212050230 -I/usr/local/src/php4-200212050230/Zend -I/usr/local/include -I/usr/local/include/freetype2 -I/usr/local/include/mysql -I/usr/local/src/php4-200212050230/ext/xml/expat -I/usr/local/src/php4-200212050230/TSRM -g -O2 -c /usr/local/src/php4-200212050230/ext/gd/gd.c -o ext/gd/gd.o echo ext/gd/gd.lo /usr/local/src/php4-200212050230/ext/gd/gd.c: In function `_php_image_create_from': /usr/local/src/php4-200212050230/ext/gd/gd.c:1427: warning: assignment makes pointer from integer without a cast /usr/local/src/php4-200212050230/ext/gd/gd.c: In function `zif_imagecreatefromxpm': /usr/local/src/php4-200212050230/ext/gd/gd.c:1497: `gdImageCreateFromXpm' undeclared (first use in this function) /usr/local/src/php4-200212050230/ext/gd/gd.c:1497: (Each undeclared identifier is reported only once /usr/local/src/php4-200212050230/ext/gd/gd.c:1497: for each function it appears in.) *** Error code 1 Stop in /usr/local/src/php4-200212050230. [2002-12-04 18:33:57] [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. [2002-12-04 18:27:29] [EMAIL PROTECTED] I am trying to test the latest build to see if bug #19378 has been fixed. I have downloaded both Stable (4.3.x-dev) and Latest CVS (4.4.x-dev) both built on: Dec 04, 2002 22:30 GMT. Both were configured with... ./configure \ --with-config-file-path=/usr/local/etc/php.standalone \ --disable-pear \ --enable-discard-path \ --with-readline=/usr \ --enable-versioning \ --with-regex=system \ --with-gd=/usr/local \ --enable-gd-native-ttf \ --with-freetype-dir=/usr/local \ --with-jpeg-dir=/usr/local \ --with-png-dir=/usr/local \ --with-zlib \ --with-mysql=/usr/local \ --enable-trans-sid \ --prefix=/usr/local and both fail to compile at the same place. See below. gcc -I/usr/local/include -Iext/gd/ -I/usr/local/src/php4-200212042230/ext/gd/ -DPHP_ATOM_INC -I/usr/local/src/php4-200212042230/include -I/usr/local/src/php4-200212042230/main -I/usr/local/src/php4-200212042230 -I/usr/local/src/php4-200212042230/Zend -I/usr/local/include -I/usr/local/include/freetype2 -I/usr/local/include/mysql -I/usr/local/src/php4-200212042230/ext/xml/expat -I/usr/local/src/php4-200212042230/TSRM -g -O2 -c /usr/local/src/php4-200212042230/ext/gd/gd.c -o ext/gd/gd.o echo ext/gd/gd.lo /usr/local/src/php4-200212042230/ext/gd/gd.c: In function `_php_image_create_from': /usr/local/src/php4-200212042230/ext/gd/gd.c:1426: warning: assignment makes pointer from integer without a cast /usr/local/src/php4-200212042230/ext/gd/gd.c: In function `zif_imagecreatefromxpm': /usr/local/src/php4-200212042230/ext/gd/gd.c:1495: `gdImageCreateFromXpm' undeclared (first use in this function) /usr/local/src/php4-200212042230/ext/gd/gd.c:1495: (Each undeclared identifier is reported only once /usr/local/src/php4-200212042230/ext/gd/gd.c:1495: for each function it appears in.) *** Error code 1 -- Edit this bug report at http://bugs.php.net/?id=20821edit=1
#20823 [Opn-Fbk]: form post results in duplicitous $_REQUEST
ID: 20823 Updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] -Status: Open +Status: Feedback -Bug Type: Performance problem +Bug Type: Apache2 related Operating System: Redhat7.2 PHP Version: 4.3.0RC2 New Comment: What does 'var_dump($_REQUEST)' output? And can you please add a short but _complete_ example script here? Previous Comments: [2002-12-04 22:17:38] [EMAIL PROTECTED] using: PHP Version 4.3.0RC2 './configure' '--with-mysql=/usr' '--with-apxs2=/usr/local/apache2/bin/apxs' '--with-zlib=yes' '--enable-calendar' '--enable-ctype' '--enable-sysvsem' '--with-bz2' '--with-openssl' Apache2.0.43 php source reads: a href=modifyDuties.php?staffId=?php echo $_REQUEST[staffId]; ?duties/a resulting page reads: a href=modifyDuties.php?staffId=3staffId=3duties/a Why is '$_REQUEST[name]' equal to 'valuename=value'? -- Edit this bug report at http://bugs.php.net/?id=20823edit=1
