Bug #15772 Updated: PHP is developed and maintained by morons
ID: 15772 Updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] Status: Closed Bug Type: *General Issues Operating System: all PHP Version: 4.0.6 New Comment: We can search and fix what's wrong if there is a bug description, but it would nice if you could post patch to php-dev directly. We know PHP has many bugs and appreciate patches fixes bugs. You have skills, right :) Previous Comments: [2002-02-28 03:02:27] [EMAIL PROTECTED] Your claims are simply wrong. Not a single str* function is able to read beyond the buffer, cause the buffer is '\0' terminated and strcmp/strcasecmp whatever will stop there. [2002-02-27 23:42:47] [EMAIL PROTECTED] Fine by me, but the problems are not fixed in CVS. You asked me for more specifics, I gave them to you. [2002-02-27 23:34:49] [EMAIL PROTECTED] The specific memchr()+1 issue is fixed in CVS which was the only useful part of this bug report. We close bugs when they are fixed in CVS, not when we ship releases. [2002-02-27 23:20:44] [EMAIL PROTECTED] It what way is it "fixed"? Every PHP user in the entire world is going to have to download the patches from www.php.net to fix the security hole, and those patches contain this bug. I know that it is fixed in CVS in that the entire file has been replaced, but as I understand it there is no fixed release version. As to the other bugs, just look at the main while() loop in php_mime_split(). Pretty much every call to str* functions (including the very first one) are reading beyond the end of the buffer. If this happens, 'rem' may become negative and even more excitement ensues. [2002-02-27 22:55:48] [EMAIL PROTECTED] True, that bit of code made no sense and has been fixed. The entire thing has been reworked for the 4.2 tree, but if you could expand on the muriad of buffer overflows aside from the memchr()+1 mixup, and submit a useful bug report it would be appreciated. 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/15772 -- Edit this bug report at http://bugs.php.net/?id=15772&edit=1
Bug #15759 Updated: pgsql.c void value not ignored as it ought to be
ID: 15759 Updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] -Status: Open +Status: Feedback Bug Type: Compile Failure Operating System: Solaris 2.8 PHP Version: 4.1.1 New Comment: You have something wrong in your libpq. The line contains something like result = PQputline(.); and PQputline's prototype is int PQputline(PGconn *conn, const char *string); What is your libpq version? (PostgreSQL version?) Previous Comments: [2002-02-27 05:25:22] [EMAIL PROTECTED] Downloaded Apache_1.3.23, PHP_4.1.1 (=matest versions) Env. vars set: INFORMDIR=/home/informix2000 PATH=/home/informix2000/bin:$PATH LD_LIBRARY_PATH=/home/informix2000/lib/esql:$LD_LIBRARY_PATH LIBRARY_PATH=/home/informix2000/lib/esql:$LIBRARY_PATH SQLEXEC= export INFORMIXDIR PATH LD_LIBRARY_PATH LIBRARY_PATH SQLEXEC Unpacked apache-1.3.23, did a # ./configure --prefix=/usr/local/apache_1323 Unpacked php_4.1.1, did a # ./configure --with-apache=/home/wins/cosslocal/src/other/apache_1.3.23 \ --with=pgsql \ --with-informix=/home/informix2000 \ --enable-yp (we have PGSQL in /usr/local/pgsql and INFORMIX2000 up and running) then did a # make ... at the gcc compile of pgsql.c I get: pgsql.c: In function 'zif_pg_put_line': pgsql.c:849: void value not ignored as it ought to be make[3]: *** [pgsql.lo] Error 1 ... I didn't have that error with our previous apache_1.3.14 and PHP4.0.4pl1 compilation (with the same PGSQL and INFORMIX2000) At line 849 in pgsql.c I don't find zif_pg_put_line, substring 'zif' is nowhere in pgsql.c ... Pieter -- Edit this bug report at http://bugs.php.net/?id=15759&edit=1
Bug #15678 Updated: isset fails for 4.1.1 and CVS version
ID: 15678 Updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] -Status: Open +Status: Critical Bug Type: Variables related Operating System: i686-pc-linux-gnu PHP Version: 4.0CVS-2002-02-2 New Comment: This is critical bug in any cases. isset() must not return FALSE when value is not set. This is enough to be a critical bug. This bug is not only hard to find, but also can make security hole in script. Don't you have script relys on isset() to grant access? (Well, I don't have actually since I like everything to be explicit, but some users will have) Previous Comments: [2002-02-27 07:24:00] [EMAIL PROTECTED] not critical [2002-02-23 22:59:43] [EMAIL PROTECTED] It should be fixed before 4.2.0 at least. Hopefully before 4.1.2 :) [2002-02-22 11:41:57] [EMAIL PROTECTED] Btw, this has nothing to do with current CVS. This applies to at least 4.1.0 I tested (so there's nothing broken since current stable and CVS; if it's broken, it is for a long time) [2002-02-22 11:17:03] [EMAIL PROTECTED] Andrey Hristov wrote: >The answer to your question: > var_dump((int) 'y'); >?> ??? this is not the answer of the second question and also not to the first one, because results: "Notice: Undefined offset: 0 in foo.php on line 2" [2002-02-22 11:03:55] [EMAIL PROTECTED] hi, the declaration of a second dimension in a normal array results a strange array content. results: Array ( [c] => boo ) is this a normal behavior? i think this ist completely wrong, because 'd' is not string position 1. Also a normal condition like results true ... but it is absolutely not true i have test it on linux with the lastest cvs tree php version. regards, Steve -- Edit this bug report at http://bugs.php.net/?id=15678&edit=1
Bug #15775: Incomplete tar 4.1.2
From: [EMAIL PROTECTED] Operating system: Any PHP version: 4.1.1 PHP Bug Type: Unknown/Other Function Bug description: Incomplete tar 4.1.2 This is for PHP 4.1.2 and not 4.1.1! I don't know if this is the right address to contact, but here goes: I tried to download php 4.1.2 (for security reasons), but the tar seems incomplete. From several mirrors as well as from the main site, the unpacking fails (gzip crashes -- cannot decompress). Guess you need to put a new tar in place? -- Edit bug report at http://bugs.php.net/?id=15775&edit=1 -- Fixed in CVS:http://bugs.php.net/fix.php?id=15775&r=fixedcvs Fixed in release:http://bugs.php.net/fix.php?id=15775&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=15775&r=needtrace Try newer version: http://bugs.php.net/fix.php?id=15775&r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=15775&r=support Expected behavior: http://bugs.php.net/fix.php?id=15775&r=notwrong Not enough info: http://bugs.php.net/fix.php?id=15775&r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=15775&r=submittedtwice
Bug #15678 Updated: isset fails for 4.1.1 and CVS version
ID: 15678 Updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] Status: Critical Bug Type: Variables related Operating System: i686-pc-linux-gnu PHP Version: 4.0CVS-2002-02-2 New Comment: OOPS. isset() must not return FALSE when value is not set. should be isset() must not return TRUE when value is not set. Previous Comments: [2002-02-28 03:47:28] [EMAIL PROTECTED] This is critical bug in any cases. isset() must not return FALSE when value is not set. This is enough to be a critical bug. This bug is not only hard to find, but also can make security hole in script. Don't you have script relys on isset() to grant access? (Well, I don't have actually since I like everything to be explicit, but some users will have) [2002-02-27 07:24:00] [EMAIL PROTECTED] not critical [2002-02-23 22:59:43] [EMAIL PROTECTED] It should be fixed before 4.2.0 at least. Hopefully before 4.1.2 :) [2002-02-22 11:41:57] [EMAIL PROTECTED] Btw, this has nothing to do with current CVS. This applies to at least 4.1.0 I tested (so there's nothing broken since current stable and CVS; if it's broken, it is for a long time) [2002-02-22 11:17:03] [EMAIL PROTECTED] Andrey Hristov wrote: >The answer to your question: > var_dump((int) 'y'); >?> ??? this is not the answer of the second question and also not to the first one, because results: "Notice: Undefined offset: 0 in foo.php on line 2" 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/15678 -- Edit this bug report at http://bugs.php.net/?id=15678&edit=1
Bug #15775 Updated: Incomplete tar 4.1.2
ID: 15775 Updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] Status: Open Bug Type: Unknown/Other Function Operating System: Any PHP Version: 4.1.1 New Comment: Sorry for the confusion. Must have been some network error at my end. An hour later, the download worked fine.. even from the mirrors. Previous Comments: [2002-02-28 04:16:05] [EMAIL PROTECTED] This is for PHP 4.1.2 and not 4.1.1! I don't know if this is the right address to contact, but here goes: I tried to download php 4.1.2 (for security reasons), but the tar seems incomplete. From several mirrors as well as from the main site, the unpacking fails (gzip crashes -- cannot decompress). Guess you need to put a new tar in place? -- Edit this bug report at http://bugs.php.net/?id=15775&edit=1
Bug #15774 Updated: apache dies immediately after starting
ID: 15774 Updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] -Status: Feedback +Status: Bogus Bug Type: Reproducible crash Operating System: GNU/Linux Debian Potato PHP Version: 4.1.2 New Comment: After working with user on IRC for a while, the problem appears to have been loading a dynamic PHP module in an apache that had a later PHP version builtin. Perhaps there is some way we could watch for this and let the user know what they've dong? Previous Comments: [2002-02-28 03:12:39] [EMAIL PROTECTED] Reopened. You have something wrong. Exit code 0377 is actually a 255(or -1). Apache is exiting without proper exit code set, most likely. I suggest to get rid of module one by one and locate which module is offending module and let us know. [2002-02-28 02:52:35] [EMAIL PROTECTED] Did some more poking in gdb: (gdb) br zend_hash_destroy Breakpoint 1 at 0x813a7c3: file zend_hash.c, line 532. (gdb) r -X Starting program: /usr/local/apache/bin/httpd_new -X Breakpoint 1, zend_hash_destroy (ht=0x81e8ce0) at zend_hash.c:532 532 IS_CONSISTENT(ht); (gdb) n 534 SET_INCONSISTENT(HT_IS_DESTROYING); (gdb) 536 p = ht->pListHead; (gdb) c Continuing. Breakpoint 1, zend_hash_destroy (ht=0x81edb20) at zend_hash.c:532 532 IS_CONSISTENT(ht); (gdb) n 534 SET_INCONSISTENT(HT_IS_DESTROYING); (gdb) 536 p = ht->pListHead; (gdb) c Continuing. Breakpoint 1, zend_hash_destroy (ht=0x81e9c9c) at zend_hash.c:532 532 IS_CONSISTENT(ht); (gdb) c Continuing. Breakpoint 1, zend_hash_destroy (ht=0x81d8c60) at zend_hash.c:532 532 IS_CONSISTENT(ht); (gdb) c Continuing. Breakpoint 1, zend_hash_destroy (ht=0x81ea7b4) at zend_hash.c:532 532 IS_CONSISTENT(ht); (gdb) c Continuing. Breakpoint 1, zend_hash_destroy (ht=0x81ea788) at zend_hash.c:532 532 IS_CONSISTENT(ht); (gdb) d Delete all breakpoints? (y or n) n (gdb) c Continuing. Breakpoint 1, zend_hash_destroy (ht=0x82059b8) at zend_hash.c:532 532 IS_CONSISTENT(ht); (gdb) c Continuing. Breakpoint 1, zend_hash_destroy (ht=0x82059e8) at zend_hash.c:532 532 IS_CONSISTENT(ht); (gdb) watch 0x081d8860 Watchpoint 2: 136153184 (gdb) c Continuing. Breakpoint 1, zend_hash_destroy (ht=0x8205d58) at zend_hash.c:532 532 IS_CONSISTENT(ht); (gdb) c Continuing. Breakpoint 1, zend_hash_destroy (ht=0x8205d84) at zend_hash.c:532 532 IS_CONSISTENT(ht); (gdb) c Continuing. Breakpoint 1, zend_hash_destroy (ht=0x820e8b0) at zend_hash.c:532 532 IS_CONSISTENT(ht); (gdb) clear zend_hash_destroy Deleted breakpoint 1 (gdb) c Continuing. Program exited with code 0377. (gdb) quit Not a very useful error... if this is user error, it isn't very obvious what is wrong. [2002-02-28 02:50:07] [EMAIL PROTECTED] Actually, I was running 4.0.6 before this upgrade, not 4.1.1, but I did use the same configuration options that I used from 4.0.6 (I always save my ./configure options so that I can recreate them). [2002-02-28 02:43:31] [EMAIL PROTECTED] This is what I am using for my apache configuration: ./configure \ --prefix=/usr/local/apache \ --enable-module=unique_id \ --enable-module=rewrite \ --enable-module=speling \ --enable-module=expires \ --enable-module=info \ --enable-module=log_agent \ --enable-module=log_referer \ --enable-module=so \ --logfiledir=/var/log/apache \ --activate-module=src/modules/php4/libphp4.a \ --enable-module=vhost_alias This is what I am using for my php configuration: ./configure \ --prefix=/usr/local/php \ --with-apache=../apache_1.3.23 \ --enable-ftp \ --with-xml \ --enable-track-vars \ --with-mysql=/usr/local/mysql \ --with-pgsql=/usr/local/pgsql/ \ --enable-debug \--with-config-file-path=/usr/local/php/lib also, ran gdb and did a little poking around: (gdb) br zend_hash_destroy Breakpoint 1 at 0x813a7c3: file zend_hash.c, line 532. (gdb) r -X Starting program: /usr/local/apache/bin/httpd_new -X Breakpoint 1, zend_hash_destroy (ht=0x81e8ce0) at zend_hash.c:532 532 IS_CONSISTENT(ht); (gdb) n 534 SET_INCONSISTENT(HT_IS_DESTROYING); (gdb) 536 p = ht->pListHead; (gdb) c Continuing. Breakpoint 1, zend_hash_destroy (ht=0x81edb20) at zend_hash.c:532 532 IS_CONSISTENT(ht); (gdb) n 534 SET_INCONSISTENT(HT_IS_DESTROYING); (gdb) 536 p = ht->pListHead; (gdb) c Continuing. Breakpoint 1, zend_hash_destroy (ht=0x81e9c9c) at zend_has
Bug #15759 Updated: pgsql.c void value not ignored as it ought to be
ID: 15759 Updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] Status: Feedback Bug Type: Compile Failure Operating System: Solaris 2.8 PHP Version: 4.1.1 New Comment: My PostgreSQL is indeed rather old (version 6.3.2) but so far it always worked well. A newer version (7.2 latest) will probably force me to setup a new database of users etc... Would there be another work arround ? Pieter Previous Comments: [2002-02-28 03:28:27] [EMAIL PROTECTED] You have something wrong in your libpq. The line contains something like result = PQputline(.); and PQputline's prototype is int PQputline(PGconn *conn, const char *string); What is your libpq version? (PostgreSQL version?) [2002-02-27 05:25:22] [EMAIL PROTECTED] Downloaded Apache_1.3.23, PHP_4.1.1 (=matest versions) Env. vars set: INFORMDIR=/home/informix2000 PATH=/home/informix2000/bin:$PATH LD_LIBRARY_PATH=/home/informix2000/lib/esql:$LD_LIBRARY_PATH LIBRARY_PATH=/home/informix2000/lib/esql:$LIBRARY_PATH SQLEXEC= export INFORMIXDIR PATH LD_LIBRARY_PATH LIBRARY_PATH SQLEXEC Unpacked apache-1.3.23, did a # ./configure --prefix=/usr/local/apache_1323 Unpacked php_4.1.1, did a # ./configure --with-apache=/home/wins/cosslocal/src/other/apache_1.3.23 \ --with=pgsql \ --with-informix=/home/informix2000 \ --enable-yp (we have PGSQL in /usr/local/pgsql and INFORMIX2000 up and running) then did a # make ... at the gcc compile of pgsql.c I get: pgsql.c: In function 'zif_pg_put_line': pgsql.c:849: void value not ignored as it ought to be make[3]: *** [pgsql.lo] Error 1 ... I didn't have that error with our previous apache_1.3.14 and PHP4.0.4pl1 compilation (with the same PGSQL and INFORMIX2000) At line 849 in pgsql.c I don't find zif_pg_put_line, substring 'zif' is nowhere in pgsql.c ... Pieter -- Edit this bug report at http://bugs.php.net/?id=15759&edit=1
Bug #15775 Updated: Incomplete tar 4.1.2
ID: 15775 Updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] -Status: Open +Status: Bogus Bug Type: Unknown/Other Function Operating System: Any PHP Version: 4.1.1 Previous Comments: [2002-02-28 04:33:40] [EMAIL PROTECTED] Sorry for the confusion. Must have been some network error at my end. An hour later, the download worked fine.. even from the mirrors. [2002-02-28 04:16:05] [EMAIL PROTECTED] This is for PHP 4.1.2 and not 4.1.1! I don't know if this is the right address to contact, but here goes: I tried to download php 4.1.2 (for security reasons), but the tar seems incomplete. From several mirrors as well as from the main site, the unpacking fails (gzip crashes -- cannot decompress). Guess you need to put a new tar in place? -- Edit this bug report at http://bugs.php.net/?id=15775&edit=1
Bug #15619 Updated: odbc_result() doesn't return ms sql server text field correctly
ID: 15619 Updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] Status: Open Bug Type: ODBC related Operating System: Win2k Pro/Adv Server PHP Version: 4.1.1 New Comment: The Problem is also there with text fields and Informix 7.2 (Sparc). We tried the generic ODBC Drivers and the Merant Drivers (Ad. W2k Server, Apache, PHP 4.1.1). It must be a general problem with text-fields. Selecting only other than text colums will go around the problem. Alex Previous Comments: [2002-02-19 11:12:16] [EMAIL PROTECTED] No - this is with text type fields. I just tried it with ntext and php just crashes. (using mssql functions text works fine and ntext gives an error todo with unicode). I'm using the isapi dll btw. [2002-02-19 10:49:58] [EMAIL PROTECTED] Is your text field of type 'ntext'? [2002-02-19 06:52:40] [EMAIL PROTECTED] Using odbc functions with MS SQL Server 2k, using odbc_exec() with a select query to fill a result set. Fields of type varchar are returned successfully, but text fields behave strangely. When doing: $someField = odbc_result($resID, "textField"); the value of the field seems to be echoed, and $someField is given the value '1'. Changing the field type to varchar in SQL Server (and changing no php code), it returns to the expected behaviour (value of the field assigned to $someField). I've got the same behavior on 2 different installs of php, one running w2k pro with local sql server and one w2k adv server and remote sql server. Ed Eastman -- Edit this bug report at http://bugs.php.net/?id=15619&edit=1
Bug #15772 Updated: PHP is developed and maintained by morons
ID: 15772 Updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] Status: Closed Bug Type: *General Issues Operating System: all PHP Version: 4.0.6 New Comment: I'll admit that I did not examine the rest of the program to see if the buffer was '\0'-terminated, however if it is, it's not just me that thought it wasn't - whoever wrote the routine thought it wasn't either. Otherwise there wouldn't even be any point in passing the buffer length to the function, or the main loop's "while (ptr - buf < cnt)" or indeed half the function. As to providing patches, I know from experience that what you tend to do with them is ignore them, insult them, re-write them badly and apply them six months later, and then fail to credit. Plus I see no point in providing band-aids in a futile attempt to cover the gaping wounds in PHP. I *can* give you the fix I recommend to people for PHP, however, which is 'rm -rf php-*' ;-) Previous Comments: [2002-02-28 03:21:22] [EMAIL PROTECTED] We can search and fix what's wrong if there is a bug description, but it would nice if you could post patch to php-dev directly. We know PHP has many bugs and appreciate patches fixes bugs. You have skills, right :) [2002-02-28 03:02:27] [EMAIL PROTECTED] Your claims are simply wrong. Not a single str* function is able to read beyond the buffer, cause the buffer is '\0' terminated and strcmp/strcasecmp whatever will stop there. [2002-02-27 23:42:47] [EMAIL PROTECTED] Fine by me, but the problems are not fixed in CVS. You asked me for more specifics, I gave them to you. [2002-02-27 23:34:49] [EMAIL PROTECTED] The specific memchr()+1 issue is fixed in CVS which was the only useful part of this bug report. We close bugs when they are fixed in CVS, not when we ship releases. [2002-02-27 23:20:44] [EMAIL PROTECTED] It what way is it "fixed"? Every PHP user in the entire world is going to have to download the patches from www.php.net to fix the security hole, and those patches contain this bug. I know that it is fixed in CVS in that the entire file has been replaced, but as I understand it there is no fixed release version. As to the other bugs, just look at the main while() loop in php_mime_split(). Pretty much every call to str* functions (including the very first one) are reading beyond the end of the buffer. If this happens, 'rem' may become negative and even more excitement ensues. 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/15772 -- Edit this bug report at http://bugs.php.net/?id=15772&edit=1
Bug #15772 Updated: PHP is developed and maintained by morons
ID: 15772 Updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] Status: Closed Bug Type: *General Issues Operating System: all PHP Version: 4.0.6 New Comment: You are again wrong, cnt must be supplied. I advise you to think before you speak. A POST fileupload block can have lots of '\0's in it. Without the number of bytes it would be impossibe to handle such a block. Previous Comments: [2002-02-28 04:59:29] [EMAIL PROTECTED] I'll admit that I did not examine the rest of the program to see if the buffer was '\0'-terminated, however if it is, it's not just me that thought it wasn't - whoever wrote the routine thought it wasn't either. Otherwise there wouldn't even be any point in passing the buffer length to the function, or the main loop's "while (ptr - buf < cnt)" or indeed half the function. As to providing patches, I know from experience that what you tend to do with them is ignore them, insult them, re-write them badly and apply them six months later, and then fail to credit. Plus I see no point in providing band-aids in a futile attempt to cover the gaping wounds in PHP. I *can* give you the fix I recommend to people for PHP, however, which is 'rm -rf php-*' ;-) [2002-02-28 03:21:22] [EMAIL PROTECTED] We can search and fix what's wrong if there is a bug description, but it would nice if you could post patch to php-dev directly. We know PHP has many bugs and appreciate patches fixes bugs. You have skills, right :) [2002-02-28 03:02:27] [EMAIL PROTECTED] Your claims are simply wrong. Not a single str* function is able to read beyond the buffer, cause the buffer is '\0' terminated and strcmp/strcasecmp whatever will stop there. [2002-02-27 23:42:47] [EMAIL PROTECTED] Fine by me, but the problems are not fixed in CVS. You asked me for more specifics, I gave them to you. [2002-02-27 23:34:49] [EMAIL PROTECTED] The specific memchr()+1 issue is fixed in CVS which was the only useful part of this bug report. We close bugs when they are fixed in CVS, not when we ship releases. 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/15772 -- Edit this bug report at http://bugs.php.net/?id=15772&edit=1
Bug #15776: imap compile failure
From: [EMAIL PROTECTED] Operating system: Red Hat 6.2 PHP version: 4.1.1 PHP Bug Type: Compile Failure Bug description: imap compile failure First off, I've tried this using PHP4.0.6, the compile works okay with this earlier version (all other software reported below was used with 4.0.6). The problem occurs under the following conditions:- Software Versions: == Distro: RH6.2 Kernel: 2.2.19-6.2.12 PHP: 4.1.1 Cyrus IMAP: 2.0.16 UW imap client: imap-2001a Apache: 1.3.23 MySQL: 3.23.49 Configure: == My configure script is as follows:- ./configure --with-mysql=/usr/local/mysql --with-apxs=/usr/local/apache/bin/ apxs --with-cyrus --with-openssl --with-imap-ssl --with-zlib --with-gdbm=/us r/include/gdbm --with-imap=/usr/local/uw-imap configure runs to completion i.e. doesn't complain about not being able to find something it expects. Make: = Originally I had some problems with cyrus.c, but a trawl through the bugs on bugs.php.net furnished an up-to-date version which no longer causes any probs. Make eventually fails with the following:- make[1]: Entering directory `/usr/local/src/php-4.1.1.p1' /bin/sh /usr/local/src/php-4.1.1.p1/libtool --silent --mode=compile gcc -I. -I/usr/local/src/php-4.1.1.p1/ -I/usr/local/src/php-4.1 .1.p1/main -I/usr/local/src/php-4.1.1.p1 -I/usr/local/apache/include -I/usr/ local/src/php-4.1.1.p1/Zend -I/usr/local/include -I/usr/ local/uw-imap/c-client -I/usr/local/mysql/include/mysql -I/usr/local/src/php -4.1.1.p1/ext/xml/expat -DLINUX=22 -DUSE_HSREGEX -DUSE_ EXPAT -I/usr/local/src/php-4.1.1.p1/TSRM -g -O2 -prefer-pic -c stub.c /bin/sh /usr/local/src/php-4.1.1.p1/libtool --silent --mode=link gcc -I. -I/usr/local/src/php-4.1.1.p1/ -I/usr/local/src/php-4.1.1. p1/main -I/usr/local/src/php-4.1.1.p1 -I/usr/local/apache/include -I/usr/loc al/src/php-4.1.1.p1/Zend -I/usr/local/include -I/usr/loc al/uw-imap/c-client -I/usr/local/mysql/include/mysql -I/usr/local/src/php-4. 1.1.p1/ext/xml/expat -DLINUX=22 -DUSE_HSREGEX -DUSE_EXP AT -I/usr/local/src/php-4.1.1.p1/TSRM -g -O2 -prefer-pic -o libphp4.la -rpath /usr/local/src/php-4.1.1.p1/libs -avoid-version -L/u sr/local/lib -L/usr/local/uw-imap/c-client -L/usr/local/mysql/lib/mysql -R /usr/local/lib -R /usr/local/uw-imap/c-client -R /usr/lo cal/mysql/lib/mysql stub.lo Zend/libZend.la sapi/apache/libsapi.la main/libmain.la regex/libregex.la ext/zlib/libzlib.la ext/cyrus/ libcyrus.la ext/dba/libdba.la ext/imap/libimap.la ext/mysql/libmysql.la ext/openssl/libopenssl.la ext/pcre/libpcre.la ext/posix/libp osix.la ext/session/libsession.la ext/standard/libstandard.la ext/xml/libxml.la TSRM/libtsrm.la -lpam -lcrypto -lssl -lc-client4 -ld l -lmysqlclient -lz -lcrypt -lpam -lgdbm -lcyrus -lsasl -lz -lcrypt -lssl -l crypto -lresolv -lm -ldl -lnsl -lresolv -lcrypt libtool: link: warning: library `/usr/lib/libgdbm.la' was moved. libtool: link: warning: library `/usr/lib/libgdbm.la' was moved. /usr/local/uw-imap/c-client/libc-client4.a(osdep.o): In function `fatal': /usr/local/src/imap-2001a/c-client/ftl_unix.c:27: multiple definition of `fatal' ext/cyrus/.libs/libcyrus.al(cyrus.lo):/usr/local/src/php-4.1.1.p1/ext/cyrus/ cyrus.c:110: first defined here /usr/local/lib/libcyrus.a(xmalloc.o): In function `fs_get': xmalloc.o(.text+0xf8): multiple definition of `fs_get' /usr/local/uw-imap/c-client/libc-client4.a(osdep.o):/usr/local/src/imap-2001 a/c-client/fs_unix.c:27: first defined here /usr/bin/ld: Warning: size of symbol `fs_get' changed from 90 to 32 in xmalloc.o /usr/local/lib/libcyrus.a(xmalloc.o): In function `fs_give': xmalloc.o(.text+0x118): multiple definition of `fs_give' /usr/local/uw-imap/c-client/libc-client4.a(osdep.o):/usr/local/src/imap-2001 a/c-client/fs_unix.c:57: first defined here /usr/bin/ld: Warning: size of symbol `fs_give' changed from 59 to 25 in xmalloc.o collect2: ld returned 1 exit status make[1]: *** [libphp4.la] Error 1 make[1]: Leaving directory `/usr/local/src/php-4.1.1.p1' make: *** [all-recursive] Error 1 -- Edit bug report at http://bugs.php.net/?id=15776&edit=1 -- Fixed in CVS:http://bugs.php.net/fix.php?id=15776&r=fixedcvs Fixed in release:http://bugs.php.net/fix.php?id=15776&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=15776&r=needtrace Try newer version: http://bugs.php.net/fix.php?id=15776&r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=15776&r=support Expected behavior: http://bugs.php.net/fix.php?id=15776&r=notwrong Not enough info: http://bugs.php.net/fix.php?id=15776&r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=15776&r=submittedtwice
Bug #15777: REMOTE_USER
From: [EMAIL PROTECTED] Operating system: Solaris PHP version: 4.1.2 PHP Bug Type: Documentation problem Bug description: REMOTE_USER anyone know when REMOTE_USER is not empty? Tried to capture it in a Solaris/Apache server, only got REMOTE_ADDR pointed to the remote IP, REMOTE_USER always empty, tried it in perl, in PHP, always failed to get anything. Are these controled by my local windows/browsers or apache in the server? -- Edit bug report at http://bugs.php.net/?id=15777&edit=1 -- Fixed in CVS:http://bugs.php.net/fix.php?id=15777&r=fixedcvs Fixed in release:http://bugs.php.net/fix.php?id=15777&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=15777&r=needtrace Try newer version: http://bugs.php.net/fix.php?id=15777&r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=15777&r=support Expected behavior: http://bugs.php.net/fix.php?id=15777&r=notwrong Not enough info: http://bugs.php.net/fix.php?id=15777&r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=15777&r=submittedtwice
Bug #15777 Updated: REMOTE_USER
ID: 15777 Updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] -Status: Open +Status: Bogus Bug Type: Documentation problem Operating System: Solaris PHP Version: 4.1.2 New Comment: The bug system is not the appropriate forum for asking support questions. For a list of a range of more appropriate places to ask for help using PHP, please visit http://www.php.net/support.php Previous Comments: [2002-02-28 05:19:25] [EMAIL PROTECTED] anyone know when REMOTE_USER is not empty? Tried to capture it in a Solaris/Apache server, only got REMOTE_ADDR pointed to the remote IP, REMOTE_USER always empty, tried it in perl, in PHP, always failed to get anything. Are these controled by my local windows/browsers or apache in the server? -- Edit this bug report at http://bugs.php.net/?id=15777&edit=1
Bug #15251 Updated: Cannot upload one file but two files
ID: 15251 Updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] -Status: Feedback +Status: Analyzed -Bug Type: HTTP related +Bug Type: Output Control Operating System: Linux -PHP Version: 4.2.0 2002-02-07 +PHP Version: 4.3.0-dev New Comment: Test with today's CVS source, the same result :( BTW, sample script is missing ";", but you know it's a typo :) This is actually a related to output buffering. reclassified as output control problem. I cannot upload one file only when zlib.compression is used. (I haven't tried ob_gzhandler) Previous Comments: [2002-02-27 07:47:16] [EMAIL PROTECTED] Can you provide me with script for me to reproduce it? Derick [2002-02-07 20:10:23] [EMAIL PROTECTED] I forgot to memtion apache error log with a single file upload Unknown(0) : Warning - No file uploaded BTW, I usually test both IE and Mozilla(Linux) latest The same result. Assign to me for now. [2002-02-07 08:25:39] [EMAIL PROTECTED] Status -> Feedback [2002-02-07 07:17:02] [EMAIL PROTECTED] Hmmm tjo, you know the procedure... 1) Can you try it with IE5.5? 2) Is this exact the script you used? (remember the ;) 3) what is your config.nice (cause i wasnt able to reproduce) with my plain installation [2002-02-07 05:52:31] [EMAIL PROTECTED] Oops. Problem still exists :( 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/15251 -- Edit this bug report at http://bugs.php.net/?id=15251&edit=1
Bug #15750 Updated: reset() resets nested arrays too
ID: 15750 Updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] -Status: Open +Status: Bogus Bug Type: Arrays related Operating System: FreeBSD-4.3 PHP Version: 4.0.6 New Comment: Sorry. We don't fix bugs for 4.0.6. It works as expected for current CVS. and 4.1.2. Use 4.1.2 ;) Previous Comments: [2002-02-27 01:16:02] [EMAIL PROTECTED] Thais kind of error does NOT occur at PHP4.1 for Win32, but I have no opportunity to check it at the same version PHP for FreeBSD. Example: That scrips produces "1 4 2 5 " at PHP4.1.0@Win32 but "1 4 1 4" at [EMAIL PROTECTED] -- Edit this bug report at http://bugs.php.net/?id=15750&edit=1
Bug #9694 Updated: module not found
ID: 9694 Updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] Status: Closed Bug Type: IIS related Operating System: WinNT4 PHP Version: 4.0.2 New Comment: Kea, Most likely not a bug. Ask support question to php-general or php-install lists. Previous Comments: [2002-02-27 01:08:12] [EMAIL PROTECTED] I try to connect a mssql database and get the error: X-Powered-By: PHP/4.1.1 Content-type: text/html PHP Warning: Unable to load dynamic library 'C:\Inetpub\php\dlls/php_mssql.dll' - Das angegebene Modul wurde nicht gefunden. in Unknown on line 0 PHP Fatal error: Call to undefined function: mssql_connect() in c:\inetpub\wwwroot\dbconnection\dbconnection.php on line 3 I think the problem is the slash 'c:\blabla/php_mssql.dll'. [2001-06-12 10:51:17] [EMAIL PROTECTED] if php reports so, it'll most likely be that way :) in newer versions there's only one mssql extension (php_mssql.dll) left. also check the php_mssql.dll dependencies with http://www.dependencywalker.com [2001-03-12 02:53:26] [EMAIL PROTECTED] Hai.. try to connect to mssql and got this error Unable to load dynamic library `d:\php402/php_mssql70.dll'- The specified module could not be found. Here are my configuration in php.ini Path and directories; ... extension_dir = d:\php402;./ Dynamic extension; ... ;Windows Extensions ;extension=php_nsmail.dll ;extension=php_calendar.dll ;extension=php_dbase.dll ;extension=php_filepro.dll ;extension=php_gd.dll ;extension=php_dbm.dll ;extension=php_mssql.dll ;extension=php_zlib.dll ;extension=php_filepro.dll ;extension=php_imap4r2.dll ;extension=php_ldap.dll extension=php_mssql70.dll ;extension=php_crypt.dll ;extension=php_msql2.dll ;extension=php_odbc.dll [2001-03-12 01:51:07] [EMAIL PROTECTED] Hai.. Try to do a mssql connect and get this error Unable to load dynamic library `d:\php402/php_mssql70.dll'.The specified module could not be found. Thanks. -- Edit this bug report at http://bugs.php.net/?id=9694&edit=1
Bug #15769 Updated: php-4.0 crypt("abc") != php-4.1 crypt("abc")
ID: 15769
Updated by: [EMAIL PROTECTED]
-Summary: php-4.0 crypt("abc") != php-4.1 crypt("abc")
Reported By: [EMAIL PROTECTED]
Status: Bogus
Bug Type: *Encryption and hash functions
Operating System: linux
PHP Version: 4.1.1
New Comment:
from the docs:
> If no salt is provided, PHP will auto-generate a standard > 2
character salt by default, unless the default encryption
> type on the system is MD5, in which case a random
> MD5-compatible salt is generated.
well, the "default encryption type" on the system has not changed
between upgrade from 4.0 to 4.1, so why does the crypt behaviour change
on the way? I really see that as a bug, or please tell me how to revert
to the "normal" crypt (DES). Saw no options in the ./configure as
well... :/
Previous Comments:
[2002-02-28 02:09:06] [EMAIL PROTECTED]
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
http://www.php.net/manual/en/function.crypt.php
[2002-02-28 02:08:38] [EMAIL PROTECTED]
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
[2002-02-27 19:53:56] [EMAIL PROTECTED]
On the same system after upgrade, the result of crypt with only one
arguments has another format: before (php 4.0.6) it was the standard 13
chars string, and now this md5-like hash is comming:
"$1$ngOfu9A.$AoUUzzXjwxQiqKq7c2wDt1"...
Shouldn't the default behaviour of crypt() stay the same on a specific
system ? This way it breaks a lots of customers scripts on the web
server on upgrade, and this is *very* annoying. (no, I can't tell all
people: rewrite all your scripts and use 2 args with the crypt
command).
Isn't there a way to tell at compliation time: crypt() defaults to DES?
Regards,
Olivier
--
Edit this bug report at http://bugs.php.net/?id=15769&edit=1
Bug #15774 Updated: apache dies immediately after starting
ID: 15774 Updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] Status: Bogus Bug Type: Reproducible crash Operating System: GNU/Linux Debian Potato PHP Version: 4.1.2 New Comment: I hope apache detects the misconfiguration and print nice error, too :) Previous Comments: [2002-02-28 04:35:33] [EMAIL PROTECTED] After working with user on IRC for a while, the problem appears to have been loading a dynamic PHP module in an apache that had a later PHP version builtin. Perhaps there is some way we could watch for this and let the user know what they've dong? [2002-02-28 03:12:39] [EMAIL PROTECTED] Reopened. You have something wrong. Exit code 0377 is actually a 255(or -1). Apache is exiting without proper exit code set, most likely. I suggest to get rid of module one by one and locate which module is offending module and let us know. [2002-02-28 02:52:35] [EMAIL PROTECTED] Did some more poking in gdb: (gdb) br zend_hash_destroy Breakpoint 1 at 0x813a7c3: file zend_hash.c, line 532. (gdb) r -X Starting program: /usr/local/apache/bin/httpd_new -X Breakpoint 1, zend_hash_destroy (ht=0x81e8ce0) at zend_hash.c:532 532 IS_CONSISTENT(ht); (gdb) n 534 SET_INCONSISTENT(HT_IS_DESTROYING); (gdb) 536 p = ht->pListHead; (gdb) c Continuing. Breakpoint 1, zend_hash_destroy (ht=0x81edb20) at zend_hash.c:532 532 IS_CONSISTENT(ht); (gdb) n 534 SET_INCONSISTENT(HT_IS_DESTROYING); (gdb) 536 p = ht->pListHead; (gdb) c Continuing. Breakpoint 1, zend_hash_destroy (ht=0x81e9c9c) at zend_hash.c:532 532 IS_CONSISTENT(ht); (gdb) c Continuing. Breakpoint 1, zend_hash_destroy (ht=0x81d8c60) at zend_hash.c:532 532 IS_CONSISTENT(ht); (gdb) c Continuing. Breakpoint 1, zend_hash_destroy (ht=0x81ea7b4) at zend_hash.c:532 532 IS_CONSISTENT(ht); (gdb) c Continuing. Breakpoint 1, zend_hash_destroy (ht=0x81ea788) at zend_hash.c:532 532 IS_CONSISTENT(ht); (gdb) d Delete all breakpoints? (y or n) n (gdb) c Continuing. Breakpoint 1, zend_hash_destroy (ht=0x82059b8) at zend_hash.c:532 532 IS_CONSISTENT(ht); (gdb) c Continuing. Breakpoint 1, zend_hash_destroy (ht=0x82059e8) at zend_hash.c:532 532 IS_CONSISTENT(ht); (gdb) watch 0x081d8860 Watchpoint 2: 136153184 (gdb) c Continuing. Breakpoint 1, zend_hash_destroy (ht=0x8205d58) at zend_hash.c:532 532 IS_CONSISTENT(ht); (gdb) c Continuing. Breakpoint 1, zend_hash_destroy (ht=0x8205d84) at zend_hash.c:532 532 IS_CONSISTENT(ht); (gdb) c Continuing. Breakpoint 1, zend_hash_destroy (ht=0x820e8b0) at zend_hash.c:532 532 IS_CONSISTENT(ht); (gdb) clear zend_hash_destroy Deleted breakpoint 1 (gdb) c Continuing. Program exited with code 0377. (gdb) quit Not a very useful error... if this is user error, it isn't very obvious what is wrong. [2002-02-28 02:50:07] [EMAIL PROTECTED] Actually, I was running 4.0.6 before this upgrade, not 4.1.1, but I did use the same configuration options that I used from 4.0.6 (I always save my ./configure options so that I can recreate them). [2002-02-28 02:43:31] [EMAIL PROTECTED] This is what I am using for my apache configuration: ./configure \ --prefix=/usr/local/apache \ --enable-module=unique_id \ --enable-module=rewrite \ --enable-module=speling \ --enable-module=expires \ --enable-module=info \ --enable-module=log_agent \ --enable-module=log_referer \ --enable-module=so \ --logfiledir=/var/log/apache \ --activate-module=src/modules/php4/libphp4.a \ --enable-module=vhost_alias This is what I am using for my php configuration: ./configure \ --prefix=/usr/local/php \ --with-apache=../apache_1.3.23 \ --enable-ftp \ --with-xml \ --enable-track-vars \ --with-mysql=/usr/local/mysql \ --with-pgsql=/usr/local/pgsql/ \ --enable-debug \--with-config-file-path=/usr/local/php/lib also, ran gdb and did a little poking around: (gdb) br zend_hash_destroy Breakpoint 1 at 0x813a7c3: file zend_hash.c, line 532. (gdb) r -X Starting program: /usr/local/apache/bin/httpd_new -X Breakpoint 1, zend_hash_destroy (ht=0x81e8ce0) at zend_hash.c:532 532 IS_CONSISTENT(ht); (gdb) n 534 SET_INCONSISTENT(HT_IS_DESTROYING); (gdb) 536 p = ht->pListHead; (gdb) c Continuing. Breakpoint 1, zend_hash_destroy (ht=0x81edb20) at zend_hash.c:532 532 IS_CONSISTENT(ht); (gdb) n 534 SET
Bug #15778: Segmentation Fault with iPlanet module on php4_init
From: [EMAIL PROTECTED] Operating system: AIX 4.3.3 PHP version: 4.1.2 PHP Bug Type: Reproducible crash Bug description: Segmentation Fault with iPlanet module on php4_init When I compile PHP as an iPlanet module, the httpd server crashes on loading the module (php4_init) with a signal 11/segmentation fault. I get the same behaviour with php 4.1.1 and with 4.1.2. (output below is from 4.1.2) When compiling as a commandline executable, everything seems to work fine though, so I guess its a problem with iPlanet and maybe in combination with AIX 4.3.3 and shared libraries. I compiled using GCC, not AIX's 'native' compiler. If more information is needed to address this issue, please let me know. Please be aware though, that even though I am decently skilled in *nix administration, I have no programming or debugging skills, so please provide 'idiot instructions' ;) The configure line I used: ./configure --with-nsapi=/appl/netscape4/server4 --prefix=/appl/php -exec-prefix=/appl/php --enable-debug The output of gdb (bt): # gdb /appl/netscape4/server4/bin/https/bin/ns-httpd /appl/netscape4/server4/https-splu9029/config/config/core GNU gdb 5.0 Copyright 2000 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 "powerpc-ibm-aix4.3.2.0"...(no debugging symbols found)... Core was generated by `ns-httpd'. Program terminated with signal 11, Segmentation fault. (no debugging symbols found)...#0 0xd1541508 in php4_init (pb=0x5, sn=0x0, rq=0x0) at nsapi.c:492 492 log_error(LOG_INFORM, "php4_init", sn, rq, "Initialized PHP Module\n"); (gdb) bt #0 0xd1541508 in php4_init (pb=0x5, sn=0x0, rq=0x0) at nsapi.c:492 #1 0xd0d9aca8 in func_native_pool_wait_work () #2 0xd0d9bd88 in func_exec_str () #3 0xd0d9b2b4 in INTfunc_exec () #4 0xd0d8eea0 in INTconf_run_late_init_functions () #5 0xd0e11d50 in DaemonProcessorUX::__ct () #6 0xd0e105fc in DaemonProcessor::NewDaemonProcessor () #7 0xd0e41640 in daemon_run () #8 0x10001bac in ?? () from /appl/netscape4/server4/bin/https/bin/ns-httpd -- Edit bug report at http://bugs.php.net/?id=15778&edit=1 -- Fixed in CVS:http://bugs.php.net/fix.php?id=15778&r=fixedcvs Fixed in release:http://bugs.php.net/fix.php?id=15778&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=15778&r=needtrace Try newer version: http://bugs.php.net/fix.php?id=15778&r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=15778&r=support Expected behavior: http://bugs.php.net/fix.php?id=15778&r=notwrong Not enough info: http://bugs.php.net/fix.php?id=15778&r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=15778&r=submittedtwice
Bug #15778 Updated: Segmentation Fault with iPlanet module on php4_init
ID: 15778 Updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] Status: Open Bug Type: Reproducible crash Operating System: AIX 4.3.3 PHP Version: 4.1.2 New Comment: As a test, Ive tried compiling the same version of PHP in combination with the same version of iPlanet on my linux system, and everything seems to work fine on my linux box. So I guess this only occurs in combination with AIX. Previous Comments: [2002-02-28 06:04:27] [EMAIL PROTECTED] When I compile PHP as an iPlanet module, the httpd server crashes on loading the module (php4_init) with a signal 11/segmentation fault. I get the same behaviour with php 4.1.1 and with 4.1.2. (output below is from 4.1.2) When compiling as a commandline executable, everything seems to work fine though, so I guess its a problem with iPlanet and maybe in combination with AIX 4.3.3 and shared libraries. I compiled using GCC, not AIX's 'native' compiler. If more information is needed to address this issue, please let me know. Please be aware though, that even though I am decently skilled in *nix administration, I have no programming or debugging skills, so please provide 'idiot instructions' ;) The configure line I used: ./configure --with-nsapi=/appl/netscape4/server4 --prefix=/appl/php -exec-prefix=/appl/php --enable-debug The output of gdb (bt): # gdb /appl/netscape4/server4/bin/https/bin/ns-httpd /appl/netscape4/server4/https-splu9029/config/config/core GNU gdb 5.0 Copyright 2000 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 "powerpc-ibm-aix4.3.2.0"...(no debugging symbols found)... Core was generated by `ns-httpd'. Program terminated with signal 11, Segmentation fault. (no debugging symbols found)...#0 0xd1541508 in php4_init (pb=0x5, sn=0x0, rq=0x0) at nsapi.c:492 492 log_error(LOG_INFORM, "php4_init", sn, rq, "Initialized PHP Module\n"); (gdb) bt #0 0xd1541508 in php4_init (pb=0x5, sn=0x0, rq=0x0) at nsapi.c:492 #1 0xd0d9aca8 in func_native_pool_wait_work () #2 0xd0d9bd88 in func_exec_str () #3 0xd0d9b2b4 in INTfunc_exec () #4 0xd0d8eea0 in INTconf_run_late_init_functions () #5 0xd0e11d50 in DaemonProcessorUX::__ct () #6 0xd0e105fc in DaemonProcessor::NewDaemonProcessor () #7 0xd0e41640 in daemon_run () #8 0x10001bac in ?? () from /appl/netscape4/server4/bin/https/bin/ns-httpd -- Edit this bug report at http://bugs.php.net/?id=15778&edit=1
Bug #14883 Updated: Remote vulnerability allows access to ALL files on webserver
ID: 14883 Updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] Status: Open Bug Type: Apache related Operating System: Windows NT (all Win32) PHP Version: 4.1.1 New Comment: Actually, this exploit allows anyone to gain root access to the Machine and so the severity should be ugraded to High. Previous Comments: [2002-01-06 02:12:42] [EMAIL PROTECTED] Report yesterday (4 Jan 02) at http://www.securiteam.com/windowsntfocus/5ZP030U60U.html outlines the security hole. I have tested it on NT4, Apache 1.3.9, PHP 4.0.4 and then upgraded to NT4, Apache 1.3.22, PHP 4.1.1 and the problem remains. I've been monitoring the PHP newsgroups (announcements and Windows user lists) since the vulnerability was announced and searched the buglist but haven't found mention of it anywhere. -- Edit this bug report at http://bugs.php.net/?id=14883&edit=1
Bug #15779: Warning: Failed opening '/usr/local/lib/php/bbph_smtp.php' for inclusion (inclu
From: [EMAIL PROTECTED]
Operating system: Tru 64 Sun Solaris Unix
PHP version: 4.1.2
PHP Bug Type: Scripting Engine problem
Bug description: Warning: Failed opening '/usr/local/lib/php/bbph_smtp.php' for
inclusion (inclu
Whenever I open our client webpage and view the recommendation and
quotation links that uses php, I get below error:
Warning: Failed opening '/usr/local/lib/php/bbph_smtp.php' for inclusion
(include_path='/usr/local/lib') in
/usr/data/ftp/info/Forms/List/recommend.php on line 2
We have install/ run a script on our server that uses smtp.pph and we
instruct our client to include the "bbph_smtp.php" script on their
phpscripts that will call this function:
the syntax is:
bbphmail (string to, string subject, string message [,string
additional_headers]);
the command is:
include ("bbph_smtp.php");
--
Edit bug report at http://bugs.php.net/?id=15779&edit=1
--
Fixed in CVS:http://bugs.php.net/fix.php?id=15779&r=fixedcvs
Fixed in release:http://bugs.php.net/fix.php?id=15779&r=alreadyfixed
Need backtrace: http://bugs.php.net/fix.php?id=15779&r=needtrace
Try newer version: http://bugs.php.net/fix.php?id=15779&r=oldversion
Not developer issue: http://bugs.php.net/fix.php?id=15779&r=support
Expected behavior: http://bugs.php.net/fix.php?id=15779&r=notwrong
Not enough info: http://bugs.php.net/fix.php?id=15779&r=notenoughinfo
Submitted twice: http://bugs.php.net/fix.php?id=15779&r=submittedtwice
Bug #12061 Updated: CGI Error
ID: 12061 Updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] Status: Bogus Bug Type: IIS related Operating System: Win 2K PHP Version: 4.0.6 New Comment: I'm having the same problem mikevalstar, I've tried a lot of things but I can't manage to have the phpmyadmin to open! Please if there's someone out there who knows what's going on. Let me know! Tkz. Previous Comments: [2002-02-18 14:15:31] [EMAIL PROTECTED] i am attempting to run phpmyadmin and all i get is a split screen in franes with a cgi error in both, i have the newest version of mysql and the newest version of php, im running on a win 2000 box and i am running iis. any ideas how to fix my problem? [2001-07-12 06:16:13] [EMAIL PROTECTED] Ok - you don't seem to want to read install.txt, so here's the relevant bit - please read and act on it: You have installed PHP, but when try to access a php script file via your browser, you get the error: cgi error: The specified CGI application misbehaved by not returning a complete set of HTTP headers. The headers it did return are: This error message means that php failed to output anything at all. From the command line hange to the directory containing php.exe. Run php.exe -i If php has any problems running, then a suitable error message will be displayed which will give you a clue as to what needs to be done next. If you get a screen full of html codes (the output of the phpinfo() function) then php is working ok. Once php is working at the command line, try accessing the php script via the browser again. If it still fails then it could be one of the following: file permissions on your php script, php.exe, php4ts.dll, php.ini or any php extensions you are trying to load are such that the anonymous internet user ISUR_ cannot access them. The script file does not exist (or possibly isn't where you think it is relative to your web root directory). Note that for IIS you can trap this error by ticking the 'check file exists' box when setting up the script mappings in the Internet Services Manager. If a script file does not exist then the server will return a 404 error instead. There is also the additional benefit that IIS will do any authentication required for you based on the NTLanMan permissions on your script file. Other problems If you are still stuck, someone on the PHP installation mailing list may be able to help you. You should check out the archive first, in case someone already answered someone else who had the same problem as you. The archives are available from the support page on www.php.net To subscribe to the PHP installation mailing list, send an empty mail to [EMAIL PROTECTED] The mailing list address is [EMAIL PROTECTED] If you want to get help on the mailing list, please try to be precise and give the necessary details about your environment (which operating system, what PHP version, what web server, if ou are running PHP as CGI or a server module, etc.), and referably enough code to make others able to reproduce and test our problem. [2001-07-11 14:43:00] [EMAIL PROTECTED] Installed using the Installshield package... install and go... but it doesn't... what changes does it make that it should or that it doesn't... what manually changes need to be made... other people posted the same question.. and have go no useful answers what need to be done so that it works? [2001-07-11 14:34:22] [EMAIL PROTECTED] Installed using the Installshield package... install and go... but it doesn't... what changes does it make that it should or that it doesn't... what manually changes need to be made... other people posted the same question.. and have go no useful answers what need to be done so that it works? [2001-07-11 14:19:47] [EMAIL PROTECTED] Your setup is just incorrectly configured. Please read the install.txt file for details of what you need to check. If you still have problems, post a query to the php-windows or php-install lists. 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/12061 -- Edit this bug report at http://bugs.php.net/?id=12061&edit=1
Bug #13182 Updated: session_start() can't create a _new_ session control file.
ID: 13182 Updated by: [EMAIL PROTECTED] -Summary: session_start() can't create a _new_ session control file. Reported By: [EMAIL PROTECTED] -Status: Assigned +Status: Closed Bug Type: Session related Operating System: Solaris 7 PHP Version: 4.1.1 Assigned To: yohgaki New Comment: This bug has been fixed in CVS. Previous Comments: [2002-02-03 19:48:46] [EMAIL PROTECTED] This my be fixed by my patch. (Session module was trying to open exlusively more than once) [2002-01-15 04:20:40] [EMAIL PROTECTED] We sloved the problem in out system by saving the session data in the mySQL-databas. That is at least a way to avoid the problem. best regards, Andreas Lundgren [2002-01-15 03:37:51] [EMAIL PROTECTED] Version update. [2002-01-15 03:34:49] [EMAIL PROTECTED] Got feedback from a user. -- feedback from [EMAIL PROTECTED] -- Hello, I was hoping you could re-open PHP-BUG #13182. I have completed a test in 4.1.1 and receive the same error. I have also attempted to compile a snapshot from CVS but the build failed so I will have to tweak it and get back to you on that. As for this bug, I am attaching the error on top of a phpinfo() page. I originally tried it in 4.0.6 or some older release. The only configure params, as you can see, are the Roxen location and the Sybase location (for Sybase support). I have tested this application from 4.0.0 on in Apache on Win2000, Solaris 7 and Solaris 8. I have tested it with 4.0.6 on Roxen with Solaris 7. So the difference here (and I have really tried to bring the configs as close as possible) seems to be the Solaris 7 vs 8. I will try and gather more information but would appreciate the bug being reopened as I feel it is reproducible. Regards, Sam Cooley __ Do You Yahoo!? Send FREE video emails in Yahoo! Mail! http://promo.yahoo.com/videomail/ 4.1.1 OUTPUT - - Warning: open(/opt/www/cgi-bin/blahapp/conf/sess_9265832f97f81fa3ad1ee1bcc7bd4de7, O_RDWR) failed: Error 0 (0) in /opt/www/cgi-bin/blahapp/php/blahapp_init.phtml on line 37 PHP Version 4.1.1 System SunOS www.blah.com 5.8 Generic_108528-05 sun4u sparc SUNW,Ultra-80 Build Date Jan 15 2002 Configure Command './configure' '--with-sybase=/opt/sybase/SQL/current' '--with-roxen=/opt/roxen/server' Server API Roxen Virtual Directory Support disabled Configuration File (php.ini) Path /usr/local/lib/php.ini ZEND_DEBUG disabled Thread Safety disabled This program makes use of the Zend Scripting Language Engine: Zend Engine v1.1.1, Copyright (c) 1998-2001 Zend Technologies PHP 4.0 Credits Configuration PHP Core Directive Local Value Master Value allow_call_time_pass_reference On On allow_url_fopen 1 1 always_populate_raw_post_data 0 0 arg_separator.input & & arg_separator.output & & asp_tags Off Off auto_append_file no value no value auto_prepend_file no value no value browscap no value no value default_charset no value no value default_mimetype text/html text/html define_syslog_variables Off Off disable_functions no value no value display_errors On On display_startup_errors Off Off doc_root no value no value enable_dl On On error_append_string no value no value error_log no value no value error_prepend_string no value no value error_reporting 2039 2039 expose_php On On extension_dir ./ ./ file_uploads 1 1 gpc_order GPC GPC highlight.bg #FF #FF highlight.comment #FF9900 #FF9900 highlight.default #CC #CC highlight.html #00 #00 highlight.keyword #006600 #006600 highlight.string #CC #CC html_errors On On ignore_user_abort Off Off implicit_flush Off Off include_path .:/usr/local/lib/php .:/usr/local/lib/php log_errors Off Off magic_quotes_gpc On On magic_quotes_runtime Off Off magic_quotes_sybase Off Off max_execution_time 30 30 open_basedir no value no value output_buffering no value no value output_handler no value no value post_max_size 8M 8M precision 14 14 register_argc_argv On On register_globals Off Off safe_mode Off Off safe_mode_exec_dir no value no value safe_mode_gid Off Off safe_mode_include_dir no value no value send
Bug #15769 Updated: php-4.0 crypt("abc") != php-4.1 crypt("abc")
ID: 15769
Updated by: [EMAIL PROTECTED]
-Summary: php-4.0 crypt("abc") != php-4.1 crypt("abc")
Reported By: [EMAIL PROTECTED]
Status: Bogus
Bug Type: *Encryption and hash functions
Operating System: linux
PHP Version: 4.1.1
New Comment:
ok, found a solution :
1. ./configure [options]
2. edit main/php_config.h and set PHP_MD5_CRYPT = 0
3. compile.
Previous Comments:
[2002-02-28 05:44:41] [EMAIL PROTECTED]
from the docs:
> If no salt is provided, PHP will auto-generate a standard > 2
character salt by default, unless the default encryption
> type on the system is MD5, in which case a random
> MD5-compatible salt is generated.
well, the "default encryption type" on the system has not changed
between upgrade from 4.0 to 4.1, so why does the crypt behaviour change
on the way? I really see that as a bug, or please tell me how to revert
to the "normal" crypt (DES). Saw no options in the ./configure as
well... :/
[2002-02-28 02:09:06] [EMAIL PROTECTED]
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
http://www.php.net/manual/en/function.crypt.php
[2002-02-28 02:08:38] [EMAIL PROTECTED]
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
[2002-02-27 19:53:56] [EMAIL PROTECTED]
On the same system after upgrade, the result of crypt with only one
arguments has another format: before (php 4.0.6) it was the standard 13
chars string, and now this md5-like hash is comming:
"$1$ngOfu9A.$AoUUzzXjwxQiqKq7c2wDt1"...
Shouldn't the default behaviour of crypt() stay the same on a specific
system ? This way it breaks a lots of customers scripts on the web
server on upgrade, and this is *very* annoying. (no, I can't tell all
people: rewrite all your scripts and use 2 args with the crypt
command).
Isn't there a way to tell at compliation time: crypt() defaults to DES?
Regards,
Olivier
--
Edit this bug report at http://bugs.php.net/?id=15769&edit=1
Bug #12061 Updated: CGI Error
ID: 12061 Updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] Status: Bogus Bug Type: IIS related Operating System: Win 2K PHP Version: 4.0.6 New Comment: I've fixed the problem, all you gotta do is set full permition to phpmyadmin directory. At least now it works fine on my w2k server. =] Previous Comments: [2002-02-28 07:11:26] [EMAIL PROTECTED] I'm having the same problem mikevalstar, I've tried a lot of things but I can't manage to have the phpmyadmin to open! Please if there's someone out there who knows what's going on. Let me know! Tkz. [2002-02-18 14:15:31] [EMAIL PROTECTED] i am attempting to run phpmyadmin and all i get is a split screen in franes with a cgi error in both, i have the newest version of mysql and the newest version of php, im running on a win 2000 box and i am running iis. any ideas how to fix my problem? [2001-07-12 06:16:13] [EMAIL PROTECTED] Ok - you don't seem to want to read install.txt, so here's the relevant bit - please read and act on it: You have installed PHP, but when try to access a php script file via your browser, you get the error: cgi error: The specified CGI application misbehaved by not returning a complete set of HTTP headers. The headers it did return are: This error message means that php failed to output anything at all. From the command line hange to the directory containing php.exe. Run php.exe -i If php has any problems running, then a suitable error message will be displayed which will give you a clue as to what needs to be done next. If you get a screen full of html codes (the output of the phpinfo() function) then php is working ok. Once php is working at the command line, try accessing the php script via the browser again. If it still fails then it could be one of the following: file permissions on your php script, php.exe, php4ts.dll, php.ini or any php extensions you are trying to load are such that the anonymous internet user ISUR_ cannot access them. The script file does not exist (or possibly isn't where you think it is relative to your web root directory). Note that for IIS you can trap this error by ticking the 'check file exists' box when setting up the script mappings in the Internet Services Manager. If a script file does not exist then the server will return a 404 error instead. There is also the additional benefit that IIS will do any authentication required for you based on the NTLanMan permissions on your script file. Other problems If you are still stuck, someone on the PHP installation mailing list may be able to help you. You should check out the archive first, in case someone already answered someone else who had the same problem as you. The archives are available from the support page on www.php.net To subscribe to the PHP installation mailing list, send an empty mail to [EMAIL PROTECTED] The mailing list address is [EMAIL PROTECTED] If you want to get help on the mailing list, please try to be precise and give the necessary details about your environment (which operating system, what PHP version, what web server, if ou are running PHP as CGI or a server module, etc.), and referably enough code to make others able to reproduce and test our problem. [2001-07-11 14:43:00] [EMAIL PROTECTED] Installed using the Installshield package... install and go... but it doesn't... what changes does it make that it should or that it doesn't... what manually changes need to be made... other people posted the same question.. and have go no useful answers what need to be done so that it works? [2001-07-11 14:34:22] [EMAIL PROTECTED] Installed using the Installshield package... install and go... but it doesn't... what changes does it make that it should or that it doesn't... what manually changes need to be made... other people posted the same question.. and have go no useful answers what need to be done so that it works? 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/12061 -- Edit this bug report at http://bugs.php.net/?id=12061&edit=1
Bug #15780: openssl: undefined reference to `OPENSSL_add_all_algorithms_noconf'
From: [EMAIL PROTECTED] Operating system: Linux PHP version: 4.0CVS-2002-02-28 PHP Bug Type: Compile Failure Bug description: openssl: undefined reference to `OPENSSL_add_all_algorithms_noconf' A compile error. OpenSSL version : OpenSSL 0.9.7-dev 24 Sep 2000 make[2]: Nothing to be done for `all-p'. make[2]: Leaving directory `/usr/src/php4/regex' make[1]: Leaving directory `/usr/src/php4/regex' Making all in sapi/cli make[1]: Entering directory `/usr/src/php4/sapi/cli' make[2]: Entering directory `/usr/src/php4/sapi/cli' /bin/sh /usr/src/php4/libtool --silent --mode=link gcc -I. -I/usr/src/php4/sapi/cli -I/usr/src/php4/main -I/usr/src/php4 -I/usr/src/apache_1.3.23//src/include -I/usr/src/apache_1.3.23//src/os/unix -I/usr/src/php4/Zend -I/usr/src/openssl/include -I/usr/include/libxml2 -I/usr/include/freetype -I/usr/include/mysql -I/data/virtual/include -I/usr/src/php4/ext/xml/expat -I/usr/src/php4/TSRM -fPIC -O3 -m486 -o php -export-dynamic libphp4cli.la ./.libs/libphp4cli.a(openssl.o): In function `zm_startup_openssl': openssl.o(.text+0xa16): undefined reference to `OPENSSL_add_all_algorithms_noconf' collect2: ld returned 1 exit status make[2]: *** [php] Error 1 make[2]: Leaving directory `/usr/src/php4/sapi/cli' make[1]: *** [all-recursive] Error 1 make[1]: Leaving directory `/usr/src/php4/sapi/cli' make: *** [all-recursive] Error 1 -- Edit bug report at http://bugs.php.net/?id=15780&edit=1 -- Fixed in CVS:http://bugs.php.net/fix.php?id=15780&r=fixedcvs Fixed in release:http://bugs.php.net/fix.php?id=15780&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=15780&r=needtrace Try newer version: http://bugs.php.net/fix.php?id=15780&r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=15780&r=support Expected behavior: http://bugs.php.net/fix.php?id=15780&r=notwrong Not enough info: http://bugs.php.net/fix.php?id=15780&r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=15780&r=submittedtwice
Bug #15781: Reentrancy.c fails to compile
From: [EMAIL PROTECTED] Operating system: SuSE 7.0 2.2.16-SMP PHP version: 4.1.2 PHP Bug Type: Compile Failure Bug description: Reentrancy.c fails to compile # ./configure --with-mysql --with-apxs=/www/apache/bin/apxs --with-curl=/usr/local --enable-versioning --enable-track-vars # make reentrancy.c:130: too few arguments to function `readdir_r' gcc -v Reading specs from /usr/lib/gcc-lib/i486-suse-linux/2.95.2/specs gcc version 2.95.2 19991024 (release) kernel 2.2.16-SMP - PHP 4.0.6 compiles ok. -- Edit bug report at http://bugs.php.net/?id=15781&edit=1 -- Fixed in CVS:http://bugs.php.net/fix.php?id=15781&r=fixedcvs Fixed in release:http://bugs.php.net/fix.php?id=15781&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=15781&r=needtrace Try newer version: http://bugs.php.net/fix.php?id=15781&r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=15781&r=support Expected behavior: http://bugs.php.net/fix.php?id=15781&r=notwrong Not enough info: http://bugs.php.net/fix.php?id=15781&r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=15781&r=submittedtwice
Bug #15782: Unsupported variant type: 8209 (0x2011)
From: [EMAIL PROTECTED]
Operating system: Windows 2000
PHP version: 4.1.1
PHP Bug Type: COM related
Bug description: Unsupported variant type: 8209 (0x2011)
Hi,
With PHP 4.0.6 on Windows 2000, i use this code :
$conn = new COM("ADODB.Connection");
$conn->Open("DRIVER={Microsoft Access Driver (*.mdb)}; DBQ=C:/bdd.mdb;");
$rs = $conn->Execute("SELECT Libellé FROM [TV/Substrat]");
$num_fields = $rs->Fields->Count();
while (!$rs->EOF)
{
for ($i=0; $i < $num_fields; $i++)
{
$f=$rs->Fields($i);
$field_value=$f->Value;
echo "$field_value\n";
}
$rs->MoveNext();
}
It works fine and the result is :
CARB
HSS
HSS-E
HSS-E5
HSS-E8
HSS-EE
HSS-ES
HSS-PM
But after installing the application software "IBM AS400 Client Access
Express", (but i can't proove actually, it's because of it), i've got this
message :
Unsupported variant type: 8209 (0x2011)
I think this software changed the ODBC drivers as i can see "Microsoft
Access Driver" and "Microsoft Access-Treiber" for example.
I updated PHP to 4.1.1 and the result for the previous code was :
Array
Array
Array
Array
Array
Array
Array
Array
When i print each element of an array i had something like this :
670650820660
720830830
720830830450690
720830830450690530
720830830450690560
720830830450690690
720830830450690830
720830830450800770
So, i understood it was ascii codes separated by "0". After applying CHR()
function to each element i have the right previous answer (CARB, HSS,
etc...).
Well, what's the trouble ?
Jean-François GAZET (France)
--
Edit bug report at http://bugs.php.net/?id=15782&edit=1
--
Fixed in CVS:http://bugs.php.net/fix.php?id=15782&r=fixedcvs
Fixed in release:http://bugs.php.net/fix.php?id=15782&r=alreadyfixed
Need backtrace: http://bugs.php.net/fix.php?id=15782&r=needtrace
Try newer version: http://bugs.php.net/fix.php?id=15782&r=oldversion
Not developer issue: http://bugs.php.net/fix.php?id=15782&r=support
Expected behavior: http://bugs.php.net/fix.php?id=15782&r=notwrong
Not enough info: http://bugs.php.net/fix.php?id=15782&r=notenoughinfo
Submitted twice: http://bugs.php.net/fix.php?id=15782&r=submittedtwice
Bug #15782 Updated: Unsupported variant type: 8209 (0x2011)
ID: 15782
Updated by: [EMAIL PROTECTED]
Reported By: [EMAIL PROTECTED]
Status: Open
Bug Type: COM related
Operating System: Windows 2000
PHP Version: 4.1.1
New Comment:
I add that with the error message "Unsupported variant type: 8209
(0x2011)" the line which caused the error was "$field_value=$f->Value;"
Previous Comments:
[2002-02-28 08:43:01] [EMAIL PROTECTED]
Hi,
With PHP 4.0.6 on Windows 2000, i use this code :
$conn = new COM("ADODB.Connection");
$conn->Open("DRIVER={Microsoft Access Driver (*.mdb)};
DBQ=C:/bdd.mdb;");
$rs = $conn->Execute("SELECT Libellé FROM [TV/Substrat]");
$num_fields = $rs->Fields->Count();
while (!$rs->EOF)
{
for ($i=0; $i < $num_fields; $i++)
{
$f=$rs->Fields($i);
$field_value=$f->Value;
echo "$field_value\n";
}
$rs->MoveNext();
}
It works fine and the result is :
CARB
HSS
HSS-E
HSS-E5
HSS-E8
HSS-EE
HSS-ES
HSS-PM
But after installing the application software "IBM AS400 Client Access
Express", (but i can't proove actually, it's because of it), i've got
this message :
Unsupported variant type: 8209 (0x2011)
I think this software changed the ODBC drivers as i can see "Microsoft
Access Driver" and "Microsoft Access-Treiber" for example.
I updated PHP to 4.1.1 and the result for the previous code was :
Array
Array
Array
Array
Array
Array
Array
Array
When i print each element of an array i had something like this :
670650820660
720830830
720830830450690
720830830450690530
720830830450690560
720830830450690690
720830830450690830
720830830450800770
So, i understood it was ascii codes separated by "0". After applying
CHR() function to each element i have the right previous answer (CARB,
HSS, etc...).
Well, what's the trouble ?
Jean-François GAZET (France)
--
Edit this bug report at http://bugs.php.net/?id=15782&edit=1
Bug #1965 Updated: Sybase-CT doesn't compile with PHP4 source
ID: 1965 Updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] Status: Closed Bug Type: Sybase-ct (ctlib) related Operating System: Linux PHP Version: 4.0 Beta 1 New Comment: Hey there, got the same problem. Used several options, but for some reason --with-sybase-ct doesn't work. The configure command seens to work fine, but make crashes. I also tried removing "-lcs -linsck -lintl -lcomn and -lsybtcl" from the configure script, but then it crashed on -lct. I tried compiling php-4.1.2 which is the newest version, and using a (new installed) RedHat 7.2 freetds > sybase-common and then php... php crashes.. Previous Comments: [1999-11-07 09:51:41] [EMAIL PROTECTED] Fixed in beta 2 [1999-08-04 19:20:54] [EMAIL PROTECTED] Hi, I tried to compile PHP4/Linux with Sybase-CT support to communicate with an MS SQL server, however the compiler crashed with "too less arguments" for several instructions within the Sybase-CT support. Ofcourse i downloaded all the required components; php3 compiles fine but php4 refuses. Ruud. -- Edit this bug report at http://bugs.php.net/?id=1965&edit=1
Bug #15561 Updated: make install fails to copy libphp4.so
ID: 15561 Updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] Status: Open Bug Type: Compile Failure Operating System: AIX 4.3.3 PHP Version: 4.1.1 New Comment: I have the same problem, on the same platform using the same PHP version, and reproducible for PHP 4.1.2 as well. I used the same work around for the 'make-install' issue (cp ./.libs/* ./libs), and have the same problem on server-startup. I got some more information when I discovered that in my case, iPlanet is recieving signal 11/segmentation fault and trying to dump core when it 'hangs'. It's the uxwdog process that restarts it/keeps it from crashing, giving the impression that the server is 'frozen'. In order to get a core file and some more info: Make sure the account you are running the server as, can write to "/usr/netscape/server4/https-/config/core". By default, the core file should be located there. Make sure that the filesystem this dir is in has enough space for a corefile. Make sure there is no limit set for dumping core for the user-id the server is running under, by checking the users stanza in '/etc/security/limits' (set core=-1). start the httpd manually (instead of using the 'start' script) by doing: cd /usr/netscape/server4/bin/https/bin ./ns-httpd -d /usr/netscape/server4/https-/config Also, check the aix error log for messages by doing: errpt -a | more If you are running syslog, check that logfile too for messages from uxwdog. Previous Comments: [2002-02-21 10:18:09] [EMAIL PROTECTED] I have copied libphp4.a, libphp4.la, and libphp4.so.0 from the .libs directory to the libs/ directory. Renaming libphp4.so.0 to libphp4.so. Then run make install, the install goes fine after this and copies the binaries around. Is this ok to do? iPlanet is still hanging when I go to a page as it was with php 4.0.6. Thanks, Chris [2002-02-21 03:53:35] [EMAIL PROTECTED] I guess this is PHP's fault. It seems libphp4.a is collect shared lib name for AIX. (not?) [2002-02-20 15:16:43] [EMAIL PROTECTED] AIX uses lib*.a for shared libraries as well as static archives, so the *.so file isn't supposed to be installed, rather it is archived into the lib*.a file. [2002-02-15 18:03:33] [EMAIL PROTECTED] This is not PHP problem, but a bug in libtool. Please report it to the friendly gnu people. --Jani [2002-02-15 16:00:24] [EMAIL PROTECTED] In that case: Reopening! 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/15561 -- Edit this bug report at http://bugs.php.net/?id=15561&edit=1
Bug #15439 Updated: PHP hangs web server when started
ID: 15439 Updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] Status: Bogus Bug Type: iPlanet related Operating System: AIX 4.3.3 PHP Version: 4.0.6 New Comment: I have the same problem, on the same platform using the same PHP version, and reproducible for PHP 4.1.1 and 4.1.2 as well. libphp4.so *is* made, but strangely enough its located in the '.libs' directory instead of 'libs', which 'make install' chokes on. I used the following work around for the 'make-install' issue (cp ./.libs/* ./libs), but then the server choked on server-startup. I got some more information when I discovered that in my case, iPlanet is recieving signal 11/segmentation fault and trying to dump core when it 'hangs'. It's the uxwdog process that restarts it/keeps it from crashing, giving the impression that the server is 'frozen'. In order to get a core file and some more info: Make sure the account you are running the server as, can write to "/usr/netscape/server4/https-/config/core". By default, the core file should be located there. Make sure that the filesystem this dir is in has enough space for a corefile. Make sure there is no limit set for dumping core for the user-id the server is running under, by checking the users stanza in '/etc/security/limits' (set core=-1). start the httpd manually (instead of using the 'start' script) by doing: cd /usr/netscape/server4/bin/https/bin ./ns-httpd -d /usr/netscape/server4/https-servername>/config Also, check the aix error log for messages by doing: errpt -a | more If you are running syslog, check that logfile too for messages from uxwdog. Previous Comments: [2002-02-08 21:28:19] [EMAIL PROTECTED] I tried to compile php 4.1.1 before I used 4.0.6, but 4.1.1 would run through the ./configure, and make, and fail on make install. It would not make libphp4.so where 4.0.6 had no problem making libphp4.so. Thanks, Chris [2002-02-07 21:56:28] [EMAIL PROTECTED] The version of PHP that this bug was reported in is too old. Please try to reproduce this bug in the latest version of PHP (available from http://www.php.net/downloads.php If you are still able to reproduce the bug with one of the latest versions of PHP, please change the PHP version on this bug report to the version you tested and change the status back to "Open". [2002-02-07 17:25:59] [EMAIL PROTECTED] The web server hangs when you go to a page, almost seems like a loop and does not seem to time out. When php is commented out in obj.conf, magnus.com, and mime.types the webserver works fine. I am using iPlanet 4.1 SP9, on AIX 4.3.3 I have downloaded and installed gcc, bison, flex, autoconf, automake, make and many others from freeware.bull.net export PATH=/usr/local/bin:$PATH:/usr/vac/bin:/usr/ccs/bin export LD_LIBRARY_PATH=$LD_LIBRARY_PATH:/usr/local/lib PHP 4.0.6 compile line CC=gcc ./configure --without-mysql \ --with-nsapi=/usr/netscape/server4 \ --with-dbm \ --with-gdbm \ --enable-libgcc compiles fine, i used dump -n to see the libpthread was included. I have even tried to compile this without dbm and gdbm support and still the same problem. Thanks for any help, Chris -- Edit this bug report at http://bugs.php.net/?id=15439&edit=1
Bug #15769 Updated: php-4.0 crypt("abc") != php-4.1 crypt("abc")
ID: 15769
Updated by: [EMAIL PROTECTED]
-Summary: php-4.0 crypt("abc") != php-4.1 crypt("abc")
Reported By: [EMAIL PROTECTED]
Status: Bogus
Bug Type: *Encryption and hash functions
Operating System: linux
PHP Version: 4.1.1
New Comment:
The behaviour unfortunatelly did change (and its not documented). You
don't have to disable MD5 like that to get regular crypt, but you would
need to generate a two character salt, which would then be passed as a
second argument to crypt().
Previous Comments:
[2002-02-28 07:32:22] [EMAIL PROTECTED]
ok, found a solution :
1. ./configure [options]
2. edit main/php_config.h and set PHP_MD5_CRYPT = 0
3. compile.
[2002-02-28 05:44:41] [EMAIL PROTECTED]
from the docs:
> If no salt is provided, PHP will auto-generate a standard > 2
character salt by default, unless the default encryption
> type on the system is MD5, in which case a random
> MD5-compatible salt is generated.
well, the "default encryption type" on the system has not changed
between upgrade from 4.0 to 4.1, so why does the crypt behaviour change
on the way? I really see that as a bug, or please tell me how to revert
to the "normal" crypt (DES). Saw no options in the ./configure as
well... :/
[2002-02-28 02:09:06] [EMAIL PROTECTED]
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
http://www.php.net/manual/en/function.crypt.php
[2002-02-28 02:08:38] [EMAIL PROTECTED]
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
[2002-02-27 19:53:56] [EMAIL PROTECTED]
On the same system after upgrade, the result of crypt with only one
arguments has another format: before (php 4.0.6) it was the standard 13
chars string, and now this md5-like hash is comming:
"$1$ngOfu9A.$AoUUzzXjwxQiqKq7c2wDt1"...
Shouldn't the default behaviour of crypt() stay the same on a specific
system ? This way it breaks a lots of customers scripts on the web
server on upgrade, and this is *very* annoying. (no, I can't tell all
people: rewrite all your scripts and use 2 args with the crypt
command).
Isn't there a way to tell at compliation time: crypt() defaults to DES?
Regards,
Olivier
--
Edit this bug report at http://bugs.php.net/?id=15769&edit=1
Bug #15112 Updated: failed to compile extension modules as a dso
ID: 15112 Updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] Status: Open Bug Type: *Compile Issues Operating System: NetBSD/Alpha-1.5.2 PHP Version: 4.1.1 New Comment: Seeing the same problems with php-4.1.2 Previous Comments: [2002-01-19 04:29:24] [EMAIL PROTECTED] # NetBSD/Alpha 1.5.2 PHP-4.1.1 # # Building the CGI export LDFLAGS="-Wl,-R/usr/lib -L/usr/lib -Wl,-R/usr/pkg/lib -L/usr/pkg/lib -Wl,-R/usr/local/lib -L/usr/local/lib -Wl,--export-dynamic -Wl,--whole-archive -Wl,-lgcc -Wl,--no-whole-archive" ./configure \ --prefix=/usr/local_install/php-4.1.1 \ --with-config-file-path=/usr/local/etc \ --with-regex=system \ --with-gettext=shared,/usr/pkg \ --with-pgsql=shared,/usr/local \ --with-mysql=shared,/usr/pkg \ --with-pcre-regex \ --with-gd=shared,/usr/local \ --with-jpeg-dir=shared,/usr/pkg \ --with-png-dir=shared,/usr/pkg \ --with-xpm-dir=shared,/usr/pkg \ --with-ttf=shared,/usr/pkg \ --with-freetype-dir=shared,/usr/pkg \ --with-zlib-dir=/usr \ --enable-gd-native-ttf \ --enable-sysvsem=shared \ --enable-sysvshm=shared \ --enable-sockets=shared \ --enable-xml=shared \ --enable-trans-sid \ --enable-discard-path \ --enable-force-cgi-redirect \ --enable-memory-limit \ --enable-track-vars \ --without-t1lib \ --disable-static \ --enable-shared Compiles fine and all that, but the modules aren't in *.so format, instead: # ls -l /usr/local_install/php-4.1.1/lib/php/20010901 total 1291 -rw-r--r-- 1 root wheel 312754 Jan 19 03:25 gd.a -rw-r--r-- 1 root wheel 42044 Jan 19 03:25 gettext.a -rw-r--r-- 1 root wheel 169096 Jan 19 03:25 mysql.a -rw-r--r-- 1 root wheel 263840 Jan 19 03:25 pcre.a -rw-r--r-- 1 root wheel 181726 Jan 19 03:25 pgsql.a -rw-r--r-- 1 root wheel 174484 Jan 19 03:25 sockets.a -rw-r--r-- 1 root wheel 49260 Jan 19 03:25 sysvsem.a -rw-r--r-- 1 root wheel 57342 Jan 19 03:25 sysvshm.a # Seems like libtool failed somewhere? -- Edit this bug report at http://bugs.php.net/?id=15112&edit=1
Bug #15769 Updated: php-4.0 crypt("abc") != php-4.1 crypt("abc")
ID: 15769
Updated by: [EMAIL PROTECTED]
-Summary: php-4.0 crypt("abc") != php-4.1 crypt("abc")
Reported By: [EMAIL PROTECTED]
Status: Bogus
Bug Type: *Encryption and hash functions
Operating System: linux
PHP Version: 4.1.1
New Comment:
The behaviour changed because there was a bug in the
detection for crypt() capabilities in previous PHP versions.
Now it behaves as documented.
--Jani
Previous Comments:
[2002-02-28 09:55:59] [EMAIL PROTECTED]
The behaviour unfortunatelly did change (and its not documented). You
don't have to disable MD5 like that to get regular crypt, but you would
need to generate a two character salt, which would then be passed as a
second argument to crypt().
[2002-02-28 07:32:22] [EMAIL PROTECTED]
ok, found a solution :
1. ./configure [options]
2. edit main/php_config.h and set PHP_MD5_CRYPT = 0
3. compile.
[2002-02-28 05:44:41] [EMAIL PROTECTED]
from the docs:
> If no salt is provided, PHP will auto-generate a standard > 2
character salt by default, unless the default encryption
> type on the system is MD5, in which case a random
> MD5-compatible salt is generated.
well, the "default encryption type" on the system has not changed
between upgrade from 4.0 to 4.1, so why does the crypt behaviour change
on the way? I really see that as a bug, or please tell me how to revert
to the "normal" crypt (DES). Saw no options in the ./configure as
well... :/
[2002-02-28 02:09:06] [EMAIL PROTECTED]
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
http://www.php.net/manual/en/function.crypt.php
[2002-02-28 02:08:38] [EMAIL PROTECTED]
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
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/15769
--
Edit this bug report at http://bugs.php.net/?id=15769&edit=1
Bug #15783: shebang appear
From: [EMAIL PROTECTED] Operating system: FreeBSD 4.5 stable PHP version: 4.1.2 PHP Bug Type: *General Issues Bug description: shebang appear When executing php scripts from the command line the shebang #!/usr/local/bin/php appear on the output. The code next to this line is correctly executed. Is it a bug like in previous version of php ? Or am i doing something wrong ? Didier Bleuzen -- Edit bug report at http://bugs.php.net/?id=15783&edit=1 -- Fixed in CVS:http://bugs.php.net/fix.php?id=15783&r=fixedcvs Fixed in release:http://bugs.php.net/fix.php?id=15783&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=15783&r=needtrace Try newer version: http://bugs.php.net/fix.php?id=15783&r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=15783&r=support Expected behavior: http://bugs.php.net/fix.php?id=15783&r=notwrong Not enough info: http://bugs.php.net/fix.php?id=15783&r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=15783&r=submittedtwice
Bug #15784: shebang appear
From: [EMAIL PROTECTED] Operating system: FreeBSD 4.5 stable PHP version: 4.1.2 PHP Bug Type: *General Issues Bug description: shebang appear When executing php scripts from the command line the shebang #!/usr/local/bin/php appear on the output. The code next to this line is correctly executed. Is it a bug like in previous version of php ? Or am i doing something wrong ? Didier Bleuzen -- Edit bug report at http://bugs.php.net/?id=15784&edit=1 -- Fixed in CVS:http://bugs.php.net/fix.php?id=15784&r=fixedcvs Fixed in release:http://bugs.php.net/fix.php?id=15784&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=15784&r=needtrace Try newer version: http://bugs.php.net/fix.php?id=15784&r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=15784&r=support Expected behavior: http://bugs.php.net/fix.php?id=15784&r=notwrong Not enough info: http://bugs.php.net/fix.php?id=15784&r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=15784&r=submittedtwice
Bug #15784 Updated: shebang appear
ID: 15784 Updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] -Status: Open +Status: Bogus Bug Type: *General Issues Operating System: FreeBSD 4.5 stable PHP Version: 4.1.2 New Comment: Please do not submit the same bug more than once. Previous Comments: [2002-02-28 10:47:27] [EMAIL PROTECTED] When executing php scripts from the command line the shebang #!/usr/local/bin/php appear on the output. The code next to this line is correctly executed. Is it a bug like in previous version of php ? Or am i doing something wrong ? Didier Bleuzen -- Edit this bug report at http://bugs.php.net/?id=15784&edit=1
Bug #15785: shebang appear
From: [EMAIL PROTECTED] Operating system: FreeBSD 4.5 stable PHP version: 4.1.2 PHP Bug Type: *General Issues Bug description: shebang appear When executing php scripts from the command line the shebang #!/usr/local/bin/php appear on the output. The code next to this line is correctly executed. Is it a bug like in previous version of php ? Or am i doing something wrong ? Didier Bleuzen -- Edit bug report at http://bugs.php.net/?id=15785&edit=1 -- Fixed in CVS:http://bugs.php.net/fix.php?id=15785&r=fixedcvs Fixed in release:http://bugs.php.net/fix.php?id=15785&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=15785&r=needtrace Try newer version: http://bugs.php.net/fix.php?id=15785&r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=15785&r=support Expected behavior: http://bugs.php.net/fix.php?id=15785&r=notwrong Not enough info: http://bugs.php.net/fix.php?id=15785&r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=15785&r=submittedtwice
Bug #15785 Updated: shebang appear
ID: 15785 Updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] -Status: Open +Status: Bogus Bug Type: *General Issues Operating System: FreeBSD 4.5 stable PHP Version: 4.1.2 New Comment: Please do not submit the same bug more than once. Previous Comments: [2002-02-28 10:56:07] [EMAIL PROTECTED] When executing php scripts from the command line the shebang #!/usr/local/bin/php appear on the output. The code next to this line is correctly executed. Is it a bug like in previous version of php ? Or am i doing something wrong ? Didier Bleuzen -- Edit this bug report at http://bugs.php.net/?id=15785&edit=1
Bug #15783 Updated: shebang appear
ID: 15783 Updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] -Status: Open +Status: Closed Bug Type: *General Issues Operating System: FreeBSD 4.5 stable PHP Version: 4.1.2 New Comment: This has already been fixed in CVS and will be in 4.2.0 Previous Comments: [2002-02-28 10:41:10] [EMAIL PROTECTED] When executing php scripts from the command line the shebang #!/usr/local/bin/php appear on the output. The code next to this line is correctly executed. Is it a bug like in previous version of php ? Or am i doing something wrong ? Didier Bleuzen -- Edit this bug report at http://bugs.php.net/?id=15783&edit=1
Bug #15787: --with-apxs=pathtoapxs fails
From: [EMAIL PROTECTED] Operating system: Solaris 8 PHP version: 4.1.2 PHP Bug Type: *Configuration Issues Bug description: --with-apxs=pathtoapxs fails When trying to run configure I call out: --with-apxs=/usr/local/apache-vip1/bin/apxs and configure returns: 1Sorry, I was not able to successfully run APXS. Possible reasons: 1. Perl is not installed; 2. Apache was not compiled with DSO support (--enable-module=so); 3. 'apxs' is not in your path. Try to use --with-apxs=/path/to/apxs The output of /usr/local/apache-vip1/bin/apxs follows Usage: apxs -g [-S =] -n apxs -q [-S =] ... apxs -c [-S =] [-o ] [-D [=]] [-I ] [-L ] [-l ] [-Wc,] [-Wl,] ... apxs -i [-S =] [-a] [-A] [-n ] ... apxs -e [-S =] [-a] [-A] [-n ] ... configure: error: Aborting Now maybe its because I'm not root, but I'm having lots of the same types of problems on a RedHat 7.2 machine even though I am root on that one. Perl is installed in the /usr/local/lib/perl5. Also the return from apxs is in the output of the error. I think the configure script is horribly broken in 4.1.2 -- Edit bug report at http://bugs.php.net/?id=15787&edit=1 -- Fixed in CVS:http://bugs.php.net/fix.php?id=15787&r=fixedcvs Fixed in release:http://bugs.php.net/fix.php?id=15787&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=15787&r=needtrace Try newer version: http://bugs.php.net/fix.php?id=15787&r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=15787&r=support Expected behavior: http://bugs.php.net/fix.php?id=15787&r=notwrong Not enough info: http://bugs.php.net/fix.php?id=15787&r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=15787&r=submittedtwice
Bug #15736 Updated: Security Exploit
ID: 15736 Updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] Status: Open Bug Type: Unknown/Other Function Operating System: All UNIX PHP Version: 4.1.1 New Comment: Shouldn't the patch on the downloads page also include this patch by Rasmus? http://cvs.php.net/diff.php/php4/main/rfc1867.c?r1=1.71.2.2&r2=1.71.2.3&ty=u Previous Comments: [2002-02-28 02:27:52] [EMAIL PROTECTED] ..and I take this back, it's fixed in CVS but not in any release. [2002-02-28 02:11:04] [EMAIL PROTECTED] This bug has already been fixed in the latest released version of PHP, which you can download at http://www.php.net/downloads.php [2002-02-27 20:54:47] [EMAIL PROTECTED] The patch for file rfc1867.c applied to php 4.0.6 seems to not work when trying to upload from Opera 6.01 (on Windows). Uploading in Internet Explorer (6.0) seems to work allright, whereas uploading with Opera simply either times out or just fails (without any errors). [2002-02-26 13:41:58] [EMAIL PROTECTED] Well, the part of doing this before Apache demotes its priviledges doesn't sound feasible to me. Apache forks child processes as a non-privileged user. You can't get it to serve up a PHP request as root. And if you could, then why use a "high port" as you mentioned? We will however have a fix for the file upload buffer overflow shortly. In the meantime, simply turn off file uploads in your php.ini file to protect yourself against this. [2002-02-26 13:34:46] [EMAIL PROTECTED] I am trying to get the source code, or at least an strace of the binary used for this exploit. 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/15736 -- Edit this bug report at http://bugs.php.net/?id=15736&edit=1
Bug #7365 Updated: php_value error_reporting doesn't work for me
ID: 7365
Updated by: [EMAIL PROTECTED]
Reported By: [EMAIL PROTECTED]
Status: Closed
Bug Type: PHP options/info functions
Operating System: Linux
PHP Version: 4.0.3pl1
New Comment:
I still get this problem with PHP 4.1.1, compiled as a DSO module:
This doesnt work in apache .conf files:
php_value error_log "/tmp/phperr.log"
php_value error_reporting 0
Just this also doesnt work:
php_value error_reporting 0
In both previous cases, I still get warnings shown...
But the flag WORKS:
php_flag display_errors 0
Norman
Previous Comments:
[2001-01-12 12:51:53] [EMAIL PROTECTED]
this seems to be fixed in both 4.0.4 and current CVS. if you experience
the same behavior after update, please reopen this bug report.
[2000-10-20 07:27:31] [EMAIL PROTECTED]
PHP version 4.0.3, compiled as DSO module.
I want to disable warnings, so I have:
/www/conf/httpd.conf:
---
php_value error_log "/tmp/phperr.log"
php_value error_reporting 0 # disabled EVERYTHING
---
'faulty' code (line 120:
---
if(is_array($messages[$seed]["replies"])){
---
In browser when I request the page, I get:
---
Warning: Undefined index: replies in
/home/www-html/htdocs/forum/multi-threads.inc on line 120
---
, this is a warning I guess, but they should be disabled
phpinfo() says about my configuration:
---
error_log /tmp/phperr.log no value
error_reporting 0 no value
---
, so it seems that config is read ok
/tmp/phperr.log doesn't get created. If I write
---
php_flag display_errors 0
---
It disables all error reporting whatsoever, but it makes debugging
nearly impossible. Error log isn't created in this case as well.
--
Edit this bug report at http://bugs.php.net/?id=7365&edit=1
Bug #15787 Updated: --with-apxs=pathtoapxs fails
ID: 15787 Updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] -Status: Open +Status: Bogus Bug Type: *Configuration Issues Operating System: Solaris 8 PHP Version: 4.1.2 New Comment: The bug system is not the appropriate forum for asking support questions. For a list of a range of more appropriate places to ask for help using PHP, please visit http://www.php.net/support.php Previous Comments: [2002-02-28 12:11:14] [EMAIL PROTECTED] When trying to run configure I call out: --with-apxs=/usr/local/apache-vip1/bin/apxs and configure returns: 1Sorry, I was not able to successfully run APXS. Possible reasons: 1. Perl is not installed; 2. Apache was not compiled with DSO support (--enable-module=so); 3. 'apxs' is not in your path. Try to use --with-apxs=/path/to/apxs The output of /usr/local/apache-vip1/bin/apxs follows Usage: apxs -g [-S =] -n apxs -q [-S =] ... apxs -c [-S =] [-o ] [-D [=]] [-I ] [-L ] [-l ] [-Wc,] [-Wl,] ... apxs -i [-S =] [-a] [-A] [-n ] ... apxs -e [-S =] [-a] [-A] [-n ] ... configure: error: Aborting Now maybe its because I'm not root, but I'm having lots of the same types of problems on a RedHat 7.2 machine even though I am root on that one. Perl is installed in the /usr/local/lib/perl5. Also the return from apxs is in the output of the error. I think the configure script is horribly broken in 4.1.2 -- Edit this bug report at http://bugs.php.net/?id=15787&edit=1
Bug #15788: microtime.c compile failure
From: [EMAIL PROTECTED] Operating system: Red Hat 6.0 (modified) PHP version: 4.1.2 PHP Bug Type: Compile Failure Bug description: microtime.c compile failure Yes, I know this bug was marked "bogus" before. And I know the FAQ says to make sure your symlink is right. But with the symlink set right, using kernel 2.4.16 (built from the tar), compilation chokes on this. This is not a good thing when you have a bunch of people trying to upgrade because of the security issue. (The symlink: /usr/include# ls -l linux lrwxrwxrwx1 root root 26 May 2 2001 linux -> ../src/linux/include/linux/) This is using gcc version 2.95.3 20010315 (release), also built from tar. Tried building the most recent version of glibc, but installing that was a serious mistake - breaking gcc among other things (if you make that mistake and have to revert to backup, be sure to restore or rebuild ld.so.cache first, without including it's files in /usr/local/include in ld.so.conf). Please let me suggest that the PHP team would better always check against compiles of recent kernels. On further attempt, the fix mentioned in the comments in the FAQ, of commenting lines in microtime.c as follows: /* #ifdef HAVE_SYS_RESOURCE_H */ #include /* #endif */ does work (although I've also reverted to gcc-2.7.2.3 since the glibc fiasco still has an afteraffect). So this is a bug in PHP, not in the user's system (unless you want to argue that kernel 2.4.16 has a bug here). Please fix it. And please correct the FAQ build section to remove the bogus advice that the user's symlinks or glibc version are what needs to be fixed. -- Edit bug report at http://bugs.php.net/?id=15788&edit=1 -- Fixed in CVS:http://bugs.php.net/fix.php?id=15788&r=fixedcvs Fixed in release:http://bugs.php.net/fix.php?id=15788&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=15788&r=needtrace Try newer version: http://bugs.php.net/fix.php?id=15788&r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=15788&r=support Expected behavior: http://bugs.php.net/fix.php?id=15788&r=notwrong Not enough info: http://bugs.php.net/fix.php?id=15788&r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=15788&r=submittedtwice
Bug #15789: php_value error_reporting in apache virtualhosts
From: [EMAIL PROTECTED] Operating system: Linux PHP version: 4.1.1 PHP Bug Type: *Configuration Issues Bug description: php_value error_reporting in apache virtualhosts php_value error_reporting 0 Simply doesnt work from within a in my apache server. I found some previous bug reports about this behaviour where is stated that this bug was fixed on 4.0.3, but Im using 4.1.1... phpinfo() output on this virtualhost reports that error_reporting has a local value of 0 and master value of 2039. But I still get all warnings. My ./configure command: './configure' '--prefix=/usr' '--with-apxs=/usr/sbin/apxs' '--with-mod_charset' '--enable-force-cgi-redirect' '--enable-discard-path' '--with-config-file-path=/etc/apache' '--enable-safe-mode' '--with-openssl' '--enable-bcmath' '--with-bz2' '--enable-calendar' '--enable-ctype' '--with-gdbm' '--with-db2' '--with-db3' '--enable-dbase' '--enable-ftp' '--enable-gd-imgstrttf' '--with-gd=/tmp/gd-1.8.2' '--with-jpeg-dir=/tmp/gd-1.8.2' '--with-mysql=/usr' '--with-xml=shared' '--with-mm=/usr' '--enable-trans-sid' '--enable-shmop' '--enable-sockets' '--with-regex=php' '--enable-sysvsem' '--enable-sysvshm' '--enable-yp' '--enable-memory-limit' '--with-tsrm-pthreads' '--enable-shared' '--disable-debug' '--with-zlib=/usr' '--with-imap=/home/norman/packs/src/c-client' Norman -- Edit bug report at http://bugs.php.net/?id=15789&edit=1 -- Fixed in CVS:http://bugs.php.net/fix.php?id=15789&r=fixedcvs Fixed in release:http://bugs.php.net/fix.php?id=15789&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=15789&r=needtrace Try newer version: http://bugs.php.net/fix.php?id=15789&r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=15789&r=support Expected behavior: http://bugs.php.net/fix.php?id=15789&r=notwrong Not enough info: http://bugs.php.net/fix.php?id=15789&r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=15789&r=submittedtwice
Bug #15788 Updated: microtime.c compile failure
ID: 15788 Updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] -Status: Open +Status: Bogus Bug Type: Compile Failure Operating System: Red Hat 6.0 (modified) PHP Version: 4.1.2 New Comment: the faq is (was, after the recent checkin) wrong. /usr/include/linux should never be a symlink to kernel sources. this has been well-discussed on various linux mailing lists. if your system has symlinks from /usr/include to the kernel source tree, it is broken. Previous Comments: [2002-02-28 13:03:36] [EMAIL PROTECTED] Yes, I know this bug was marked "bogus" before. And I know the FAQ says to make sure your symlink is right. But with the symlink set right, using kernel 2.4.16 (built from the tar), compilation chokes on this. This is not a good thing when you have a bunch of people trying to upgrade because of the security issue. (The symlink: /usr/include# ls -l linux lrwxrwxrwx1 root root 26 May 2 2001 linux -> ../src/linux/include/linux/) This is using gcc version 2.95.3 20010315 (release), also built from tar. Tried building the most recent version of glibc, but installing that was a serious mistake - breaking gcc among other things (if you make that mistake and have to revert to backup, be sure to restore or rebuild ld.so.cache first, without including it's files in /usr/local/include in ld.so.conf). Please let me suggest that the PHP team would better always check against compiles of recent kernels. On further attempt, the fix mentioned in the comments in the FAQ, of commenting lines in microtime.c as follows: /* #ifdef HAVE_SYS_RESOURCE_H */ #include /* #endif */ does work (although I've also reverted to gcc-2.7.2.3 since the glibc fiasco still has an afteraffect). So this is a bug in PHP, not in the user's system (unless you want to argue that kernel 2.4.16 has a bug here). Please fix it. And please correct the FAQ build section to remove the bogus advice that the user's symlinks or glibc version are what needs to be fixed. -- Edit this bug report at http://bugs.php.net/?id=15788&edit=1
Bug #15774 Updated: apache dies immediately after starting
ID: 15774 Updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] Status: Bogus Bug Type: Reproducible crash Operating System: GNU/Linux Debian Potato PHP Version: 4.1.2 New Comment: The configuration problem was in the apache configuration, however it was on the PHP side. I was compiling in the php module static, yet also trying to load the module. A simple check at the first load of PHP as a dynamic module to see if php support is already built into apache would do the trick. Apache has no mechanism to tell if a module is loaded or not, perhaps it ought to have better hooks for this sort of thing, but until then maybe PHP should shine and do this check itself. This is the second time I've been caught in the middle of a PHP/Apache finger pointing. Apache says it is PHP's poor error reporting, PHP says it is Apache's fault. Meanwhile, I spend literally hours (unplanned in this case due to the security bug) trying to get php/apache to work on the 4th system that day. I like PHP and I like Apache, and I accept having to update all my systems that run them when it is needed, but nobody should do what I had to do. :) Just a little bit of coordination between the two projects could really iron out a lot of problems and instead of an obscure lookng zend related problem, I could get hit with a cluestick, "You are trying to load a module that is compiled in statically, duuuh" btw. I will be submitting this to apache as well, and I dont want to hear from both sides that the other should do it, that would be really frustrating (admitedly, it wouldn't turn me to Microsoft, but it would be disheartening to see two great projects acting this way) Previous Comments: [2002-02-28 05:47:28] [EMAIL PROTECTED] I hope apache detects the misconfiguration and print nice error, too :) [2002-02-28 04:35:33] [EMAIL PROTECTED] After working with user on IRC for a while, the problem appears to have been loading a dynamic PHP module in an apache that had a later PHP version builtin. Perhaps there is some way we could watch for this and let the user know what they've dong? [2002-02-28 03:12:39] [EMAIL PROTECTED] Reopened. You have something wrong. Exit code 0377 is actually a 255(or -1). Apache is exiting without proper exit code set, most likely. I suggest to get rid of module one by one and locate which module is offending module and let us know. [2002-02-28 02:52:35] [EMAIL PROTECTED] Did some more poking in gdb: (gdb) br zend_hash_destroy Breakpoint 1 at 0x813a7c3: file zend_hash.c, line 532. (gdb) r -X Starting program: /usr/local/apache/bin/httpd_new -X Breakpoint 1, zend_hash_destroy (ht=0x81e8ce0) at zend_hash.c:532 532 IS_CONSISTENT(ht); (gdb) n 534 SET_INCONSISTENT(HT_IS_DESTROYING); (gdb) 536 p = ht->pListHead; (gdb) c Continuing. Breakpoint 1, zend_hash_destroy (ht=0x81edb20) at zend_hash.c:532 532 IS_CONSISTENT(ht); (gdb) n 534 SET_INCONSISTENT(HT_IS_DESTROYING); (gdb) 536 p = ht->pListHead; (gdb) c Continuing. Breakpoint 1, zend_hash_destroy (ht=0x81e9c9c) at zend_hash.c:532 532 IS_CONSISTENT(ht); (gdb) c Continuing. Breakpoint 1, zend_hash_destroy (ht=0x81d8c60) at zend_hash.c:532 532 IS_CONSISTENT(ht); (gdb) c Continuing. Breakpoint 1, zend_hash_destroy (ht=0x81ea7b4) at zend_hash.c:532 532 IS_CONSISTENT(ht); (gdb) c Continuing. Breakpoint 1, zend_hash_destroy (ht=0x81ea788) at zend_hash.c:532 532 IS_CONSISTENT(ht); (gdb) d Delete all breakpoints? (y or n) n (gdb) c Continuing. Breakpoint 1, zend_hash_destroy (ht=0x82059b8) at zend_hash.c:532 532 IS_CONSISTENT(ht); (gdb) c Continuing. Breakpoint 1, zend_hash_destroy (ht=0x82059e8) at zend_hash.c:532 532 IS_CONSISTENT(ht); (gdb) watch 0x081d8860 Watchpoint 2: 136153184 (gdb) c Continuing. Breakpoint 1, zend_hash_destroy (ht=0x8205d58) at zend_hash.c:532 532 IS_CONSISTENT(ht); (gdb) c Continuing. Breakpoint 1, zend_hash_destroy (ht=0x8205d84) at zend_hash.c:532 532 IS_CONSISTENT(ht); (gdb) c Continuing. Breakpoint 1, zend_hash_destroy (ht=0x820e8b0) at zend_hash.c:532 532 IS_CONSISTENT(ht); (gdb) clear zend_hash_destroy Deleted breakpoint 1 (gdb) c Continuing. Program exited with code 0377. (gdb) quit Not a very useful error... if this is user error, it isn't very obvious what is wrong. [2002-02-28 02:50:07] [EMAIL PROTECTED] Actually, I was ru
Bug #15198 Updated: unexpected error 'OCI8 Recursive call!'
ID: 15198 Updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] Status: Analyzed Bug Type: OCI8 related Operating System: Redhat Linux 6.1 PHP Version: 4.1.1 Assigned To: thies New Comment: 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. Previous Comments: [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;-) [2002-01-25 10:39:26] [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;-) [2002-01-24 04:44:03] [EMAIL PROTECTED] I have a script that does an OCILogin, then OCIParses a query, then does a few OCIBindByName calls, an OCIExecute, an OCIFreeStatement and finally OCILogoff. The query is a PL/SQL block with a BEGIN, a few update and insert queries and an END. Most of the time the script runs fine. But every now and then (haven't discovered any regularity yet) I'm getting 'OCI8 Recursive call!' in my error logs. I've taken a look at ext/oci8/oci8.c to see what would trigger this error, and from what I see there, I can think of no errors in my script that could cause this. So my guess os that it is some internal error. -- Edit this bug report at http://bugs.php.net/?id=15198&edit=1
Bug #15773 Updated: LoadModule directive incorrectly added to httpd.conf when mod_ssl is used
ID: 15773 Updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] Status: Analyzed Bug Type: Apache related Operating System: SunOS 5.8 PHP Version: 4.1.1 New Comment: It appears this issue was reported to the Apache group almost exactly a year ago (3/2/2001 - http://bugs.apache.org/index.cgi/full/7340), which may not bode well for seeing it fixed in Apache anytime soon. If nothing else, perhaps PHP could warn users to manually validate their new httpd.conf once they've finished compiling/building PHP with --with-apxs . Previous Comments: [2002-02-28 02:04:53] [EMAIL PROTECTED] Yes, this httpd.conf file mangling is done by apxs which is outside the domain of PHP. I suppose we could try to work around it somehow, but it would be rather non-trivial. The most we might be able to do is detect the situation and tell apxs not to try to mangle the httpd.conf file. [2002-02-28 02:00:32] [EMAIL PROTECTED] (This actually applies to PHP 4.1.2, but the pulldown box on the bug reporting page hasn't been updated to reflect that yet). When Apache (1.3.23) is compiled with mod_ssl (2.8.7) as a DSO module, mod_ssl automatically adds this to httpd.conf: ... LoadModule ssl_module libexec/libssl.so Later, when building a DSO version of PHP (4.1.2), using the --with-apxs option, PHP helpfully tries to add the appropriate LoadModule/AddModule directives to httpd.conf. However, it appears to guess incorrectly where the LoadModule directive should go, so httpd.conf now contains this: ... LoadModule ssl_module libexec/libssl.so LoadModule php4_modulelibexec/libphp4.so which will cause PHP not to load (and httpd to not start) unless SSL is also running. The solution, of course, is for httpd.conf to look like this: LoadModule ssl_module libexec/libssl.so LoadModule php4_modulelibexec/libphp4.so (actually, as I dig into the PHP code, I'm beginning to wonder if it's an apxs problem rather than a PHP problem. Still, even if it is, perhaps PHP's installer can work around it?) Thanks. -- Edit this bug report at http://bugs.php.net/?id=15773&edit=1
Bug #15788 Updated: microtime.c compile failure
ID: 15788 Updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] Status: Bogus Bug Type: Compile Failure Operating System: Red Hat 6.0 (modified) PHP Version: 4.1.2 New Comment: If my system was truly broken, then editing the microtime.c file would not allow PHP to compile okay. Further, well up into the 4.x series PHP compiled fine on this same system. Expecting people to follow the Linux mailing lists for changes in the weight of opinion on whether Red Hat set up the 6.0 filesystem right, as compared to fixing PHP sources so that HAVE_SYS_RESOURCE_H is properly defined _even for systems like Red Hat 6.0, or the Slackware versions where PHP compilation presents a similar problem_ is the correct, right, decent and friendly thing to do. Short of that, the FAQ should present a either links to or a full description of the particular revision of the file system standard the PHP is unnecessarily trying to enforce. But the best solution is to make PHP compile successfully whether or not /usr/include is set up according to the latest fashion. Previous Comments: [2002-02-28 13:17:46] [EMAIL PROTECTED] the faq is (was, after the recent checkin) wrong. /usr/include/linux should never be a symlink to kernel sources. this has been well-discussed on various linux mailing lists. if your system has symlinks from /usr/include to the kernel source tree, it is broken. [2002-02-28 13:03:36] [EMAIL PROTECTED] Yes, I know this bug was marked "bogus" before. And I know the FAQ says to make sure your symlink is right. But with the symlink set right, using kernel 2.4.16 (built from the tar), compilation chokes on this. This is not a good thing when you have a bunch of people trying to upgrade because of the security issue. (The symlink: /usr/include# ls -l linux lrwxrwxrwx1 root root 26 May 2 2001 linux -> ../src/linux/include/linux/) This is using gcc version 2.95.3 20010315 (release), also built from tar. Tried building the most recent version of glibc, but installing that was a serious mistake - breaking gcc among other things (if you make that mistake and have to revert to backup, be sure to restore or rebuild ld.so.cache first, without including it's files in /usr/local/include in ld.so.conf). Please let me suggest that the PHP team would better always check against compiles of recent kernels. On further attempt, the fix mentioned in the comments in the FAQ, of commenting lines in microtime.c as follows: /* #ifdef HAVE_SYS_RESOURCE_H */ #include /* #endif */ does work (although I've also reverted to gcc-2.7.2.3 since the glibc fiasco still has an afteraffect). So this is a bug in PHP, not in the user's system (unless you want to argue that kernel 2.4.16 has a bug here). Please fix it. And please correct the FAQ build section to remove the bogus advice that the user's symlinks or glibc version are what needs to be fixed. -- Edit this bug report at http://bugs.php.net/?id=15788&edit=1
Bug #15790: Getting Parse error when trying to access page. I believe it's related to mysql
From: [EMAIL PROTECTED]
Operating system: Mac OS 10.1.3 (Darwin 5.3)
PHP version: 4.1.2
PHP Bug Type: MySQL related
Bug description: Getting Parse error when trying to access page. I believe it's
related to mysql
OS: Mac OS 10.1.3
Apache: 1.3.22 (DARWIN)
PHP: 4.1.2
mySQL: 3.23.48
This is the error I get when I try to accecss the page:
"Parse error: parse error in /Library/WebServer/Documents/
timemanagement/billing.php on line 2"
Code:
click here to enter another.";
exit;
}
?>
Billing
Client
Job Type
Time Spent (hrs)
Wage
Billable
Description
$client";
}
?>
Technical
Support
Programming
Accounting
Consultation
$20 x hr
$40 x hr
$60 x hr
$80 x hr
$100 x hr
Yes
No
Add new client:
{$employees[$i]}";
}
?>
--
Edit bug report at http://bugs.php.net/?id=15790&edit=1
--
Fixed in CVS:http://bugs.php.net/fix.php?id=15790&r=fixedcvs
Fixed in release:http://bugs.php.net/fix.php?id=15790&r=alreadyfixed
Need backtrace: http://bugs.php.net/fix.php?id=15790&r=needtrace
Try newer version: http://bugs.php.net/fix.php?id=15790&r=oldversion
Not developer issue: http://bugs.php.net/fix.php?id=15790&r=support
Expected behavior: http://bugs.php.net/fix.php?id=15790&r=notwrong
Not enough info: http://bugs.php.net/fix.php?id=15790&r=notenoughinfo
Submitted twice: http://bugs.php.net/fix.php?id=15790&r=submittedtwice
Bug #14860 Updated: PHP segfault in mysql driver
ID: 14860 Updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] Status: Open Bug Type: MySQL related Operating System: Solaris 8 PHP Version: 4.1.1 New Comment: We've had the same exact problem - specifically with mysql_fetch_array(), and with the exact same symptoms. Not predictable, random occurance, etc'. We're running PHP 4.1.1 as a static build for Apache 1.3.22 on RedHat Linux 6.1. MySQL version is 3.23.42 Previous Comments: [2002-01-12 09:25:24] [EMAIL PROTECTED] I'am having the same problem using apache2 and latest cvs. I see that ext/mysql/libmysql/ is always compiled with #define UNDEF_THREADS_HACK so producing a non thread safe mysql builtin library. Not using the builtin libmysql this problem is solved. Don't know if it's the same for win32 builds. I also noticed that build this libmysql the debug code is not turned off definig DBUG_OFF (?), is this intented ? [2002-01-04 17:14:49] [EMAIL PROTECTED] Running PHP under continuity (pthread based), and serving phpMyAdmin 2.2.2, connecting remotely to a 3.23.47 mysql database. The server randomly crashes(trace below), but not always. The seg fault doesn't seem to be related to load, length of server operation, etc. It can crash on the 1st or 80th load of a phpMyAdmin page, but is fairly reproducable. If the server is restarted, may operate normally right away or it may not. Backtrace: current thread: t@15 =>[1] _db_return_(_line_ = 167U, _sfunc_ = 0xfdefa014, _sfile_ = 0xfdefa010, _slevel_ = 0xfdefa00c), line 827 in "dbug.c" [2] vio_read(vio = 0x210ec8, buf = 0x2ba220 "^C", size = 4), line 167 in "violite.c" [3] my_real_read(net = 0x2ba018, complen = 0xfdefa11c), line 457 in "net.c" [4] my_net_read(net = 0x2ba018), line 603 in "net.c" [5] net_safe_read(mysql = 0x2ba018), line 288 in "libmysql.c" [6] mysql_real_connect(mysql = 0x2ba018, host = 0x2c6140 "sugar.makintosh.com", user = 0x2777a8 "phpbugs", passwd = 0x257c58 "phpbugs", db = (nil), port = 3306U, unix_socket = (nil), client_flag = 8325U), line 1517 in "libmysql.c" [7] php_mysql_do_connect(ht = 3, return_value = 0x211038, this_ptr = (nil), return_value_used = 1, tsrm_ls = 0x11c058, persistent = 0), line 646 in "php_mysql.c" [8] zif_mysql_connect(ht = 3, return_value = 0x211038, this_ptr = (nil), return_value_used = 1, tsrm_ls = 0x11c058), line 698 in "php_mysql.c" [9] execute(op_array = 0x192370, tsrm_ls = 0x11c058), line 1590 in "zend_execute.c" [10] execute(op_array = 0x17bce8, tsrm_ls = 0x11c058), line 2133 in "zend_execute.c" [11] zend_execute_scripts(type = 8, tsrm_ls = 0x11c058, retval = (nil), file_count = 3, ...), line 814 in "zend.c" [12] php_execute_script(primary_file = 0xfdf05b28, tsrm_ls = 0x11c058), line 1307 in "main.c" [13] capi_module_main(request_context = 0x121830, tsrm_ls = 0x11c058), line 411 in "capi.c" [14] php4_execute(t = 0xb0348, opts = 0x3f058), line 456 in "capi.c" [15] dlFtransaction_process(class = 4, t = 0xb0348), line 336 in "dl.c" [16] disFhttp_handler(p = 0xb0348), line 69 in "dispatch.c" [17] thrFthread(arg = 0xb0218), line 281 in "tpool.c" -- Edit this bug report at http://bugs.php.net/?id=14860&edit=1
Bug #15746 Updated: Process exec() is slow from webserver - running from shell is ok ...
ID: 15746
Updated by: [EMAIL PROTECTED]
Reported By: [EMAIL PROTECTED]
Status: Open
Bug Type: Performance problem
Operating System: Windows 2000 Server
PHP Version: 4.1.1
New Comment:
This is a frequently reported problem on the Gallery Users mailing list
(http://gallery.sourceforge.net/)
Previous Comments:
[2002-02-26 22:29:22] [EMAIL PROTECTED]
Summary:
Running a PHP script which calls exec() from withing Apache runs
terribly slow or times out. Running same from the command prompt
returns in seconds.
Details:
I (and other NT users) have run into performance issues running PHP
4.1.1 with the NETPBM distribution.When running thumbnailing
operations via. webpages, the performance (throughtput) of the system
is dismal.
Running the same PHP script manually from the command shell completes
operations in under a second which usually timeout when executed from a
webpage.
A full "ready to run" repro of this problem is available via. a small
ZIP file at http://www.green-bean.com/bugfiles/slowrepro.zip.; This
contains the required NETPBM files. If these are already installed on
your system, you can run the script below with slight modifications.
Thanks,
Nigel.
Repro:
http://www.green-bean.com/bugfiles/slowrepro.zip
//
// Location of your NETPBM distribution
// We're using
http://prdownloads.sourceforge.net/gallery/netpbm1.1-gallery1.0-win32.tgz
//
$pbmroot = "netpbm";
// JPG input file (from
http://www.green-bean.com/DallasChristmasHat.jpg)
$file = "DallasChristmasHat.jpg";
function fs_exec($cmd, &$results, &$status, &$time) {
// We can't redirect stderr with Windows. Hope that we won't need
to.
$time_st = time();
$x = exec("$cmd", $results, $status);
$time = time() - $time_st;
}
$quiet = "-quiet";
// JPEG to PNM
$cmd_to_pnm= "$pbmroot\\jpegtopnm $quiet $file > out\\$file.pnm";
print "Exec: $cmd_to_pnm\n";
fs_exec($cmd_to_pnm, $results, $status, $elapsed);
print "Elapsed: $elapsed secs\nStatus: $status";
// PNM to scaled PNM
$cmd_scale_pnm = "$pbmroot\\pnmscale $quiet -xysize 150 150
out\\$file.pnm > out\\$file.scale.pnm";
print "Exec: $cmd_scale_pnm\n";
fs_exec($cmd_scale_pnm, $results, $status, $elapsed);
print "Elapsed: $elapsed secs\nStatus: $status";
// PNM scaled to JPG
$cmd_to_jpg= "$pbmroot\\ppmtojpeg $quiet out\\$file.scale.pnm
--quality=150 > out\\tn_$file";
print "Exec: $cmd_to_jpg\n";
fs_exec($cmd_to_jpg, $results, $status, $elapsed);
print "Elapsed: $elapsed secs\nStatus: $status";
?>
--
Edit this bug report at http://bugs.php.net/?id=15746&edit=1
Bug #15791: set_error_handler() can not be used to set error control to a class function
From: [EMAIL PROTECTED]
Operating system: All
PHP version: 4.1.1
PHP Bug Type: Feature/Change Request
Bug description: set_error_handler() can not be used to set error control to a class
function
Heres the long and short of it: set_error_handler() wants a string as the
name of the function that will handle errors. However, if you create a
class and try to assign error handling to a function within the class,
there is no way to reference that function.
For example
class ApplicationObject {
var $error_List as array();
function ApplicationObject() {
set_error_handler('trapError');
}
function trapError($err_no, $err_str, $err_file, $err_line, $err_context)
{
echo "Trap error caught error ".$err_no;
}
}
// *** Now create the object ***
$app = new ApplicationObject();
trigger_error ("Cannot divide by zero", E_USER_ERROR);
This doesn't work. Nor does changing set_error_handler('trapError') to
set_error_handler('$this->trapError'). Removing the quotes just executes
the function. Removing the assignment of error handling outside of the
class like so:
$app = new ApplicationObject();
set_error_handler('$app->trapError');
trigger_error ("Cannot divide by zero", E_USER_ERROR);
Since the error handling function will need access to $error_List and I
sure dont want to GLOBAL it, this kind of makes things difficult.
--
Edit bug report at http://bugs.php.net/?id=15791&edit=1
--
Fixed in CVS:http://bugs.php.net/fix.php?id=15791&r=fixedcvs
Fixed in release:http://bugs.php.net/fix.php?id=15791&r=alreadyfixed
Need backtrace: http://bugs.php.net/fix.php?id=15791&r=needtrace
Try newer version: http://bugs.php.net/fix.php?id=15791&r=oldversion
Not developer issue: http://bugs.php.net/fix.php?id=15791&r=support
Expected behavior: http://bugs.php.net/fix.php?id=15791&r=notwrong
Not enough info: http://bugs.php.net/fix.php?id=15791&r=notenoughinfo
Submitted twice: http://bugs.php.net/fix.php?id=15791&r=submittedtwice
Bug #13556 Updated: PHP4 should be able to use dso version of cracklib
ID: 13556 Updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] -Status: Closed +Status: Open Bug Type: *Compile Issues -Operating System: +Operating System: linux -PHP Version: 4.0.6 +PHP Version: 4.1.1 & 4.1.2 -Assigned To: +Assigned To: sniper New Comment: This was "fixed" in CVS, but incorrectly. Please apply the following patch to the crack extension: --BEGIN_PATCH-- === RCS file: /repository/php4/ext/crack/config.m4,v retrieving revision 1.6 diff -u -u -r1.6 config.m4 --- config.m4 30 Nov 2001 18:59:28 - 1.6 +++ config.m4 28 Feb 2002 19:33:14 - @@ -8,7 +8,7 @@ if test "$PHP_CRACK" != "no"; then for i in /usr/local/lib /usr/lib $PHP_CRACK/lib $PHP_CRACK/cracklib; do - test -f $i/lib/libcrack.$SHLIB_SUFFIX_NAME -o -f $i/libcrack.a && CRACK_LIBDIR=$i + test -f $i/libcrack.$SHLIB_SUFFIX_NAME -o -f $i/libcrack.a && CRACK_LIBDIR=$i done for i in /usr/local/include /usr/include $PHP_CRACK/include $PHP_CRACK/cracklib; do --END_PATCH-- The code that searched for the shared objects was looking under a subdirectory lib, so instead of looking in /usr/lib it was looking in /usr/lib/lib. This patch fixes the problem. Previous Comments: [2001-10-11 20:21:03] [EMAIL PROTECTED] Fixed in CVS. Fix will be in PHP 4.1 --Jani [2001-10-05 03:12:59] [EMAIL PROTECTED] Configure only checks for the static libcrack.a when it would be possible to use libcrack.so. -- Edit this bug report at http://bugs.php.net/?id=13556&edit=1
Bug #12465 Updated: posix_* issuing Warnings, no error code.
ID: 12465 Updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] Status: Bogus Bug Type: POSIX related Operating System: Linux PHP Version: 4.0.6 New Comment: It´s still nonsense to write an error-message! stat() *IS STILL USED* for checking the existence of files. Why do I have to *suppress* error-messages?! PHP should not *generate* them in the first! *If* you choose to implement stat() and name it after the C-function, then stat() should behave as closely as possible like its C-equivalent. Previous Comments: [2002-02-04 02:46:54] [EMAIL PROTECTED] It returns false. You need to get rid of error messages with @... [2001-07-30 09:24:17] [EMAIL PROTECTED] hi, I tried to use some of the posix_* functions to work with user-accounts on the system, like "posix_getpwnam()" and "posix_getpwuid()". I expected to get an error-code back (like Failed or FALSE) for pwnames or pwuids which do not exist in /etc/passwd. Instead, PHP will write a warning message in my html-output: : Warning: posix_getpwuid(4711) failed with 'Success' in : /data/home/webmaster/admin/admin.php : on line 197 and, what I think is strange, will "fail with ´Success´". Could you please modify the posix_getpw* functions in a way that they 1) do not write strange warning-messages and 2) return a NULL-Value or FALSE, where the unix getpw*(3) will return NULL (just like documented in the man-page) thanks in advance, herbert rosmanith [EMAIL PROTECTED] -- Edit this bug report at http://bugs.php.net/?id=12465&edit=1
Bug #15009 Updated: Compile Error in file gd.c
ID: 15009 Updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] Status: Open Bug Type: Compile Failure Operating System: Linux (Kernel 2.4.17) PHP Version: 4.1.1 New Comment: This problem also occurs with GD 2.0.1, on earlier and later kernels (on separate machines), and on machines which are both fresh installs and which have had PHP (and older versions of gd) installed before. Previous Comments: [2002-01-12 16:09:46] [EMAIL PROTECTED] If i compiled php with gd. There was an error while compiling gd.c: gd.c:92: conflicting types for `gdIOCtx' /usr/local/include/gd_io.h:18: previous declaration of `gdIOCtx' It works, if I've uncomment the line 92 in gd.c. I compiled previously gd 1.8.4 -- Edit this bug report at http://bugs.php.net/?id=15009&edit=1
Bug #15792: sapi_apache2.c:247
From: [EMAIL PROTECTED] Operating system: GNU/Linux PHP version: 4.1.2 PHP Bug Type: Compile Failure Bug description: sapi_apache2.c:247 in sapi/apache2filter/sapi_apache2.c sapi_apache2.c: In function `php_apache_sapi_register_variables': sapi_apache2.c:148: warning: initialization discards qualifiers from pointer target type sapi_apache2.c: In function `php_input_filter': sapi_apache2.c:247: incompatible type for argument 4 of `ap_get_brigade' sapi_apache2.c:247: too few arguments to function `ap_get_brigade' sapi_apache2.c: In function `php_register_hook': sapi_apache2.c:408: warning: passing arg 2 of `ap_register_input_filter' from incompatible pointer type -- Edit bug report at http://bugs.php.net/?id=15792&edit=1 -- Fixed in CVS:http://bugs.php.net/fix.php?id=15792&r=fixedcvs Fixed in release:http://bugs.php.net/fix.php?id=15792&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=15792&r=needtrace Try newer version: http://bugs.php.net/fix.php?id=15792&r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=15792&r=support Expected behavior: http://bugs.php.net/fix.php?id=15792&r=notwrong Not enough info: http://bugs.php.net/fix.php?id=15792&r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=15792&r=submittedtwice
Bug #15793: inconsistent behaviour for __FILE__ constant
From: [EMAIL PROTECTED] Operating system: Solaris 8 PHP version: 4.1.2 PHP Bug Type: Scripting Engine problem Bug description: inconsistent behaviour for __FILE__ constant __FILE__ constant behaviour in PHP seems to have some problems that are Solaris specific, and some problems that are just general. Put the following in a file "test.php": Try: php test.php The expected result is: file /test.php The result on both Linux and Solaris PHP is: file test.php Now call the same php script VIA the web. The result will be the expected "file /test.php" on both Linux and Solaris. If this isn't a bug, it seems like maybe an inconsistency in PHP behaviour under different operating modes. However, the problems continue. Change the original test.php script above to: And in tmp/test1.php put the following: Access test.php VIA the web. I expect to see: file /cs/home/jas/www//test.php file /cs/home/jas/www/tmp/test1.php On Linux that's what you'll see. On Solaris, I see: file /cs/home/jas/www/test.php file /tmp/test1.php If I specify a full path to "tmp/test1.php" -- /cs/home/jas/www/tmp/test1.php, then the result is as expected. What's going on with __FILE__? Am I misunderstanding its use? -- Edit bug report at http://bugs.php.net/?id=15793&edit=1 -- Fixed in CVS:http://bugs.php.net/fix.php?id=15793&r=fixedcvs Fixed in release:http://bugs.php.net/fix.php?id=15793&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=15793&r=needtrace Try newer version: http://bugs.php.net/fix.php?id=15793&r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=15793&r=support Expected behavior: http://bugs.php.net/fix.php?id=15793&r=notwrong Not enough info: http://bugs.php.net/fix.php?id=15793&r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=15793&r=submittedtwice
Bug #14529 Updated: script doesn't always finish output
ID: 14529 Updated by: [EMAIL PROTECTED] -Summary: script doesn't always finish output Reported By: [EMAIL PROTECTED] Status: Open Bug Type: Output Control Operating System: Linux RH 7.2 -PHP Version: 4.1.1 +PHP Version: 4.1.2 New Comment: We are getting closer, I've got a small team of people at this end working on solving this bug and are now trying to dedicate much more time and money into getting this bug solved! (Our business success depends on it) The problem, we only know PHP programming well and are weaker in the server end of things (I'm the only one with some Linux knowledge) so we need your help to solve this. Here is a summary of all things done so far to narrow this down (much already due to your help). We've seperated everything into sections below. PROBLEM: While running some more complex PHP scripts they will not work on anything newer than 4.0.6 but works 100% on 4.0 -> 4.0.6. The page simply stops displaying part ways through a script (usually right in the middle of an echo statement or between echo statements). The script seemed to finish commands past the point of where it stopped but is only known through the sessions (seeing nothing else is being displayed to screen) But, we've discovered when this crash happens where it has been giving us problems as well so we can not confirm this anymore. APACHE ERROR_LOG: When a page is loaded with my problem scripts I get either 1 or 2 errors in my apache error_log: [date] [notice] child pid exit signal Segmentation fault (11) (if two errors the second is the same except different pid number) SCRIPTS CAUSING CRASHES: These scripts that cause the problems have been in development for almost 3 years now and are fairly complex. Not all scripts give me hassles, but from the tests I have done, it appears only scripts that have sessions AND use fairly large hashes (passed into and out from sessions via serialize() functions) is where I have problems. Even complex or large scripts without this in it seem to run fine. All scripts run fine in PHP versions 4.0.6 or older but not since 4.1.0 or newer (up to 4.2.2) PHP compiling configurations: Have tried compiling with various combinations of options trying to narrow down if a particular option is what is causing the problems. So far I can not find anything consistent. GDB RESULTS: You gave me the link to the generating bug-traces and I'm having problems getting it to run apache properly. I could not find a core file on my server. (Apache isn't generating them, or I simply can not find them). So I've been using your suggested method of running the script through gdb itself. Here is what I've done so far. Stopped the apache server (tested going to web page and confirmed it was down), I then typed: gdb /usr/sbin/httpd run -X (from inside the gdb prompt) It then says it's starting /usr/sbin/httpd with a new thread and then starts a new blank line (while it's waiting for an apache crash signal). If at this point I use my browser and go to plain html web page it works (so that tells me the apache server is running again), BUT if I go to a php page, I get a page not available error. This means I am unable to load the pages that will make apache crash. What am I doing wrong to get apache running with PHP through the gdb? Also, once httpd is started through gdb, how do I stop it and exit gdb - I can CNTL-C but apache keeps running and I can't find the process to kill it. There must be a cleaner way. Previous Comments: [2002-02-18 13:29:41] [EMAIL PROTECTED] I think i had something similar happen to me. It would just stop printing to the screen and either spit out crazy characters or stop altogether. I commented out every line and brought it back one by one until i located the problem. Although i'm still not exactly sure what's going on I might have a solution. (worked in my case) I put a flush() every now and then. It seemed to fix the problem. [2002-02-15 20:23:31] [EMAIL PROTECTED] I've followed the instructions on the gdb backtrace page but I can not find a core file anywhere on the site. When I tried running httpd -X in the gdb itself I can not access the page. I'm using RedHat 7.2 on my test server. I ran the command (to test it) /usr/sbin/httpd -X and it starts fine and no prompt comes back (which I think is normal). The moment I open a webpage it returns the line: Segmentation fault and then goes back to the command prompt. So this would tell me I found the right command line to run but when I try: gdb /usr/sbin/httpd run -X (from inside the gdb prompt) it says starting new thread and then locks up. If I try opening a web page it comes up as not found (just like it does when the httpd
Bug #10833 Updated: Hyperlink tag when split on multiple lines, session ids are not propagated
ID: 10833 Updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] Status: Closed Bug Type: Session related Operating System: Linux PHP Version: 4.0.5 New Comment: This problem exists also in 4.0.6 ' will work will not work Previous Comments: [2001-08-06 08:48:12] [EMAIL PROTECTED] No feedback. And the latest CVS works just fine on this kind of urls. --Jani [2001-07-10 05:05:45] [EMAIL PROTECTED] Could you give a snapshot a try? http://snaps.php.net/ The scanner is supposed to ignore whitespace. [2001-05-12 17:24:31] [EMAIL PROTECTED] This applicable for browsers that don't allow cookies: The following is not working: "> Menu But if href is on the same line as tag, it works: "> Menu -- Edit this bug report at http://bugs.php.net/?id=10833&edit=1
Bug #15794: vurtual host path is not detected
From: [EMAIL PROTECTED] Operating system: IRIX 6.5 PHP version: 4.1.2 PHP Bug Type: Apache related Bug description: vurtual host path is not detected I could not find this problem reported so I hope I am not duplicating the report of this issue. I have compiled both 4.1.1 and 4.1.2 with the same configuration flags that I used for 4.0.6 and now the virtual host document path is not properly recognized. I am running php as an CGI executable outside of the webserver document root, and configured it with the following flags: ./configure --cache-file=/dev/null \ --prefix=/usr/local \ --enable-discard-path \ --enable-track-vars \ --enable-safe-mode \ --with-exec-dir=/usr/local/php/exec/ \ --with-pgsql=/usr/local/postgres \ --without-mysql \ --without-msql \ --with-gd=/usr/local/src/gd-1.8.4 \ --enable-gd-native-ttf \ --with-zlib=/usr/local \ --with-png-dir=/usr/local \ --with-freetype-dir=/usr/local The page that I am testing with works find if called from the main server path but not from the virtual host URL. The following is a quick description of the Apache setup: sandstorm.cosc.brocku.ca has docroot /www admin.cosc.brocku.ca has docroot /www/admin when I run the script: http://admin.cosc.brocku.ca/tools/scripts/cslookup.php I get and error in the php error log stating that /www/tools/scripts/cslookup.php can not be found when the docroot of the virtualhost should be /www/admin not /www. I have both versions 4.1.2 and 4.0.6 on the system for testing and the same Apache configuration works with the 4.0.6 and not the 4.1.2 version of PHP. -- Edit bug report at http://bugs.php.net/?id=15794&edit=1 -- Fixed in CVS:http://bugs.php.net/fix.php?id=15794&r=fixedcvs Fixed in release:http://bugs.php.net/fix.php?id=15794&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=15794&r=needtrace Try newer version: http://bugs.php.net/fix.php?id=15794&r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=15794&r=support Expected behavior: http://bugs.php.net/fix.php?id=15794&r=notwrong Not enough info: http://bugs.php.net/fix.php?id=15794&r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=15794&r=submittedtwice
Bug #15793 Updated: inconsistent behaviour for __FILE__ constant
ID: 15793 Updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] Status: Open Bug Type: Scripting Engine problem Operating System: Solaris 8 PHP Version: 4.1.2 New Comment: I'm experiencing the exact same problem, and it's making horde/imp a no-go. The new horde 2.0 and imp 3.0 is using __FILE__ everywhere in the code, and due to this bug it just won't work without modifying a lot of the code. /pb Previous Comments: [2002-02-28 16:00:08] [EMAIL PROTECTED] __FILE__ constant behaviour in PHP seems to have some problems that are Solaris specific, and some problems that are just general. Put the following in a file "test.php": Try: php test.php The expected result is: file /test.php The result on both Linux and Solaris PHP is: file test.php Now call the same php script VIA the web. The result will be the expected "file /test.php" on both Linux and Solaris. If this isn't a bug, it seems like maybe an inconsistency in PHP behaviour under different operating modes. However, the problems continue. Change the original test.php script above to: And in tmp/test1.php put the following: Access test.php VIA the web. I expect to see: file /cs/home/jas/www//test.php file /cs/home/jas/www/tmp/test1.php On Linux that's what you'll see. On Solaris, I see: file /cs/home/jas/www/test.php file /tmp/test1.php If I specify a full path to "tmp/test1.php" -- /cs/home/jas/www/tmp/test1.php, then the result is as expected. What's going on with __FILE__? Am I misunderstanding its use? -- Edit this bug report at http://bugs.php.net/?id=15793&edit=1
Bug #15794 Updated: virtual host path is not detected
ID: 15794 Updated by: [EMAIL PROTECTED] -Summary: vurtual host path is not detected Reported By: [EMAIL PROTECTED] Status: Open Bug Type: Apache related Operating System: IRIX 6.5 PHP Version: 4.1.2 New Comment: Just correcting spelling in the Summary so that a search will find this topic properly. Previous Comments: [2002-02-28 16:55:51] [EMAIL PROTECTED] I could not find this problem reported so I hope I am not duplicating the report of this issue. I have compiled both 4.1.1 and 4.1.2 with the same configuration flags that I used for 4.0.6 and now the virtual host document path is not properly recognized. I am running php as an CGI executable outside of the webserver document root, and configured it with the following flags: ./configure --cache-file=/dev/null \ --prefix=/usr/local \ --enable-discard-path \ --enable-track-vars \ --enable-safe-mode \ --with-exec-dir=/usr/local/php/exec/ \ --with-pgsql=/usr/local/postgres \ --without-mysql \ --without-msql \ --with-gd=/usr/local/src/gd-1.8.4 \ --enable-gd-native-ttf \ --with-zlib=/usr/local \ --with-png-dir=/usr/local \ --with-freetype-dir=/usr/local The page that I am testing with works find if called from the main server path but not from the virtual host URL. The following is a quick description of the Apache setup: sandstorm.cosc.brocku.ca has docroot /www admin.cosc.brocku.ca has docroot /www/admin when I run the script: http://admin.cosc.brocku.ca/tools/scripts/cslookup.php I get and error in the php error log stating that /www/tools/scripts/cslookup.php can not be found when the docroot of the virtualhost should be /www/admin not /www. I have both versions 4.1.2 and 4.0.6 on the system for testing and the same Apache configuration works with the 4.0.6 and not the 4.1.2 version of PHP. -- Edit this bug report at http://bugs.php.net/?id=15794&edit=1
Bug #15768 Updated: FastCgi not picking up envrionemnt variables
ID: 15768
Updated by: [EMAIL PROTECTED]
Reported By: [EMAIL PROTECTED]
Status: Open
Bug Type: PHP options/info functions
Operating System: Linux 2.2.20
PHP Version: 4.1.1
New Comment:
Sorry, typo, its HTTP_SERVER_VARS
Register globals is turned on so there is no reason why the script
should only return one key/value.
This seems to be a bug in the 4.1.x branch as the same script produces
the expected output in 4.0.x
Thx
Previous Comments:
[2002-02-28 02:07:13] [EMAIL PROTECTED]
I don't see how this is a support question. In fact, there is no
question at all in this report. Granted, his example code should
probably use $HTTP_SERVER_VARS, but if it actually behaves like he says
then it appears to be a bug.
[2002-02-28 02:06:32] [EMAIL PROTECTED]
oops..I clicked wrong link. Anyways, your example script
is pretty much bogus. There is no such variable as HTTP_SERV_VARS. Try
this instead:
$value) {
echo $key.":".$value."";
}
?>
[2002-02-28 02:04:01] [EMAIL PROTECTED]
The bug system is not the appropriate forum for asking support
questions. For a list of a range of more appropriate places to ask
for help using PHP, please visit http://www.php.net/support.php
[2002-02-27 19:03:17] [EMAIL PROTECTED]
The following script:
$value) {
echo $key.":".$value."";
}
?>
Produces the following output:
PHP_SELF=/dump_globals.php4
Same script of PHP 4.0.x works fine.
Seems to be consistent with the 4.1.x branch.
Server: Zeus 3.4r2
Compile Options:
./configure --prefix=/usr/local/php4 --with-regex=system
--enable-calendar --with-iodbc --with-dom --with-curl --with-openssl
--with-db2 --with-iconv --enable-filepro --enable-ftp --with-gettext
--enable-sysvsem --enable-sysvshm --enable-track-vars
--enable-trans-sid --disable-debug --with-gd=/usr --with-imap=/usr
--with-ldap=/usr --with-mm=/usr --with-mysql=/usr --with-regex=system
--with-pcre-regex=/usr --with-pgsql=/usr --enable-sockets --with-ttf
--enable-freetype-4bit-antialias-hack --with-t1lib --with-zlib
--enable-memory-limit --with-fastcgi=/usr/local/fcgi/ --with-pear
--enable-mbstring --enable-shmop --enable-exif --enable-bcmath
--enable-safemode --with-jpeg-dir=/usr --with-png-dir=/usr
--with-xpm-dir=/usr --with-xslt --with-xslt-sablot --with-mhash
--with-mcrypt=/usr/local
--with-tsrm-pth --enable-wddx --enable-shared=false
Thx
--
Edit this bug report at http://bugs.php.net/?id=15768&edit=1
Bug #15795: bug in dynamic linker ld.so
From: [EMAIL PROTECTED] Operating system: redhat 6.1 PHP version: 4.1.2 PHP Bug Type: *Configuration Issues Bug description: bug in dynamic linker ld.so Just upgrading from 4.1.1 to 4.1.2, but during the configure stage, this error is featured in the checks. "checking for mkfifo... BUG IN DYNAMIC LINKER ld.so: dl-minimal.c: 69: malloc: As sertion `page != ((void *) -1)' failed! no" The configure then completes as normal, but i daren't carry on with the make because of the error above. My configure line is/are: ./configure --prefix=/usr/local/php --with-config-file-path=/usr/local/php --with-apxs=/usr/sbin/apxs --enable-track-vars --enable-magic-quotes --disable-debug --with-mcrypt=/usr/local/lib --with-dom=/usr/local/lib --with-pcre --with-zlib --enable-sockets Any ideas as to what that might be? Is it safe to continue with the make and upgrade? -- Edit bug report at http://bugs.php.net/?id=15795&edit=1 -- Fixed in CVS:http://bugs.php.net/fix.php?id=15795&r=fixedcvs Fixed in release:http://bugs.php.net/fix.php?id=15795&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=15795&r=needtrace Try newer version: http://bugs.php.net/fix.php?id=15795&r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=15795&r=support Expected behavior: http://bugs.php.net/fix.php?id=15795&r=notwrong Not enough info: http://bugs.php.net/fix.php?id=15795&r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=15795&r=submittedtwice
Bug #14529 Updated: script doesn't always finish output
ID: 14529 Updated by: [EMAIL PROTECTED] -Summary: script doesn't always finish output Reported By: [EMAIL PROTECTED] Status: Open Bug Type: Output Control Operating System: Linux RH 7.2 PHP Version: 4.1.2 New Comment: Regarding the configure line and your MySQL problems. You should NEVER (okay this is my opinion) use the bundled MySQL libs. On your configure line you should do --with-mysql=/usr | --with-mysql=/usr/local Just depends on where it put your libs, which you can find like so [root@somemachine /]# ldconfig -p | grep mysql libmysqlclient.so.10 (libc6) => /usr/local/lib/mysql/libmysqlclient.so.10 libmysqlclient.so (libc6) => /usr/local/lib/mysql/libmysqlclient.so I think the RPM puts it in /usr. -Chris Previous Comments: [2002-02-28 16:27:48] [EMAIL PROTECTED] We are getting closer, I've got a small team of people at this end working on solving this bug and are now trying to dedicate much more time and money into getting this bug solved! (Our business success depends on it) The problem, we only know PHP programming well and are weaker in the server end of things (I'm the only one with some Linux knowledge) so we need your help to solve this. Here is a summary of all things done so far to narrow this down (much already due to your help). We've seperated everything into sections below. PROBLEM: While running some more complex PHP scripts they will not work on anything newer than 4.0.6 but works 100% on 4.0 -> 4.0.6. The page simply stops displaying part ways through a script (usually right in the middle of an echo statement or between echo statements). The script seemed to finish commands past the point of where it stopped but is only known through the sessions (seeing nothing else is being displayed to screen) But, we've discovered when this crash happens where it has been giving us problems as well so we can not confirm this anymore. APACHE ERROR_LOG: When a page is loaded with my problem scripts I get either 1 or 2 errors in my apache error_log: [date] [notice] child pid exit signal Segmentation fault (11) (if two errors the second is the same except different pid number) SCRIPTS CAUSING CRASHES: These scripts that cause the problems have been in development for almost 3 years now and are fairly complex. Not all scripts give me hassles, but from the tests I have done, it appears only scripts that have sessions AND use fairly large hashes (passed into and out from sessions via serialize() functions) is where I have problems. Even complex or large scripts without this in it seem to run fine. All scripts run fine in PHP versions 4.0.6 or older but not since 4.1.0 or newer (up to 4.2.2) PHP compiling configurations: Have tried compiling with various combinations of options trying to narrow down if a particular option is what is causing the problems. So far I can not find anything consistent. GDB RESULTS: You gave me the link to the generating bug-traces and I'm having problems getting it to run apache properly. I could not find a core file on my server. (Apache isn't generating them, or I simply can not find them). So I've been using your suggested method of running the script through gdb itself. Here is what I've done so far. Stopped the apache server (tested going to web page and confirmed it was down), I then typed: gdb /usr/sbin/httpd run -X (from inside the gdb prompt) It then says it's starting /usr/sbin/httpd with a new thread and then starts a new blank line (while it's waiting for an apache crash signal). If at this point I use my browser and go to plain html web page it works (so that tells me the apache server is running again), BUT if I go to a php page, I get a page not available error. This means I am unable to load the pages that will make apache crash. What am I doing wrong to get apache running with PHP through the gdb? Also, once httpd is started through gdb, how do I stop it and exit gdb - I can CNTL-C but apache keeps running and I can't find the process to kill it. There must be a cleaner way. [2002-02-18 13:29:41] [EMAIL PROTECTED] I think i had something similar happen to me. It would just stop printing to the screen and either spit out crazy characters or stop altogether. I commented out every line and brought it back one by one until i located the problem. Although i'm still not exactly sure what's going on I might have a solution. (worked in my case) I put a flush() every now and then. It seemed to fix the problem. [2002-02-15 20:23:31] [EMAIL PROTECTED] I've followed the instructions on the gdb backtrace page but I can not find a core file anywhere on the site. When I t
Bug #15764 Updated: mysql_real_connect client flags: compression & SSL
ID: 15764
Updated by: [EMAIL PROTECTED]
Reported By: [EMAIL PROTECTED]
Status: Open
Bug Type: Feature/Change Request
Operating System: all
PHP Version: 4.0CVS-2002-02-27
New Comment:
Would this patch be ok? I am not sure when these constants were added
to MYSQL, I could not find them in the mysql docs. I know for sure
that the >4 series has them though...
diff ../php4-orig/ext/mysql/php_mysql.c ext/mysql/php_mysql.c
344a345,352
> REGISTER_LONG_CONSTANT("MYSQL_CLIENT_SSL", CLIENT_SSL, CONST_CS
| CONST_PERSISTENT);
> REGISTER_LONG_CONSTANT("MYSQL_CLIENT_COMPRESS",
CLIENT_COMPRESS, CONST_CS | CONST_PERSISTENT);
> REGISTER_LONG_CONSTANT("MYSQL_CLIENT_FOUND_ROWS",
CLIENT_FOUND_ROWS, CONST_CS | CONST_PERSISTENT);
> REGISTER_LONG_CONSTANT("MYSQL_CLIENT_NO_SCHEMA",
CLIENT_NO_SCHEMA, CONST_CS | CONST_PERSISTENT);
> REGISTER_LONG_CONSTANT("MYSQL_CLIENT_INTERACTIVE ",
CLIENT_INTERACTIVE, CONST_CS | CONST_PERSISTENT);
> REGISTER_LONG_CONSTANT("MYSQL_CLIENT_ODBC", CLIENT_ODBC,
CONST_CS | CONST_PERSISTENT);
> REGISTER_LONG_CONSTANT("MYSQL_CLIENT_IGNORE_SPACE",
CLIENT_IGNORE_SPACE,CONST_CS | CONST_PERSISTENT);
>
436a445
> int client_flags = 0;
439c448
< zval **z_host=NULL, **z_user=NULL, **z_passwd=NULL,
**z_new_link=NULL;
---
> zval **z_host=NULL, **z_user=NULL, **z_passwd=NULL,
**z_new_link=NULL, **z_client_flags=NULL;
441a451
>
495a506,518
> case 5: {
> if (zend_get_parameters_ex(5,
&z_host, &z_user, &z_passwd, &z_new_link, &z_client_flags) == FAILURE)
{
>
MYSQL_DO_CONNECT_RETURN_FALSE();
> }
>
convert_to_string_ex(z_user);
>
convert_to_string_ex(z_passwd);
>
convert_to_long_ex(z_client_flags);
> user = Z_STRVAL_PP(z_user);
> passwd =
Z_STRVAL_PP(z_passwd);
> new_link =
Z_BVAL_PP(z_new_link);
> client_flags =
Z_LVAL_PP(z_client_flags);
> }
> break;
569c592
< if (mysql_real_connect(&mysql->conn, host,
user, passwd, NULL, port, socket, 0)==NULL) {
---
> if (mysql_real_connect(&mysql->conn, host,
user, passwd, NULL, port, socket, client_flags)==NULL) {
609c632
< if (mysql_real_connect(le->ptr, host,
user, passwd, NULL, port, socket, 0)==NULL) {
---
> if (mysql_real_connect(le->ptr, host,
user, passwd, NULL, port, socket, client_flags)==NULL) {
662c685
< if (mysql_real_connect(&mysql->conn, host, user,
passwd, NULL, port, socket, 0)==NULL) {
---
> if (mysql_real_connect(&mysql->conn, host, user,
passwd, NULL, port, socket, client_flags)==NULL) {
Previous Comments:
[2002-02-27 14:26:08] [EMAIL PROTECTED]
mysql with a VERSION_ID > 40001 (maybe 4) supports the following
clientflags
CLIENT_COMPRESS Use compression protocol.
CLIENT_FOUND_ROWS Return the number of found (matched) rows, not the
number of affected rows.
CLIENT_IGNORE_SPACE Allow spaces after function names. Makes all
functions names reserved words.
CLIENT_INTERACTIVE Allow interactive_timeout seconds (instead of
wait_timeout seconds) of inactivity before closing the connection.
CLIENT_NO_SCHEMA Don't allow the db_name.tbl_name.col_name syntax.
This is for ODBC. It causes the parser to generate an error if you use
that syntax, which is useful for trapping bugs in some ODBC programs.
CLIENT_ODBC The client is an ODBC client. This changes mysqld to be
more ODBC-friendly.
CLIENT_SSL Use SSL (encrypted protocol).
It would be nice to add CLIENT_SSL and CLIENT_COMPRESS options to the
php_mysql_do_connect() ...
--
Edit this bug report at http://bugs.php.net/?id=15764&edit=1
Bug #15743 Updated: On attempted opening of Session, browser gives me HTTP 500 error
ID: 15743 Updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] Status: Bogus Bug Type: Session related Operating System: Windows 2000 Advanced Server PHP Version: 4.1.1 New Comment: Sorry, wrong forum. And I did fix it by simply creating a new folder under the installed drive (D:) which was /TMP Sorry for any inconveniences Previous Comments: [2002-02-27 03:45:18] [EMAIL PROTECTED] The bug system is not the appropriate forum for asking support questions. For a list of a range of more appropriate places to ask for help using PHP, please visit http://www.php.net/support.php [2002-02-26 19:47:02] [EMAIL PROTECTED] PHP works great except for sessions. Whenever I put session_start(); or session_register(); i get an HTTP 500 error. Nothing will work either. I have tried evry Session script and every possible way of registering a PHP session but absoutely nothing works -- Edit this bug report at http://bugs.php.net/?id=15743&edit=1
Bug #15790 Updated: Getting Parse error when trying to access page. I believe it's related to mysql
ID: 15790
Updated by: [EMAIL PROTECTED]
-Summary: Getting Parse error when trying to access page. I
believe it's related to mysql
Reported By: [EMAIL PROTECTED]
-Status: Open
+Status: Feedback
Bug Type: MySQL related
Operating System: Mac OS 10.1.3 (Darwin 5.3)
PHP Version: 4.1.2
New Comment:
Please give a SHORTER example of the code which doesn't work.
Anyway, if that's the file billing.php, then the line 2 would be the
empty one ...
Previous Comments:
[2002-02-28 14:20:40] [EMAIL PROTECTED]
OS: Mac OS 10.1.3
Apache: 1.3.22 (DARWIN)
PHP: 4.1.2
mySQL: 3.23.48
This is the error I get when I try to accecss the page:
"Parse error: parse error in /Library/WebServer/Documents/
timemanagement/billing.php on line 2"
Code:
click here to enter another.";
exit;
}
?>
Billing
Client
Job Type
Time Spent (hrs)
Wage
Billable
Description
$client";
}
?>
Technical
Support
Programming
Accounting
Consultation
$20 x hr
$40 x hr
$60 x hr
$80 x hr
$100 x hr
Yes
No
Add new client:
{$employees[$i]}";
}
?>
--
Edit this bug report at http://bugs.php.net/?id=15790&edit=1
Bug #15796: mail() doesn't work with qmail
From: [EMAIL PROTECTED]
Operating system: RedHat 7.2
PHP version: 4.1.2
PHP Bug Type: Mail related
Bug description: mail() doesn't work with qmail
On my apache 1.3.23 and php 4.1.2 system the mail() function does not send
mail, although the local mail system (QMail) is functioning in every other
capacity. I have tried the suggestions of changing the "sendmail_path"
to:
/usr/sbin/sendmail
/var/qmail/bin/sendmail
and
/var/qmail/bin/qmail-inject
(I have also tried the sendmail wrapper commands with -t and qmail-inject
with -h)
This short script segment:
if (mail($to, $sub, $body)){
print ("MAIL SENT");
} else {
print ("MAIL DIED");
}
always returns "MAIL DIED".
Qmail logs and mail logs show nothing.
--
Edit bug report at http://bugs.php.net/?id=15796&edit=1
--
Fixed in CVS:http://bugs.php.net/fix.php?id=15796&r=fixedcvs
Fixed in release:http://bugs.php.net/fix.php?id=15796&r=alreadyfixed
Need backtrace: http://bugs.php.net/fix.php?id=15796&r=needtrace
Try newer version: http://bugs.php.net/fix.php?id=15796&r=oldversion
Not developer issue: http://bugs.php.net/fix.php?id=15796&r=support
Expected behavior: http://bugs.php.net/fix.php?id=15796&r=notwrong
Not enough info: http://bugs.php.net/fix.php?id=15796&r=notenoughinfo
Submitted twice: http://bugs.php.net/fix.php?id=15796&r=submittedtwice
Bug #15791 Updated: set_error_handler() can not be used to set error control to a class function
ID: 15791
Updated by: [EMAIL PROTECTED]
Reported By: [EMAIL PROTECTED]
-Status: Open
+Status: Analyzed
Bug Type: Feature/Change Request
Operating System: All
PHP Version: 4.1.1
New Comment:
This request is valid (it's a limitation of the current implementation
in zend_builtin_functions.c) but your analysis wasn't very accurat.
Methods of Static Classes or objects are normally passed with the
syntax array($obj, 'method'); or array('class', 'method');
Anyway, it's an open feature request.
Previous Comments:
[2002-02-28 14:26:17] [EMAIL PROTECTED]
Heres the long and short of it: set_error_handler() wants a string as
the name of the function that will handle errors. However, if you
create a class and try to assign error handling to a function within
the class, there is no way to reference that function.
For example
class ApplicationObject {
var $error_List as array();
function ApplicationObject() {
set_error_handler('trapError');
}
function trapError($err_no, $err_str, $err_file, $err_line,
$err_context) {
echo "Trap error caught error ".$err_no;
}
}
// *** Now create the object ***
$app = new ApplicationObject();
trigger_error ("Cannot divide by zero", E_USER_ERROR);
This doesn't work. Nor does changing set_error_handler('trapError') to
set_error_handler('$this->trapError'). Removing the quotes just
executes the function. Removing the assignment of error handling
outside of the class like so:
$app = new ApplicationObject();
set_error_handler('$app->trapError');
trigger_error ("Cannot divide by zero", E_USER_ERROR);
Since the error handling function will need access to $error_List and I
sure dont want to GLOBAL it, this kind of makes things difficult.
--
Edit this bug report at http://bugs.php.net/?id=15791&edit=1
Bug #12465 Updated: posix_* issuing Warnings, no error code.
ID: 12465 Updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] -Status: Bogus +Status: Open Bug Type: POSIX related Operating System: Linux PHP Version: 4.0.6 New Comment: I agree with Herbert here. It's pretty worthless for the function to generate this verbose error messages during runtime. It's mimic is excatly what the C version does (function-wise). Does the C version do any output itself if it encounters an error (e.g. posix_getpwuid) ? No. Why? Because a NULL return value is a valid return value. It's not a php_error() nor a E_WARNING. Instead, the extension should be re-written to a) return false (the PHP-way), b) store the errno in a thread-global contect variable and c) provide a function to cleanly retrieve the exacty error message (currently, you would habe to catch $php_errmsg (or whatever it was) and parse it out. Short: re-opening ;) Previous Comments: [2002-02-28 14:48:28] [EMAIL PROTECTED] It´s still nonsense to write an error-message! stat() *IS STILL USED* for checking the existence of files. Why do I have to *suppress* error-messages?! PHP should not *generate* them in the first! *If* you choose to implement stat() and name it after the C-function, then stat() should behave as closely as possible like its C-equivalent. [2002-02-04 02:46:54] [EMAIL PROTECTED] It returns false. You need to get rid of error messages with @... [2001-07-30 09:24:17] [EMAIL PROTECTED] hi, I tried to use some of the posix_* functions to work with user-accounts on the system, like "posix_getpwnam()" and "posix_getpwuid()". I expected to get an error-code back (like Failed or FALSE) for pwnames or pwuids which do not exist in /etc/passwd. Instead, PHP will write a warning message in my html-output: : Warning: posix_getpwuid(4711) failed with 'Success' in : /data/home/webmaster/admin/admin.php : on line 197 and, what I think is strange, will "fail with ´Success´". Could you please modify the posix_getpw* functions in a way that they 1) do not write strange warning-messages and 2) return a NULL-Value or FALSE, where the unix getpw*(3) will return NULL (just like documented in the man-page) thanks in advance, herbert rosmanith [EMAIL PROTECTED] -- Edit this bug report at http://bugs.php.net/?id=12465&edit=1
Bug #15772 Updated: PHP is developed and maintained by morons
ID: 15772
Updated by: [EMAIL PROTECTED]
Reported By: [EMAIL PROTECTED]
Status: Closed
Bug Type: *General Issues
Operating System: all
PHP Version: 4.0.6
New Comment:
How about this patch:
--- main/rfc1867.c.orig Thu Feb 28 14:08:25 2002
+++ main/rfc1867.c Thu Feb 28 14:33:03 2002
@@ -163,20 +163,28 @@
SAFE_RETURN;
}
/* some other headerfield
found, skip it */
- loc = (char *) memchr(ptr,
'\n', rem)+1;
+ loc = (char *) memchr(ptr,
'\n', rem);
if (!loc) {
/* broken */
php_error(E_WARNING,
"File Upload Mime headers garbled ptr: [%c%c%c%c%c]", *ptr, *(ptr + 1),
*(ptr + 2), *(ptr
+ 3), *(ptr + 4));
SAFE_RETURN;
}
+ else
+ {
+ loc++;
+ }
while (*loc == ' ' || *loc ==
'\t') {
/* other field is
folded, skip it */
- loc = (char *)
memchr(loc, '\n', rem-(loc-ptr))+1;
+ loc = (char *)
memchr(loc, '\n', rem-(loc-ptr));
if (!loc) {
/* broken */
php_error(E_WARNING, "File Upload Mime headers garbled ptr:
[%c%c%c%c%c]", *ptr, *(ptr + 1), *(ptr +
2), *(ptr + 3), *(ptr + 4));
SAFE_RETURN;
}
+ else
+ {
+ loc++;
+ }
}
rem -= (loc - ptr);
ptr = loc;
@@ -232,6 +240,10 @@
* pre 4.0.6 code here
*/
loc2 = memchr(loc + 1, '\n',
rem);
+ if (!loc2) {
+ php_error(E_WARNING,
"File Upload Mime headers - no newline");
+ SAFE_RETURN;
+ }
rem -= (loc2 - ptr) + 1;
ptr = loc2 + 1;
/* is_arr_upload is true when
name of file upload field
Previous Comments:
[2002-02-28 05:06:42] [EMAIL PROTECTED]
You are again wrong, cnt must be supplied.
I advise you to think before you speak.
A POST fileupload block can have lots of '\0's in it.
Without the number of bytes it would be impossibe to
handle such a block.
[2002-02-28 04:59:29] [EMAIL PROTECTED]
I'll admit that I did not examine the rest of the program to see if the
buffer was '\0'-terminated, however if it is, it's not just me that
thought it wasn't - whoever wrote the routine thought it wasn't either.
Otherwise there wouldn't even be any point in passing the buffer length
to the function, or the main loop's "while (ptr - buf < cnt)" or indeed
half the function.
As to providing patches, I know from experience that what you tend to
do with them is ignore them, insult them, re-write them badly and apply
them six months later, and then fail to credit. Plus I see no point in
providing band-aids in a futile attempt to cover the gaping wounds in
PHP. I *can* give you the fix I recommend to people for PHP, however,
which is 'rm -rf php-*' ;-)
[2002-02-28 03:21:22] [EMAIL PROTECTED]
We can search and fix what's wrong if there is a bug description, but
it would nice if you could post patch to php-dev directly. We know PHP
has many bugs and appreciate patches fixes bugs.
You have skills, right :)
[2002-02-28 03:02:27] [EMAIL PROTECTED]
Your claims are simply wrong.
Not a single str* function is able to read beyond the
buffer, cause the buffer is '\0' terminated and
Bug #15797: Inconsistent Error Behavior.
From: [EMAIL PROTECTED]
Operating system: linux
PHP version: 4.0.6
PHP Bug Type: GD related
Bug description: Inconsistent Error Behavior.
The function ImageCreateTrueColor() will cause a fatal error when it
detects that an incorrect version of GD is installed. Since the php code
cannot investigate which version of GD is installed before this call is
made, this makes it impossible to create applications which can gracefully
degrade depending on the version of GD installed. The fatal error is
inconsistent with the warnings that are returned when GIF,PNG, or JPEG
support is not compiled into GD. The return value for all these functions
should be a warning to allow maximum flexibility to the programmer.
if (! $Image = ImageCreateTrueColor($w,$h)) {
$Image = ImageCreate($w,$h);
}
It is not possible to execute the above code because the fatal error when
GD 2.0 is not installed will cease execution of the code.
--
Edit bug report at http://bugs.php.net/?id=15797&edit=1
--
Fixed in CVS:http://bugs.php.net/fix.php?id=15797&r=fixedcvs
Fixed in release:http://bugs.php.net/fix.php?id=15797&r=alreadyfixed
Need backtrace: http://bugs.php.net/fix.php?id=15797&r=needtrace
Try newer version: http://bugs.php.net/fix.php?id=15797&r=oldversion
Not developer issue: http://bugs.php.net/fix.php?id=15797&r=support
Expected behavior: http://bugs.php.net/fix.php?id=15797&r=notwrong
Not enough info: http://bugs.php.net/fix.php?id=15797&r=notenoughinfo
Submitted twice: http://bugs.php.net/fix.php?id=15797&r=submittedtwice
Bug #10833 Updated: Hyperlink tag when split on multiple lines, session ids are not propagated
ID: 10833 Updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] Status: Closed Bug Type: Session related Operating System: Linux PHP Version: 4.0.5 New Comment: Is it worth the hassle to extend the (post?)parse to recognize this (slow down if parse would also recognize this). Clearly documenting what's possinle and what not would be better imho. Previous Comments: [2002-02-28 16:43:20] [EMAIL PROTECTED] This problem exists also in 4.0.6 ' will work will not work [2001-08-06 08:48:12] [EMAIL PROTECTED] No feedback. And the latest CVS works just fine on this kind of urls. --Jani [2001-07-10 05:05:45] [EMAIL PROTECTED] Could you give a snapshot a try? http://snaps.php.net/ The scanner is supposed to ignore whitespace. [2001-05-12 17:24:31] [EMAIL PROTECTED] This applicable for browsers that don't allow cookies: The following is not working: "> Menu But if href is on the same line as tag, it works: "> Menu -- Edit this bug report at http://bugs.php.net/?id=10833&edit=1
Bug #15797 Updated: Inconsistent Error Behavior.
ID: 15797
Updated by: [EMAIL PROTECTED]
Reported By: [EMAIL PROTECTED]
-Status: Open
+Status: Closed
Bug Type: GD related
Operating System: linux
PHP Version: 4.0.6
New Comment:
This bug has been fixed in CVS.
Previous Comments:
[2002-02-28 17:51:32] [EMAIL PROTECTED]
The function ImageCreateTrueColor() will cause a fatal error when it
detects that an incorrect version of GD is installed. Since the php
code cannot investigate which version of GD is installed before this
call is made, this makes it impossible to create applications which can
gracefully degrade depending on the version of GD installed. The fatal
error is inconsistent with the warnings that are returned when GIF,PNG,
or JPEG support is not compiled into GD. The return value for all
these functions should be a warning to allow maximum flexibility to the
programmer.
if (! $Image = ImageCreateTrueColor($w,$h)) {
$Image = ImageCreate($w,$h);
}
It is not possible to execute the above code because the fatal error
when GD 2.0 is not installed will cease execution of the code.
--
Edit this bug report at http://bugs.php.net/?id=15797&edit=1
Bug #12465 Updated: posix_* issuing Warnings, no error code.
ID: 12465 Updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] Status: Open Bug Type: POSIX related Operating System: Linux PHP Version: 4.0.6 New Comment: ouch, little mistake, I confused two reports (one concerns stat(), the other one (this one) conceners posix_*). But anyway, both reports adress the same behaviour, so my reply is still valid. Previous Comments: [2002-02-28 17:48:57] [EMAIL PROTECTED] I agree with Herbert here. It's pretty worthless for the function to generate this verbose error messages during runtime. It's mimic is excatly what the C version does (function-wise). Does the C version do any output itself if it encounters an error (e.g. posix_getpwuid) ? No. Why? Because a NULL return value is a valid return value. It's not a php_error() nor a E_WARNING. Instead, the extension should be re-written to a) return false (the PHP-way), b) store the errno in a thread-global contect variable and c) provide a function to cleanly retrieve the exacty error message (currently, you would habe to catch $php_errmsg (or whatever it was) and parse it out. Short: re-opening ;) [2002-02-28 14:48:28] [EMAIL PROTECTED] It´s still nonsense to write an error-message! stat() *IS STILL USED* for checking the existence of files. Why do I have to *suppress* error-messages?! PHP should not *generate* them in the first! *If* you choose to implement stat() and name it after the C-function, then stat() should behave as closely as possible like its C-equivalent. [2002-02-04 02:46:54] [EMAIL PROTECTED] It returns false. You need to get rid of error messages with @... [2001-07-30 09:24:17] [EMAIL PROTECTED] hi, I tried to use some of the posix_* functions to work with user-accounts on the system, like "posix_getpwnam()" and "posix_getpwuid()". I expected to get an error-code back (like Failed or FALSE) for pwnames or pwuids which do not exist in /etc/passwd. Instead, PHP will write a warning message in my html-output: : Warning: posix_getpwuid(4711) failed with 'Success' in : /data/home/webmaster/admin/admin.php : on line 197 and, what I think is strange, will "fail with ´Success´". Could you please modify the posix_getpw* functions in a way that they 1) do not write strange warning-messages and 2) return a NULL-Value or FALSE, where the unix getpw*(3) will return NULL (just like documented in the man-page) thanks in advance, herbert rosmanith [EMAIL PROTECTED] -- Edit this bug report at http://bugs.php.net/?id=12465&edit=1
Bug #15736 Updated: Security Exploit
ID: 15736 Updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] -Status: Open +Status: Closed Bug Type: Unknown/Other Function Operating System: All UNIX PHP Version: 4.1.1 New Comment: I was wrong, the exploit is fixed. Rasmus fixed just one segfault. Previous Comments: [2002-02-28 12:46:48] [EMAIL PROTECTED] Shouldn't the patch on the downloads page also include this patch by Rasmus? http://cvs.php.net/diff.php/php4/main/rfc1867.c?r1=1.71.2.2&r2=1.71.2.3&ty=u [2002-02-28 02:27:52] [EMAIL PROTECTED] ..and I take this back, it's fixed in CVS but not in any release. [2002-02-28 02:11:04] [EMAIL PROTECTED] This bug has already been fixed in the latest released version of PHP, which you can download at http://www.php.net/downloads.php [2002-02-27 20:54:47] [EMAIL PROTECTED] The patch for file rfc1867.c applied to php 4.0.6 seems to not work when trying to upload from Opera 6.01 (on Windows). Uploading in Internet Explorer (6.0) seems to work allright, whereas uploading with Opera simply either times out or just fails (without any errors). [2002-02-26 13:41:58] [EMAIL PROTECTED] Well, the part of doing this before Apache demotes its priviledges doesn't sound feasible to me. Apache forks child processes as a non-privileged user. You can't get it to serve up a PHP request as root. And if you could, then why use a "high port" as you mentioned? We will however have a fix for the file upload buffer overflow shortly. In the meantime, simply turn off file uploads in your php.ini file to protect yourself against this. 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/15736 -- Edit this bug report at http://bugs.php.net/?id=15736&edit=1
Bug #13556 Updated: PHP4 should be able to use dso version of cracklib
ID: 13556 Updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] -Status: Open +Status: Closed -Bug Type: *Compile Issues +Bug Type: Compile Failure Operating System: linux PHP Version: 4.1.1 & 4.1.2 Assigned To: sniper New Comment: Really fixed now. Thanks for the patch, jtate. --Jani Previous Comments: [2002-02-28 14:39:06] [EMAIL PROTECTED] This was "fixed" in CVS, but incorrectly. Please apply the following patch to the crack extension: --BEGIN_PATCH-- === RCS file: /repository/php4/ext/crack/config.m4,v retrieving revision 1.6 diff -u -u -r1.6 config.m4 --- config.m4 30 Nov 2001 18:59:28 - 1.6 +++ config.m4 28 Feb 2002 19:33:14 - @@ -8,7 +8,7 @@ if test "$PHP_CRACK" != "no"; then for i in /usr/local/lib /usr/lib $PHP_CRACK/lib $PHP_CRACK/cracklib; do - test -f $i/lib/libcrack.$SHLIB_SUFFIX_NAME -o -f $i/libcrack.a && CRACK_LIBDIR=$i + test -f $i/libcrack.$SHLIB_SUFFIX_NAME -o -f $i/libcrack.a && CRACK_LIBDIR=$i done for i in /usr/local/include /usr/include $PHP_CRACK/include $PHP_CRACK/cracklib; do --END_PATCH-- The code that searched for the shared objects was looking under a subdirectory lib, so instead of looking in /usr/lib it was looking in /usr/lib/lib. This patch fixes the problem. [2001-10-11 20:21:03] [EMAIL PROTECTED] Fixed in CVS. Fix will be in PHP 4.1 --Jani [2001-10-05 03:12:59] [EMAIL PROTECTED] Configure only checks for the static libcrack.a when it would be possible to use libcrack.so. -- Edit this bug report at http://bugs.php.net/?id=13556&edit=1
Bug #15113 Updated: PHP4,javabeans, libphp_java.so
ID: 15113 Updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] Status: Feedback Bug Type: Java related Operating System: Redhat Linux7.2 PHP Version: 4.1.1 New Comment: I am having the same problemI'm running Solaris 8, JDK1.2, Apache 1.2.23, Php 4.1.2 and gcc 2.95.2. No matter what I can't get it to build libphp_java.so. It always builds libphp_java.a. Any help would be great. - Mike Previous Comments: [2002-02-24 06:19:58] [EMAIL PROTECTED] Please test with PHP 4.1.1+JDK 1.2 and report the result back Please do not forget updating PHP version. Thanks. [2002-01-19 05:41:03] [EMAIL PROTECTED] Hi, I want to setup a php with javabeans support. My versions is Redhat Linux7.2+jdk1.3.1+php4.1.1 when i finished all the setup job, i found haven't the 'libphp_java.so' file. I searched all the directories, only found a libphp_java.la and libphp_java.a file. Who can tell me why? my /etc/profile file relation setting is below: PATH=$PATH:/usr/local/jdk1.3.1_02/bin:/usr/local/jdk1.3.1_02/jre/bin PATH=$PATH:/usr/local/mysql/bin:/usr/local/etc/httpd/bin CLASSPATH=/usr/local/jdk1.3.1_02/jre/lib/rt.jar JAVA_HOME=/usr/local/jdk1.3.1_02 My php.ini file is at /usr/local/lib/php.ini java.class.path = /usr/local/etc/php4/ext/java/php_java.jar:/usr/local/jdk1.3.1_02/jre/lib /rt.jar java.home = /usr/local/jdk1.3.1_02 java.library = libjava.so java.library.path = /usr/local/jdk1.3.1_02/jre/lib/i386:/usr/local/jdk1.3.1_02/jre/lib/i386/ classic:/usr/local/jdk1.3.1_02/jre/lib/i386/native_threads ;extension_dir = /usr/local/lib/php/20010901 ;extension = libphp_java.so [2002-01-19 05:38:45] [EMAIL PROTECTED] Hi, I want to setup a php with javabeans support. My versions is Redhat Linux7.2+jdk1.3.1+php4.1.1 when i finished all the setup job, i found haven't the 'libphp_java.so' file. I searched all the directories, only found a libphp_java.la and libphp_java.a file. Who can tell me why? my /etc/profile file relation setting is below: PATH=$PATH:/usr/local/jdk1.3.1_02/bin:/usr/local/jdk1.3.1_02/jre/bin PATH=$PATH:/usr/local/mysql/bin:/usr/local/etc/httpd/bin CLASSPATH=/usr/local/jdk1.3.1_02/jre/lib/rt.jar JAVA_HOME=/usr/local/jdk1.3.1_02 java.class.path = /usr/local/etc/php4/ext/java/php_java.jar:/usr/local/jdk1.3.1_02/jre/lib/rt.jar java.home = /usr/local/jdk1.3.1_02 java.library = libjava.so java.library.path = /usr/local/jdk1.3.1_02/jre/lib/i386:/usr/local/jdk1.3.1_02/jre/lib/i386/classic:/usr/local/jdk1.3.1_02/jre/lib/i386/native_threads ;extension_dir = /usr/local/lib/php/20010901 ;extension = libphp_java.so -- Edit this bug report at http://bugs.php.net/?id=15113&edit=1
Bug #15798: unresolved symbol __log1p
From: [EMAIL PROTECTED] Operating system: TurboLinux 4 PHP version: 4.1.2 PHP Bug Type: Compile Failure Bug description: unresolved symbol __log1p Unable to compile PHP/4.1.2 either as a module or static. Either way, I get: undefined reference to `__log1p' If I compile static, I get: <=== src/modules gcc -c -I./os/unix -I./include -DLINUX=22 -I/var/src/php-4.1.2 -I/var/src/php-4.1.2/main -I/var/src/php-4.1.2/main -I/var/src/php-4.1.2/Zend -I/var/src/php-4.1.2/Zend -I/var/src/php-4.1.2/TSRM -I/var/src/php-4.1.2/TSRM -I/var/src/php-4.1.2 -DUSE_EXPAT -I./lib/expat-lite `./apaci` modules.c gcc -c -I./os/unix -I./include -DLINUX=22 -I/var/src/php-4.1.2 -I/var/src/php-4.1.2/main -I/var/src/php-4.1.2/main -I/var/src/php-4.1.2/Zend -I/var/src/php-4.1.2/Zend -I/var/src/php-4.1.2/TSRM -I/var/src/php-4.1.2/TSRM -I/var/src/php-4.1.2 -DUSE_EXPAT -I./lib/expat-lite `./apaci` buildmark.c gcc -DLINUX=22 -I/var/src/php-4.1.2 -I/var/src/php-4.1.2/main -I/var/src/php-4.1.2/main -I/var/src/php-4.1.2/Zend -I/var/src/php-4.1.2/Zend -I/var/src/php-4.1.2/TSRM -I/var/src/php-4.1.2/TSRM -I/var/src/php-4.1.2 -DUSE_EXPAT -I./lib/expat-lite `./apaci` -rdynamic \ -o httpd buildmark.o modules.o modules/standard/libstandard.a modules/php4/libphp4.a main/libmain.a ./os/unix/libos.a ap/libap.a lib/expat-lite/libexpat.a -rdynamic -Lmodules/php4 -L../modules/php4 -L../../modules/php4 -lmodphp4 -lpam -ldl -lcrypt -lresolv -lm -ldl -lnsl -lresolv -lcrypt -lm -lcrypt -lndbm -ldl modules/php4/libphp4.a(math.o): In function `zif_atanh': /usr/include/__math.h:426: undefined reference to `__log1p' collect2: ld returned 1 exit status make[2]: *** [target_static] Error 1 make[2]: Leaving directory `/var/src/apache_1.3.23/src' make[1]: *** [build-std] Error 2 make[1]: Leaving directory `/var/src/apache_1.3.23' make: *** [build] Error 2 # If I compile dynamic, it builds, but on startup, I get: Starting httpd: httpd Syntax error on line 63 of /etc/httpd/conf/httpd.conf: Cannot load /usr/lib/apache/libphp4.so into server: /usr/lib/apache/libphp4.so: undefined symbol: __log1p Here is the ldd: # ldd -r /usr/lib/apache/libphp4.so libdl.so.2 => /lib/libdl.so.2 (0x4013a000) libcrypt.so.1 => /lib/libcrypt.so.1 (0x4013d000) libresolv.so.2 => /lib/libresolv.so.2 (0x4016a000) libpam.so.0 => /lib/libpam.so.0 (0x40179000) libm.so.6 => /lib/libm.so.6 (0x40181000) libnsl.so.1 => /lib/libnsl.so.1 (0x4019f000) libc.so.6 => /lib/libc.so.6 (0x401b6000) /lib/ld-linux.so.2 => /lib/ld-linux.so.2 (0x8000) undefined symbol: ap_user_id(/usr/lib/apache/libphp4.so) undefined symbol: ap_server_root(/usr/lib/apache/libphp4.so) undefined symbol: ap_group_id (/usr/lib/apache/libphp4.so) undefined symbol: ap_user_name (/usr/lib/apache/libphp4.so) undefined symbol: top_module(/usr/lib/apache/libphp4.so) undefined symbol: ap_max_requests_per_child (/usr/lib/apache/libphp4.so) undefined symbol: ap_table_get (/usr/lib/apache/libphp4.so) undefined symbol: ap_update_mtime (/usr/lib/apache/libphp4.so) undefined symbol: ap_kill_timeout (/usr/lib/apache/libphp4.so) undefined symbol: ap_uudecode (/usr/lib/apache/libphp4.so) undefined symbol: ap_setup_client_block (/usr/lib/apache/libphp4.so) undefined symbol: ap_add_cgi_vars (/usr/lib/apache/libphp4.so) undefined symbol: ap_getword(/usr/lib/apache/libphp4.so) undefined symbol: ap_getword_nulls_nc (/usr/lib/apache/libphp4.so) undefined symbol: ap_destroy_sub_req(/usr/lib/apache/libphp4.so) undefined symbol: __log1p (/usr/lib/apache/libphp4.so) undefined symbol: ap_pstrdup(/usr/lib/apache/libphp4.so) undefined symbol: ap_log_error (/usr/lib/apache/libphp4.so) undefined symbol: ap_table_add (/usr/lib/apache/libphp4.so) undefined symbol: ap_sub_req_lookup_uri (/usr/lib/apache/libphp4.so) undefined symbol: ap_run_sub_req(/usr/lib/apache/libphp4.so) undefined symbol: ap_register_cleanup (/usr/lib/apache/libphp4.so) undefined symbol: ap_signal (/usr/lib/apache/libphp4.so) undefined symbol: ap_send_http_header (/usr/lib/apache/libphp4.so) undefined symbol: ap_block_alarms (/usr/lib/apache/libphp4.so) undefined symbol: ap_child_terminate(/usr/lib/apache/libphp4.so) undefined symbol: ap_set_etag (/usr/lib/apache/libphp4.so) undefined symbol: ap_rwrite (/usr/lib/apache/libphp4.so) undefined symbol: ap_table_set (/usr/lib/apache/libphp4.so) undefined symbol: ap_get_client_block (/usr/lib/apache/libphp4.so) undefined symbol: ap_add_version_component (/usr/lib/apache/libphp4.so) undefined symbol: ap_hard_timeout (/usr/lib/apache/libphp4.so) undefined symbol: ap_rflush (/usr/lib/apache/libphp4.so) undefined symbol: ap_set_last_modified (/usr/lib/apache/libphp4.so) undefined symbol: ap_reset_timeout (/usr/lib/apache/libphp4.so) undefined symbol: ap
Bug #15763 Updated: Compile failure
ID: 15763 Updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] Status: Open Bug Type: Compile Failure Operating System: Linux Debian 2.2 PHP Version: 4.1.2 New Comment: I also get errors. I will cut the first part of it and paste here. I an running the exact same configuration as I had previously with 4.1.1. It's a little long but here goes: ./configure --with-apxs=/usr/local/apache/bin/apxs --with-curl --with-swf=/usr/local/flash --with-gd=/usr/local --with-jpeg-dir=/usr/local --with-xpm-dir=/usr/X11R6 --with-zlib-dir=shared --enable-ftp --with-db=shared --with-ming=/home/pfmartin/Download/PHP/ming-0.2a --enable-magic-quotes --with-mysql --enable-safe-mode --enable-track-vars --with-ttf --enable-versioning --with-mcrypt=/usr --with-gettext --enable-sysvsem --enable-sysvshm --enable-trans-sid --with-mhash=/usr --with-cybercash=/usr/local/cybercash/mck-3.2.0.3-linux --with-png-dir --enable-xslt --with-xslt-sablot --with-expat --with-pfpro=/usr/local/payflow root@server375 [/home/pfmartin/Download/PHP/php-4.1.2]# make Making all in Zend make[1]: Entering directory `/home/pfmartin/Download/PHP/php-4.1.2/Zend' /bin/sh ../libtool --silent --mode=compile gcc -DHAVE_CONFIG_H -I. -I. -I../main -DLINUX=22 -DMOD_SSL=208105 -DUSE_HSREGEX -DEAPI -I../TSRM -g -O2 -prefer-pic -c zend_language_parser.c In file included from /usr/include/stdio.h:57, from zend.h:34, from zend_compile.h:24, from zend_language_parser.c:148: /usr/include/libio.h:214: parse error before `__off_t' /usr/include/libio.h:214: warning: no semicolon at end of struct or union /usr/include/libio.h:233: parse error before `_offset' /usr/include/libio.h:233: warning: data definition has no type or storage class /usr/include/libio.h:237: parse error before `}' /usr/include/libio.h:262: parse error before `__io_read_fn' /usr/include/libio.h:263: warning: data definition has no type or storage class /usr/include/libio.h:271: parse error before `__io_write_fn' /usr/include/libio.h:272: warning: data definition has no type or storage class /usr/include/libio.h:280: parse error before `__off_t' Previous Comments: [2002-02-27 13:04:07] [EMAIL PROTECTED] Anybody able to reproduce this compile failure? It builds cleanly for me here with the same configure flags except for the --with-mnogosearch one since I don't have that installed here. And there were no mnogosearch changes between 4.1.1 and 4.1.2 so you'd have to assume that wouldn't cause this. [2002-02-27 12:08:50] [EMAIL PROTECTED] Note: This is 4.1.2 bug not 4.1.1 Note: Make on the same system, same config works fine with 4.0.6 Note: Make without any flags in configure works fine with 4.1.1 Now the issue: Configure: ./configure --with-mysql --with-xml --with-apache=../apache_1.3.19 --enable-track-vars --with-gd --with-mnogosearch Make: srv1:/usr/local/src/php-4.1.2# make Making all in Zend make[1]: Entering directory `/usr/local/src/php-4.1.2/Zend' make[1]: Nothing to be done for `all'. make[1]: Leaving directory `/usr/local/src/php-4.1.2/Zend' Making all in main make[1]: Entering directory `/usr/local/src/php-4.1.2/main' make[2]: Entering directory `/usr/local/src/php-4.1.2/main' gcc -I. -I/usr/local/src/php-4.1.2/main -I/usr/local/src/php-4.1.2/main -I/usr/local/src/php-4.1.2 -I/usr/local/src/apache_1.3.19/src/include -I/usr/local/src/apache_1.3.19/src/os/unix -I/usr/local/src/php-4.1.2/Zend -I/usr/local/mnogosearch/include -I/usr/local/src/php-4.1.2/ext/mysql/libmysql -I/usr/local/src/php-4.1.2/ext/xml/expat -I/usr/local/src/php-4.1.2/TSRM -g -O2 -c main.c && touch main.lo In file included from php.h:163, from main.c:26: fopen_wrappers.h:69: parse error before `TSRMLS_DC' fopen_wrappers.h:71: parse error before `TSRMLS_DC' fopen_wrappers.h:72: parse error before `TSRMLS_DC' fopen_wrappers.h:74: parse error before `TSRMLS_DC' fopen_wrappers.h:75: parse error before `TSRMLS_DC' fopen_wrappers.h:77: parse error before `TSRMLS_DC' fopen_wrappers.h:83: warning: parameter names (without types) in function declaration fopen_wrappers.h:84: warning: parameter names (without types) in function declaration fopen_wrappers.h:85: parse error before `TSRMLS_DC' fopen_wrappers.h:86: parse error before `TSRMLS_DC' In file included from main.c:26: php.h:226: parse error before `TSRMLS_DC' php.h:228: parse error before `TSRMLS_DC' In file included from php.h:290, from main.c:26: /usr/local/src/php-4.1.2/main/php_output.h:26: parse error before `TSRMLS_DC' /usr/local/src/php-4.1.2/main/php_output.h:29: warning: parameter names (without types) in function declaration /usr/local/src/php-4.1.2/main/php_output.h:30: parse error before `TSRMLS_DC' /usr
Bug #15799: Another segfault on iconv
From: [EMAIL PROTECTED]
Operating system: Linux
PHP version: 4.0CVS-2002-02-28
PHP Bug Type: ICONV related
Bug description: Another segfault on iconv
Hi, it's me again.
I got another segfault, this time with the iconv output buffer handler,
though iconv() seems to work now, somehow.
That's the code:
iconv_set_encoding('input_encoding', 'BIG5');
iconv_set_encoding('internal_encoding', 'UTF-8');
iconv_set_encoding('output_encoding', 'UTF-8');
ob_start('ob_iconv_handler');
echo $text;
$return = ob_get_contents();
ob_end_clean();
$text contains a BIG5 encoded message of course.
This is the bt:
Program received signal SIGSEGV, Segmentation fault.
0x4010621a in chunk_free (ar_ptr=0x89fff7cb, p=0x404e8108) at
malloc.c:3049
3049malloc.c: No such file or directory.
(gdb)
(gdb) bt
#0 0x4010621a in chunk_free (ar_ptr=0x89fff7cb, p=0x404e8108) at
malloc.c:3049
#1 0x401061bf in free () at malloc.c:2952
#2 0x40372aac in zif_iconv_set_encoding () at iconv.c:174
#3 0x40316987 in execute () at ./zend_execute.c:959
#4 0x40316baf in execute () at ./zend_execute.c:959
#5 0x403288c4 in zend_execute_scripts () at zend.c:373
#6 0x4033c507 in php_execute_script () at main.c:1265
#7 0x40336b40 in apache_php_module_main () at sapi_apache.c:100
#8 0x40337ad8 in send_php (r=0x81823a0, display_source_mode=0,
filename=0x81841b0 "/usr/local/httpd/htdocs/headhorde/imp/view.php")
at mod_php4.c:575
#9 0x40337b63 in send_parsed_php (r=0x81823a0) at mod_php4.c:590
#10 0x8055250 in ap_invoke_handler ()
#11 0x80677bc in ap_some_auth_required ()
#12 0x8067833 in ap_process_request ()
#13 0x805fd27 in ap_child_terminate ()
#14 0x805fed5 in ap_child_terminate ()
#15 0x8060016 in ap_child_terminate ()
#16 0x8060628 in ap_child_terminate ()
#17 0x8060e95 in main ()
#18 0x400cca8e in __libc_start_main () at
../sysdeps/generic/libc-start.c:93
--
Edit bug report at http://bugs.php.net/?id=15799&edit=1
--
Fixed in CVS:http://bugs.php.net/fix.php?id=15799&r=fixedcvs
Fixed in release:http://bugs.php.net/fix.php?id=15799&r=alreadyfixed
Need backtrace: http://bugs.php.net/fix.php?id=15799&r=needtrace
Try newer version: http://bugs.php.net/fix.php?id=15799&r=oldversion
Not developer issue: http://bugs.php.net/fix.php?id=15799&r=support
Expected behavior: http://bugs.php.net/fix.php?id=15799&r=notwrong
Not enough info: http://bugs.php.net/fix.php?id=15799&r=notenoughinfo
Submitted twice: http://bugs.php.net/fix.php?id=15799&r=submittedtwice
Bug #15800: german characters cannot be stored
From: [EMAIL PROTECTED]
Operating system: Win2000
PHP version: 4.1.1
PHP Bug Type: WDDX related
Bug description: german characters cannot be stored
Summary:
german characters cannot be stored
by wddx_serialize_vars
To make it easier for you to reproduce
the bug i write a little step-by-step
summary:
1) Setting the correct local zone
setlocale("LC_ALL","german");
2) Writing some test-data with german characters
ÄÖÜäüö
3) Pushing the test-data into wddx_serialize_vars
on a Win2000 Server. Results on Win2000:
ÄÜä
Results on Linux (correct values):
ÄÖÜäöü
4) Reading the values back (from the saved wddx package)
Ä Üä
It seams like that only some locale characters (ÄÜä) are recognized on an
Win2000 Server. With the same script
and the same data, there are no problems on an Linux
Server.
Happy Debugging :-)
Thomas
--
Edit bug report at http://bugs.php.net/?id=15800&edit=1
--
Fixed in CVS:http://bugs.php.net/fix.php?id=15800&r=fixedcvs
Fixed in release:http://bugs.php.net/fix.php?id=15800&r=alreadyfixed
Need backtrace: http://bugs.php.net/fix.php?id=15800&r=needtrace
Try newer version: http://bugs.php.net/fix.php?id=15800&r=oldversion
Not developer issue: http://bugs.php.net/fix.php?id=15800&r=support
Expected behavior: http://bugs.php.net/fix.php?id=15800&r=notwrong
Not enough info: http://bugs.php.net/fix.php?id=15800&r=notenoughinfo
Submitted twice: http://bugs.php.net/fix.php?id=15800&r=submittedtwice
Bug #15799 Updated: Another segfault on iconv
ID: 15799
Updated by: [EMAIL PROTECTED]
Reported By: [EMAIL PROTECTED]
-Status: Open
+Status: Feedback
Bug Type: ICONV related
Operating System: Linux
-PHP Version: 4.0CVS-2002-02-28
+PHP Version: 4.0CVS-2002-02-2
New Comment:
BIG5
I guess it's supported by libiconv and your glibc is ok..
If text is small enough, could you pate uuencoded text there?
Previous Comments:
[2002-02-28 19:21:20] [EMAIL PROTECTED]
Hi, it's me again.
I got another segfault, this time with the iconv output buffer handler,
though iconv() seems to work now, somehow.
That's the code:
iconv_set_encoding('input_encoding', 'BIG5');
iconv_set_encoding('internal_encoding', 'UTF-8');
iconv_set_encoding('output_encoding', 'UTF-8');
ob_start('ob_iconv_handler');
echo $text;
$return = ob_get_contents();
ob_end_clean();
$text contains a BIG5 encoded message of course.
This is the bt:
Program received signal SIGSEGV, Segmentation fault.
0x4010621a in chunk_free (ar_ptr=0x89fff7cb, p=0x404e8108) at
malloc.c:3049
3049malloc.c: No such file or directory.
(gdb)
(gdb) bt
#0 0x4010621a in chunk_free (ar_ptr=0x89fff7cb, p=0x404e8108) at
malloc.c:3049
#1 0x401061bf in free () at malloc.c:2952
#2 0x40372aac in zif_iconv_set_encoding () at iconv.c:174
#3 0x40316987 in execute () at ./zend_execute.c:959
#4 0x40316baf in execute () at ./zend_execute.c:959
#5 0x403288c4 in zend_execute_scripts () at zend.c:373
#6 0x4033c507 in php_execute_script () at main.c:1265
#7 0x40336b40 in apache_php_module_main () at sapi_apache.c:100
#8 0x40337ad8 in send_php (r=0x81823a0, display_source_mode=0,
filename=0x81841b0
"/usr/local/httpd/htdocs/headhorde/imp/view.php")
at mod_php4.c:575
#9 0x40337b63 in send_parsed_php (r=0x81823a0) at mod_php4.c:590
#10 0x8055250 in ap_invoke_handler ()
#11 0x80677bc in ap_some_auth_required ()
#12 0x8067833 in ap_process_request ()
#13 0x805fd27 in ap_child_terminate ()
#14 0x805fed5 in ap_child_terminate ()
#15 0x8060016 in ap_child_terminate ()
#16 0x8060628 in ap_child_terminate ()
#17 0x8060e95 in main ()
#18 0x400cca8e in __libc_start_main () at
../sysdeps/generic/libc-start.c:93
--
Edit this bug report at http://bugs.php.net/?id=15799&edit=1
Bug #13182 Updated: session_start() can't create a _new_ session control file.
ID: 13182 Updated by: [EMAIL PROTECTED] -Summary: session_start() can't create a _new_ session control file. Reported By: [EMAIL PROTECTED] -Status: Closed +Status: Assigned Bug Type: Session related Operating System: Solaris 7 PHP Version: 4.1.1 Assigned To: yohgaki New Comment: I'm holding commit, it's not fixed yet Previous Comments: [2002-02-28 07:17:53] [EMAIL PROTECTED] This bug has been fixed in CVS. [2002-02-03 19:48:46] [EMAIL PROTECTED] This my be fixed by my patch. (Session module was trying to open exlusively more than once) [2002-01-15 04:20:40] [EMAIL PROTECTED] We sloved the problem in out system by saving the session data in the mySQL-databas. That is at least a way to avoid the problem. best regards, Andreas Lundgren [2002-01-15 03:37:51] [EMAIL PROTECTED] Version update. [2002-01-15 03:34:49] [EMAIL PROTECTED] Got feedback from a user. -- feedback from [EMAIL PROTECTED] -- Hello, I was hoping you could re-open PHP-BUG #13182. I have completed a test in 4.1.1 and receive the same error. I have also attempted to compile a snapshot from CVS but the build failed so I will have to tweak it and get back to you on that. As for this bug, I am attaching the error on top of a phpinfo() page. I originally tried it in 4.0.6 or some older release. The only configure params, as you can see, are the Roxen location and the Sybase location (for Sybase support). I have tested this application from 4.0.0 on in Apache on Win2000, Solaris 7 and Solaris 8. I have tested it with 4.0.6 on Roxen with Solaris 7. So the difference here (and I have really tried to bring the configs as close as possible) seems to be the Solaris 7 vs 8. I will try and gather more information but would appreciate the bug being reopened as I feel it is reproducible. Regards, Sam Cooley __ Do You Yahoo!? Send FREE video emails in Yahoo! Mail! http://promo.yahoo.com/videomail/ 4.1.1 OUTPUT - - Warning: open(/opt/www/cgi-bin/blahapp/conf/sess_9265832f97f81fa3ad1ee1bcc7bd4de7, O_RDWR) failed: Error 0 (0) in /opt/www/cgi-bin/blahapp/php/blahapp_init.phtml on line 37 PHP Version 4.1.1 System SunOS www.blah.com 5.8 Generic_108528-05 sun4u sparc SUNW,Ultra-80 Build Date Jan 15 2002 Configure Command './configure' '--with-sybase=/opt/sybase/SQL/current' '--with-roxen=/opt/roxen/server' Server API Roxen Virtual Directory Support disabled Configuration File (php.ini) Path /usr/local/lib/php.ini ZEND_DEBUG disabled Thread Safety disabled This program makes use of the Zend Scripting Language Engine: Zend Engine v1.1.1, Copyright (c) 1998-2001 Zend Technologies PHP 4.0 Credits Configuration PHP Core Directive Local Value Master Value allow_call_time_pass_reference On On allow_url_fopen 1 1 always_populate_raw_post_data 0 0 arg_separator.input & & arg_separator.output & & asp_tags Off Off auto_append_file no value no value auto_prepend_file no value no value browscap no value no value default_charset no value no value default_mimetype text/html text/html define_syslog_variables Off Off disable_functions no value no value display_errors On On display_startup_errors Off Off doc_root no value no value enable_dl On On error_append_string no value no value error_log no value no value error_prepend_string no value no value error_reporting 2039 2039 expose_php On On extension_dir ./ ./ file_uploads 1 1 gpc_order GPC GPC highlight.bg #FF #FF highlight.comment #FF9900 #FF9900 highlight.default #CC #CC highlight.html #00 #00 highlight.keyword #006600 #006600 highlight.string #CC #CC html_errors On On ignore_user_abort Off Off implicit_flush Off Off include_path .:/usr/local/lib/php .:/usr/local/lib/php log_errors Off Off magic_quotes_gpc On On magic_quotes_runtime Off Off magic_quotes_sybase Off Off max_execution_time 30 30 open_basedir no value no value output_buffering no value no value output_handler no value no value post_max_size 8M 8M precision 14 14 register_argc_argv On On register_gl
Bug #7365 Updated: php_value error_reporting doesn't work for me
ID: 7365
Updated by: [EMAIL PROTECTED]
-Summary: php_value error_reporting doesn't work for me
Reported By: [EMAIL PROTECTED]
-Status: Closed
+Status: Feedback
Bug Type: PHP options/info functions
Operating System: Linux
-PHP Version: 4.0.3pl1
+PHP Version: 4.1.1
New Comment:
error_reporting should be able to changed anywhere.
PHP_INI_ENTRY("error_reporting",NULL, PHP_INI_ALL,
OnUpdateErrorReporting)
Could you try snapshot to see if it helps?
http://snaps.php.net/
Previous Comments:
[2002-02-28 12:47:45] [EMAIL PROTECTED]
I still get this problem with PHP 4.1.1, compiled as a DSO module:
This doesnt work in apache .conf files:
php_value error_log "/tmp/phperr.log"
php_value error_reporting 0
Just this also doesnt work:
php_value error_reporting 0
In both previous cases, I still get warnings shown...
But the flag WORKS:
php_flag display_errors 0
Norman
[2001-01-12 12:51:53] [EMAIL PROTECTED]
this seems to be fixed in both 4.0.4 and current CVS. if you experience
the same behavior after update, please reopen this bug report.
[2000-10-20 07:27:31] [EMAIL PROTECTED]
PHP version 4.0.3, compiled as DSO module.
I want to disable warnings, so I have:
/www/conf/httpd.conf:
---
php_value error_log "/tmp/phperr.log"
php_value error_reporting 0 # disabled EVERYTHING
---
'faulty' code (line 120:
---
if(is_array($messages[$seed]["replies"])){
---
In browser when I request the page, I get:
---
Warning: Undefined index: replies in
/home/www-html/htdocs/forum/multi-threads.inc on line 120
---
, this is a warning I guess, but they should be disabled
phpinfo() says about my configuration:
---
error_log /tmp/phperr.log no value
error_reporting 0 no value
---
, so it seems that config is read ok
/tmp/phperr.log doesn't get created. If I write
---
php_flag display_errors 0
---
It disables all error reporting whatsoever, but it makes debugging
nearly impossible. Error log isn't created in this case as well.
--
Edit this bug report at http://bugs.php.net/?id=7365&edit=1
Bug #15796 Updated: mail() doesn't work with qmail
ID: 15796
Updated by: [EMAIL PROTECTED]
Reported By: [EMAIL PROTECTED]
-Status: Open
+Status: Bogus
Bug Type: Mail related
Operating System: RedHat 7.2
PHP Version: 4.1.2
New Comment:
The bug system is not the appropriate forum for asking support
questions. For a list of a range of more appropriate places to ask
for help using PHP, please visit http://www.php.net/support.php
Previous Comments:
[2002-02-28 17:28:58] [EMAIL PROTECTED]
On my apache 1.3.23 and php 4.1.2 system the mail() function does not
send mail, although the local mail system (QMail) is functioning in
every other capacity. I have tried the suggestions of changing the
"sendmail_path" to:
/usr/sbin/sendmail
/var/qmail/bin/sendmail
and
/var/qmail/bin/qmail-inject
(I have also tried the sendmail wrapper commands with -t and
qmail-inject with -h)
This short script segment:
if (mail($to, $sub, $body)){
print ("MAIL SENT");
} else {
print ("MAIL DIED");
}
always returns "MAIL DIED".
Qmail logs and mail logs show nothing.
--
Edit this bug report at http://bugs.php.net/?id=15796&edit=1
Bug #15795 Updated: bug in dynamic linker ld.so
ID: 15795 Updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] -Status: Open +Status: Bogus Bug Type: *Configuration Issues Operating System: redhat 6.1 PHP Version: 4.1.2 New Comment: This is not a PHP bug, but ld bug. It seems ld's assertion is failing. Upgrade your ld. (and/or your build tools) Previous Comments: [2002-02-28 17:14:59] [EMAIL PROTECTED] Just upgrading from 4.1.1 to 4.1.2, but during the configure stage, this error is featured in the checks. "checking for mkfifo... BUG IN DYNAMIC LINKER ld.so: dl-minimal.c: 69: malloc: As sertion `page != ((void *) -1)' failed! no" The configure then completes as normal, but i daren't carry on with the make because of the error above. My configure line is/are: ./configure --prefix=/usr/local/php --with-config-file-path=/usr/local/php --with-apxs=/usr/sbin/apxs --enable-track-vars --enable-magic-quotes --disable-debug --with-mcrypt=/usr/local/lib --with-dom=/usr/local/lib --with-pcre --with-zlib --enable-sockets Any ideas as to what that might be? Is it safe to continue with the make and upgrade? -- Edit this bug report at http://bugs.php.net/?id=15795&edit=1
Bug #15789 Updated: php_value error_reporting in apache virtualhosts
ID: 15789 Updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] -Status: Open +Status: Duplicate Bug Type: *Configuration Issues Operating System: Linux PHP Version: 4.1.1 New Comment: Duplicate of #7365 Previous Comments: [2002-02-28 13:06:56] [EMAIL PROTECTED] php_value error_reporting 0 Simply doesnt work from within a in my apache server. I found some previous bug reports about this behaviour where is stated that this bug was fixed on 4.0.3, but Im using 4.1.1... phpinfo() output on this virtualhost reports that error_reporting has a local value of 0 and master value of 2039. But I still get all warnings. My ./configure command: './configure' '--prefix=/usr' '--with-apxs=/usr/sbin/apxs' '--with-mod_charset' '--enable-force-cgi-redirect' '--enable-discard-path' '--with-config-file-path=/etc/apache' '--enable-safe-mode' '--with-openssl' '--enable-bcmath' '--with-bz2' '--enable-calendar' '--enable-ctype' '--with-gdbm' '--with-db2' '--with-db3' '--enable-dbase' '--enable-ftp' '--enable-gd-imgstrttf' '--with-gd=/tmp/gd-1.8.2' '--with-jpeg-dir=/tmp/gd-1.8.2' '--with-mysql=/usr' '--with-xml=shared' '--with-mm=/usr' '--enable-trans-sid' '--enable-shmop' '--enable-sockets' '--with-regex=php' '--enable-sysvsem' '--enable-sysvshm' '--enable-yp' '--enable-memory-limit' '--with-tsrm-pthreads' '--enable-shared' '--disable-debug' '--with-zlib=/usr' '--with-imap=/home/norman/packs/src/c-client' Norman -- Edit this bug report at http://bugs.php.net/?id=15789&edit=1
Bug #15439 Updated: PHP hangs web server when started
ID: 15439 Updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] -Status: Bogus +Status: Open Bug Type: iPlanet related Operating System: AIX 4.3.3 PHP Version: 4.0.6 Previous Comments: [2002-02-28 09:13:32] [EMAIL PROTECTED] I have the same problem, on the same platform using the same PHP version, and reproducible for PHP 4.1.1 and 4.1.2 as well. libphp4.so *is* made, but strangely enough its located in the '.libs' directory instead of 'libs', which 'make install' chokes on. I used the following work around for the 'make-install' issue (cp ./.libs/* ./libs), but then the server choked on server-startup. I got some more information when I discovered that in my case, iPlanet is recieving signal 11/segmentation fault and trying to dump core when it 'hangs'. It's the uxwdog process that restarts it/keeps it from crashing, giving the impression that the server is 'frozen'. In order to get a core file and some more info: Make sure the account you are running the server as, can write to "/usr/netscape/server4/https-/config/core". By default, the core file should be located there. Make sure that the filesystem this dir is in has enough space for a corefile. Make sure there is no limit set for dumping core for the user-id the server is running under, by checking the users stanza in '/etc/security/limits' (set core=-1). start the httpd manually (instead of using the 'start' script) by doing: cd /usr/netscape/server4/bin/https/bin ./ns-httpd -d /usr/netscape/server4/https-servername>/config Also, check the aix error log for messages by doing: errpt -a | more If you are running syslog, check that logfile too for messages from uxwdog. [2002-02-08 21:28:19] [EMAIL PROTECTED] I tried to compile php 4.1.1 before I used 4.0.6, but 4.1.1 would run through the ./configure, and make, and fail on make install. It would not make libphp4.so where 4.0.6 had no problem making libphp4.so. Thanks, Chris [2002-02-07 21:56:28] [EMAIL PROTECTED] The version of PHP that this bug was reported in is too old. Please try to reproduce this bug in the latest version of PHP (available from http://www.php.net/downloads.php If you are still able to reproduce the bug with one of the latest versions of PHP, please change the PHP version on this bug report to the version you tested and change the status back to "Open". [2002-02-07 17:25:59] [EMAIL PROTECTED] The web server hangs when you go to a page, almost seems like a loop and does not seem to time out. When php is commented out in obj.conf, magnus.com, and mime.types the webserver works fine. I am using iPlanet 4.1 SP9, on AIX 4.3.3 I have downloaded and installed gcc, bison, flex, autoconf, automake, make and many others from freeware.bull.net export PATH=/usr/local/bin:$PATH:/usr/vac/bin:/usr/ccs/bin export LD_LIBRARY_PATH=$LD_LIBRARY_PATH:/usr/local/lib PHP 4.0.6 compile line CC=gcc ./configure --without-mysql \ --with-nsapi=/usr/netscape/server4 \ --with-dbm \ --with-gdbm \ --enable-libgcc compiles fine, i used dump -n to see the libpthread was included. I have even tried to compile this without dbm and gdbm support and still the same problem. Thanks for any help, Chris -- Edit this bug report at http://bugs.php.net/?id=15439&edit=1
Bug #15801: unjustified open_basedir restriction on copy()
From: [EMAIL PROTECTED] Operating system: linux rh PHP version: 4.1.2 PHP Bug Type: Filesystem function related Bug description: unjustified open_basedir restriction on copy() Hello, I've got a weird open_basedir restriction error on copy() of an uploaded file. This occurs with php4.1.2, after upgrading from the old 4.0.4pl1, which didn't have the problem. php.ini and apache configuration were unchanged. Virtual host settings: php_admin_value open_basedir /path/to/website/ php_admin_value upload_tmp_dir /path/to/website/temp I'm now getting an error when file is being copied from /path/to/website/temp/ to /path/to/website/somewhereelse/ Error label: Warning: open_basedir restriction in effect. File is in wrong directory in /path/to/website/somescript.phtml on line 1055 As copy-source, copy-destination and tmp folder are all within open_basedir, I really don't get the problem. Am I missing something? Please note that in my case, /path/to/website is a symbolic link to /mnt/mountpoint/to/website, but i had no more success by putting the "real" path into open_basedir section. Thanx, -- vedad -- Edit bug report at http://bugs.php.net/?id=15801&edit=1 -- Fixed in CVS:http://bugs.php.net/fix.php?id=15801&r=fixedcvs Fixed in release:http://bugs.php.net/fix.php?id=15801&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=15801&r=needtrace Try newer version: http://bugs.php.net/fix.php?id=15801&r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=15801&r=support Expected behavior: http://bugs.php.net/fix.php?id=15801&r=notwrong Not enough info: http://bugs.php.net/fix.php?id=15801&r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=15801&r=submittedtwice
Bug #15799 Updated: Another segfault on iconv
ID: 15799
Updated by: [EMAIL PROTECTED]
Reported By: [EMAIL PROTECTED]
Status: Feedback
Bug Type: ICONV related
Operating System: Linux
PHP Version: 4.0CVS-2002-02-2
New Comment:
Better yet.
Could you make a script that included base64/uuencoded BIG5 data end
decode it and feed it to iconv?
Previous Comments:
[2002-02-28 19:32:59] [EMAIL PROTECTED]
BIG5
I guess it's supported by libiconv and your glibc is ok..
If text is small enough, could you pate uuencoded text there?
[2002-02-28 19:21:20] [EMAIL PROTECTED]
Hi, it's me again.
I got another segfault, this time with the iconv output buffer handler,
though iconv() seems to work now, somehow.
That's the code:
iconv_set_encoding('input_encoding', 'BIG5');
iconv_set_encoding('internal_encoding', 'UTF-8');
iconv_set_encoding('output_encoding', 'UTF-8');
ob_start('ob_iconv_handler');
echo $text;
$return = ob_get_contents();
ob_end_clean();
$text contains a BIG5 encoded message of course.
This is the bt:
Program received signal SIGSEGV, Segmentation fault.
0x4010621a in chunk_free (ar_ptr=0x89fff7cb, p=0x404e8108) at
malloc.c:3049
3049malloc.c: No such file or directory.
(gdb)
(gdb) bt
#0 0x4010621a in chunk_free (ar_ptr=0x89fff7cb, p=0x404e8108) at
malloc.c:3049
#1 0x401061bf in free () at malloc.c:2952
#2 0x40372aac in zif_iconv_set_encoding () at iconv.c:174
#3 0x40316987 in execute () at ./zend_execute.c:959
#4 0x40316baf in execute () at ./zend_execute.c:959
#5 0x403288c4 in zend_execute_scripts () at zend.c:373
#6 0x4033c507 in php_execute_script () at main.c:1265
#7 0x40336b40 in apache_php_module_main () at sapi_apache.c:100
#8 0x40337ad8 in send_php (r=0x81823a0, display_source_mode=0,
filename=0x81841b0
"/usr/local/httpd/htdocs/headhorde/imp/view.php")
at mod_php4.c:575
#9 0x40337b63 in send_parsed_php (r=0x81823a0) at mod_php4.c:590
#10 0x8055250 in ap_invoke_handler ()
#11 0x80677bc in ap_some_auth_required ()
#12 0x8067833 in ap_process_request ()
#13 0x805fd27 in ap_child_terminate ()
#14 0x805fed5 in ap_child_terminate ()
#15 0x8060016 in ap_child_terminate ()
#16 0x8060628 in ap_child_terminate ()
#17 0x8060e95 in main ()
#18 0x400cca8e in __libc_start_main () at
../sysdeps/generic/libc-start.c:93
--
Edit this bug report at http://bugs.php.net/?id=15799&edit=1
Bug #15801 Updated: unjustified open_basedir restriction on copy()
ID: 15801 Updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] Status: Open Bug Type: Filesystem function related Operating System: linux rh PHP Version: 4.1.2 New Comment: I've done some tests, and this is not specific to uploaded file. The copy() doesn't work at all any more, always giving open_basedir error. I've checked phpinfo() output from faulty scripts, and open_basedir paths are correct. Please let me know if you need more info... -- vedad Previous Comments: [2002-02-28 20:07:05] [EMAIL PROTECTED] Hello, I've got a weird open_basedir restriction error on copy() of an uploaded file. This occurs with php4.1.2, after upgrading from the old 4.0.4pl1, which didn't have the problem. php.ini and apache configuration were unchanged. Virtual host settings: php_admin_value open_basedir /path/to/website/ php_admin_value upload_tmp_dir /path/to/website/temp I'm now getting an error when file is being copied from /path/to/website/temp/ to /path/to/website/somewhereelse/ Error label: Warning: open_basedir restriction in effect. File is in wrong directory in /path/to/website/somescript.phtml on line 1055 As copy-source, copy-destination and tmp folder are all within open_basedir, I really don't get the problem. Am I missing something? Please note that in my case, /path/to/website is a symbolic link to /mnt/mountpoint/to/website, but i had no more success by putting the "real" path into open_basedir section. Thanx, -- vedad -- Edit this bug report at http://bugs.php.net/?id=15801&edit=1
