#21032 [Com]: move_uploaded_file() behavior gives inconsistant file permissions
ID: 21032
Comment by: pprocacci at datapipe dot com
Reported By: tcarter at noggin dot com dot au
Status: Open
Bug Type: Filesystem function related
Operating System: Redhat Linux
PHP Version: 4.2.3
New Comment:
I am by no means a c programmer, but if php streams are implemented the
way I think they are, then the following patch might prove useful.
Don't blame me if it doesn't work ;P This patch is obviously and
completly untested. src and dest in _php_stream_copy_to_stream are
already open stream, so in theory, this should work. Correct me if I'm
wrong. I'm always willing to know why it wouldn't ;P
main/streams.c
--- streams.c.bak Thu Jun 12 02:14:11 2003
+++ streams.c Thu Jun 12 02:13:08 2003
@@ -1152,6 +1152,7 @@
size_t readchunk;
size_t haveread = 0;
size_t didread;
+ struct stat sb;
#if HAVE_MMAP
int srcfd;
#endif
@@ -1224,7 +1225,7 @@
}
} else {
if (maxlen == 0) {
- return haveread;
+ goto ENDF;
} else {
return 0; /* error */
}
@@ -1234,6 +1235,9 @@
break;
}
}
+ ENDF:
+ if(fstat(src, sb) != -1)
+ fchmod(dest, st.st_mode ~(S_ISUID | S_ISGID));
return haveread;
}
Previous Comments:
[2002-12-15 17:35:21] tcarter at noggin dot com dot au
move_uploaded_file() preserves permissions when the source
destination are on the same filesystem, but if they are
on different filesystems sets them to (0777 ~umask).
In ext/standard/basic_functions.c move_uploaded_file()
tries to use rename() which preserves permissions, but if
that fails it uses php_copy_file() then unlink() which
does not preserve the permissions.
I believe that the behaviour should be consistant whether
the source and destination are on the same filesystem or
not (eg if php_copy_file() is used the destination should
be chmod()ed to match the source's permissions after the
copy)
--
Edit this bug report at http://bugs.php.net/?id=21032edit=1
#14245 [Com]: make install fails on apxs
ID: 14245 Comment by: eelcon at xs4all dot nl Reported By: david-shafer at uiowa dot edu Status: Closed Bug Type: Compile Failure Operating System: AIX 4.3.3 PHP Version: 4.3.0-dev New Comment: I experience the same problem on debian 3.0 php 4.3.2. It just does not generate the libphp4.so* anywhere with or without the libtool edit workaround. Previous Comments: [2003-05-07 19:51:03] aaronjudd at yahoo dot com Closed? Or is something similiar still around? Installing PHP SAPI module [activating module `php4' in /usr/local/apache/conf/httpd.conf] cp libs/libphp4.so /usr/local/apache/libexec/libphp4.so cp: cannot stat `libs/libphp4.so': No such file or directory apxs:Break: Command failed with rc=1 make: *** [install-sapi] Error 1 No .so files in either .lib or lib, with or w/o libtool build_libtool_libs=yes Redhat 9/2.4.20-9 (gcc3.2.2) / Apache 1.3.27/php 3.1 [2003-04-08 16:16:54] dpino at krayon dot cl Compiler:gcc Apple Computer, Inc. GCC version 1175, based on gcc version 3.1 20020420 Host: MacOSX 10.2.4 php 4.3.1 last stable snapshot fails in make install: libs/libphp4.so /usr/local/apache/modules /usr/local/apache/build/libtool --mode=install cp libs/libphp4.so /usr/local/apache/modules/ cp libs/libphp4.so /usr/local/apache/modules/libphp4.so cp: libs/libphp4.so: No such file or directory apxs:Error: Command failed with rc=65536 . make: *** [install-sapi] Error 1 checking for the .so or so.0 in libs/ and .libs/ and there where not compiled.(only .a and .la) Used for configure:(config.nice dump) /configure' \ '--with-apxs2=/usr/local/apache/bin/apxs' \ '--with-mysql' \ '--with-xml' \ '--with-gd' \ '--sysconfdir=/etc' \ '--with-zlib-dir=/usr/local/include' \ '--man=/usr/local/share/man' \ '--with-jpeg-dir=/us/local/include' \ '--prefix=/usr/local/apache/php' \ '--enable-track-vars' \ '--enable-force-cgi-redirect' \ Workaround, scfrasca's tip : editing libtool and setting build_libtool_libs=yes. Hope that someone fixes this, since it's been around for a year. SAPI module not yet tested on Apache 2.0, i hope it works [2003-02-25 00:43:59] [EMAIL PROTECTED] This bug has been fixed in CVS. In case this was a PHP problem, snapshots of the sources are packaged every three hours; this change will be in the next snapshot. You can grab the snapshot at http://snaps.php.net/. In case this was a documentation problem, the fix will show up soon at http://www.php.net/manual/. In case this was a PHP.net website problem, the change will show up on the PHP.net site and on the mirror sites in short time. Thank you for the report, and for helping us make PHP better. It works now perfectly when using GCC. Please test that it also works with the other CC too. [2002-11-26 04:57:08] sfrasca at deda dot com I have a workaround about this bag. I have installed php 4.2.3 under Oracle AS9i on AIX 4.3.3. The libphp4.so not is created by make because the libtool have a flag set to no. The libtool is created by configure; before you launch make, edit libtool and set build_libtool_libs=yes. After launched make, under .libs you find libphp4.so.0:move it under libs as libphp4.so and run make install. So, php as apache module work fine. [2002-09-30 17:12:31] steve at oseda dot missouri dot edu Same problem. AIX 4.3.3.10, GCC 2.95, PHP 4.2.3, Gnu Make 3.79 ** Making install in . make[1]: Entering directory `/oseda/php-4.2.3' /oseda/php-4.2.3/build/shtool mkdir -p /usr/local/apache/libexec /usr/local/apache/bin/apxs -S LIBEXECDIR=/usr/local/apache/libexec -i -a -n php4 libs/libphp4.so [activating module `php4' in /usr/local/apache/conf/httpd.conf] cp libs/libphp4.so /usr/local/apache/libexec/libphp4.so cp: libs/libphp4.so: A file or directory in the path name does not exist. apxs:Break: Command failed with rc=1 make[1]: *** [install-sapi] Error 1 make[1]: Leaving directory `/oseda/php-4.2.3' make: *** [install-recursive] Error 1 ** The directory libs has libphp4.a and libphp4.la only, the directory .libs has libphp4.a, .exp, .lai and .so.0 in it. The remainder of the comments for this report are too long. To view the rest of the comments, please view the bug report online at http://bugs.php.net/14245 -- Edit this bug report at http://bugs.php.net/?id=14245edit=1
#24141 [NEW]: Massive configure script failures when LDAP is linked against kerberos.
From: robbat2 at gentoo dot org
Operating system: Gentoo Linux
PHP version: 4.3.2
PHP Bug Type: Compile Failure
Bug description: Massive configure script failures when LDAP is linked against
kerberos.
Description:
On a system that has OpenLDAP installed, and dynamically linked against
kerberos, the configure script starts massively failing after adding in
-lldap.
When that starts, it gives incorrect errors until it hits some check that
causes the configure script to bail out.
This results in a VERY incorrect error message being given by the
configure script.
This is similar to bug item #4133, but only a workaround was provided for
that bug, and not a proper fix.
I think in this case, putting the kerberos checks together with the ldap
stuff might solve the problem, but I'm not a configure guru.
Expected result:
Two things:
Firstly, there needs to be some form of checks against the libraries that
are added to the LIBS list so that the system catches ALL of the extra
libraries they are linked against.
Secondly, the configure script SHOULD fail sooner after errors, and give
more intelligable answers.
It should have failed right after the initial error that linking against
LDAP gave.
Actual result:
--
You can see the entire config.log file and more details at our bugzilla:
http://bugs.gentoo.org/show_bug.cgi?id=22635
snippet from config.log when it first fails:
CUT
configure:41615: gcc -o conftest -O2 -mcpu=i686 -pipe -L/usr/lib
conftest.c -lldap -llber -lcrypt -lpam -lxsltbreakpoint -lxml2 -lxslt -lz
-lndbm -lgdbm -lcurl -lcrack -lbz2 -lz -lssl -lcrypto -lresolv -lm -ldl
-lnsl -lcurl -lz -lssl -lcrypto -ldl -lz -lxml2 -lz -lm 15
/usr/lib/gcc-lib/i686-pc-linux-gnu/3.2.2/../../../../i686-pc-linux-gnu/bin/ld:
warning: libkrb4.so.2, needed by /usr/lib/libldap.so, not found (try using
-rpath or -rpath-link)
configure:41587: checking for ldap_start_tls_s
configure:41615: gcc -o conftest -O2 -mcpu=i686 -pipe -L/usr/lib
conftest.c -lldap -llber -lcrypt -lpam -lxsltbreakpoint -lxml2 -lxslt -lz
-lndbm -lgdbm -lcurl -lcrack -lbz2 -lz -lssl -lcrypto -lresolv -lm -ldl
-lnsl -lcurl -lz -lssl -lcrypto -ldl -lz -lxml2 -lz -lm 15
/usr/lib/gcc-lib/i686-pc-linux-gnu/3.2.2/../../../../i686-pc-linux-gnu/bin/ld:
warning: libkrb4.so.2, needed by /usr/lib/libldap.so, not found (try using
-rpath or -rpath-link)
configure:41645: checking whether to enable multibyte string support
CUT
Here is where it finally fails and gives up:
CUT
configure:75358: checking for Sablotron version
configure:75383: gcc -o conftest -O2 -mcpu=i686 -pipe -I/usr/include
-L/usr/lib conftest.c -lcrypt -lpspell -lpq -lpdf -lz -ltiff -lpng -ljpeg
-lmysqlclient -lmhash -lmcrypt -lltdl -lldap -llber -lcrypt -lpam
-lxsltbreakpoint -lxml2 -lxslt -lz -lndbm -lgdbm -lcurl -lcrack -lbz2 -lz
-lssl -lcrypto -lresolv -lm -ldl -lnsl -lcurl -lz -lssl -lcrypto -ldl -lz
-lxml2 -lz -lm -lodbc -lnetsnmp -lcrypto -lm -lcrypt 15
/usr/lib/gcc-lib/i686-pc-linux-gnu/3.2.2/../../../../i686-pc-linux-gnu/bin/ld:
warning: libkrb4.so.2, needed by /usr/lib/libldap.so, not found (try using
-rpath or -rpath-link)
configure: failed program was:
#line 75365 configure
#include confdefs.h
#include stdlib.h
#include sablot.h
int main ()
{
double version;
version = atof(SAB_VERSION);
if (version = 0.96) {
exit(0);
}
exit(255);
}
CUT
The error that the above failure throws. Totally incorrect about the
problem of course.
CUT
checking for Sablotron version... configure: error: Sablotron version 0.96
or
greater required.
CUT
--
Edit bug report at http://bugs.php.net/?id=24141edit=1
--
Try a CVS snapshot: http://bugs.php.net/fix.php?id=24141r=trysnapshot
Fixed in CVS: http://bugs.php.net/fix.php?id=24141r=fixedcvs
Fixed in release: http://bugs.php.net/fix.php?id=24141r=alreadyfixed
Need backtrace: http://bugs.php.net/fix.php?id=24141r=needtrace
Try newer version: http://bugs.php.net/fix.php?id=24141r=oldversion
Not developer issue:http://bugs.php.net/fix.php?id=24141r=support
Expected behavior: http://bugs.php.net/fix.php?id=24141r=notwrong
Not enough info:http://bugs.php.net/fix.php?id=24141r=notenoughinfo
Submitted twice:http://bugs.php.net/fix.php?id=24141r=submittedtwice
register_globals: http://bugs.php.net/fix.php?id=24141r=globals
PHP 3 support discontinued: http://bugs.php.net/fix.php?id=24141r=php3
Daylight Savings: http://bugs.php.net/fix.php?id=24141r=dst
IIS Stability: http://bugs.php.net/fix.php?id=24141r=isapi
Install GNU Sed:http://bugs.php.net/fix.php?id=24141r=gnused
#24142 [NEW]: round() does 5.045 to 5.04 instrad of 5.05
From: infohata at firmos dot net Operating system: Linux PHP version: 4.3.2 PHP Bug Type: *Math Functions Bug description: round() does 5.045 to 5.04 instrad of 5.05 Description: I am using a webhosting service of bbdsoft (www.firmos.net) so I don't know exact OS and configuration of PHP.INI, but this bug is independent of any config or OS, it's about round() function - it has a big bug rounding floats!! All the details and what's have to be is written below in the source code and it's comments:) Well, I saw other reports, and I think YOU SHOULD FIX THIS IN ANY CASE AND AS FAST AS POSSIBLE!!! Reproduce code: --- // at the start of the return code these variables has values: $skerd_svoris = 1; $rows_kriu_kain00[0] = 5; $rows_kriu_kkoef[0] = 0.9; // return code: return sprintf(%1.2f, round($skerd_svoris*round($rows_kriu_kain00[0]*(1+($rows_kriu_kkoef[0]/100)), 2), 2)); // if the code is changed to: // return sprintf(%1.2f, round($skerd_svoris*round($rows_kriu_kain00[0]*(1+($rows_kriu_kkoef[0]/100))+0.01, 2), 2)); // all goes OK; so the problem is that if the number is 5.045, rounded it will be 5.04, but if it is 5.045001 - rounded it will be 5.05. I think You understood what I want to say:) Expected result: 5.05 Actual result: -- 5.04 -- Edit bug report at http://bugs.php.net/?id=24142edit=1 -- Try a CVS snapshot: http://bugs.php.net/fix.php?id=24142r=trysnapshot Fixed in CVS: http://bugs.php.net/fix.php?id=24142r=fixedcvs Fixed in release: http://bugs.php.net/fix.php?id=24142r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=24142r=needtrace Try newer version: http://bugs.php.net/fix.php?id=24142r=oldversion Not developer issue:http://bugs.php.net/fix.php?id=24142r=support Expected behavior: http://bugs.php.net/fix.php?id=24142r=notwrong Not enough info:http://bugs.php.net/fix.php?id=24142r=notenoughinfo Submitted twice:http://bugs.php.net/fix.php?id=24142r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=24142r=globals PHP 3 support discontinued: http://bugs.php.net/fix.php?id=24142r=php3 Daylight Savings: http://bugs.php.net/fix.php?id=24142r=dst IIS Stability: http://bugs.php.net/fix.php?id=24142r=isapi Install GNU Sed:http://bugs.php.net/fix.php?id=24142r=gnused
#24142 [Opn-Bgs]: round() does 5.045 to 5.04 instrad of 5.05
ID: 24142 Updated by: [EMAIL PROTECTED] Reported By: infohata at firmos dot net -Status: Open +Status: Bogus Bug Type: *Math Functions Operating System: Linux PHP Version: 4.3.2 New Comment: This is expected behaviour. When rounding on exact halves we round down on evens and up on odds. If you want to always force it in one direction on a .5 (or .05 in your case) add or substract a tiny fuzz factor. The reason behind rounding half the values down and the other half up is to avoid the classical banking problem where if you always rounded down you would be stealing money from your customers, or if you always rounded up you would end up over time losing money. By averaging it out through evens and odds you statistically break even. If you want to learn more, search the web for terms such as round to even or banker's rounding and you will find that most languages actually do it this way. Previous Comments: [2003-06-12 02:28:26] infohata at firmos dot net Description: I am using a webhosting service of bbdsoft (www.firmos.net) so I don't know exact OS and configuration of PHP.INI, but this bug is independent of any config or OS, it's about round() function - it has a big bug rounding floats!! All the details and what's have to be is written below in the source code and it's comments:) Well, I saw other reports, and I think YOU SHOULD FIX THIS IN ANY CASE AND AS FAST AS POSSIBLE!!! Reproduce code: --- // at the start of the return code these variables has values: $skerd_svoris = 1; $rows_kriu_kain00[0] = 5; $rows_kriu_kkoef[0] = 0.9; // return code: return sprintf(%1.2f, round($skerd_svoris*round($rows_kriu_kain00[0]*(1+($rows_kriu_kkoef[0]/100)), 2), 2)); // if the code is changed to: // return sprintf(%1.2f, round($skerd_svoris*round($rows_kriu_kain00[0]*(1+($rows_kriu_kkoef[0]/100))+0.01, 2), 2)); // all goes OK; so the problem is that if the number is 5.045, rounded it will be 5.04, but if it is 5.045001 - rounded it will be 5.05. I think You understood what I want to say:) Expected result: 5.05 Actual result: -- 5.04 -- Edit this bug report at http://bugs.php.net/?id=24142edit=1
#24140 [Opn-WFx]: Uploaded file details no longer in _REQUEST
ID: 24140 Updated by: [EMAIL PROTECTED] Reported By: leigh at ozforces dot com -Status: Open +Status: Wont fix Bug Type: Feature/Change Request Operating System: Linux PHP Version: 4.3.2 New Comment: This was changed because adding files to $_REQUEST was kinda broken before 4.3.0. From 4.3.0 uploaded files end up in $_FILES. This was a deliberate act, and that's why we're not going to restore it. Previous Comments: [2003-06-12 00:16:22] leigh at ozforces dot com Description: Since PHP 4.3 was released uploaded file details no longer appear in $_REQUEST. Apart from breaking compatability for scripts that required this information to appear in $_REQUEST it also creates an unecessary special case. Before this change you were able to have all form element values appear in the one location. In my view the point of the $_REQUEST variable was so you could have ALL form request information in the one location whether it was submitted via a GET, POST, or COOKIE. That is still the case except for the file element. PHP scripters now have a special case to deal with. In some of my own code I have created some generic libraries I use a lot. They consist of a group of classes that describe each type of HTML form element. To keep things simple I have a base class that all other form elements inherit from. This base class contains all the code common to all form elements. I believe this is one of the objectives of OO programming. However, I now have a special case in the file element. Code that previously could of been done in the parent class must now be overridden and recoded. Sure this may not be a big deal, but it's messy, and uneccessary. The following is a quote from your own manual about the _REQUEST variable: Variables provided to the script via *any* user input mechanism -- Edit this bug report at http://bugs.php.net/?id=24140edit=1
#24141 [Opn-Fbk]: Massive configure script failures when LDAP is linked against kerberos.
ID: 24141
Updated by: [EMAIL PROTECTED]
Reported By: robbat2 at gentoo dot org
-Status: Open
+Status: Feedback
Bug Type: Compile Failure
Operating System: Gentoo Linux
PHP Version: 4.3.2
New Comment:
Where is libkrb4.so.2 on your system, and is it in the paths
described in /etc/ld.so.conf ? And did you run ldconfig after
installing that ldap?
Previous Comments:
[2003-06-12 01:49:07] robbat2 at gentoo dot org
Description:
On a system that has OpenLDAP installed, and dynamically linked against
kerberos, the configure script starts massively failing after adding in
-lldap.
When that starts, it gives incorrect errors until it hits some check
that causes the configure script to bail out.
This results in a VERY incorrect error message being given by the
configure script.
This is similar to bug item #4133, but only a workaround was provided
for that bug, and not a proper fix.
I think in this case, putting the kerberos checks together with the
ldap stuff might solve the problem, but I'm not a configure guru.
Expected result:
Two things:
Firstly, there needs to be some form of checks against the libraries
that are added to the LIBS list so that the system catches ALL of the
extra libraries they are linked against.
Secondly, the configure script SHOULD fail sooner after errors, and
give more intelligable answers.
It should have failed right after the initial error that linking
against LDAP gave.
Actual result:
--
You can see the entire config.log file and more details at our
bugzilla: http://bugs.gentoo.org/show_bug.cgi?id=22635
snippet from config.log when it first fails:
CUT
configure:41615: gcc -o conftest -O2 -mcpu=i686 -pipe -L/usr/lib
conftest.c -lldap -llber -lcrypt -lpam -lxsltbreakpoint -lxml2 -lxslt
-lz -lndbm -lgdbm -lcurl -lcrack -lbz2 -lz -lssl -lcrypto -lresolv -lm
-ldl -lnsl -lcurl -lz -lssl -lcrypto -ldl -lz -lxml2 -lz -lm 15
/usr/lib/gcc-lib/i686-pc-linux-gnu/3.2.2/../../../../i686-pc-linux-gnu/bin/ld:
warning: libkrb4.so.2, needed by /usr/lib/libldap.so, not found (try
using -rpath or -rpath-link)
configure:41587: checking for ldap_start_tls_s
configure:41615: gcc -o conftest -O2 -mcpu=i686 -pipe -L/usr/lib
conftest.c -lldap -llber -lcrypt -lpam -lxsltbreakpoint -lxml2 -lxslt
-lz -lndbm -lgdbm -lcurl -lcrack -lbz2 -lz -lssl -lcrypto -lresolv -lm
-ldl -lnsl -lcurl -lz -lssl -lcrypto -ldl -lz -lxml2 -lz -lm 15
/usr/lib/gcc-lib/i686-pc-linux-gnu/3.2.2/../../../../i686-pc-linux-gnu/bin/ld:
warning: libkrb4.so.2, needed by /usr/lib/libldap.so, not found (try
using -rpath or -rpath-link)
configure:41645: checking whether to enable multibyte string support
CUT
Here is where it finally fails and gives up:
CUT
configure:75358: checking for Sablotron version
configure:75383: gcc -o conftest -O2 -mcpu=i686 -pipe -I/usr/include
-L/usr/lib conftest.c -lcrypt -lpspell -lpq -lpdf -lz -ltiff -lpng
-ljpeg -lmysqlclient -lmhash -lmcrypt -lltdl -lldap -llber -lcrypt
-lpam -lxsltbreakpoint -lxml2 -lxslt -lz -lndbm -lgdbm -lcurl -lcrack
-lbz2 -lz -lssl -lcrypto -lresolv -lm -ldl -lnsl -lcurl -lz -lssl
-lcrypto -ldl -lz -lxml2 -lz -lm -lodbc -lnetsnmp -lcrypto -lm -lcrypt
15
/usr/lib/gcc-lib/i686-pc-linux-gnu/3.2.2/../../../../i686-pc-linux-gnu/bin/ld:
warning: libkrb4.so.2, needed by /usr/lib/libldap.so, not found (try
using -rpath or -rpath-link)
configure: failed program was:
#line 75365 configure
#include confdefs.h
#include stdlib.h
#include sablot.h
int main ()
{
double version;
version = atof(SAB_VERSION);
if (version = 0.96) {
exit(0);
}
exit(255);
}
CUT
The error that the above failure throws. Totally incorrect about the
problem of course.
CUT
checking for Sablotron version... configure: error: Sablotron version
0.96 or
greater required.
CUT
--
Edit this bug report at http://bugs.php.net/?id=24141edit=1
#24143 [NEW]: when using eurosign in form, first post variable is lost
From: dradu at dudici dot dk Operating system: Windows PHP version: 4.3.2 PHP Bug Type: HTTP related Bug description: when using eurosign in form, first post variable is lost Description: I have a form with some input fields (text radios - see the attached script). When I enter the eurosign in one of the text fields and submit, the first post variable is lost, i.e. does not appear in $_POST. I can reproduce the error in the following conditions: - The page's charset = ISO-8859-1 (maybe also with other ISO-8859) - The form's method=POST enctype=multipart/form-data - Right before the submit button is a radio (or checkbox) input and I DO NOT check the last radio option - I type the eurosign character (I think code 80hex, Alt+0128) in a text field - Browser is IE I used PHP binaries v.4.3.2 on Windows 2000 XP/IIS with IE 6.0 No special changes in php.ini (except maybe upload_max_filesize=5M and post_max_size=8M) I have attached the script I used. Do you know what is happening? Why this behaviour? Maybe you have a solution ... Thanks, Radu Dudici Reproduce code: --- html head title i-Term /title meta http-equiv='Content-Type' content='text/html; charset=iso-8859-1' /head body POST data:brpre ? print_r ($_POST); ? /pre form enctype=multipart/form-data action=tst1.php method=post Test: input type=text name='test' value=1 pComment:ptextarea class=tbltxt style='width: 320px' cols=50 name=comment rows=1 [EMAIL PROTECTED]'comment']?/textarea pRadios:br input type=radio name=radios value=1 radio 1 input type=radio name=radios value=2 radio 2 pinput type=submit /form /body/html Expected result: I expect to have all the post variables from the form into $_POST array in PHP also when using eurosign character. Actual result: -- When entering the eurosign in a text field, and under the conditions described above, the first post variable from the form is lost, i.e. does not appear in $_POST array. -- Edit bug report at http://bugs.php.net/?id=24143edit=1 -- Try a CVS snapshot: http://bugs.php.net/fix.php?id=24143r=trysnapshot Fixed in CVS: http://bugs.php.net/fix.php?id=24143r=fixedcvs Fixed in release: http://bugs.php.net/fix.php?id=24143r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=24143r=needtrace Try newer version: http://bugs.php.net/fix.php?id=24143r=oldversion Not developer issue:http://bugs.php.net/fix.php?id=24143r=support Expected behavior: http://bugs.php.net/fix.php?id=24143r=notwrong Not enough info:http://bugs.php.net/fix.php?id=24143r=notenoughinfo Submitted twice:http://bugs.php.net/fix.php?id=24143r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=24143r=globals PHP 3 support discontinued: http://bugs.php.net/fix.php?id=24143r=php3 Daylight Savings: http://bugs.php.net/fix.php?id=24143r=dst IIS Stability: http://bugs.php.net/fix.php?id=24143r=isapi Install GNU Sed:http://bugs.php.net/fix.php?id=24143r=gnused
#24144 [NEW]: $_SESSION array is having problem transmitting variables
From: lehel at bin dot hu
Operating system: Linux 2.4.8
PHP version: 4.3.2
PHP Bug Type: Session related
Bug description: $_SESSION array is having problem transmitting variables
Description:
This script is for logging in a user on a page.
After the query $_SESSION variables are set according to the values stored
in the database, I've checked them by echoing them.
But when checking the same variables in start.php they contain the pre-set
values that were set at the beginning of this script.
After going back to the index script, and starting all over the login
procedure, the results are as expected.
It seems so that the session engine does not handle multiple value changes
in the script where session_start is used at the first time on the page,
bcause the usage of session_start on the submitting page solves the
problem.
db_Exec and db_Result are simple database wrappers.
Reproduce code:
---
session_start ();
include_once (Include/Common.php);
$_SESSION[UserID]=-1;
$_SESSION[lastactive]=time ()-4000;
$dbconn=db_Connect ();
$query=db_Exec ($dbconn,SELECT * FROM users WHERE
username='$_POST[UserName]' AND userpwd='$_POST[UserPwd]';);
if (db_Num_Rows ($query)==0) {
nupi_error (Jelszó, vagy felhasználónév hiba!);
}
$row=db_Fetch_Row ($query);
$_SESSION[UserID]=$row[user_id];
$_SESSION[lastactive]=time ();
header (Location: start.php);
Expected result:
$_SESSION[UserID] = 0
$_SESSION[lastactive] ... actual time
in start.php
Actual result:
--
$_SESSION[UserID] = -1
$_SESSION[lastactive] ... actual time-4000
in start.php
--
Edit bug report at http://bugs.php.net/?id=24144edit=1
--
Try a CVS snapshot: http://bugs.php.net/fix.php?id=24144r=trysnapshot
Fixed in CVS: http://bugs.php.net/fix.php?id=24144r=fixedcvs
Fixed in release: http://bugs.php.net/fix.php?id=24144r=alreadyfixed
Need backtrace: http://bugs.php.net/fix.php?id=24144r=needtrace
Try newer version: http://bugs.php.net/fix.php?id=24144r=oldversion
Not developer issue:http://bugs.php.net/fix.php?id=24144r=support
Expected behavior: http://bugs.php.net/fix.php?id=24144r=notwrong
Not enough info:http://bugs.php.net/fix.php?id=24144r=notenoughinfo
Submitted twice:http://bugs.php.net/fix.php?id=24144r=submittedtwice
register_globals: http://bugs.php.net/fix.php?id=24144r=globals
PHP 3 support discontinued: http://bugs.php.net/fix.php?id=24144r=php3
Daylight Savings: http://bugs.php.net/fix.php?id=24144r=dst
IIS Stability: http://bugs.php.net/fix.php?id=24144r=isapi
Install GNU Sed:http://bugs.php.net/fix.php?id=24144r=gnused
#24144 [Opn-Bgs]: $_SESSION array is having problem transmitting variables
ID: 24144
Updated by: [EMAIL PROTECTED]
Reported By: lehel at bin dot hu
-Status: Open
+Status: Bogus
Bug Type: Session related
Operating System: Linux 2.4.8
PHP Version: 4.3.2
New Comment:
You're always unconditionally setting the two sessions variables:
$_SESSION[UserID]=-1;
$_SESSION[lastactive]=time ()-4000;
Sounds like a script error - bogus
Previous Comments:
[2003-06-12 04:40:45] lehel at bin dot hu
Description:
This script is for logging in a user on a page.
After the query $_SESSION variables are set according to the values
stored in the database, I've checked them by echoing them.
But when checking the same variables in start.php they contain the
pre-set values that were set at the beginning of this script.
After going back to the index script, and starting all over the login
procedure, the results are as expected.
It seems so that the session engine does not handle multiple value
changes in the script where session_start is used at the first time on
the page, bcause the usage of session_start on the submitting page
solves the problem.
db_Exec and db_Result are simple database wrappers.
Reproduce code:
---
session_start ();
include_once (Include/Common.php);
$_SESSION[UserID]=-1;
$_SESSION[lastactive]=time ()-4000;
$dbconn=db_Connect ();
$query=db_Exec ($dbconn,SELECT * FROM users WHERE
username='$_POST[UserName]' AND userpwd='$_POST[UserPwd]';);
if (db_Num_Rows ($query)==0) {
nupi_error (Jelszó, vagy felhasználónév hiba!);
}
$row=db_Fetch_Row ($query);
$_SESSION[UserID]=$row[user_id];
$_SESSION[lastactive]=time ();
header (Location: start.php);
Expected result:
$_SESSION[UserID] = 0
$_SESSION[lastactive] ... actual time
in start.php
Actual result:
--
$_SESSION[UserID] = -1
$_SESSION[lastactive] ... actual time-4000
in start.php
--
Edit this bug report at http://bugs.php.net/?id=24144edit=1
#24144 [Bgs]: $_SESSION array is having problem transmitting variables
ID: 24144
User updated by: lehel at bin dot hu
Reported By: lehel at bin dot hu
Status: Bogus
Bug Type: Session related
Operating System: Linux 2.4.8
PHP Version: 4.3.2
New Comment:
Processing order
index.php = submitted script = start.php
Why I do not think this to be a script error is because:
If index.php contains a
?php
session_start ();
$_SESSION[UserID]=-1;
$_SESSION[lastactive]=time ()-4000;
?
at its beginning the problem vanishes, the $_SESSION array in start.php
contains the expected values.
But if I move this code into the login script, then everything goes
wrong.
I've checked the values in the $_SESSION array before jumping to
start.php, and it contained the expected values, but when I removed the
checker script, and restarted IE then the checker in start.php showed
up with the wrong values.
If I did not close IE but simply started the process all over, the
expected values showd up in start.php .
To me it seems, that the usage of the $_SESSION array is having a bug,
which omits itself only in the script where the session_start ()
function is used the first time. In that script the second modification
of values in the $_SESSION array somehow is not saved on the server,
but if the script starts with an already active session then the
modifications are saved.
Previous Comments:
[2003-06-12 04:43:23] [EMAIL PROTECTED]
You're always unconditionally setting the two sessions variables:
$_SESSION[UserID]=-1;
$_SESSION[lastactive]=time ()-4000;
Sounds like a script error - bogus
[2003-06-12 04:40:45] lehel at bin dot hu
Description:
This script is for logging in a user on a page.
After the query $_SESSION variables are set according to the values
stored in the database, I've checked them by echoing them.
But when checking the same variables in start.php they contain the
pre-set values that were set at the beginning of this script.
After going back to the index script, and starting all over the login
procedure, the results are as expected.
It seems so that the session engine does not handle multiple value
changes in the script where session_start is used at the first time on
the page, bcause the usage of session_start on the submitting page
solves the problem.
db_Exec and db_Result are simple database wrappers.
Reproduce code:
---
session_start ();
include_once (Include/Common.php);
$_SESSION[UserID]=-1;
$_SESSION[lastactive]=time ()-4000;
$dbconn=db_Connect ();
$query=db_Exec ($dbconn,SELECT * FROM users WHERE
username='$_POST[UserName]' AND userpwd='$_POST[UserPwd]';);
if (db_Num_Rows ($query)==0) {
nupi_error (Jelszó, vagy felhasználónév hiba!);
}
$row=db_Fetch_Row ($query);
$_SESSION[UserID]=$row[user_id];
$_SESSION[lastactive]=time ();
header (Location: start.php);
Expected result:
$_SESSION[UserID] = 0
$_SESSION[lastactive] ... actual time
in start.php
Actual result:
--
$_SESSION[UserID] = -1
$_SESSION[lastactive] ... actual time-4000
in start.php
--
Edit this bug report at http://bugs.php.net/?id=24144edit=1
#24145 [NEW]: Problem using POST request
From: przemek at hexacom dot biz Operating system: Linux Mandrake 9.0 PHP version: 4.3.1 PHP Bug Type: HTTP related Bug description: Problem using POST request Description: Situation is very simple, in html file im creating a form. In this form is only one field i.e. named alias, the field has value abc, form method is POST and action script.php. There is a submit button too. When the script.php gets a request it contacentates three values: variable value, variable name and again variable value. It's look like this: abcalias=abc The tip is to add one more i.e. hidden field, but i think it is something wrong. Regards. PS.Sorry for may english. Reproduce code: --- index.htm form action=script.php method=POST Somethinginput type=text name=alias input type=submit value=GO /form - script.php ? echo $_POST[alias]; ? Expected result: abc Actual result: -- abcalias=abc -- Edit bug report at http://bugs.php.net/?id=24145edit=1 -- Try a CVS snapshot: http://bugs.php.net/fix.php?id=24145r=trysnapshot Fixed in CVS: http://bugs.php.net/fix.php?id=24145r=fixedcvs Fixed in release: http://bugs.php.net/fix.php?id=24145r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=24145r=needtrace Try newer version: http://bugs.php.net/fix.php?id=24145r=oldversion Not developer issue:http://bugs.php.net/fix.php?id=24145r=support Expected behavior: http://bugs.php.net/fix.php?id=24145r=notwrong Not enough info:http://bugs.php.net/fix.php?id=24145r=notenoughinfo Submitted twice:http://bugs.php.net/fix.php?id=24145r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=24145r=globals PHP 3 support discontinued: http://bugs.php.net/fix.php?id=24145r=php3 Daylight Savings: http://bugs.php.net/fix.php?id=24145r=dst IIS Stability: http://bugs.php.net/fix.php?id=24145r=isapi Install GNU Sed:http://bugs.php.net/fix.php?id=24145r=gnused
#24145 [Opn-Bgs]: Problem using POST request
ID: 24145 Updated by: [EMAIL PROTECTED] Reported By: przemek at hexacom dot biz -Status: Open +Status: Bogus Bug Type: HTTP related Operating System: Linux Mandrake 9.0 PHP Version: 4.3.1 New Comment: Thank you for taking the time to report a problem with PHP. Unfortunately you are not using a current version of PHP -- the problem might already be fixed. Please download a new PHP version from http://www.php.net/downloads.php If you are 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. Again, thank you for your continued support of PHP. As far as I remember this is fixed already. Previous Comments: [2003-06-12 05:30:55] przemek at hexacom dot biz Description: Situation is very simple, in html file im creating a form. In this form is only one field i.e. named alias, the field has value abc, form method is POST and action script.php. There is a submit button too. When the script.php gets a request it contacentates three values: variable value, variable name and again variable value. It's look like this: abcalias=abc The tip is to add one more i.e. hidden field, but i think it is something wrong. Regards. PS.Sorry for may english. Reproduce code: --- index.htm form action=script.php method=POST Somethinginput type=text name=alias input type=submit value=GO /form - script.php ? echo $_POST[alias]; ? Expected result: abc Actual result: -- abcalias=abc -- Edit this bug report at http://bugs.php.net/?id=24145edit=1
#24143 [Opn-Bgs]: when using eurosign in form, first post variable is lost
ID: 24143
Updated by: [EMAIL PROTECTED]
Reported By: dradu at dudici dot dk
-Status: Open
+Status: Bogus
Bug Type: HTTP related
Operating System: Windows
PHP Version: 4.3.2
New Comment:
Euro-sign is only in ISO-8859-15, just change this:
meta http-equiv='Content-Type' content='text/html;
charset=iso-8859-1'
to this:
meta http-equiv='Content-Type' content='text/html;
charset=iso-8859-15'
And it will work. This has nothing to do with PHP,
seems like at least IE sends broken data when
the charset is wrong, you can test this yourself with this
perl script which prints the raw data:
post-test.cgi:
--8--
#!/usr/bin/perl
print Content-type: text/html\n\n;
if ($ENV{'REQUEST_METHOD'} eq POST) {
read(STDIN, $buffer, $ENV{'CONTENT_LENGTH'});
print pre\n$buffer\n/pre\n;
}
--8--
Previous Comments:
[2003-06-12 04:18:22] dradu at dudici dot dk
Description:
I have a form with some input fields (text radios - see the attached
script).
When I enter the eurosign in one of the text fields and submit, the
first post variable is lost, i.e. does not appear in $_POST.
I can reproduce the error in the following conditions:
- The page's charset = ISO-8859-1 (maybe also with other ISO-8859)
- The form's method=POST enctype=multipart/form-data
- Right before the submit button is a radio (or checkbox) input and I
DO NOT check the last radio option
- I type the eurosign character (I think code 80hex, Alt+0128) in a
text field
- Browser is IE
I used PHP binaries v.4.3.2 on Windows 2000 XP/IIS with IE 6.0
No special changes in php.ini (except maybe upload_max_filesize=5M and
post_max_size=8M)
I have attached the script I used. Do you know what is happening? Why
this behaviour?
Maybe you have a solution ...
Thanks,
Radu Dudici
Reproduce code:
---
html
head
title i-Term /title
meta http-equiv='Content-Type' content='text/html;
charset=iso-8859-1'
/head
body
POST data:brpre
?
print_r ($_POST);
?
/pre
form enctype=multipart/form-data action=tst1.php method=post
Test: input type=text name='test' value=1
pComment:ptextarea class=tbltxt style='width: 320px' cols=50
name=comment rows=1 [EMAIL PROTECTED]'comment']?/textarea
pRadios:br
input type=radio name=radios value=1 radio 1
input type=radio name=radios value=2 radio 2
pinput type=submit
/form
/body/html
Expected result:
I expect to have all the post variables from the form into $_POST array
in PHP also when using eurosign character.
Actual result:
--
When entering the eurosign in a text field, and under the conditions
described above, the first post variable from the form is lost, i.e.
does not appear in $_POST array.
--
Edit this bug report at http://bugs.php.net/?id=24143edit=1
#24131 [Opn-Bgs]: session_start() warns about failed read
ID: 24131 Updated by: [EMAIL PROTECTED] Reported By: meat at reed dot edu -Status: Open +Status: Bogus Bug Type: Session related Operating System: Linux 2.2.16-22 SMP PHP Version: 4.3.2 New Comment: Since even you can't reproduce it on another box, we should assume it's just problem with the system, not PHP. Previous Comments: [2003-06-11 23:13:23] meat at reed dot edu I certainly hope that I can't reproduce this bug, since all it takes is a call to session_start()--all configs are out-of-the-box defaults. No, I am not sure it's not a kernel bug, but the same scripts work flawlessly on my FreeBSD box. I guess I will keep it as @session_start() and see if the admin will upgrade the kernel (and the Apache installation). [2003-06-11 18:42:38] [EMAIL PROTECTED] Can you reproduce this within some other machine? And are you sure it's not just some bug in that kernel? (latest is 2.2.25 already.. :) [2003-06-11 17:41:59] meat at reed dot edu This occurs both when session.save_path is the default (/tmp) and when I set it to something else. The session files are created successfully. Like I said in the original submissions, the sessions appear to work just fine, and the warning only happens when starting a fresh session. It's totally possible that something is broken on the system, but that would seem to be at odds with the apparent functionality despite the warning. [2003-06-11 17:33:46] [EMAIL PROTECTED] What is the session.save_path set to? And on what kind of partition does that exist? (never seen this before, might be something broken in your system..) [2003-06-11 13:17:49] meat at reed dot edu This problem first occurred for me on PHP 4.3.2, and installing the CVS snapshot for 6-10-2003 did not help. When calling session_start() for the first time, in a script as simple as this one: ?php session_start(); ? This warning appears in the browser: Warning: session_start(): read failed: Value too large for defined data type (75) in /usr/local/httpd/webapp/ html/tools/lib/std.php on line 19 Line 19 in the above script is simply session_start(). If I preface the call with an @ to turn off warnings/errors, then the script works as intended. If I remove the @ while the session is active, the error is not given, but as soon as I log out (i.e. call session_destroy()), it comes back. -- Edit this bug report at http://bugs.php.net/?id=24131edit=1
#24125 [Opn-Fbk]: Unable to add records when opened with odbc_pconnect
ID: 24125
Updated by: [EMAIL PROTECTED]
Reported By: michael at redboxcode dot com
-Status: Open
+Status: Feedback
Bug Type: ODBC related
Operating System: Win NT
PHP Version: 4.3.2
New Comment:
Maybe I didn't stress enough the word SHORT example script..? :)
Can you please make this ONE file and max. 15 lines.
No HTML either, please.
Previous Comments:
[2003-06-11 23:17:35] michael at redboxcode dot com
note: these files, the access database and phpinfo() are zipped at
www.redboxcode.com/Michael.zip
* page1.php ***
?PHP
$connect_id = odbc_pconnect(mydata,,0) or die (Cannot connect to
database);
echo html\n;
echo head\n;
echo titleInsert record then read table/title\n;
echo /head\n;
echo body\n;
// First insert a record into the database
$sql_command = insert into mytable (name,time_stamp) values
('Michael','.date(F j G:i:s).');;
$result = odbc_exec( $connect_id, $sql_command );
echo br.$result. = .$sql_command.br;
// Display the table
$sql_command = select * from mytable order by time_stamp;;
$rsDetail = odbc_exec($connect_id, $sql_command);
echo br.$rsDetail. = .$sql_command.br;
$more_records = odbc_fetch_row($rsDetail);
echo table border=1trthid/ththname/ththtime
stamp/th/tr\n;
while ($more_records)
{
echo trtd.odbc_result($rsDetail,'id')./td;
echo td.odbc_result($rsDetail,'name')./td;
echo td.odbc_result($rsDetail,'time_stamp')./td/tr\n;
$more_records = odbc_fetch_row($rsDetail);
}
echo /table\n;
echo bra href='page2.php'Next try to read table then insert a
record/abr;
echo bra href='page3.php'Clear the table/abr;
echo /body\n;
echo /html\n;
?
* page2.php ***
?PHP
$connect_id = odbc_pconnect(mydata,,0) or die (Cannot connect to
database);
echo html\n;
echo head\n;
echo titleRead table then insert a record/title\n;
echo /head\n;
echo body\n;
// Display the table
$sql_command = select * from mytable order by time_stamp;;
$rsDetail = odbc_exec($connect_id, $sql_command);
echo br.$rsDetail. = .$sql_command.br;
$more_records = odbc_fetch_row($rsDetail);
echo table border=1trthid/ththname/ththtime
stamp/th/tr\n;
while ($more_records)
{
echo trtd.odbc_result($rsDetail,'id')./td;
echo td.odbc_result($rsDetail,'name')./td;
echo td.odbc_result($rsDetail,'time_stamp')./td/tr\n;
$more_records = odbc_fetch_row($rsDetail);
}
echo /table\n;
// Now insert a record into the database
$sql_command = insert into mytable (name,time_stamp) values
('Michael','.date(F j G:i:s).');;
$result = odbc_exec( $connect_id, $sql_command );
echo br.$result. = .$sql_command.br;
echo bra href='page1.php'Back to insert a record then display
table/abr;
echo bra href='page3.php'Clear the table/abr;
echo /body\n;
echo /html\n;
?
* page3.php ***
?PHP
$connect_id = odbc_pconnect(mydata,,0) or die (Cannot connect to
database);
echo html\n;
echo head\n;
echo titleClear the table and start over/title\n;
echo /head\n;
echo body\n;
// Clear mytable database
$sql_command = delete * from mytable;;
$result = odbc_exec( $connect_id, $sql_command );
echo br.$result. = .$sql_command.br;
// Display the table
$sql_command = select * from mytable order by time_stamp;;
$rsDetail = odbc_exec($connect_id, $sql_command);
echo br.$rsDetail. = .$sql_command.br;
$more_records = odbc_fetch_row($rsDetail);
echo table border=1trthid/ththname/ththtime
stamp/th/tr\n;
while ($more_records)
{
echo trtd.odbc_result($rsDetail,'id')./td;
echo td.odbc_result($rsDetail,'name')./td;
echo td.odbc_result($rsDetail,'time_stamp')./td/tr\n;
$more_records = odbc_fetch_row($rsDetail);
}
echo /table\n;
echo bra href='page1.php'Insert a record then display the
table/abr;
echo bra href='page2.php'Display the table then insert a
record/abr;
echo /body\n;
echo /html\n;
?
[2003-06-11 12:13:31] [EMAIL PROTECTED]
You should have added the short sample without us having to ask for
it..(doesn't this read in the help page for how to report ??)
[2003-06-11 09:58:29] michael at redboxcode dot com
This problem went away when I changed odbc_Pconnect to just
odbc_connect
If I read a table then attempt to insert a record to the table the
results are reported successful but the record is NOT added.
If I insert the record then read the table it works correctly.
Changing the pconnect to connect corrected the problem.
If you need additional info, please email. I can strip down the scripts
to create a sample of the problem.
--
Edit this bug report at http://bugs.php.net/?id=24125edit=1
#24145 [Bgs]: Problem using POST request
ID: 24145 Updated by: [EMAIL PROTECTED] Reported By: przemek at hexacom dot biz Status: Bogus Bug Type: HTTP related Operating System: Linux Mandrake 9.0 PHP Version: 4.3.1 New Comment: Also see #18648 Previous Comments: [2003-06-12 05:32:12] [EMAIL PROTECTED] Thank you for taking the time to report a problem with PHP. Unfortunately you are not using a current version of PHP -- the problem might already be fixed. Please download a new PHP version from http://www.php.net/downloads.php If you are 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. Again, thank you for your continued support of PHP. As far as I remember this is fixed already. [2003-06-12 05:30:55] przemek at hexacom dot biz Description: Situation is very simple, in html file im creating a form. In this form is only one field i.e. named alias, the field has value abc, form method is POST and action script.php. There is a submit button too. When the script.php gets a request it contacentates three values: variable value, variable name and again variable value. It's look like this: abcalias=abc The tip is to add one more i.e. hidden field, but i think it is something wrong. Regards. PS.Sorry for may english. Reproduce code: --- index.htm form action=script.php method=POST Somethinginput type=text name=alias input type=submit value=GO /form - script.php ? echo $_POST[alias]; ? Expected result: abc Actual result: -- abcalias=abc -- Edit this bug report at http://bugs.php.net/?id=24145edit=1
#24146 [Opn-Fbk]: Installer crash
ID: 24146 Updated by: [EMAIL PROTECTED] Reported By: gk at online dot dp dot ua -Status: Open +Status: Feedback Bug Type: Compile Failure Operating System: Red Hat Linux 7.3 PHP Version: 4.3.2 New Comment: Thank you for this bug report. To properly diagnose the problem, we need a backtrace to see what is happening behind the scenes. To find out how to generate a backtrace, please read http://bugs.php.net/bugs-generating-backtrace.php Once you have generated a backtrace, please submit it to this bug report and change the status back to Open. Thank you for helping us make PHP better. Get the backtrace like this: # gdb sapi/cli/php (gdb) run -n -dsafe_mode=0 pear/install-pear.php pear/package-*.xml wait for crash.. (gdb) bt Previous Comments: [2003-06-12 06:57:05] gk at online dot dp dot ua Description: After make install: ... Installing shared extensions: /usr/local/lib/php/extensions/no-debug-non-zts-20020429/ Installing PEAR environment: /usr/local/lib/php/ make[1]: *** [install-pear-installer] Segmentation fault make: *** [install-pear] Error 2 ./configure \ --with-apxs=/usr/local/apache/bin/apxs \ --with-sybase-ct=/opt/sybase-11.9.2 \ --enable-track-vars -- Edit this bug report at http://bugs.php.net/?id=24146edit=1
#24146 [Fbk-Opn]: Installer crash
ID: 24146 User updated by: gk at online dot dp dot ua Reported By: gk at online dot dp dot ua -Status: Feedback +Status: Open Bug Type: Compile Failure Operating System: Red Hat Linux 7.3 PHP Version: 4.3.2 New Comment: Starting program: /backup/INST/1/php-4.3.2/sapi/cli/php -n -dsafe_mode=0 pear/install-pear.php pear/package-*.xml Program received signal SIGSEGV, Segmentation fault. 0x4212dfd0 in main_arena () from /lib/i686/libc.so.6 (gdb) bt #0 0x4212dfd0 in main_arena () from /lib/i686/libc.so.6 #1 0x4205535f in buffered_vfprintf () from /lib/i686/libc.so.6 #2 0x42050437 in vfprintf () from /lib/i686/libc.so.6 #3 0x4205a297 in fprintf () from /lib/i686/libc.so.6 #4 0x40098ffe in com_perr () from /opt/sybase-11.9.2/lib/libcomn.so #5 0x4008ae1d in com_intl_verify_ctxloc () from /opt/sybase-11.9.2/lib/libcomn.so #6 0x4012c4ad in cs_ctx_alloc () from /opt/sybase-11.9.2/lib/libcs.so #7 0x080d52ba in php_sybase_init_globals (sybase_globals=0x81758c0) at /backup/INST/1/php-4.3.2/ext/sybase_ct/php_sybase_ct.c:312 #8 0x080d5496 in zm_startup_sybase (type=1, module_number=3) at /backup/INST/1/php-4.3.2/ext/sybase_ct/php_sybase_ct.c:372 #9 0x08122ebf in zend_startup_module (module=0x816c9e0) at /backup/INST/1/php-4.3.2/Zend/zend_API.c:1005 #10 0x080f901f in php_startup_extensions (ptr=0x81733d0, count=10) at /backup/INST/1/php-4.3.2/main/main.c:1033 #11 0x0813bc49 in php_startup_internal_extensions () at main/internal_functions_cli.c:69 #12 0x080f9469 in php_module_startup (sf=0x8173340, additional_modules=0x0, num_additional_modules=0) at /backup/INST/1/php-4.3.2/main/main.c:1200 #13 0x0813af09 in main (argc=7, argv=0xbfffe984) at /backup/INST/1/php-4.3.2/sapi/cli/php_cli.c:520 #14 0x42017589 in __libc_start_main () from /lib/i686/libc.so.6 Previous Comments: [2003-06-12 07:30:48] [EMAIL PROTECTED] Thank you for this bug report. To properly diagnose the problem, we need a backtrace to see what is happening behind the scenes. To find out how to generate a backtrace, please read http://bugs.php.net/bugs-generating-backtrace.php Once you have generated a backtrace, please submit it to this bug report and change the status back to Open. Thank you for helping us make PHP better. Get the backtrace like this: # gdb sapi/cli/php (gdb) run -n -dsafe_mode=0 pear/install-pear.php pear/package-*.xml wait for crash.. (gdb) bt [2003-06-12 06:57:05] gk at online dot dp dot ua Description: After make install: ... Installing shared extensions: /usr/local/lib/php/extensions/no-debug-non-zts-20020429/ Installing PEAR environment: /usr/local/lib/php/ make[1]: *** [install-pear-installer] Segmentation fault make: *** [install-pear] Error 2 ./configure \ --with-apxs=/usr/local/apache/bin/apxs \ --with-sybase-ct=/opt/sybase-11.9.2 \ --enable-track-vars -- Edit this bug report at http://bugs.php.net/?id=24146edit=1
#24146 [Opn-Fbk]: Installer crash
ID: 24146 Updated by: [EMAIL PROTECTED] Reported By: gk at online dot dp dot ua -Status: Open +Status: Feedback Bug Type: Compile Failure Operating System: Red Hat Linux 7.3 PHP Version: 4.3.2 New Comment: Do you have SYBASE abd LANG environment variables set when running 'make install' ?? Previous Comments: [2003-06-12 07:42:28] gk at online dot dp dot ua Starting program: /backup/INST/1/php-4.3.2/sapi/cli/php -n -dsafe_mode=0 pear/install-pear.php pear/package-*.xml Program received signal SIGSEGV, Segmentation fault. 0x4212dfd0 in main_arena () from /lib/i686/libc.so.6 (gdb) bt #0 0x4212dfd0 in main_arena () from /lib/i686/libc.so.6 #1 0x4205535f in buffered_vfprintf () from /lib/i686/libc.so.6 #2 0x42050437 in vfprintf () from /lib/i686/libc.so.6 #3 0x4205a297 in fprintf () from /lib/i686/libc.so.6 #4 0x40098ffe in com_perr () from /opt/sybase-11.9.2/lib/libcomn.so #5 0x4008ae1d in com_intl_verify_ctxloc () from /opt/sybase-11.9.2/lib/libcomn.so #6 0x4012c4ad in cs_ctx_alloc () from /opt/sybase-11.9.2/lib/libcs.so #7 0x080d52ba in php_sybase_init_globals (sybase_globals=0x81758c0) at /backup/INST/1/php-4.3.2/ext/sybase_ct/php_sybase_ct.c:312 #8 0x080d5496 in zm_startup_sybase (type=1, module_number=3) at /backup/INST/1/php-4.3.2/ext/sybase_ct/php_sybase_ct.c:372 #9 0x08122ebf in zend_startup_module (module=0x816c9e0) at /backup/INST/1/php-4.3.2/Zend/zend_API.c:1005 #10 0x080f901f in php_startup_extensions (ptr=0x81733d0, count=10) at /backup/INST/1/php-4.3.2/main/main.c:1033 #11 0x0813bc49 in php_startup_internal_extensions () at main/internal_functions_cli.c:69 #12 0x080f9469 in php_module_startup (sf=0x8173340, additional_modules=0x0, num_additional_modules=0) at /backup/INST/1/php-4.3.2/main/main.c:1200 #13 0x0813af09 in main (argc=7, argv=0xbfffe984) at /backup/INST/1/php-4.3.2/sapi/cli/php_cli.c:520 #14 0x42017589 in __libc_start_main () from /lib/i686/libc.so.6 [2003-06-12 07:30:48] [EMAIL PROTECTED] Thank you for this bug report. To properly diagnose the problem, we need a backtrace to see what is happening behind the scenes. To find out how to generate a backtrace, please read http://bugs.php.net/bugs-generating-backtrace.php Once you have generated a backtrace, please submit it to this bug report and change the status back to Open. Thank you for helping us make PHP better. Get the backtrace like this: # gdb sapi/cli/php (gdb) run -n -dsafe_mode=0 pear/install-pear.php pear/package-*.xml wait for crash.. (gdb) bt [2003-06-12 06:57:05] gk at online dot dp dot ua Description: After make install: ... Installing shared extensions: /usr/local/lib/php/extensions/no-debug-non-zts-20020429/ Installing PEAR environment: /usr/local/lib/php/ make[1]: *** [install-pear-installer] Segmentation fault make: *** [install-pear] Error 2 ./configure \ --with-apxs=/usr/local/apache/bin/apxs \ --with-sybase-ct=/opt/sybase-11.9.2 \ --enable-track-vars -- Edit this bug report at http://bugs.php.net/?id=24146edit=1
#24148 [NEW]: increasing memory usage
From: ardo at np dot ee
Operating system: Windows 2000
PHP version: 4.3.2
PHP Bug Type: Java related
Bug description: increasing memory usage
Description:
When using Java extension PHP seems to increase memory usage constantly.
When I used a very simple example, Windows Task Manager showd that memory
usage of php.exe constantly increased. When using infinite loop I finally
got java.lang.OutOfMemoryError.
Reproduce code:
---
$formatter = new Java('java.text.SimpleDateFormat', , dd,
'at' h:mm:ss a );
$date = new Java('java.util.Date');
while(1) {
$formatter-format($date);
}
Expected result:
Should be just infinite loop.
Actual result:
--
java.lang.OutOfMemoryError
--
Edit bug report at http://bugs.php.net/?id=24148edit=1
--
Try a CVS snapshot: http://bugs.php.net/fix.php?id=24148r=trysnapshot
Fixed in CVS: http://bugs.php.net/fix.php?id=24148r=fixedcvs
Fixed in release: http://bugs.php.net/fix.php?id=24148r=alreadyfixed
Need backtrace: http://bugs.php.net/fix.php?id=24148r=needtrace
Try newer version: http://bugs.php.net/fix.php?id=24148r=oldversion
Not developer issue:http://bugs.php.net/fix.php?id=24148r=support
Expected behavior: http://bugs.php.net/fix.php?id=24148r=notwrong
Not enough info:http://bugs.php.net/fix.php?id=24148r=notenoughinfo
Submitted twice:http://bugs.php.net/fix.php?id=24148r=submittedtwice
register_globals: http://bugs.php.net/fix.php?id=24148r=globals
PHP 3 support discontinued: http://bugs.php.net/fix.php?id=24148r=php3
Daylight Savings: http://bugs.php.net/fix.php?id=24148r=dst
IIS Stability: http://bugs.php.net/fix.php?id=24148r=isapi
Install GNU Sed:http://bugs.php.net/fix.php?id=24148r=gnused
#24149 [NEW]: auth_gssapi_valid undefined
From: andreas at conectiva dot com dot br
Operating system: Linux
PHP version: 4.3.2
PHP Bug Type: Compile Failure
Bug description: auth_gssapi_valid undefined
Description:
The imap package from the University of Washington (which includes the
infamous c-client lib used by php) does not define auth_gssapi_valid in
any of its header files.
PHP-4.3.2 started testing this symbol in the ./configure stage. The
conftest.c program defines a dummy auth_gssapi_valid and attempts do
compile and link it. Linkage works, because the library does have this
symbol, and compiling also works because auth_gssapi_valid is declared in
the conftest.c program itself. This makes configure define
HAVE_IMAP_AUTH_GSS 1.
Later on, when compiling the imap module, compiling fails, because there
is no auth_gssapi_valid definition in any header file. I tried with
imap-2002b and imap-2002d (which seems to be the latest stable version
from their site).
This is the conftest.c program that configure attempts to build and run.
Notice that it declares (wrongly, in fact, it should be a long, but it's
enough for a autoconf test) auth_gssapi_valid, so this does compile and
link:
#line 36311 configure
#include confdefs.h
void mm_log(void){}
void mm_dlog(void){}
void mm_flags(void){}
void mm_fatal(void){}
void mm_critical(void){}
void mm_nocritical(void){}
void mm_notify(void){}
void mm_login(void){}
void mm_diskerror(void){}
void mm_status(void){}
void mm_lsub(void){}
void mm_list(void){}
void mm_exists(void){}
void mm_searched(void){}
void mm_expunged(void){}
char auth_gssapi_valid();
int main() {
auth_gssapi_valid();
return 0;
}
This is the error:
/bin/sh /storage/andreas/svn/php4/BUILD/php-4.3.2/build-cgi/libtool
--silent --preserve-dup-deps --mode=compile gcc -Iext/imap/
-I/storage/andreas/svn/php4/BUILD/php-4.3.2/ext/imap/ -DPHP_ATOM_INC
-I/storage/andreas/svn/php4/BUILD/php-4.3.2/build-cgi/include
-I/storage/andreas/svn/php4/BUILD/php-4.3.2/build-cgi/main
-I/storage/andreas/svn/php4/BUILD/php-4.3.2
-I/storage/andreas/svn/php4/BUILD/php-4.3.2/build-cgi/Zend
-I/usr/include/libxml2 -I/usr/include/freetype2 -I/usr/include/imap
-I/usr/lib/krb5/include -I/usr/include/mysql -I/usr/include/postgresql
-I/usr/include/pspell -I/storage/andreas/svn/php4/BUILD/php-4.3.2/main
-I/storage/andreas/svn/php4/BUILD/php-4.3.2/Zend
-I/storage/andreas/svn/php4/BUILD/php-4.3.2/TSRM
-I/storage/andreas/svn/php4/BUILD/php-4.3.2/build-cgi/TSRM -O2
-march=i386 -mcpu=pentiumpro -fPIC -prefer-pic -c
/storage/andreas/svn/php4/BUILD/php-4.3.2/ext/imap/php_imap.c -o
ext/imap/php_imap.lo
/storage/andreas/svn/php4/BUILD/php-4.3.2/ext/imap/php_imap.c: In function
`zm_startup_imap':
/storage/andreas/svn/php4/BUILD/php-4.3.2/ext/imap/php_imap.c:428: error:
`auth_gss' undeclared (first use in this function)
/storage/andreas/svn/php4/BUILD/php-4.3.2/ext/imap/php_imap.c:428: error:
(Each undeclared identifier is reported only once
/storage/andreas/svn/php4/BUILD/php-4.3.2/ext/imap/php_imap.c:428: error:
for each function it appears in.)
make: ** [ext/imap/php_imap.lo] Erro 1
The fix? I don't know. Maybe auth_gssapi_valid is not supposed to be
tested this way, maybe uw-imap is broken (wouldn't be surprising).
--
Edit bug report at http://bugs.php.net/?id=24149edit=1
--
Try a CVS snapshot: http://bugs.php.net/fix.php?id=24149r=trysnapshot
Fixed in CVS: http://bugs.php.net/fix.php?id=24149r=fixedcvs
Fixed in release: http://bugs.php.net/fix.php?id=24149r=alreadyfixed
Need backtrace: http://bugs.php.net/fix.php?id=24149r=needtrace
Try newer version: http://bugs.php.net/fix.php?id=24149r=oldversion
Not developer issue:http://bugs.php.net/fix.php?id=24149r=support
Expected behavior: http://bugs.php.net/fix.php?id=24149r=notwrong
Not enough info:http://bugs.php.net/fix.php?id=24149r=notenoughinfo
Submitted twice:http://bugs.php.net/fix.php?id=24149r=submittedtwice
register_globals: http://bugs.php.net/fix.php?id=24149r=globals
PHP 3 support discontinued: http://bugs.php.net/fix.php?id=24149r=php3
Daylight Savings: http://bugs.php.net/fix.php?id=24149r=dst
IIS Stability: http://bugs.php.net/fix.php?id=24149r=isapi
Install GNU Sed:http://bugs.php.net/fix.php?id=24149r=gnused
#24150 [NEW]: imap_fetch_overview crashes with a very big address in From:
From: nuno at co dot sapo dot pt Operating system: Linux 2.4.x PHP version: 4.3.2 PHP Bug Type: IMAP related Bug description: imap_fetch_overview crashes with a very big address in From: Description: I reproduced this bug with php 4.3.2 and 4.2.3, so this is not a new problem. If you imap_fetch_overview() a mailbox with a message with an huge address in the To: field, php crashes. The message on which I discovered this bug has the following From: field: From: ctqbscittqlxpghclcooontnvlqgwnkheymoitwvkkyqykkwsqdrryumoreloyhnjjqdxtmcrcyjmqonmvmiqndryislkqsdyxeruecmggxgiwrydhyqxfeqkxqteyqjkhbvynhlijkwedtcqv fctwxwktibgmhbbyjqwesbqujjpfekofjubmvvgjbiyfwvcuelfyortvjfgresluvkdywsqvgjowuyqoijcoripgtyrgxhmqluygircvswdtwqvisbwctunnxoxgpjjjlmfegnndyxdmlvtlvsyrtnvg ryhkrtugmolpghxqnhqhrogmtwgbgtbkhdxgmvnrtghtqrtjcxwkcpypvvbwoqkjnftnmpvtxcrjbsirngvrrhchyrvxcojojdvebccptotftjdebmlppfvcfcunjpsusxoejtljrbyxeiegpmrhdpxr kfwqljwxmuwjvxqgjtokmcpufqqrjullrrwsjyrqlsusgcnmddllslmvviluhiuyxspdcelwjqtnflmkdmyollkbcifvwuuumnoqjddloookgptdwhieioupxdmsuntlrttteltpikojyqyvioilspwp orrmdxxiwkujvhjpvxjlyqhdmksbrleqqumfvwfvrbsvttooedmwrishdvxxvuvuhbvqudohenpeixyhcecrjitjtrtwbiqvfxqovonqkbhktgfjmbmkhwcfsxdfpfppetgqueecdfkqopjkboyqtjpb eebptwhoekrqrsumtvcmigitdrpbbbsyjvpbfqqljykotgicicguivebbnwkecpbhwllkbkvsopggeghkcgxfidpmouvnmwhoknnkkxodpmogbxdthgvcjdwkyfydegjkvfkldfudfjktjpfbmlrmmwd qrucdmbieoqqrvrwebgkwentrghfmgwjkgghnwqimibnmjixdpfrrcvquvuxyyhunqevhsbluyjflrdvbmqqcyfejrfptwqneeyjhddkrrddrbdrqmgehvpjosfhyehicfydujkbncmxgjklrvjuvpdf dcxuyfhijukjodlvxbmejxrbderhmpjmqrgrfleqteovcibbwmttclwrysixflpjefbongjphojdyeftulmokkofthvfdspgjwfdnqbplbjqrhjppjkiwvvebeotjgwiuxwngxnlgikoqbmlgsxyymqw ieprbpbnbpjcojrwkbdobyokxoyuievwvhgqedvtsvtwmlvjtjwnsrchgtmlfbwqtvtdljdhekwfwrnjsvocnprnprooeyotlosxrnygjnjdytkkfrmfmenfyfnnrqqsytlliwsjxyhvjgsvtlkejikx rnoqwjqmydhtdytkonngsojhcmxkryklldbwsiiipiupovbftcpqhgbqbehfmirconfbslxkphykkrtcftwccddtlhtgrnqdimyqfmmyqiqucoejjgousurqmjpbtntbsgevkjbxmfoenwguitfdhyrw rosinuyjuhkdhpeysrtssrwkeffeyrukinkyjhsuxxpntjedkjwqrebflcgnkhtlrekbtdnowvkvinjriodpxhguqrrjmvytnopvqjbxjqgeorghvljibnpibujfceikiggfmcwrbrtyunbhhpmhsfso fwjlshgyxcmygfvuwfqreqmbvhcjqfbnwkguscxkjhfmlfvdgjgbiuqjxlpkqitmmobwscncybpyrtysjcjfxyyivxmgotbnkhfdfqjiyupvfqnceyhsedcwjqpkdigtqwklnlfmljgnydxsdpjctmjy mfdsjsxtsbihxoubgxmedwjmiwqujiirftkmwhfqlcnqwqttbnxggurdpoevxuiummjgfwxubuiosfteqwbpshkfcdfctuuimouqmxbvmewbdheoooewkitbsloyrmvhvxgndtbdfuprgfsjvxiejrcf rqrlrcurofmtgprmqgofuejbiohcvmrhrcsknkxykbdxtnnrxlvfeivlbbpvroqwcnkkfbxnxvmjytvmbkgihnwlqfvdepwekltjdutcgnpneppdqpgrpoxiglhpuyxkeemwsgffhncvnsjtsxwlmixu bvgjonsedmcflxkhbkelugjusjpcnmnygyjfplufdtuyjjvvtvxlipflpdxxqeeqrftmrnpkbqmxswoqplegodygeedvbkukofwcfpjjhevbrupydwuskqxtsoocxkgjtnywiqeevvqddqfpxcbyoupt qgtkshbeoyckcispjggignmmithhfvkntcfchfimdnyfgvkojtqcopjmuiluccilwokwddiobnmihdmhymrfnylgwkddjwjxkbjykqfodjwqxfxvvdtknpvlxxyvfpbrwfffcuwtrcllspeiuetyfvyh fynqoxujnguryvkbhcdwdfdjmvubiiuglstincnhydtcmosxfnnwxienoyqbjgfplufgvmugenuuwwlmthpckwlqlrdyjpifuterhhfsmddbcnrpfxostusqttlbrxxotkfomcsnynpoltgbdcslbmyl ecunxblsjxlfxfhgspedrnliijltidoepdyqdjsrsdtxxosceccxjlxuchckwjnyvmlbgsysqgyhcycbnuxxfotwsetbuxlyqcvtcyyyqfqbuuigkkwrvksotthueflvftgefebqovkwvugnkqxckjjn ptjvltfpdsgkfepqhojmqpbohblberwghjkvjkcyrftcbrvytyinfclfglephosvgrbubphiolggsmnljjpovoyqntnmeqoedppqbjyintqygyywkfvpfcslhtfigltgqwwsfdxtlfdhnhmythjxlbor brpmlrkmcrdcohyopmuxljdbqnjkhsuomwcufduqhmpwqdojmkdgnqtjgnsqbctmfcsrvpwmeibujvngkfusufupenjdijesxrimhvcejulgwrvfrrjbmjcsnselvvxwnbjdlcumioocvjfnyumwtben njpbyufydmfnxlkfoubwkwvrtymhqqhcvqgheggvqmygfsscmrjoqssgpjrqmlhonwbdwyespnrymismboffrbndmufldlsknbotnbpsqcgtxrvygxqflxobdsdhjcubjclgriedkmrtdktbmjuuxvxh thekrfbvujnlhnuqyltnggifprsusmuwvpdrftrlxjihnvcbwlvvsqibyxglxgponegnpqxrrsxhgrxyutetmndevledlchhcupnroenvypxfnptpewihprlunwybrsepbqyhlspysyoibdqoosqsdlx dimxboneqlvkrvoridhgpbcndvljffegobhhgsdwvskprdybtfuonmxqtrvmpsqswjwhcxnqqgpfbhyklwgdtrwyrdwpwhhwliqjfekepjmsjvefhckjdmlibrgdsctmcqqkyvgdyjkvjwledvevojml jnxorljxoumqxgwrlcmsordumgeuipxtvbbppyjphmoxnsskxcevvdqxbdtkmrohrtqdxflqjkdiuuyntnxxvjslxjesdrptsnvsobmndevrfxbbxselpnhhxpmgvwjihyfcumvembkmpoohthkqytmc ndircukbvfjcjibwyxcfjpfefmvbvptrvnuslmbqsgxmsjhjfxsluwpxnywqiedsxhhgrhrknxxwxohgjmyfkllotfhkxjphinpbqmjoqklbulxyuhkssqfpndmsocwjwuqukfdssoxxfskxemklloxf gdshjlvtgegjtyckqolnwmtxscotonjrynfynynsiioqnvklukpqtheekynfpxtvqrsgpvwiqdrmgvodoydsmycfqknrbupekvyqyudgdnnolqycjuhucyvbvjwncpxmcnhsyeeddwqkmpcpnrxyevbd sgigcuimxbxgfldbesksuysjqmgwnkymyvjsecxmcmoqtccrhgshpnossinhlkroqnhemyegcvbmcbxoqfwnvugrmhcslwmchngdsipohlwuxukiyovcknkptmocwujuupopwfooqruqyqkdxqbnpgje kcusklugjelxwiovqtlpycuukrrujfjrwsfxmmxtbxcouuxqbsyscodqhbnltyulixxjpnwnmumwtosdcurmgkfwvncrjbmqlrfpukhfukqovwfswxcwolhbkhcojumdkywhsghlkeisvigubfddfrbw mylkhktydjnhektpqdspuedksonnsrfdghyugpncmgivfcsdiwqikmppkovtcpgvcjnppkyyhojtehxtmeukbgtnqrnpnrnmtudvsgpuoqfymrrnptogphygrghrejnfvrljddmqqhhwkrgctutwcitw
#24151 [NEW]: Not overloading methods.
From: [EMAIL PROTECTED]
Operating system: windows xp pro
PHP version: 4.3.1
PHP Bug Type: Class/Object related
Bug description: Not overloading methods.
Description:
When I write two methods in a class, the interpreter emits an error.
The error says that the program cannot redeclare the method.
Reproduce code:
---
?php
class Foo {
var $_foo;
function Foo(){}
function Foo( $foo ){
$this-_foo = $foo;
}
}
?
Expected result:
I expect use the two methods. When it will be convenient.
--
Edit bug report at http://bugs.php.net/?id=24151edit=1
--
Try a CVS snapshot: http://bugs.php.net/fix.php?id=24151r=trysnapshot
Fixed in CVS: http://bugs.php.net/fix.php?id=24151r=fixedcvs
Fixed in release: http://bugs.php.net/fix.php?id=24151r=alreadyfixed
Need backtrace: http://bugs.php.net/fix.php?id=24151r=needtrace
Try newer version: http://bugs.php.net/fix.php?id=24151r=oldversion
Not developer issue:http://bugs.php.net/fix.php?id=24151r=support
Expected behavior: http://bugs.php.net/fix.php?id=24151r=notwrong
Not enough info:http://bugs.php.net/fix.php?id=24151r=notenoughinfo
Submitted twice:http://bugs.php.net/fix.php?id=24151r=submittedtwice
register_globals: http://bugs.php.net/fix.php?id=24151r=globals
PHP 3 support discontinued: http://bugs.php.net/fix.php?id=24151r=php3
Daylight Savings: http://bugs.php.net/fix.php?id=24151r=dst
IIS Stability: http://bugs.php.net/fix.php?id=24151r=isapi
Install GNU Sed:http://bugs.php.net/fix.php?id=24151r=gnused
#24149 [Opn]: auth_gssapi_valid undefined
ID: 24149
User updated by: andreas at conectiva dot com dot br
Reported By: andreas at conectiva dot com dot br
Status: Open
Bug Type: Compile Failure
Operating System: Linux
PHP Version: 4.3.2
New Comment:
I guess I made some confusion, but the build problem remains. I
confused auth_gss with auth_gssapi_valid. I'll check the build process
of uw-imap now and see why it didn't add the auth_gss AUTHENTICATOR to
my linkage.h header file like it did with the others.
Previous Comments:
[2003-06-12 09:20:09] andreas at conectiva dot com dot br
Description:
The imap package from the University of Washington (which includes the
infamous c-client lib used by php) does not define auth_gssapi_valid
in any of its header files.
PHP-4.3.2 started testing this symbol in the ./configure stage. The
conftest.c program defines a dummy auth_gssapi_valid and attempts do
compile and link it. Linkage works, because the library does have this
symbol, and compiling also works because auth_gssapi_valid is declared
in the conftest.c program itself. This makes configure define
HAVE_IMAP_AUTH_GSS 1.
Later on, when compiling the imap module, compiling fails, because
there is no auth_gssapi_valid definition in any header file. I tried
with imap-2002b and imap-2002d (which seems to be the latest stable
version from their site).
This is the conftest.c program that configure attempts to build and
run. Notice that it declares (wrongly, in fact, it should be a long,
but it's enough for a autoconf test) auth_gssapi_valid, so this does
compile and link:
#line 36311 configure
#include confdefs.h
void mm_log(void){}
void mm_dlog(void){}
void mm_flags(void){}
void mm_fatal(void){}
void mm_critical(void){}
void mm_nocritical(void){}
void mm_notify(void){}
void mm_login(void){}
void mm_diskerror(void){}
void mm_status(void){}
void mm_lsub(void){}
void mm_list(void){}
void mm_exists(void){}
void mm_searched(void){}
void mm_expunged(void){}
char auth_gssapi_valid();
int main() {
auth_gssapi_valid();
return 0;
}
This is the error:
/bin/sh /storage/andreas/svn/php4/BUILD/php-4.3.2/build-cgi/libtool
--silent --preserve-dup-deps --mode=compile gcc -Iext/imap/
-I/storage/andreas/svn/php4/BUILD/php-4.3.2/ext/imap/ -DPHP_ATOM_INC
-I/storage/andreas/svn/php4/BUILD/php-4.3.2/build-cgi/include
-I/storage/andreas/svn/php4/BUILD/php-4.3.2/build-cgi/main
-I/storage/andreas/svn/php4/BUILD/php-4.3.2
-I/storage/andreas/svn/php4/BUILD/php-4.3.2/build-cgi/Zend
-I/usr/include/libxml2 -I/usr/include/freetype2 -I/usr/include/imap
-I/usr/lib/krb5/include -I/usr/include/mysql -I/usr/include/postgresql
-I/usr/include/pspell -I/storage/andreas/svn/php4/BUILD/php-4.3.2/main
-I/storage/andreas/svn/php4/BUILD/php-4.3.2/Zend
-I/storage/andreas/svn/php4/BUILD/php-4.3.2/TSRM
-I/storage/andreas/svn/php4/BUILD/php-4.3.2/build-cgi/TSRM -O2
-march=i386 -mcpu=pentiumpro -fPIC -prefer-pic -c
/storage/andreas/svn/php4/BUILD/php-4.3.2/ext/imap/php_imap.c -o
ext/imap/php_imap.lo
/storage/andreas/svn/php4/BUILD/php-4.3.2/ext/imap/php_imap.c: In
function `zm_startup_imap':
/storage/andreas/svn/php4/BUILD/php-4.3.2/ext/imap/php_imap.c:428:
error: `auth_gss' undeclared (first use in this function)
/storage/andreas/svn/php4/BUILD/php-4.3.2/ext/imap/php_imap.c:428:
error: (Each undeclared identifier is reported only once
/storage/andreas/svn/php4/BUILD/php-4.3.2/ext/imap/php_imap.c:428:
error: for each function it appears in.)
make: ** [ext/imap/php_imap.lo] Erro 1
The fix? I don't know. Maybe auth_gssapi_valid is not supposed to be
tested this way, maybe uw-imap is broken (wouldn't be surprising).
--
Edit this bug report at http://bugs.php.net/?id=24149edit=1
#24151 [Opn-Bgs]: Not overloading methods.
ID: 24151
Updated by: [EMAIL PROTECTED]
Reported By: [EMAIL PROTECTED]
-Status: Open
+Status: Bogus
Bug Type: Class/Object related
Operating System: windows xp pro
PHP Version: 4.3.1
New Comment:
Thank you for taking the time to write to us, but this is not
a bug. Please double-check the documentation available at
http://www.php.net/manual/ and the instructions on how to report
a bug at http://bugs.php.net/how-to-report.php
No bug
Previous Comments:
[2003-06-12 09:39:51] [EMAIL PROTECTED]
Description:
When I write two methods in a class, the interpreter emits an error.
The error says that the program cannot redeclare the method.
Reproduce code:
---
?php
class Foo {
var $_foo;
function Foo(){}
function Foo( $foo ){
$this-_foo = $foo;
}
}
?
Expected result:
I expect use the two methods. When it will be convenient.
--
Edit this bug report at http://bugs.php.net/?id=24151edit=1
#24149 [Opn-Bgs]: auth_gssapi_valid undefined
ID: 24149
User updated by: andreas at conectiva dot com dot br
Reported By: andreas at conectiva dot com dot br
-Status: Open
+Status: Bogus
Bug Type: Compile Failure
Operating System: Linux
PHP Version: 4.3.2
New Comment:
It turned out to be a build problem with my c-client library, sorry.
I'm closing this.
Previous Comments:
[2003-06-12 09:40:31] andreas at conectiva dot com dot br
I guess I made some confusion, but the build problem remains. I
confused auth_gss with auth_gssapi_valid. I'll check the build process
of uw-imap now and see why it didn't add the auth_gss AUTHENTICATOR to
my linkage.h header file like it did with the others.
[2003-06-12 09:20:09] andreas at conectiva dot com dot br
Description:
The imap package from the University of Washington (which includes the
infamous c-client lib used by php) does not define auth_gssapi_valid
in any of its header files.
PHP-4.3.2 started testing this symbol in the ./configure stage. The
conftest.c program defines a dummy auth_gssapi_valid and attempts do
compile and link it. Linkage works, because the library does have this
symbol, and compiling also works because auth_gssapi_valid is declared
in the conftest.c program itself. This makes configure define
HAVE_IMAP_AUTH_GSS 1.
Later on, when compiling the imap module, compiling fails, because
there is no auth_gssapi_valid definition in any header file. I tried
with imap-2002b and imap-2002d (which seems to be the latest stable
version from their site).
This is the conftest.c program that configure attempts to build and
run. Notice that it declares (wrongly, in fact, it should be a long,
but it's enough for a autoconf test) auth_gssapi_valid, so this does
compile and link:
#line 36311 configure
#include confdefs.h
void mm_log(void){}
void mm_dlog(void){}
void mm_flags(void){}
void mm_fatal(void){}
void mm_critical(void){}
void mm_nocritical(void){}
void mm_notify(void){}
void mm_login(void){}
void mm_diskerror(void){}
void mm_status(void){}
void mm_lsub(void){}
void mm_list(void){}
void mm_exists(void){}
void mm_searched(void){}
void mm_expunged(void){}
char auth_gssapi_valid();
int main() {
auth_gssapi_valid();
return 0;
}
This is the error:
/bin/sh /storage/andreas/svn/php4/BUILD/php-4.3.2/build-cgi/libtool
--silent --preserve-dup-deps --mode=compile gcc -Iext/imap/
-I/storage/andreas/svn/php4/BUILD/php-4.3.2/ext/imap/ -DPHP_ATOM_INC
-I/storage/andreas/svn/php4/BUILD/php-4.3.2/build-cgi/include
-I/storage/andreas/svn/php4/BUILD/php-4.3.2/build-cgi/main
-I/storage/andreas/svn/php4/BUILD/php-4.3.2
-I/storage/andreas/svn/php4/BUILD/php-4.3.2/build-cgi/Zend
-I/usr/include/libxml2 -I/usr/include/freetype2 -I/usr/include/imap
-I/usr/lib/krb5/include -I/usr/include/mysql -I/usr/include/postgresql
-I/usr/include/pspell -I/storage/andreas/svn/php4/BUILD/php-4.3.2/main
-I/storage/andreas/svn/php4/BUILD/php-4.3.2/Zend
-I/storage/andreas/svn/php4/BUILD/php-4.3.2/TSRM
-I/storage/andreas/svn/php4/BUILD/php-4.3.2/build-cgi/TSRM -O2
-march=i386 -mcpu=pentiumpro -fPIC -prefer-pic -c
/storage/andreas/svn/php4/BUILD/php-4.3.2/ext/imap/php_imap.c -o
ext/imap/php_imap.lo
/storage/andreas/svn/php4/BUILD/php-4.3.2/ext/imap/php_imap.c: In
function `zm_startup_imap':
/storage/andreas/svn/php4/BUILD/php-4.3.2/ext/imap/php_imap.c:428:
error: `auth_gss' undeclared (first use in this function)
/storage/andreas/svn/php4/BUILD/php-4.3.2/ext/imap/php_imap.c:428:
error: (Each undeclared identifier is reported only once
/storage/andreas/svn/php4/BUILD/php-4.3.2/ext/imap/php_imap.c:428:
error: for each function it appears in.)
make: ** [ext/imap/php_imap.lo] Erro 1
The fix? I don't know. Maybe auth_gssapi_valid is not supposed to be
tested this way, maybe uw-imap is broken (wouldn't be surprising).
--
Edit this bug report at http://bugs.php.net/?id=24149edit=1
#23936 [Bgs]: fail to select and fetch
ID: 23936 User updated by: sarusij at yahoo dot com Reported By: sarusij at yahoo dot com Status: Bogus Bug Type: InterBase related -Operating System: redhat 8 +Operating System: redhat 7.3 -PHP Version: 4.3.1 +PHP Version: 4.3.2 New Comment: Ok, I have reinstalled RH73 Interbase 6.0.1 changed php to 4.3.2 worked ok. removed Interbase 6, installed interbase 7 using interbase.so (generated with the previous interbase 6.0.1) seem worked ok (didn't full test my application). now generated interbase.so with interbase 7 (./compile --with-interbase=shared,/opt/interbase make) put it in place, started httpd and interbase and wht we get ? the exact same error !Warning: InterBase: Dynamic SQL Error SQL error code = -804 Incorrect values within SQLDA structure in /home/web-site/htdocs/main.inc on line 31 the question changed now, what shoud I do in order to get PHP and interbase 7 work together ? I asume the problem is in generating the interbase.so. Thanks Previous Comments: [2003-06-01 10:49:53] [EMAIL PROTECTED] Thank you for taking the time to report a problem with PHP. Unfortunately you are not using a current version of PHP -- the problem might already be fixed. Please download a new PHP version from http://www.php.net/downloads.php If you are 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. Again, thank you for your continued support of PHP. PHP 4.3.2 was released already and has couple of ext/interbase fixes too. [2003-06-01 09:26:22] sarusij at yahoo dot com I was using RedHat 7.3 with Interbase 6.0.1 every thing worked fine (Apache 1.3.x php 4.1.x). In order to get better performance updated to redhat 8 (apache 2.0.40 php 4.2.2) and interbase 7 (trial) generated interbase.so using ./compile --with-interbase=shared,/opt/interbase all in place, restart httpd, when accesing page with a database select it returns:- Warning: InterBase: Dynamic SQL Error SQL error code = -804 Incorrect values within SQLDA structure in /home/web-site/htdocs/main.inc on line 31 line 31 = $arr=ibase_fetch_row($sth); By mistake I have, in one of the time forgot to change to interbase.so that was compiled with interbase 7 and left interbase.so related to interbase 6, the warning above did not appear and seemed like everything operates ok. Using the tests within ext/interbase I found that test 5 (transactions) failed, it alsio failed when I have interbase 6.0.1. It did not fail using the original installation (RH7.3, IB6.0.1, php4.1.x apache 1.3.x) I have been doing it all also with php 4.3.1 with same results. What should I do in order to get the basic RH8 (apache 2.0.40 and php 4.2.2) instalation to operate correctly with interbase 7 (module interbase.so) Thanks for help Jacob -- Edit this bug report at http://bugs.php.net/?id=23936edit=1
#18648 [Com]: Single entry form POST gives incorrect variable content
ID: 18648 Comment by: CJ dot Hammond at t-online dot de Reported By: ms at ecs dot soton dot ac dot uk Status: Bogus Bug Type: Apache2 related Operating System: All PHP Version: 5CVS-2003-01-29 (dev) / 4CVS-20020121 (stable) New Comment: Please look in the /etc/httpd/conf.d/ folder. There might be a php.conf file (or likewise, as all files get included). Any Directive within will have the same effect as directives in /etc/httpd/conf/httpd.conf !!! Later, /jochen Previous Comments: [2003-06-02 20:45:56] sbeam at syxyz dot net NOT fixed on default RedHat 9.0 setup (Apache 2.0.40 and PHP 4.2.2): same form.html and test.php as original poster on 30 Jul 2002. Same exact result. Also there is NO SetOutputFilter or other stuff in httpd.conf, and adding AddInputFilter PHP .php has no effect. RedHat does not currently provide any higher version of PHP binaries. Only option is to recompile? [2003-05-04 08:36:37] anrdaemon at mtu-net dot ru Thanx to [EMAIL PROTECTED] /me stupid... AddInputFilter PHP .php solves all problems. [2003-03-05 07:32:56] jorton at redhat dot com The default configuration in Red Hat Linux has only the Files *.php* section. This bug appears to occur if the AddType x-httpd-php .php is added *as well* as the files *.php section. http://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=76559 [2003-02-20 09:43:34] apiset at hotmail dot com The default httpd configuration on RH8.0 use Files *.php SetOutputFilter PHP SetInputFilter PHP LimitRequestBody 524288 /Files so is this RedHat fault? I replace above lines with AddType application/x-httpd-php .php and it works!!! should tell redhat about this [2003-02-07 21:50:42] [EMAIL PROTECTED] First I made a typo in my previous comment. I mean application/x-httpd-php everywhere I wrote x-http-php. Anyway let me mark this as bogus... (The problem turned out to be a user fault.) 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/18648 -- Edit this bug report at http://bugs.php.net/?id=18648edit=1
#24146 [Fbk-Opn]: Installer crash
ID: 24146 User updated by: gk at online dot dp dot ua Reported By: gk at online dot dp dot ua -Status: Feedback +Status: Open Bug Type: Compile Failure Operating System: Red Hat Linux 7.3 PHP Version: 4.3.2 New Comment: Yes - LANG=en_US.iso885915, SYBASE=/opt/sybase-11.9.2 Previous Comments: [2003-06-12 08:33:48] [EMAIL PROTECTED] Do you have SYBASE abd LANG environment variables set when running 'make install' ?? [2003-06-12 07:42:28] gk at online dot dp dot ua Starting program: /backup/INST/1/php-4.3.2/sapi/cli/php -n -dsafe_mode=0 pear/install-pear.php pear/package-*.xml Program received signal SIGSEGV, Segmentation fault. 0x4212dfd0 in main_arena () from /lib/i686/libc.so.6 (gdb) bt #0 0x4212dfd0 in main_arena () from /lib/i686/libc.so.6 #1 0x4205535f in buffered_vfprintf () from /lib/i686/libc.so.6 #2 0x42050437 in vfprintf () from /lib/i686/libc.so.6 #3 0x4205a297 in fprintf () from /lib/i686/libc.so.6 #4 0x40098ffe in com_perr () from /opt/sybase-11.9.2/lib/libcomn.so #5 0x4008ae1d in com_intl_verify_ctxloc () from /opt/sybase-11.9.2/lib/libcomn.so #6 0x4012c4ad in cs_ctx_alloc () from /opt/sybase-11.9.2/lib/libcs.so #7 0x080d52ba in php_sybase_init_globals (sybase_globals=0x81758c0) at /backup/INST/1/php-4.3.2/ext/sybase_ct/php_sybase_ct.c:312 #8 0x080d5496 in zm_startup_sybase (type=1, module_number=3) at /backup/INST/1/php-4.3.2/ext/sybase_ct/php_sybase_ct.c:372 #9 0x08122ebf in zend_startup_module (module=0x816c9e0) at /backup/INST/1/php-4.3.2/Zend/zend_API.c:1005 #10 0x080f901f in php_startup_extensions (ptr=0x81733d0, count=10) at /backup/INST/1/php-4.3.2/main/main.c:1033 #11 0x0813bc49 in php_startup_internal_extensions () at main/internal_functions_cli.c:69 #12 0x080f9469 in php_module_startup (sf=0x8173340, additional_modules=0x0, num_additional_modules=0) at /backup/INST/1/php-4.3.2/main/main.c:1200 #13 0x0813af09 in main (argc=7, argv=0xbfffe984) at /backup/INST/1/php-4.3.2/sapi/cli/php_cli.c:520 #14 0x42017589 in __libc_start_main () from /lib/i686/libc.so.6 [2003-06-12 07:30:48] [EMAIL PROTECTED] Thank you for this bug report. To properly diagnose the problem, we need a backtrace to see what is happening behind the scenes. To find out how to generate a backtrace, please read http://bugs.php.net/bugs-generating-backtrace.php Once you have generated a backtrace, please submit it to this bug report and change the status back to Open. Thank you for helping us make PHP better. Get the backtrace like this: # gdb sapi/cli/php (gdb) run -n -dsafe_mode=0 pear/install-pear.php pear/package-*.xml wait for crash.. (gdb) bt [2003-06-12 06:57:05] gk at online dot dp dot ua Description: After make install: ... Installing shared extensions: /usr/local/lib/php/extensions/no-debug-non-zts-20020429/ Installing PEAR environment: /usr/local/lib/php/ make[1]: *** [install-pear-installer] Segmentation fault make: *** [install-pear] Error 2 ./configure \ --with-apxs=/usr/local/apache/bin/apxs \ --with-sybase-ct=/opt/sybase-11.9.2 \ --enable-track-vars -- Edit this bug report at http://bugs.php.net/?id=24146edit=1
#24152 [NEW]: Getting PHP to work with Apache
From: wax at y12 dot doe dot gov Operating system: OSF1 V4.0 878 alpha PHP version: 4.3.2 PHP Bug Type: Apache related Bug description: Getting PHP to work with Apache Description: OK I am trying to add PHP to the apache conf file. We are using Stronghold/2.4.1 Apache/1.3.3 C2NetEU/2409 Doorkeeper/2.0. I am unable to upgrade this version do to we need the DoorKeeper for Session timeouts. How do I add to the httpd.conf file to load the mod_php system? I have tried this: LoadModule php4_modulelibexec/libphp4.so Not to mention I did a search and I am unable to find any libphp4.so file I have tried this: IfModule mod_php4.c AddType application/x-httpd-php .php AddType application/x-httpd-php-source .phps /IfModule I even tried doing that IfModule and specify the full path on where the mod_php4.c file is located and still no good... Can someone help me out?? -- Edit bug report at http://bugs.php.net/?id=24152edit=1 -- Try a CVS snapshot: http://bugs.php.net/fix.php?id=24152r=trysnapshot Fixed in CVS: http://bugs.php.net/fix.php?id=24152r=fixedcvs Fixed in release: http://bugs.php.net/fix.php?id=24152r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=24152r=needtrace Try newer version: http://bugs.php.net/fix.php?id=24152r=oldversion Not developer issue:http://bugs.php.net/fix.php?id=24152r=support Expected behavior: http://bugs.php.net/fix.php?id=24152r=notwrong Not enough info:http://bugs.php.net/fix.php?id=24152r=notenoughinfo Submitted twice:http://bugs.php.net/fix.php?id=24152r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=24152r=globals PHP 3 support discontinued: http://bugs.php.net/fix.php?id=24152r=php3 Daylight Savings: http://bugs.php.net/fix.php?id=24152r=dst IIS Stability: http://bugs.php.net/fix.php?id=24152r=isapi Install GNU Sed:http://bugs.php.net/fix.php?id=24152r=gnused
#24152 [Opn-Bgs]: Getting PHP to work with Apache
ID: 24152 Updated by: [EMAIL PROTECTED] Reported By: wax at y12 dot doe dot gov -Status: Open +Status: Bogus Bug Type: Apache related Operating System: OSF1 V4.0 878 alpha PHP Version: 4.3.2 New Comment: Sorry, but your problem does not imply a bug in PHP itself. For a list of more appropriate places to ask for help using PHP, please visit http://www.php.net/support.php as this bug system is not the appropriate forum for asking support questions. Thank you for your interest in PHP. You should also definitely upgrade Apache to atleast 1.3.27 Previous Comments: [2003-06-12 10:29:19] wax at y12 dot doe dot gov Description: OK I am trying to add PHP to the apache conf file. We are using Stronghold/2.4.1 Apache/1.3.3 C2NetEU/2409 Doorkeeper/2.0. I am unable to upgrade this version do to we need the DoorKeeper for Session timeouts. How do I add to the httpd.conf file to load the mod_php system? I have tried this: LoadModule php4_modulelibexec/libphp4.so Not to mention I did a search and I am unable to find any libphp4.so file I have tried this: IfModule mod_php4.c AddType application/x-httpd-php .php AddType application/x-httpd-php-source .phps /IfModule I even tried doing that IfModule and specify the full path on where the mod_php4.c file is located and still no good... Can someone help me out?? -- Edit this bug report at http://bugs.php.net/?id=24152edit=1
#24083 [Bgs]: Content-Encoding: gzip output includes the wrong Content-Length header
ID: 24083 User updated by: yngve at opera dot com Reported By: yngve at opera dot com Status: Bogus Bug Type:Zlib Related PHP Version: 4.3.1 New Comment: As you are, apparently, not willing to enforce correct Content-Length headers I see no option but to make sure that Opera does not trust Content-Length headers served by PHP powered servers. This will be effective as of v7.20. Please inform me when you start enforcing RFC 2616 sec. 4.4 and only sends/passes through valid Content-Length headers, so that I can remove/limit this special handling of PHP servers. Previous Comments: [2003-06-12 08:20:23] [EMAIL PROTECTED] There's not much we can do if a script sets a wrong content-length header. Not PHP bug. [2003-06-09 22:09:11] [EMAIL PROTECTED] We still need a short script to reproduce this, anything I've tried works just fine.. [2003-06-09 09:01:37] yngve at opera dot com I do not know if this is present in 4.3.2 as I am not using PHP myself, but I do know that the problem is present on servers using PHP 4.2.2 and 4.3.1, and your changelog does not indicate many changes related to compression, and none that I can see are related to this problem. [2003-06-09 08:30:01] [EMAIL PROTECTED] Does this happen with PHP 4.3.2 ? [2003-06-08 15:24:24] yngve at opera dot com I am a developer with Opera Software, the developer of the Opera browser. We have received several reports about problems with forums using VBulletin, but based on what I've learned I suspect that the problem is a general PHP problem, not Vbulletin specific. The reason for the problem turns out to be the same, or of a similar nature, as my earlier bug report #12884. A while ago I was in contact with one of the boards affected by the problem Rage3D.com. They reported back that they were able to solve the problem by turning off global compression From the Rage3D people (with permission): The problem was caused because we were running the php output_handler = ob_gzhandler for global site compression. vB didn't know to use the right content length header. We've resolved the issue by turning off global compression and enabling gzip encoding through vBulletin. We will be seeing if an updated gzip library for our server will resolve the issue so we can run global php compression in the future. The following is a hexdump of the request and response headers from one of my tests (before Rage3D fixed the problem). --- : 47 45 54 20 2f 62 6f 61 72 64 2f 20 48 54 54 50 GET /board/ HTTP 0010 : 2f 31 2e 31 0d 0a 55 73 65 72 2d 41 67 65 6e 74 /1.1..User-Agent 0020 : 3a 20 4d 6f 7a 69 6c 6c 61 2f 34 2e 30 20 28 63 : Mozilla/4.0 (c 0030 : 6f 6d 70 61 74 69 62 6c 65 3b 20 4d 53 49 45 20 ompatible; MSIE 0040 : 36 2e 30 3b 20 57 69 6e 64 6f 77 73 20 4e 54 20 6.0; Windows NT 0050 : 35 2e 30 29 20 4f 70 65 72 61 20 37 2e 31 31 20 5.0) Opera 7.11 0060 : 20 5b 65 6e 5d 0d 0a 48 6f 73 74 3a 20 77 77 77 [en]..Host: www 0070 : 2e 72 61 67 65 33 64 2e 63 6f 6d 0d 0a 41 63 63 .rage3d.com..Acc 0080 : 65 70 74 3a 20 74 65 78 74 2f 68 74 6d 6c 2c 20 ept: text/html, 0090 : 69 6d 61 67 65 2f 70 6e 67 2c 20 69 6d 61 67 65 image/png, image 00a0 : 2f 6a 70 65 67 2c 20 69 6d 61 67 65 2f 67 69 66 /jpeg, image/gif 00b0 : 2c 20 69 6d 61 67 65 2f 78 2d 78 62 69 74 6d 61 , image/x-xbitma 00c0 : 70 2c 20 2a 2f 2a 3b 71 3d 30 2e 31 0d 0a 41 63 p, */*;q=0.1..Ac 00d0 : 63 65 70 74 2d 4c 61 6e 67 75 61 67 65 3a 20 65 cept-Language: e 00e0 : 6e 3b 71 3d 31 2e 30 2c 65 6e 3b 71 3d 30 2e 39 n;q=1.0,en;q=0.9 00f0 : 0d 0a 41 63 63 65 70 74 2d 43 68 61 72 73 65 74 ..Accept-Charset 0100 : 3a 20 77 69 6e 64 6f 77 73 2d 31 32 35 32 2c 20 : windows-1252, 0110 : 75 74 66 2d 38 2c 20 75 74 66 2d 31 36 2c 20 69 utf-8, utf-16, i 0120 : 73 6f 2d 38 38 35 39 2d 31 3b 71 3d 30 2e 36 2c so-8859-1;q=0.6, 0130 : 20 2a 3b 71 3d 30 2e 31 0d 0a 41 63 63 65 70 74 *;q=0.1..Accept 0140 : 2d 45 6e 63 6f 64 69 6e 67 3a 20 64 65 66 6c 61 -Encoding: defla 0150 : 74 65 2c 20 67 7a 69 70 2c 20 78 2d 67 7a 69 70 te, gzip, x-gzip 0160 : 2c 20 69 64 65 6e 74 69 74 79 2c 20 2a 3b 71 3d , identity, *;q= 0170 : 30 0d 0a 43 6f 6e 6e 65 63 74 69 6f 6e 3a 20 4b 0..Connection: K 0180 : 65 65 70 2d 41 6c 69 76 65 0d 0a 0d 0aeep-Alive : 48 54 54 50 2f 31 2e 31 20 32 30 30 20 4f 4b 0d HTTP/1.1 200 OK. 0010 : 0a 53 65 72 76 65 72 3a 20 4d 69 63 72 6f 73 6f .Server: Microso 0020 : 66 74 2d 49 49 53 2f 35 2e 30 0d 0a 44 61 74 65 ft-IIS/5.0..Date 0030 : 3a 20 54 68 75 2c 20 30 38 20 4d 61 79 20
#24153 [NEW]: Use default parameters in the middle while overriding def parameters at the end
From: php at electricsurfer dot com
Operating system: WIN XP
PHP version: 4.3.2
PHP Bug Type: Feature/Change Request
Bug description: Use default parameters in the middle while overriding def parameters
at the end
Description:
Given:
?
function myfunc($arg1,$arg2=2,$arg3='',$arg4=false,$arg5=1)
{...}
?
It would be nice to be able to do this:
?
myfunc('arg1',5,,true);
?
Which would keep the default values for arguments 3 5 but specify a
value for argument 4.
This way, if I ever change the default value of $arg3 from '' to null, I
have less code to modify.
--
Edit bug report at http://bugs.php.net/?id=24153edit=1
--
Try a CVS snapshot: http://bugs.php.net/fix.php?id=24153r=trysnapshot
Fixed in CVS: http://bugs.php.net/fix.php?id=24153r=fixedcvs
Fixed in release: http://bugs.php.net/fix.php?id=24153r=alreadyfixed
Need backtrace: http://bugs.php.net/fix.php?id=24153r=needtrace
Try newer version: http://bugs.php.net/fix.php?id=24153r=oldversion
Not developer issue:http://bugs.php.net/fix.php?id=24153r=support
Expected behavior: http://bugs.php.net/fix.php?id=24153r=notwrong
Not enough info:http://bugs.php.net/fix.php?id=24153r=notenoughinfo
Submitted twice:http://bugs.php.net/fix.php?id=24153r=submittedtwice
register_globals: http://bugs.php.net/fix.php?id=24153r=globals
PHP 3 support discontinued: http://bugs.php.net/fix.php?id=24153r=php3
Daylight Savings: http://bugs.php.net/fix.php?id=24153r=dst
IIS Stability: http://bugs.php.net/fix.php?id=24153r=isapi
Install GNU Sed:http://bugs.php.net/fix.php?id=24153r=gnused
#24153 [Opn-WFx]: Use default parameters in the middle while overriding def parameters at the end
ID: 24153
Updated by: [EMAIL PROTECTED]
Reported By: php at electricsurfer dot com
-Status: Open
+Status: Wont fix
Bug Type: Feature/Change Request
Operating System: WIN XP
PHP Version: 4.3.2
New Comment:
This was brought up before and it was decided not to do this.
Previous Comments:
[2003-06-12 11:04:39] php at electricsurfer dot com
Description:
Given:
?
function myfunc($arg1,$arg2=2,$arg3='',$arg4=false,$arg5=1)
{...}
?
It would be nice to be able to do this:
?
myfunc('arg1',5,,true);
?
Which would keep the default values for arguments 3 5 but specify a
value for argument 4.
This way, if I ever change the default value of $arg3 from '' to null,
I have less code to modify.
--
Edit this bug report at http://bugs.php.net/?id=24153edit=1
#24083 [Bgs]: Content-Encoding: gzip output includes the wrong Content-Length header
ID: 24083 Updated by: [EMAIL PROTECTED] Reported By: yngve at opera dot com Status: Bogus Bug Type:Zlib Related PHP Version: 4.3.1 New Comment: Erm? 1st: it has nothing to do with the PHP server, as PHP is not a server, but rather a module to a webserver. 2nd: we do not set any Content-Length header ourselves. 3rd: PHP is a flexiable scripting language allowed users to set (override) Content-Length headers themselves whereever they think it's necessary even although that might be wrong. AFAIK RFC 2606 is an HTTP RFC, PHP does NOT implement HTTP, but rather makes use of it it. So, what is your problem with PHP? Previous Comments: [2003-06-12 10:43:06] yngve at opera dot com As you are, apparently, not willing to enforce correct Content-Length headers I see no option but to make sure that Opera does not trust Content-Length headers served by PHP powered servers. This will be effective as of v7.20. Please inform me when you start enforcing RFC 2616 sec. 4.4 and only sends/passes through valid Content-Length headers, so that I can remove/limit this special handling of PHP servers. [2003-06-12 08:20:23] [EMAIL PROTECTED] There's not much we can do if a script sets a wrong content-length header. Not PHP bug. [2003-06-09 22:09:11] [EMAIL PROTECTED] We still need a short script to reproduce this, anything I've tried works just fine.. [2003-06-09 09:01:37] yngve at opera dot com I do not know if this is present in 4.3.2 as I am not using PHP myself, but I do know that the problem is present on servers using PHP 4.2.2 and 4.3.1, and your changelog does not indicate many changes related to compression, and none that I can see are related to this problem. [2003-06-09 08:30:01] [EMAIL PROTECTED] Does this happen with PHP 4.3.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/24083 -- Edit this bug report at http://bugs.php.net/?id=24083edit=1
#24155 [NEW]: imagerotate fail to copy entire source image
From: tom at gksystems dot com
Operating system: all
PHP version: 4.3.2
PHP Bug Type: GD related
Bug description: imagerotate fail to copy entire source image
Description:
When rotating an image which is taller-than-wide through an angle 225
and = 315 degrees, only a square portion of the image is copied. The
remainder is black.
ext/libgd/gd.c has a bug in gdImageRotate270:
for (uY = 0; uYsrc-sx; uY++) {
for (uX = 0; uXsrc-sx; uX++) {
uY and uX both have a range of src-sx, so only a square region is copied.
The first line should be:
for (uY = 0; uYsrc-sy; uY++) {
Reproduce code:
---
script language=PHP
// June 12, 2003 Tom Robinson
// Display a 30x50 yellow rectangle, rotated 270 degrees CCW.
$im = ImageCreateTrueColor(30,50);
imagefill($im,0,0,16777215-255);
$im = imagerotate($im,270,255);
header(Content-type: image/png);
imagepng($im);
/script
Expected result:
See a yellow rectangle.
Actual result:
--
See a rectangle with a yellow square and the rest is black.
--
Edit bug report at http://bugs.php.net/?id=24155edit=1
--
Try a CVS snapshot: http://bugs.php.net/fix.php?id=24155r=trysnapshot
Fixed in CVS: http://bugs.php.net/fix.php?id=24155r=fixedcvs
Fixed in release: http://bugs.php.net/fix.php?id=24155r=alreadyfixed
Need backtrace: http://bugs.php.net/fix.php?id=24155r=needtrace
Try newer version: http://bugs.php.net/fix.php?id=24155r=oldversion
Not developer issue:http://bugs.php.net/fix.php?id=24155r=support
Expected behavior: http://bugs.php.net/fix.php?id=24155r=notwrong
Not enough info:http://bugs.php.net/fix.php?id=24155r=notenoughinfo
Submitted twice:http://bugs.php.net/fix.php?id=24155r=submittedtwice
register_globals: http://bugs.php.net/fix.php?id=24155r=globals
PHP 3 support discontinued: http://bugs.php.net/fix.php?id=24155r=php3
Daylight Savings: http://bugs.php.net/fix.php?id=24155r=dst
IIS Stability: http://bugs.php.net/fix.php?id=24155r=isapi
Install GNU Sed:http://bugs.php.net/fix.php?id=24155r=gnused
#24156 [NEW]: T undefined during compile of php_imap.c
From: barryn at baptisthealth dot net Operating system: Solaris 8 PHP version: 4.3.2 PHP Bug Type: IMAP related Bug description: T undefined during compile of php_imap.c Description: Compiling with these switches: ./configure --prefix=/opt/php --with-nsapi=/opt/netscape --with-oci8 --enable-dbase --enable-filepro --enable-ftp --enable-sysvsem --enable-sysvshm --with-zlib --with-jpeg-dir=/opt/sfw --with-png-dir=/opt/sfw --with-gdbm --with-gd --with-imap --with-mysql --enable-sigchild --enable-libgcc --with-cpdflib --with-flatfile on Solaris 8 resulted in T being undefined when compiling php_imap.c Imap version info: * Program: Interactive Mail Access Protocol 4rev1 (IMAP4R1) routines * * Author: Mark Crispin * Networks and Distributed Computing * Computing Communications * University of Washington * Administration Building, AG-44 * Seattle, WA 98195 * Internet: [EMAIL PROTECTED] * * Date:14 October 1988 * Last Edited: 14 November 2001 Reproduce code: --- I fixed the problem by adding: #ifndef T #define T 1 #endif after the line #define PHP_IMAP_ADDRESS_SIZE_BUF 10 in php_imap.c -- Edit bug report at http://bugs.php.net/?id=24156edit=1 -- Try a CVS snapshot: http://bugs.php.net/fix.php?id=24156r=trysnapshot Fixed in CVS: http://bugs.php.net/fix.php?id=24156r=fixedcvs Fixed in release: http://bugs.php.net/fix.php?id=24156r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=24156r=needtrace Try newer version: http://bugs.php.net/fix.php?id=24156r=oldversion Not developer issue:http://bugs.php.net/fix.php?id=24156r=support Expected behavior: http://bugs.php.net/fix.php?id=24156r=notwrong Not enough info:http://bugs.php.net/fix.php?id=24156r=notenoughinfo Submitted twice:http://bugs.php.net/fix.php?id=24156r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=24156r=globals PHP 3 support discontinued: http://bugs.php.net/fix.php?id=24156r=php3 Daylight Savings: http://bugs.php.net/fix.php?id=24156r=dst IIS Stability: http://bugs.php.net/fix.php?id=24156r=isapi Install GNU Sed:http://bugs.php.net/fix.php?id=24156r=gnused
#16263 [Com]: session.start() create new empty session file and not resume existing session
ID: 16263 Comment by: steveh at brendata dot co dot uk Reported By: kur at natur dot cuni dot cz Status: No Feedback Bug Type: Session related Operating System: ANY PHP Version: 4.3.0-dev New Comment: I'm seeing the same issue on 4.3.2 on NT4 and IIS. I get a new session each time I log in, I've dumped the cookie array $_COOKIE and I see an extra cookie created each time with the name of the file in the sessiondata directory. But I thought that there should be a cookie called PHPSESSID or whatever your session name is called? I don't see this cookie, is this the underlying issue? Judging by the number of entries here, I think some effort needs to go into sorting this issue, it's been open and closed more times than. Previous Comments: [2003-03-25 08:26:07] RockyTheSuperDog at hotmail dot com Same prob with Apache 2 on win2000 with PHP 4.2.3 to 4.3.1 Tried messing with the Apache service login user permissions on php session data folder but no luck. Changed to IIS 5 and gave read/write permissions on the session data folder to IUSR_HOSTNAME and sessions started working again. Hope this info leads somebody to the right answer. [2003-03-24 16:09:12] roland at lichti dot de Sorry for this rant, but I'm really pissed off: the session handling problem is reported several times and every time closed as bogus or no feedback. I really think that the programming team has no clue where to look at and should reimplement the whole code related to session handling. It's going on now for at least 1 year and there is no solution in sight :-((( [2003-03-10 02:39:09] kasei999 at hotmail dot com Same here, after 3 non-sleeping days and nights I found this forum. I am using win XP with php 4.3.1 + apache 1.3.27 now switching to IIS 5, the problem still exists. Would anyone please try to help? [2003-03-04 11:58:25] zorman at pina dot info same problems over here ... i'm experiencing this problem only when I redirect the page using header after the authentication is done ... it works fine on my linux computer (php 4.3.0) but fails on win2k with the same distribution ... very annoying ... [2003-02-08 14:31:45] jmaldonado at webehosting dot biz I just upgraded my servers to 4.3.0 from 4.1.2 and am now experiencing this problemSessions are behaving unpredictably in that I can no longer count on the variables I set in the session from one page load to the next... The remainder of the comments for this report are too long. To view the rest of the comments, please view the bug report online at http://bugs.php.net/16263 -- Edit this bug report at http://bugs.php.net/?id=16263edit=1
#24156 [Opn-Fbk]: T undefined during compile of php_imap.c
ID: 24156 Updated by: [EMAIL PROTECTED] Reported By: barryn at baptisthealth dot net -Status: Open +Status: Feedback Bug Type: IMAP related Operating System: Solaris 8 PHP Version: 4.3.2 New Comment: Please add the full error message here. Previous Comments: [2003-06-12 13:03:17] barryn at baptisthealth dot net Description: Compiling with these switches: ./configure --prefix=/opt/php --with-nsapi=/opt/netscape --with-oci8 --enable-dbase --enable-filepro --enable-ftp --enable-sysvsem --enable-sysvshm --with-zlib --with-jpeg-dir=/opt/sfw --with-png-dir=/opt/sfw --with-gdbm --with-gd --with-imap --with-mysql --enable-sigchild --enable-libgcc --with-cpdflib --with-flatfile on Solaris 8 resulted in T being undefined when compiling php_imap.c Imap version info: * Program: Interactive Mail Access Protocol 4rev1 (IMAP4R1) routines * * Author: Mark Crispin * Networks and Distributed Computing * Computing Communications * University of Washington * Administration Building, AG-44 * Seattle, WA 98195 * Internet: [EMAIL PROTECTED] * * Date:14 October 1988 * Last Edited: 14 November 2001 Reproduce code: --- I fixed the problem by adding: #ifndef T #define T 1 #endif after the line #define PHP_IMAP_ADDRESS_SIZE_BUF 10 in php_imap.c -- Edit this bug report at http://bugs.php.net/?id=24156edit=1
#24156 [Fbk-Opn]: T undefined during compile of php_imap.c
ID: 24156 User updated by: barryn at baptisthealth dot net Reported By: barryn at baptisthealth dot net -Status: Feedback +Status: Open Bug Type: IMAP related Operating System: Solaris 8 PHP Version: 4.3.2 New Comment: My source no longer generates this error. Please read the full bug description. OBVIOUSLY the error was something to effect of: `T' undeclared (first use in this function) (Each undeclared identifier is reported only once for each function it appears in.) The line number in the source code was 1117 Previous Comments: [2003-06-12 13:15:13] [EMAIL PROTECTED] Please add the full error message here. [2003-06-12 13:03:17] barryn at baptisthealth dot net Description: Compiling with these switches: ./configure --prefix=/opt/php --with-nsapi=/opt/netscape --with-oci8 --enable-dbase --enable-filepro --enable-ftp --enable-sysvsem --enable-sysvshm --with-zlib --with-jpeg-dir=/opt/sfw --with-png-dir=/opt/sfw --with-gdbm --with-gd --with-imap --with-mysql --enable-sigchild --enable-libgcc --with-cpdflib --with-flatfile on Solaris 8 resulted in T being undefined when compiling php_imap.c Imap version info: * Program: Interactive Mail Access Protocol 4rev1 (IMAP4R1) routines * * Author: Mark Crispin * Networks and Distributed Computing * Computing Communications * University of Washington * Administration Building, AG-44 * Seattle, WA 98195 * Internet: [EMAIL PROTECTED] * * Date:14 October 1988 * Last Edited: 14 November 2001 Reproduce code: --- I fixed the problem by adding: #ifndef T #define T 1 #endif after the line #define PHP_IMAP_ADDRESS_SIZE_BUF 10 in php_imap.c -- Edit this bug report at http://bugs.php.net/?id=24156edit=1
#24156 [Opn-Fbk]: T undefined during compile of php_imap.c
ID: 24156 Updated by: [EMAIL PROTECTED] Reported By: barryn at baptisthealth dot net -Status: Open +Status: Feedback Bug Type: IMAP related Operating System: Solaris 8 PHP Version: 4.3.2 New Comment: I need the full *original* error, so remove your hack and recompile again. It works fine here. Previous Comments: [2003-06-12 13:26:00] barryn at baptisthealth dot net My source no longer generates this error. Please read the full bug description. OBVIOUSLY the error was something to effect of: `T' undeclared (first use in this function) (Each undeclared identifier is reported only once for each function it appears in.) The line number in the source code was 1117 [2003-06-12 13:15:13] [EMAIL PROTECTED] Please add the full error message here. [2003-06-12 13:03:17] barryn at baptisthealth dot net Description: Compiling with these switches: ./configure --prefix=/opt/php --with-nsapi=/opt/netscape --with-oci8 --enable-dbase --enable-filepro --enable-ftp --enable-sysvsem --enable-sysvshm --with-zlib --with-jpeg-dir=/opt/sfw --with-png-dir=/opt/sfw --with-gdbm --with-gd --with-imap --with-mysql --enable-sigchild --enable-libgcc --with-cpdflib --with-flatfile on Solaris 8 resulted in T being undefined when compiling php_imap.c Imap version info: * Program: Interactive Mail Access Protocol 4rev1 (IMAP4R1) routines * * Author: Mark Crispin * Networks and Distributed Computing * Computing Communications * University of Washington * Administration Building, AG-44 * Seattle, WA 98195 * Internet: [EMAIL PROTECTED] * * Date:14 October 1988 * Last Edited: 14 November 2001 Reproduce code: --- I fixed the problem by adding: #ifndef T #define T 1 #endif after the line #define PHP_IMAP_ADDRESS_SIZE_BUF 10 in php_imap.c -- Edit this bug report at http://bugs.php.net/?id=24156edit=1
#24156 [Fbk-Opn]: T undefined during compile of php_imap.c
ID: 24156 User updated by: barryn at baptisthealth dot net Reported By: barryn at baptisthealth dot net -Status: Feedback +Status: Open Bug Type: IMAP related Operating System: Solaris 8 PHP Version: 4.3.2 New Comment: I have no more time to assist with this. Here is the information you requested. You fix this problem (which probably only occurs with certain versions of the imap headers, maybe only on Solaris) by adding the code I included, which will do nothing if T is already defined. Or not... It's up the powers that be that maintain this package. Whatever. Here's the error text: /bin/sh /usr/share/src/php-4.3.2/libtool --silent --preserve-dup-deps --mode=compile /usr/share/src/php-4.3.2/meta_ccld -Iext/imap/ -I/usr/share/src/php-4.3.2/ext/imap/ -DPHP_ATOM_INC -I/usr/share/src/php-4.3.2/include -I/usr/share/src/php-4.3.2/main -I/usr/share/src/php-4.3.2 -I/opt/netscape/plugins/include -I/usr/share/src/php-4.3.2/Zend -I/opt/sfw/include -I/opt/app/oracle/product/8.1.6/rdbms/public -I/opt/app/oracle/product/8.1.6/rdbms/demo -I/opt/app/oracle/product/8.1.6/network/public -I/usr/share/src/php-4.3.2/ext/xml/expat -D_POSIX_PTHREAD_SEMANTICS -D_POSIX_PTHREAD_SEMANTICS -D_REENTRANT -I/usr/share/src/php-4.3.2/TSRM -DTHREAD=1 -O2 -I/opt/app/oracle/product/8.1.6/rdbms/demo -I/opt/app/oracle/product/8.1.6/rdbms/public -I/opt/app/oracle/product/8.1.6/network/public -pthreads -DZTS -prefer-pic -c /usr/share/src/php-4.3.2/ext/imap/php_imap.c -o ext/imap/php_imap.lo /usr/share/src/php-4.3.2/ext/imap/php_imap.c: In function `zif_imap_mail_copy': /usr/share/src/php-4.3.2/ext/imap/php_imap.c:1117: `T' undeclared (first use in this function) /usr/share/src/php-4.3.2/ext/imap/php_imap.c:1117: (Each undeclared identifier is reported only once /usr/share/src/php-4.3.2/ext/imap/php_imap.c:1117: for each function it appears in.) /usr/share/src/php-4.3.2/ext/imap/php_imap.c: In function `zif_imap_mail_move': /usr/share/src/php-4.3.2/ext/imap/php_imap.c:1145: `T' undeclared (first use in this function) /usr/share/src/php-4.3.2/ext/imap/php_imap.c: In function `zif_imap_createmailbox': /usr/share/src/php-4.3.2/ext/imap/php_imap.c:1168: `T' undeclared (first use in this function) /usr/share/src/php-4.3.2/ext/imap/php_imap.c: In function `zif_imap_renamemailbox': /usr/share/src/php-4.3.2/ext/imap/php_imap.c:1192: `T' undeclared (first use in this function) /usr/share/src/php-4.3.2/ext/imap/php_imap.c: In function `zif_imap_deletemailbox': /usr/share/src/php-4.3.2/ext/imap/php_imap.c:1215: `T' undeclared (first use in this function) /usr/share/src/php-4.3.2/ext/imap/php_imap.c: In function `zif_imap_subscribe': /usr/share/src/php-4.3.2/ext/imap/php_imap.c:1648: `T' undeclared (first use in this function) /usr/share/src/php-4.3.2/ext/imap/php_imap.c: In function `zif_imap_unsubscribe': /usr/share/src/php-4.3.2/ext/imap/php_imap.c:1671: `T' undeclared (first use in this function) *** Error code 1 make: Fatal error: Command failed for target `ext/imap/php_imap.lo' Previous Comments: [2003-06-12 13:28:35] [EMAIL PROTECTED] I need the full *original* error, so remove your hack and recompile again. It works fine here. [2003-06-12 13:26:00] barryn at baptisthealth dot net My source no longer generates this error. Please read the full bug description. OBVIOUSLY the error was something to effect of: `T' undeclared (first use in this function) (Each undeclared identifier is reported only once for each function it appears in.) The line number in the source code was 1117 [2003-06-12 13:15:13] [EMAIL PROTECTED] Please add the full error message here. [2003-06-12 13:03:17] barryn at baptisthealth dot net Description: Compiling with these switches: ./configure --prefix=/opt/php --with-nsapi=/opt/netscape --with-oci8 --enable-dbase --enable-filepro --enable-ftp --enable-sysvsem --enable-sysvshm --with-zlib --with-jpeg-dir=/opt/sfw --with-png-dir=/opt/sfw --with-gdbm --with-gd --with-imap --with-mysql --enable-sigchild --enable-libgcc --with-cpdflib --with-flatfile on Solaris 8 resulted in T being undefined when compiling php_imap.c Imap version info: * Program: Interactive Mail Access Protocol 4rev1 (IMAP4R1) routines * * Author: Mark Crispin * Networks and Distributed Computing * Computing Communications * University of Washington * Administration Building, AG-44 * Seattle, WA 98195 * Internet: [EMAIL PROTECTED] * * Date:14 October 1988 * Last Edited: 14 November 2001 Reproduce code: --- I fixed the problem by adding: #ifndef T #define T 1 #endif
#24083 [Bgs]: Content-Encoding: gzip output includes the wrong Content-Length header
ID: 24083 User updated by: yngve at opera dot com Reported By: yngve at opera dot com Status: Bogus Bug Type:Zlib Related PHP Version: 4.3.1 New Comment: The PHP module may not set any Content-Length headers itself, but it is allowing the scripts to set them. I do not have any real problem with that (CGI scripts also do this). Any problems caused by incorrect content-length headers would be local to that particular script. The problem is that when the PHP module apply *internal* postprocessing to the data generated by the script, such as is done by the ob_gzhandler (and possibly by other output handlers in PHP) the *length* of the output changes, and if the script sent an explicit content-length header, that particular header is no longer valid and should have been removed by your outputhandler. PHP is producing content (header + data) that is inteded to be transmitted over a HTTP channel, and is therefore IMO affected by the RFC 2616 requirements. When PHP (or any other serverside module or proxy) modifies HTTP data (apart from the original construction of header + data when processing the script) it becomes PHP's responsibility (to the best of its ability) to ensure that the headers it forwards are still consistent with the new version of the data. That includes (in this case) not just adding a Content-Encoding: gzip header, but removing or editing the Content-Length header as well. This is not really a question of the script setting a correct or incorrect header, but of the PHP postprocessing step allowing an obviously incorrect header value to be passed on to the client. Because, as far as I can see, this is a general problem with PHP, and because PHP is used by a large number of sites, this Content-Length header problem is causing problems for many of Opera's users. I therefore have to take steps to reduce the actual visible signs of the problem (repeated flashing downloads of the page due to our HTTP pipeline error recovery heuristics, or Connection closed by server errors). In this case, as it does not appear you are willing to prevent the problem, the only two options open to me are to either disable Accept-Encoding, or to not completely trust the Content-Length headers when communicating with servers that can be identified as using PHP. The first may increase network loads, unless the server uses Transfer-Encoding, the second has the advantages that compression may still be used, and if the problem is fixed later, Opera can still use persistent connections to the server (which is anyway not possible as long as incorrect Content-Length headers are sent by the server). As I already had code in place for the second option, due to similar problems with PHP 4.0.4-4.0.6, I chose to expand that code to cover all PHP versions. What this code do is to not send any new request to the server until Opera have received all the bytes of data it expects based on the content-length, even if the server claims to be a pipeline capable server, and if it does not recieve all the bytes before the connection closes assume that it really did get all the data, and not to make a fuss about the missing data. I do not like adding special handling of specific serversoftware (broad definition) but in a number of cases it has been necessary in order to handle known problems of a general nature with that particular serversoftware that cannot be handled properly, or at all, by heuristics. As soon as the cause of the problem is removed I remove, or limit the scope of the special handling. Previous Comments: [2003-06-12 12:15:35] [EMAIL PROTECTED] Erm? 1st: it has nothing to do with the PHP server, as PHP is not a server, but rather a module to a webserver. 2nd: we do not set any Content-Length header ourselves. 3rd: PHP is a flexiable scripting language allowed users to set (override) Content-Length headers themselves whereever they think it's necessary even although that might be wrong. AFAIK RFC 2606 is an HTTP RFC, PHP does NOT implement HTTP, but rather makes use of it it. So, what is your problem with PHP? [2003-06-12 10:43:06] yngve at opera dot com As you are, apparently, not willing to enforce correct Content-Length headers I see no option but to make sure that Opera does not trust Content-Length headers served by PHP powered servers. This will be effective as of v7.20. Please inform me when you start enforcing RFC 2616 sec. 4.4 and only sends/passes through valid Content-Length headers, so that I can remove/limit this special handling of PHP servers. [2003-06-12 08:20:23] [EMAIL PROTECTED] There's not much we can do if a script sets a wrong content-length header. Not PHP bug.
#24155 [Opn-Csd]: imagerotate fail to copy entire source image
ID: 24155
Updated by: [EMAIL PROTECTED]
Reported By: tom at gksystems dot com
-Status: Open
+Status: Closed
Bug Type: GD related
Operating System: all
PHP Version: 4.3.2
Assigned To: iliaa
New Comment:
This bug has been fixed in CVS.
In case this was a PHP problem, snapshots of the sources are packaged
every three hours; this change will be in the next snapshot. You can
grab the snapshot at http://snaps.php.net/.
In case this was a documentation problem, the fix will show up soon at
http://www.php.net/manual/.
In case this was a PHP.net website problem, the change will show
up on the PHP.net site and on the mirror sites in short time.
Thank you for the report, and for helping us make PHP better.
Previous Comments:
[2003-06-12 12:23:47] tom at gksystems dot com
Description:
When rotating an image which is taller-than-wide through an angle 225
and = 315 degrees, only a square portion of the image is copied. The
remainder is black.
ext/libgd/gd.c has a bug in gdImageRotate270:
for (uY = 0; uYsrc-sx; uY++) {
for (uX = 0; uXsrc-sx; uX++) {
uY and uX both have a range of src-sx, so only a square region is
copied. The first line should be:
for (uY = 0; uYsrc-sy; uY++) {
Reproduce code:
---
script language=PHP
// June 12, 2003 Tom Robinson
// Display a 30x50 yellow rectangle, rotated 270 degrees CCW.
$im = ImageCreateTrueColor(30,50);
imagefill($im,0,0,16777215-255);
$im = imagerotate($im,270,255);
header(Content-type: image/png);
imagepng($im);
/script
Expected result:
See a yellow rectangle.
Actual result:
--
See a rectangle with a yellow square and the rest is black.
--
Edit this bug report at http://bugs.php.net/?id=24155edit=1
#22505 [Asn-Csd]: no way to specify the input charset for imap_sort() and imap_search()
ID: 22505 Updated by: [EMAIL PROTECTED] Reported By: yamamoto at trustbee dot com -Status: Assigned +Status: Closed Bug Type:IMAP related PHP Version: 4.3.1 Assigned To: iliaa New Comment: This bug has been fixed in CVS. In case this was a PHP problem, snapshots of the sources are packaged every three hours; this change will be in the next snapshot. You can grab the snapshot at http://snaps.php.net/. In case this was a documentation problem, the fix will show up soon at http://www.php.net/manual/. In case this was a PHP.net website problem, the change will show up on the PHP.net site and on the mirror sites in short time. Thank you for the report, and for helping us make PHP better. Fixed in the 5.0 tree, it may be backported to 4.3 if there is a general consensus to do so. Previous Comments: [2003-06-10 19:19:40] [EMAIL PROTECTED] assigning to myself [2003-03-02 07:07:25] yamamoto at trustbee dot com I'm localizing IMP of Horde project to Japanese. I need to search by Japanese for imap_sort function, but no way to specify the input charset. I made a patch to add input charset for imap_sort() and imap_search(). Please see below. http://www.imp-jp.org/tarballs/php_imap_cvs.patch -- Edit this bug report at http://bugs.php.net/?id=22505edit=1
#23975 [Asn-Csd]: dba_open locking error with ndbm/db2/db3
ID: 23975 Updated by: [EMAIL PROTECTED] -Summary: dba_open locking error with db3 Reported By: rhalstenbach at t-online dot de -Status: Assigned +Status: Closed Bug Type: DBM/DBA related -Operating System: Windows +Operating System: ANY PHP Version: 4.3.2 Assigned To: helly New Comment: This bug has been fixed in CVS. In case this was a PHP problem, snapshots of the sources are packaged every three hours; this change will be in the next snapshot. You can grab the snapshot at http://snaps.php.net/. In case this was a documentation problem, the fix will show up soon at http://www.php.net/manual/. In case this was a PHP.net website problem, the change will show up on the PHP.net site and on the mirror sites in short time. Thank you for the report, and for helping us make PHP better. Maybe this applies to dbm, too. However the problem is solved in a generic way. Previous Comments: [2003-06-10 05:19:49] adam at saki dot com dot au This is actually because the locking will prematurely create an empty file, causing the VCWD_STAT command in dba_db3.c to return 0, resulting in the wrong parameters to db_open. This can be verified by putting a stat command after the lock detection code and before the call to open (line 590 in ext/dba/dba.c). [2003-06-05 01:28:33] [EMAIL PROTECTED] Marcus, take a look? [2003-06-03 03:43:56] rhalstenbach at t-online dot de The new locking feature (introduced with 4.3.0) does not work correctly in default mode d. Very annoying because it is the default mode ... Example: ?php $d1 = dba_open(c:/www/htdocs/dbfile, c, db3); // Old syntax, specifying no locking mode means mode d, i.e. same as cd if ($d1 === FALSE) die(Could not open dbfile); ? Same problem for mode w. It works correctly for locking mode l and for suppressing locking via -. Obviously the dba_open() function tries to create a lock file with exactly the same name as the database file - what fails of course. Tested on WindowsXP with db3, but i think it will fail for every db-driver (except gdbm) on every OS. -- Edit this bug report at http://bugs.php.net/?id=23975edit=1
#24158 [NEW]: missing settings in php.ini_*
From: holliwell at gmx dot net Operating system: any PHP version: 4.3.2 PHP Bug Type: *General Issues Bug description: missing settings in php.ini_* Description: neither php.ini-recommended nor php.ini-dist lists the following available settings: [mcrypt] mcrypt.algorithms_dir mcrypt.modes_dir [mime_magic} mime_magic.magicfile [yaz] yaz.max_links yaz.log_file Regards Friedhelm Betz -- Edit bug report at http://bugs.php.net/?id=24158edit=1 -- Try a CVS snapshot: http://bugs.php.net/fix.php?id=24158r=trysnapshot Fixed in CVS: http://bugs.php.net/fix.php?id=24158r=fixedcvs Fixed in release: http://bugs.php.net/fix.php?id=24158r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=24158r=needtrace Try newer version: http://bugs.php.net/fix.php?id=24158r=oldversion Not developer issue:http://bugs.php.net/fix.php?id=24158r=support Expected behavior: http://bugs.php.net/fix.php?id=24158r=notwrong Not enough info:http://bugs.php.net/fix.php?id=24158r=notenoughinfo Submitted twice:http://bugs.php.net/fix.php?id=24158r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=24158r=globals PHP 3 support discontinued: http://bugs.php.net/fix.php?id=24158r=php3 Daylight Savings: http://bugs.php.net/fix.php?id=24158r=dst IIS Stability: http://bugs.php.net/fix.php?id=24158r=isapi Install GNU Sed:http://bugs.php.net/fix.php?id=24158r=gnused
#24160 [NEW]: 4.3.2 Windows Problem BUG CGI CALL
From: albersag at terra dot es Operating system: WIN XP PHP version: 4.3.2 PHP Bug Type: *Configuration Issues Bug description: 4.3.2 Windows Problem BUG CGI CALL Description: I have installed php 4.3.2 as a cgi for abyss web server. http://www.aprelium.com . And i get a not imput file specified when calling a index.php file for example , but 4.3.1 works correctly without changing anything. I think is a bug of this version Reproduce code: --- No input file specified. on screen Expected result: When 4.3.1 it works and... i get phpinfo() correctly -- Edit bug report at http://bugs.php.net/?id=24160edit=1 -- Try a CVS snapshot: http://bugs.php.net/fix.php?id=24160r=trysnapshot Fixed in CVS: http://bugs.php.net/fix.php?id=24160r=fixedcvs Fixed in release: http://bugs.php.net/fix.php?id=24160r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=24160r=needtrace Try newer version: http://bugs.php.net/fix.php?id=24160r=oldversion Not developer issue:http://bugs.php.net/fix.php?id=24160r=support Expected behavior: http://bugs.php.net/fix.php?id=24160r=notwrong Not enough info:http://bugs.php.net/fix.php?id=24160r=notenoughinfo Submitted twice:http://bugs.php.net/fix.php?id=24160r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=24160r=globals PHP 3 support discontinued: http://bugs.php.net/fix.php?id=24160r=php3 Daylight Savings: http://bugs.php.net/fix.php?id=24160r=dst IIS Stability: http://bugs.php.net/fix.php?id=24160r=isapi Install GNU Sed:http://bugs.php.net/fix.php?id=24160r=gnused
#24161 [NEW]: imap_open will not timeout
From: thomas at xenocast dot com
Operating system: Windows 2000
PHP version: 4.3.2
PHP Bug Type: IMAP related
Bug description: imap_open will not timeout
Description:
This is a difficult situation to reproduce. I will try
to give you the history. We are running iMail 7.x and
the back-end is through an SQL server. there is a bug
in iMail that if the SQL Server for any reason is
'lost' then POP3 will just hang and not attempt to
reconnect. The only way around it is to restart the
service. This doesn't happen often on our system and
it's quite random, but when it happens nobody can get
their e-mail. The solution I came up with is a script
(referenced below) to check on if I can login to POP3.
If I cannot, restart the service.
The problem arises when this situation happens with
iMail, the imap_open command simply hangs there. It is
waiting for a response from the server after giving the
username and/or password. and nothing comes. It hangs
just like the e-mail clients do, howevver imap_open
FAILS to timeout. At last count the longest the script
hung there without going anywhere was 30 minutes. and I
do not even have set a script time-out so in the least
the script should have failed itself due to running too
long. the function is just sitting there waiting for a
response from the server.
Perhaps there's another way to do this or perhaps there
is a bug in imap_open that doesn't provide for the
thing to timeout or something, wdyt?
Reproduce code:
---
$mbox = imap_open({mail.neweve.com:110/pop3/notls}INBOX, thomas,
theduke);
if (!$mbox) {
system(net stop pop3d32);
system(net start pop3d32);
}
Expected result:
Expected is that imap_open would fail with a timeout or
something and $mbox would be false so my system would
restart.
Actual result:
--
Actual result is that imap_open sits there and does
nothing it never stops the script just hangs
indefinitely. When adding echo statements as debug
code I see it never passes that line.
--
Edit bug report at http://bugs.php.net/?id=24161edit=1
--
Try a CVS snapshot: http://bugs.php.net/fix.php?id=24161r=trysnapshot
Fixed in CVS: http://bugs.php.net/fix.php?id=24161r=fixedcvs
Fixed in release: http://bugs.php.net/fix.php?id=24161r=alreadyfixed
Need backtrace: http://bugs.php.net/fix.php?id=24161r=needtrace
Try newer version: http://bugs.php.net/fix.php?id=24161r=oldversion
Not developer issue:http://bugs.php.net/fix.php?id=24161r=support
Expected behavior: http://bugs.php.net/fix.php?id=24161r=notwrong
Not enough info:http://bugs.php.net/fix.php?id=24161r=notenoughinfo
Submitted twice:http://bugs.php.net/fix.php?id=24161r=submittedtwice
register_globals: http://bugs.php.net/fix.php?id=24161r=globals
PHP 3 support discontinued: http://bugs.php.net/fix.php?id=24161r=php3
Daylight Savings: http://bugs.php.net/fix.php?id=24161r=dst
IIS Stability: http://bugs.php.net/fix.php?id=24161r=isapi
Install GNU Sed:http://bugs.php.net/fix.php?id=24161r=gnused
#23936 [Bgs-Opn]: fail to select and fetch
ID: 23936 User updated by: sarusij at yahoo dot com Reported By: sarusij at yahoo dot com -Status: Bogus +Status: Open Bug Type: InterBase related Operating System: redhat 7.3 PHP Version: 4.3.2 New Comment: Forgot to change the status to open Previous Comments: [2003-06-12 10:10:45] sarusij at yahoo dot com Ok, I have reinstalled RH73 Interbase 6.0.1 changed php to 4.3.2 worked ok. removed Interbase 6, installed interbase 7 using interbase.so (generated with the previous interbase 6.0.1) seem worked ok (didn't full test my application). now generated interbase.so with interbase 7 (./compile --with-interbase=shared,/opt/interbase make) put it in place, started httpd and interbase and wht we get ? the exact same error !Warning: InterBase: Dynamic SQL Error SQL error code = -804 Incorrect values within SQLDA structure in /home/web-site/htdocs/main.inc on line 31 the question changed now, what shoud I do in order to get PHP and interbase 7 work together ? I asume the problem is in generating the interbase.so. Thanks [2003-06-01 10:49:53] [EMAIL PROTECTED] Thank you for taking the time to report a problem with PHP. Unfortunately you are not using a current version of PHP -- the problem might already be fixed. Please download a new PHP version from http://www.php.net/downloads.php If you are 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. Again, thank you for your continued support of PHP. PHP 4.3.2 was released already and has couple of ext/interbase fixes too. [2003-06-01 09:26:22] sarusij at yahoo dot com I was using RedHat 7.3 with Interbase 6.0.1 every thing worked fine (Apache 1.3.x php 4.1.x). In order to get better performance updated to redhat 8 (apache 2.0.40 php 4.2.2) and interbase 7 (trial) generated interbase.so using ./compile --with-interbase=shared,/opt/interbase all in place, restart httpd, when accesing page with a database select it returns:- Warning: InterBase: Dynamic SQL Error SQL error code = -804 Incorrect values within SQLDA structure in /home/web-site/htdocs/main.inc on line 31 line 31 = $arr=ibase_fetch_row($sth); By mistake I have, in one of the time forgot to change to interbase.so that was compiled with interbase 7 and left interbase.so related to interbase 6, the warning above did not appear and seemed like everything operates ok. Using the tests within ext/interbase I found that test 5 (transactions) failed, it alsio failed when I have interbase 6.0.1. It did not fail using the original installation (RH7.3, IB6.0.1, php4.1.x apache 1.3.x) I have been doing it all also with php 4.3.1 with same results. What should I do in order to get the basic RH8 (apache 2.0.40 and php 4.2.2) instalation to operate correctly with interbase 7 (module interbase.so) Thanks for help Jacob -- Edit this bug report at http://bugs.php.net/?id=23936edit=1
#24161 [Opn]: imap_open will not timeout
ID: 24161
User updated by: thomas at xenocast dot com
Reported By: thomas at xenocast dot com
Status: Open
Bug Type: IMAP related
Operating System: Windows 2000
PHP Version: 4.3.2
New Comment:
Damn, umn.. I had trouble with the submission form and
some funky thing with my browser. I didn't change the
values of the user/pass and domain in my script. Now
how many people got it?! Well, I changed my password.
please don't hack me.
Previous Comments:
[2003-06-12 16:30:44] thomas at xenocast dot com
Description:
This is a difficult situation to reproduce. I will try
to give you the history. We are running iMail 7.x and
the back-end is through an SQL server. there is a bug
in iMail that if the SQL Server for any reason is
'lost' then POP3 will just hang and not attempt to
reconnect. The only way around it is to restart the
service. This doesn't happen often on our system and
it's quite random, but when it happens nobody can get
their e-mail. The solution I came up with is a script
(referenced below) to check on if I can login to POP3.
If I cannot, restart the service.
The problem arises when this situation happens with
iMail, the imap_open command simply hangs there. It is
waiting for a response from the server after giving the
username and/or password. and nothing comes. It hangs
just like the e-mail clients do, howevver imap_open
FAILS to timeout. At last count the longest the script
hung there without going anywhere was 30 minutes. and I
do not even have set a script time-out so in the least
the script should have failed itself due to running too
long. the function is just sitting there waiting for a
response from the server.
Perhaps there's another way to do this or perhaps there
is a bug in imap_open that doesn't provide for the
thing to timeout or something, wdyt?
Reproduce code:
---
$mbox = imap_open({mail.neweve.com:110/pop3/notls}INBOX, thomas,
theduke);
if (!$mbox) {
system(net stop pop3d32);
system(net start pop3d32);
}
Expected result:
Expected is that imap_open would fail with a timeout or
something and $mbox would be false so my system would
restart.
Actual result:
--
Actual result is that imap_open sits there and does
nothing it never stops the script just hangs
indefinitely. When adding echo statements as debug
code I see it never passes that line.
--
Edit this bug report at http://bugs.php.net/?id=24161edit=1
#24161 [Opn]: imap_open will not timeout
ID: 24161
Updated by: [EMAIL PROTECTED]
Reported By: thomas at xenocast dot com
Status: Open
Bug Type: IMAP related
Operating System: Windows 2000
PHP Version: 4.3.2
New Comment:
About 500 ppl, but I doubt they saw it before you changed it.
Previous Comments:
[2003-06-12 16:35:30] thomas at xenocast dot com
Damn, umn.. I had trouble with the submission form and
some funky thing with my browser. I didn't change the
values of the user/pass and domain in my script. Now
how many people got it?! Well, I changed my password.
please don't hack me.
[2003-06-12 16:30:44] thomas at xenocast dot com
Description:
This is a difficult situation to reproduce. I will try
to give you the history. We are running iMail 7.x and
the back-end is through an SQL server. there is a bug
in iMail that if the SQL Server for any reason is
'lost' then POP3 will just hang and not attempt to
reconnect. The only way around it is to restart the
service. This doesn't happen often on our system and
it's quite random, but when it happens nobody can get
their e-mail. The solution I came up with is a script
(referenced below) to check on if I can login to POP3.
If I cannot, restart the service.
The problem arises when this situation happens with
iMail, the imap_open command simply hangs there. It is
waiting for a response from the server after giving the
username and/or password. and nothing comes. It hangs
just like the e-mail clients do, howevver imap_open
FAILS to timeout. At last count the longest the script
hung there without going anywhere was 30 minutes. and I
do not even have set a script time-out so in the least
the script should have failed itself due to running too
long. the function is just sitting there waiting for a
response from the server.
Perhaps there's another way to do this or perhaps there
is a bug in imap_open that doesn't provide for the
thing to timeout or something, wdyt?
Reproduce code:
---
$mbox = imap_open({mail.neweve.com:110/pop3/notls}INBOX, thomas,
theduke);
if (!$mbox) {
system(net stop pop3d32);
system(net start pop3d32);
}
Expected result:
Expected is that imap_open would fail with a timeout or
something and $mbox would be false so my system would
restart.
Actual result:
--
Actual result is that imap_open sits there and does
nothing it never stops the script just hangs
indefinitely. When adding echo statements as debug
code I see it never passes that line.
--
Edit this bug report at http://bugs.php.net/?id=24161edit=1
#24163 [NEW]: exif_read_data does not return IPTC data
From: johneagle at mesanetworks dot com Operating system: win 2000 PHP version: 4.3.2 PHP Bug Type: Unknown/Other Function Bug description: exif_read_data does not return IPTC data Description: exif_read_data does not return IPTC data on jpegs It works fine for exif data etc. I can supply an image for you to test if you like -- Edit bug report at http://bugs.php.net/?id=24163edit=1 -- Try a CVS snapshot: http://bugs.php.net/fix.php?id=24163r=trysnapshot Fixed in CVS: http://bugs.php.net/fix.php?id=24163r=fixedcvs Fixed in release: http://bugs.php.net/fix.php?id=24163r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=24163r=needtrace Try newer version: http://bugs.php.net/fix.php?id=24163r=oldversion Not developer issue:http://bugs.php.net/fix.php?id=24163r=support Expected behavior: http://bugs.php.net/fix.php?id=24163r=notwrong Not enough info:http://bugs.php.net/fix.php?id=24163r=notenoughinfo Submitted twice:http://bugs.php.net/fix.php?id=24163r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=24163r=globals PHP 3 support discontinued: http://bugs.php.net/fix.php?id=24163r=php3 Daylight Savings: http://bugs.php.net/fix.php?id=24163r=dst IIS Stability: http://bugs.php.net/fix.php?id=24163r=isapi Install GNU Sed:http://bugs.php.net/fix.php?id=24163r=gnused
#24161 [Opn-Ver]: imap_open will not timeout
ID: 24161
Updated by: [EMAIL PROTECTED]
Reported By: thomas at xenocast dot com
-Status: Open
+Status: Verified
Bug Type: IMAP related
Operating System: Windows 2000
PHP Version: 4.3.2
-Assigned To:
+Assigned To: iliaa
New Comment:
assigning to self.
Previous Comments:
[2003-06-12 16:39:55] [EMAIL PROTECTED]
About 500 ppl, but I doubt they saw it before you changed it.
[2003-06-12 16:35:30] thomas at xenocast dot com
Damn, umn.. I had trouble with the submission form and
some funky thing with my browser. I didn't change the
values of the user/pass and domain in my script. Now
how many people got it?! Well, I changed my password.
please don't hack me.
[2003-06-12 16:30:44] thomas at xenocast dot com
Description:
This is a difficult situation to reproduce. I will try
to give you the history. We are running iMail 7.x and
the back-end is through an SQL server. there is a bug
in iMail that if the SQL Server for any reason is
'lost' then POP3 will just hang and not attempt to
reconnect. The only way around it is to restart the
service. This doesn't happen often on our system and
it's quite random, but when it happens nobody can get
their e-mail. The solution I came up with is a script
(referenced below) to check on if I can login to POP3.
If I cannot, restart the service.
The problem arises when this situation happens with
iMail, the imap_open command simply hangs there. It is
waiting for a response from the server after giving the
username and/or password. and nothing comes. It hangs
just like the e-mail clients do, howevver imap_open
FAILS to timeout. At last count the longest the script
hung there without going anywhere was 30 minutes. and I
do not even have set a script time-out so in the least
the script should have failed itself due to running too
long. the function is just sitting there waiting for a
response from the server.
Perhaps there's another way to do this or perhaps there
is a bug in imap_open that doesn't provide for the
thing to timeout or something, wdyt?
Reproduce code:
---
$mbox = imap_open({mail.neweve.com:110/pop3/notls}INBOX, thomas,
theduke);
if (!$mbox) {
system(net stop pop3d32);
system(net start pop3d32);
}
Expected result:
Expected is that imap_open would fail with a timeout or
something and $mbox would be false so my system would
restart.
Actual result:
--
Actual result is that imap_open sits there and does
nothing it never stops the script just hangs
indefinitely. When adding echo statements as debug
code I see it never passes that line.
--
Edit this bug report at http://bugs.php.net/?id=24161edit=1
#21339 [Com]: cannot compile gettext support
ID: 21339
Comment by: poleson at verio dot net
Reported By: gobbers at faw dot uni-ulm dot de
Status: Bogus
Bug Type: Gettext related
Operating System: Solaris 8
PHP Version: 4.3.0
New Comment:
I was getting this same situation on Solaris 6 8, compiling with
Forte against a staticly compiled gettext lib. I fixed it with this
Patch.. I'm unsure if it is completely correct.. but it seems wierd
that the module name was listed as php_gettext and then the PHP_MINFO
macro used
gettext.
***
*** 66,72
NULL,
NULL,
NULL,
! PHP_MINFO(gettext),
NO_VERSION_YET,
STANDARD_MODULE_PROPERTIES
};
--- 66,72
NULL,
NULL,
NULL,
! PHP_MINFO(php_gettext),
NO_VERSION_YET,
STANDARD_MODULE_PROPERTIES
};
***
*** 75,81
ZEND_GET_MODULE(php_gettext)
#endif
! PHP_MINFO_FUNCTION(gettext)
{
php_info_print_table_start();
php_info_print_table_row(2, GetText Support, enabled);
--- 75,81
ZEND_GET_MODULE(php_gettext)
#endif
! PHP_MINFO_FUNCTION(php_gettext)
{
php_info_print_table_start();
php_info_print_table_row(2, GetText Support, enabled);
Index: php_gettext.h
===
RCS file: /cvsroot/contrib/php4/ext/gettext/php_gettext.h,v
retrieving revision 1.1.1.4
diff -c -r1.1.1.4 php_gettext.h
*** php_gettext.h 2002/12/31 16:34:38 1.1.1.4
--- php_gettext.h 2003/06/12 22:49:36
***
*** 22,35
#define PHP_GETTEXT_H
#if HAVE_LIBINTL
! #ifndef INIT_FUNC_ARGS
#include zend_modules.h
#endif
extern zend_module_entry php_gettext_module_entry;
#define gettext_module_ptr php_gettext_module_entry
! PHP_MINFO_FUNCTION(gettext);
PHP_FUNCTION(textdomain);
PHP_FUNCTION(gettext);
--- 22,39
#define PHP_GETTEXT_H
#if HAVE_LIBINTL
!
! #if PHP_API_VERSION 19990421
#include zend_modules.h
+ #include internal_functions.h
#endif
+ #include libintl.h
+
extern zend_module_entry php_gettext_module_entry;
#define gettext_module_ptr php_gettext_module_entry
! PHP_MINFO_FUNCTION(php_gettext);
PHP_FUNCTION(textdomain);
PHP_FUNCTION(gettext);
Previous Comments:
[2003-05-06 09:17:24] morgan dot pyne at sas dot com
I've run into a similar issue on HP-UX 11.00 compiling 4.3.1 (and
4.3.2RC2) using HP's ANSI C compiler.
The first errors in gettext.c stem from the function names in the
php_gettext_functions[] array being referenced before they are
declared. Either adding prototypes for these functions or moving the
declaration of that array to the bottom of the file after the functions
were declared solved that.
I also encountered the second error(undefined zm_info_gettext when
linking). When looking at the output of the C preprocessor from
gettext.c I noticed that this function was indeed never created. The
actual function name emitted by the PHP_MINFO_FUNCTION(gettext) macro
ends up being called zm_info_libintl_gettext instead of simply
zm_info_gettext. However, anywhere the macro PHP_MINFO was used, it
was still emitting zm_info_gettext, hence the discrepancy.
I managed workarounds for these but I'm not sure if the cause of them
is due to my build environment or the source code, since most people
don't seem to have this problem. I can provide more info or answer
further questions on the topic if anybody is interested in pursuing
this.
Regards,
Morgan
[2003-03-04 09:26:24] sjsobol at justthe dot net
Hey now. Some of us work for a living :P :)
Seriously: I finally chalked it up to a problem using a Mandrake RPM on
Red Hat (although usually I have no problems doing so). I grabbed
another source RPM (the build source is listed as Unknown, but I know
it is not Mandrake) and made my tweaks to it. It compiled just fine,
including ming, pdflib and gettext. (I was encountering the same
problem with ming and some of the other PHP modules that I was with
gettext, so it was not specifically the gettext module that was having
an issue.
I imagine Mandrake's spec file is heavily customized to work with their
distro, which normally not a problem as I have many customized Mandrake
RPMS on my server, but something was causing major issues with this
particular RPM.
Anyhow, I don't think this is a PHP issue. I think it's a
package-specific issue.
[2003-02-10 12:43:41] [EMAIL PROTECTED]
Works fine here, user has more important issues to deal with and can't
provide feedback, and this most likely is some user error anyway.
[2003-02-04 17:52:11] sjsobol at justthe dot net
Okay, now I'm really confused. I yanked the Configure
#24163 [Opn-WFx]: exif_read_data does not return IPTC data
ID: 24163 Updated by: [EMAIL PROTECTED] Reported By: johneagle at mesanetworks dot com -Status: Open +Status: Wont fix Bug Type: Unknown/Other Function -Operating System: win 2000 +Operating System: ANY PHP Version: 4.3.2 -Assigned To: +Assigned To: helly New Comment: Sure i have myselef. And PHP has dedicated iptc functions. Previous Comments: [2003-06-12 17:42:46] johneagle at mesanetworks dot com Description: exif_read_data does not return IPTC data on jpegs It works fine for exif data etc. I can supply an image for you to test if you like -- Edit this bug report at http://bugs.php.net/?id=24163edit=1
#23861 [Com]: php_gd2.dll - The Specified procedure cannot be found
ID: 23861 Comment by: iridium at beyondunreal dot com Reported By: steve at enerds dot ca Status: Bogus Bug Type: Dynamic loading Operating System: Windows PHP Version: 4.3.2RC4 New Comment: I am getting this bug as well, I am aware this one has been declared bogus, but I am curious. I have found that php_gd2.dll and php_sockets.dll will not load at all in the latest version of PHP (4.3.2), but if I take the modules from PHP 4.3.0, they will both load using PHP 4.3.2. I have made sure these are the only copies avaliable in the path, and I have tried as many locations to put these DLLs as you care to think of, but they still won't load. Since the problem only seems to occour when I try to use the latest DLLs, doens't that mean something is wrong with the DLLs? To my knowledge, I have followed the install instructions quite carefully, and I am certain that all of the relevent (PHP) DLLs have been updated on my system to version 4.3.2. I have spent quite a while puzzling over this. I'm running Apache 1.3.7 and PHP 4.3.2 on Windows XP Pro Sp1. A friend of mine found that PHP wouldn't load on his system either if he tried to use the most recent gd2.dll. Previous Comments: [2003-05-29 22:45:02] steve at enerds dot ca *puts head down with sheepish grin* For some reason or another our sysadmin had a copy of the dll's in c:\windows and c:\windows\system32.Once I deleted those from c:\windows and updated those in c:\windows\system32 all was well. Sorry for the inconvenience, appreciate the support ~Steve [2003-05-29 20:57:17] steve at enerds dot ca I am still having the problem with multiple Windows machine, with different configurations. In all cases, the gd2.dll loads with php 4.3.1, however when I upgrade to the RC 4.3.2 gd2 cannot load. Please advise. Thanks in advance [2003-05-28 21:57:53] steve at enerds dot ca This is *NOT* a configuration problem. Using 4.3.1, without changing my configuration file, paths, or anything else (just the appropriate dll's), it works - gd2 extension loads. When I change to the 4.3.2 RC4 code, it does not work. This is using the exact same machine, web server, configuration, etc. [2003-05-28 19:50:31] [EMAIL PROTECTED] Sorry, but your problem does not imply a bug in PHP itself. For a list of more appropriate places to ask for help using PHP, please visit http://www.php.net/support.php as this bug system is not the appropriate forum for asking support questions. Thank you for your interest in PHP. This issue has come up over and over again. It's NOT a bug. You've just installed PHP improperly. Ask further support questions on the appropriate mailing list. [2003-05-28 13:48:42] steve at enerds dot ca OS: Windows XP Professional, Sp1 Web Server: Apache 2.0.45 Win 32 In trying the new 4.3.2 RC4, I am trying to load the gd2 library without success. When I modify my php.ini and un-comment the line: extension=php_gd2.dll I get the following error. Unknown(): Unable to load dynamic library 'c:\php\extensions\php_gd2.dll' - The specified procedure cannot be found The dll does exist at that path, and I have verified it is actually being able to find it. In changing the dll name to php_test.dll the error message changes to the appropriate: The specified module cannot be found Regards, ~Steve -- Edit this bug report at http://bugs.php.net/?id=23861edit=1
#23861 [Com]: php_gd2.dll - The Specified procedure cannot be found
ID: 23861 Comment by: iridium at beyondunreal dot com Reported By: steve at enerds dot ca Status: Bogus Bug Type: Dynamic loading Operating System: Windows PHP Version: 4.3.2RC4 New Comment: I am a stupid idiot/dolt person. Gahh. I found that there were php4ts.dll/php4apache.dlls in my apache executable directory that were out of date. Updated them and the the problem disappeared. Let this be a lesson.. search for *.dll! Previous Comments: [2003-06-12 19:39:50] iridium at beyondunreal dot com I am getting this bug as well, I am aware this one has been declared bogus, but I am curious. I have found that php_gd2.dll and php_sockets.dll will not load at all in the latest version of PHP (4.3.2), but if I take the modules from PHP 4.3.0, they will both load using PHP 4.3.2. I have made sure these are the only copies avaliable in the path, and I have tried as many locations to put these DLLs as you care to think of, but they still won't load. Since the problem only seems to occour when I try to use the latest DLLs, doens't that mean something is wrong with the DLLs? To my knowledge, I have followed the install instructions quite carefully, and I am certain that all of the relevent (PHP) DLLs have been updated on my system to version 4.3.2. I have spent quite a while puzzling over this. I'm running Apache 1.3.7 and PHP 4.3.2 on Windows XP Pro Sp1. A friend of mine found that PHP wouldn't load on his system either if he tried to use the most recent gd2.dll. [2003-05-29 22:45:02] steve at enerds dot ca *puts head down with sheepish grin* For some reason or another our sysadmin had a copy of the dll's in c:\windows and c:\windows\system32.Once I deleted those from c:\windows and updated those in c:\windows\system32 all was well. Sorry for the inconvenience, appreciate the support ~Steve [2003-05-29 20:57:17] steve at enerds dot ca I am still having the problem with multiple Windows machine, with different configurations. In all cases, the gd2.dll loads with php 4.3.1, however when I upgrade to the RC 4.3.2 gd2 cannot load. Please advise. Thanks in advance [2003-05-28 21:57:53] steve at enerds dot ca This is *NOT* a configuration problem. Using 4.3.1, without changing my configuration file, paths, or anything else (just the appropriate dll's), it works - gd2 extension loads. When I change to the 4.3.2 RC4 code, it does not work. This is using the exact same machine, web server, configuration, etc. [2003-05-28 19:50:31] [EMAIL PROTECTED] Sorry, but your problem does not imply a bug in PHP itself. For a list of more appropriate places to ask for help using PHP, please visit http://www.php.net/support.php as this bug system is not the appropriate forum for asking support questions. Thank you for your interest in PHP. This issue has come up over and over again. It's NOT a bug. You've just installed PHP improperly. Ask further support questions on the appropriate mailing list. 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/23861 -- Edit this bug report at http://bugs.php.net/?id=23861edit=1
#24158 [Opn-Bgs]: missing settings in php.ini_*
ID: 24158 Updated by: [EMAIL PROTECTED] Reported By: holliwell at gmx dot net -Status: Open +Status: Bogus Bug Type: *General Issues Operating System: any PHP Version: 4.3.2 New Comment: Thank you for taking the time to write to us, but this is not a bug. Please double-check the documentation available at http://www.php.net/manual/ and the instructions on how to report a bug at http://bugs.php.net/how-to-report.php There are no suggested defaults for these settings because the location files/directories of these settings are fluid and differ greatly from system to system. Previous Comments: [2003-06-12 15:24:12] holliwell at gmx dot net Description: neither php.ini-recommended nor php.ini-dist lists the following available settings: [mcrypt] mcrypt.algorithms_dir mcrypt.modes_dir [mime_magic} mime_magic.magicfile [yaz] yaz.max_links yaz.log_file Regards Friedhelm Betz -- Edit this bug report at http://bugs.php.net/?id=24158edit=1
