#21698 [NEW]: httpd.conf not modified when creating dso module
From: [EMAIL PROTECTED] Operating system: Linux PHP version: 4.3.0 PHP Bug Type: Apache2 related Bug description: httpd.conf not modified when creating dso module I have upgraded from v4.2.3 to v4.3.0 When compiling PHP v4.2.3 the "make install" command updates my httpd.conf file and adds: LoadModule php4_module modules/libphp4.so I have noticed that this does not happen with the latest release of 4.3.0. I have tried the laetst CVS (php4-STABLE-200301162230) and it still does this :-( I thought it was me at first, but I have tried it several times and each time the same thing happens. Please could someone check this out for the PHP community. Many thanks, Richard. -- Edit bug report at http://bugs.php.net/?id=21698&edit=1 -- Try a CVS snapshot: http://bugs.php.net/fix.php?id=21698&r=trysnapshot Fixed in CVS: http://bugs.php.net/fix.php?id=21698&r=fixedcvs Fixed in release: http://bugs.php.net/fix.php?id=21698&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=21698&r=needtrace Try newer version: http://bugs.php.net/fix.php?id=21698&r=oldversion Not developer issue:http://bugs.php.net/fix.php?id=21698&r=support Expected behavior: http://bugs.php.net/fix.php?id=21698&r=notwrong Not enough info:http://bugs.php.net/fix.php?id=21698&r=notenoughinfo Submitted twice:http://bugs.php.net/fix.php?id=21698&r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=21698&r=globals PHP 3 support discontinued: http://bugs.php.net/fix.php?id=21698&r=php3 Daylight Savings: http://bugs.php.net/fix.php?id=21698&r=dst IIS Stability: http://bugs.php.net/fix.php?id=21698&r=isapi Install GNU Sed:http://bugs.php.net/fix.php?id=21698&r=gnused
#21698 [Fbk->Opn]: httpd.conf not modified when creating dso module
ID: 21698 User updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] -Status: Feedback +Status: Open Bug Type: Apache2 related Operating System: Linux PHP Version: 4.3.0 New Comment: No upgrade of Apache has taken place. All I have done is removed the dso module and any configuration lines in httpd.conf and then re-installed PHP. Previous Comments: [2003-01-17 08:13:57] [EMAIL PROTECTED] Did you happen upgrade Apache2 since 4.2.3 ?? Or are you using same version for both PHP 4.2.3 and 4.3.0 ? [2003-01-16 17:46:00] [EMAIL PROTECTED] I have upgraded from v4.2.3 to v4.3.0 When compiling PHP v4.2.3 the "make install" command updates my httpd.conf file and adds: LoadModule php4_module modules/libphp4.so I have noticed that this does not happen with the latest release of 4.3.0. I have tried the laetst CVS (php4-STABLE-200301162230) and it still does this :-( I thought it was me at first, but I have tried it several times and each time the same thing happens. Please could someone check this out for the PHP community. Many thanks, Richard. -- Edit this bug report at http://bugs.php.net/?id=21698&edit=1
#21698 [Com]: httpd.conf not modified when creating dso module
ID: 21698 Comment by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] Status: Closed Bug Type: Apache2 related Operating System: Linux PHP Version: 4.3.0 New Comment: I don't know if anyone will get to read this now this issue is closed. But if you do, thank you for fixing this so quickly. Shame other software companies aren't as quick! ;-) Previous Comments: [2003-01-21 00:03:25] [EMAIL PROTECTED] This bug has been fixed in CVS. In case this was a PHP problem, snapshots of the sources are packaged every three hours; this change will be in the next snapshot. You can grab the snapshot at http://snaps.php.net/. In case this was a documentation problem, the fix will show up soon at http://www.php.net/manual/. In case this was a PHP.net website problem, the change will show up on the PHP.net site and on the mirror sites in short time. Thank you for the report, and for helping us make PHP better. [2003-01-18 11:39:44] [EMAIL PROTECTED] No upgrade of Apache has taken place. All I have done is removed the dso module and any configuration lines in httpd.conf and then re-installed PHP. [2003-01-17 08:13:57] [EMAIL PROTECTED] Did you happen upgrade Apache2 since 4.2.3 ?? Or are you using same version for both PHP 4.2.3 and 4.3.0 ? [2003-01-16 17:46:00] [EMAIL PROTECTED] I have upgraded from v4.2.3 to v4.3.0 When compiling PHP v4.2.3 the "make install" command updates my httpd.conf file and adds: LoadModule php4_module modules/libphp4.so I have noticed that this does not happen with the latest release of 4.3.0. I have tried the laetst CVS (php4-STABLE-200301162230) and it still does this :-( I thought it was me at first, but I have tried it several times and each time the same thing happens. Please could someone check this out for the PHP community. Many thanks, Richard. -- Edit this bug report at http://bugs.php.net/?id=21698&edit=1
#14750 [NoF->Bgs]: exit signal Floating point exception (8)
ID: 14750 User updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] -Status: No Feedback +Status: Bogus Bug Type: Reproducible crash Operating System: FreeBSD 4.4-RELEASE #0 PHP Version: 4.1.1 New Comment: this bug is fixed Previous Comments: [2002-01-19 11:27:45] [EMAIL PROTECTED] Closed due to no feedback is the 'No Feedback' status. [2002-01-19 11:27:38] [EMAIL PROTECTED] Closed due to no feedback is the 'No Feedback' status. [2002-01-19 11:26:11] [EMAIL PROTECTED] No feedback. Closing. [2001-12-29 04:40:06] [EMAIL PROTECTED] No matter what I did, I can't reproduce this. Either with apache 1.3.22 mod_php nor command line version. Please try only with ./configure without any arguments. I think you're systems libs or so are broken. Did you verified you made a clean installation, nor other stale mod_php around? [2001-12-29 04:14:55] [EMAIL PROTECTED] And what about CGI (command line)? The remainder of the comments for this report are too long. To view the rest of the comments, please view the bug report online at http://bugs.php.net/14750 -- Edit this bug report at http://bugs.php.net/?id=14750&edit=1
Bug #15792 Updated: sapi_apache2.c:247
ID: 15792
Updated by: [EMAIL PROTECTED]
Reported By: [EMAIL PROTECTED]
Status: Open
Bug Type: Compile Failure
Operating System: GNU/Linux
PHP Version: 4.1.2
New Comment:
I just want to say I got this same error and I have
Mandrake 8.1.
[root@irc-server php-4.1.2]# ./configure
--with-apxs2=/www/bin/apxs --without-mysql --quiet
That's my configure line. It works without any errors.
Hope this bug is fixed soon. Thanks in advance. :)
Previous Comments:
[2002-03-11 01:47:02] [EMAIL PROTECTED]
Having the same problem with apache 2.0.32, PHP 4.1.2, Linux kernal
2.2.18, gcc 2.91.66, make 3.77, zlib 1.1.3, mysql 3.23.47, posgresql
7.2.
/etc/ld.so.cache has all the various shared libraries listed (and then
some).
Apache, zlib, mysql, postresql all load and operate fine (with limited
testing)
PHP however:
'./configure' \
'--with-zlib' \
'--with-zlib-dir=/usr/local/zlib' \
'--with-apxs2=/usr/local/apache2/bin/apxs' \
'--with-pgsql=shared,/usr/local/pgsql' \
'--with-mysql=shared,/usr/local/mysql' \
'--enable-force-cgi-redirect' \
'--enable-debug' \
configures fine.
make results in
sapi_apache2.c: In function `php_apache_sapi_register_variables':
sapi_apache2.c:148: warning: initialization discards `const' from
pointer target
type
sapi_apache2.c: In function `php_input_filter':
sapi_apache2.c:248: incompatible type for argument 4 of
`ap_get_brigade'
sapi_apache2.c:248: too few arguments to function `ap_get_brigade'
sapi_apache2.c: In function `php_register_hook':
sapi_apache2.c:409: warning: passing arg 2 of
`ap_register_input_filter' from in
compatible pointer type
make[3]: *** [sapi_apache2.lo] Error 1
make[2]: *** [all-recursive] Error 1
make[1]: *** [all-recursive] Error 1
make: *** [all-recursive] Error 1
make then ends.
The make compile line that results in this error is
make[3]: Entering directory `/usr/local/php-4.1.2/sapi/apache2filter'
/bin/sh /usr/local/php-4.1.2/libtool --mode=compile
/usr/local/php-4.1.2/meta_ccld -I.
-I/usr/local/php-4.1.2/sapi/apache2filter -I/usr/local/php-4.1.2/main
-I/usr/local/php-4.1.2 -I/usr/local/apache2/include
-I/usr/local/php-4.1.2/Zend -I/usr/local/mysql/include
-I/usr/local/php-4.1.2/ext/xml/expat -D_REENTRANT
-I/usr/local/php-4.1.2/TSRM -g -O2 -pthread -Wall -DZTS -prefer-pic -c
sapi_apache2.c
/usr/local/php-4.1.2/meta_ccld -I.
-I/usr/local/php-4.1.2/sapi/apache2filter -I/usr/local/php-4.1.2/main
-I/usr/local/php-4.1.2 -I/usr/local/apache2/include
-I/usr/local/php-4.1.2/Zend -I/usr/local/mysql/include
-I/usr/local/php-4.1.2/ext/xml/expat -D_REENTRANT
-I/usr/local/php-4.1.2/TSRM -g -O2 -pthread -Wall -DZTS -c
sapi_apache2.c -fPIC -DPIC -o sapi_apache2.lo
I've found some old notes on earlier releases of PHP 4 with Apache 2
that this bug exists and has been worked around slightly by changing a
line in
PHPROOT/sapi/apache2filter/sapi_apache2.c
from
if ((rv = ap_get_brigade(f->next, bb, mode, readbytes)) !=APR_SUCCESS)
{
return rv;
to
if ((rv = ap_get_brigade(f->next, bb, mode)) !=APR_SUCCESS) {
return rv;
I tried this with no success. Not having worked on any of this code in
the past, I am facing a daunting task trying to debug this. If anyone
has any insight, I would greatly appreciate it. Otherwise, I am going
to go back to Apache 1.3.23 and PHP 3.0.18.
Thanks in advance
Richard
http://www.haimann.com
[2002-03-09 12:30:32] [EMAIL PROTECTED]
I get the same thing exactly. I am using apache-2.0.23, and my
compiler is gcc-3.0.3. This might have a bearing.
Richard.
[2002-03-04 14:30:13] [EMAIL PROTECTED]
> What's your configure line?
./configure \
--with-apxs2=/usr/local/apache2/bin/apxs \
--without-mysql
> What version of Apache do you use?
httpd-2.0.32-beta.tar.gz
[2002-03-01 03:42:40] [EMAIL PROTECTED]
What's your configure line?
What version of Apache do you use? You should compile PHP with the
latest CVS of Apache 2, (although beta 32 may work too).
[2002-02-28 15:05:36] [EMAIL PROTECTED]
in sapi/apache2filter/sapi_apache2.c
sapi_apache2.c: In function `php_apache_sapi_register_variables':
sapi_apache2.c:148: warning: initialization discards qualifiers from
pointer target type
sapi_apache2.c: In function `php_input_filter':
sapi_apache2.c:247: incompatible type for argument 4 of
`ap_get_brigade'
sapi_apache2.c:247: too few arguments to function `ap_get_brigade'
sap
Bug #16229: PHP Complie with APXS2
From: [EMAIL PROTECTED] Operating system: Mandrake 8.1 PHP version: 4.1.2 PHP Bug Type: Compile Failure Bug description: PHP Complie with APXS2 !!! NOTICE: This is for 4.2.0RC1 !! ./configure works fine. During make: var_unserializer.c: In function `php_var_unserialize': var_unserializer.c:300: warning: comparison is always false due to limited range of data type and the other error: Making all in sapi make[1]: Entering directory `/root/php-4.2.0RC1/sapi' Making all in apache2filter make[2]: Entering directory `/root/php-4.2.0RC1/sapi/apache2filter' make[3]: Entering directory `/root/php-4.2.0RC1/sapi/apache2filter' /bin/sh /root/php-4.2.0RC1/libtool --silent --mode=compile gcc -I. -I/root/php-4.2.0RC1/sapi/apache2filter -I/root/php-4.2.0RC1/main -I/root/php-4.2.0RC1 -I/www/include -I/root/php-4.2.0RC1/Zend -I/root/php-4.2.0RC1/ext/xml/expat -D_REENTRANT -I/root/php-4.2.0RC1/TSRM -g -O2 -pthread -DZTS -prefer-pic -c sapi_apache2.c sapi_apache2.c: In function `php_register_hook': sapi_apache2.c:473: `AP_FTYPE_RESOURCE' undeclared (first use in this function) sapi_apache2.c:473: (Each undeclared identifier is reported only once sapi_apache2.c:473: for each function it appears in.) make[3]: *** [sapi_apache2.lo] Error 1 make[3]: Leaving directory `/root/php-4.2.0RC1/sapi/apache2filter' make[2]: *** [all-recursive] Error 1 make[2]: Leaving directory `/root/php-4.2.0RC1/sapi/apache2filter' make[1]: *** [all-recursive] Error 1 make[1]: Leaving directory `/root/php-4.2.0RC1/sapi' make: *** [all-recursive] Error 1 -- Edit bug report at http://bugs.php.net/?id=16229&edit=1 -- Fixed in CVS:http://bugs.php.net/fix.php?id=16229&r=fixedcvs Fixed in release:http://bugs.php.net/fix.php?id=16229&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=16229&r=needtrace Try newer version: http://bugs.php.net/fix.php?id=16229&r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=16229&r=support Expected behavior: http://bugs.php.net/fix.php?id=16229&r=notwrong Not enough info: http://bugs.php.net/fix.php?id=16229&r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=16229&r=submittedtwice
Bug #16229 Updated: PHP Complie with APXS2
ID: 16229 Updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] Status: Open Bug Type: Compile Failure Operating System: Mandrake 8.1 -PHP Version: 4.1.2 +PHP Version: 4.2.0RC1 New Comment: Changed the Version Number Previous Comments: [2002-03-23 04:59:20] [EMAIL PROTECTED] !!! NOTICE: This is for 4.2.0RC1 !! ./configure works fine. During make: var_unserializer.c: In function `php_var_unserialize': var_unserializer.c:300: warning: comparison is always false due to limited range of data type and the other error: Making all in sapi make[1]: Entering directory `/root/php-4.2.0RC1/sapi' Making all in apache2filter make[2]: Entering directory `/root/php-4.2.0RC1/sapi/apache2filter' make[3]: Entering directory `/root/php-4.2.0RC1/sapi/apache2filter' /bin/sh /root/php-4.2.0RC1/libtool --silent --mode=compile gcc -I. -I/root/php-4.2.0RC1/sapi/apache2filter -I/root/php-4.2.0RC1/main -I/root/php-4.2.0RC1 -I/www/include -I/root/php-4.2.0RC1/Zend -I/root/php-4.2.0RC1/ext/xml/expat -D_REENTRANT -I/root/php-4.2.0RC1/TSRM -g -O2 -pthread -DZTS -prefer-pic -c sapi_apache2.c sapi_apache2.c: In function `php_register_hook': sapi_apache2.c:473: `AP_FTYPE_RESOURCE' undeclared (first use in this function) sapi_apache2.c:473: (Each undeclared identifier is reported only once sapi_apache2.c:473: for each function it appears in.) make[3]: *** [sapi_apache2.lo] Error 1 make[3]: Leaving directory `/root/php-4.2.0RC1/sapi/apache2filter' make[2]: *** [all-recursive] Error 1 make[2]: Leaving directory `/root/php-4.2.0RC1/sapi/apache2filter' make[1]: *** [all-recursive] Error 1 make[1]: Leaving directory `/root/php-4.2.0RC1/sapi' make: *** [all-recursive] Error 1 -- Edit this bug report at http://bugs.php.net/?id=16229&edit=1
Bug #16229 Updated: PHP Complie with APXS2
ID: 16229 Updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] -Status: Feedback +Status: Open Bug Type: Compile Failure Operating System: Mandrake 8.1 PHP Version: 4.2.0RC1 New Comment: No prob. Version: Apache 2.0.32 - this is not the latest CVS Downloaded file: http://www.apache.org/dist/httpd/httpd-2.0.32-beta.tar.gz Configure lines: ./configure --quiet --prefix=/www Errors: None. Works just fine. I tired the lasest CVS (snapshot) about 2 days ago. I will try again, but I doubt it's the problem. PHP Configure Lines: ./configure --quiet --with-mysql=no --with-apxs2=/www/bin/apxs "make" fails -- see above for errors. "make install" -- never created because of errors above Previous Comments: [2002-03-23 06:54:25] [EMAIL PROTECTED] What are your configure lines? (both of Apache and PHP) Which version of Apache are you using? Can you try upgrading Apache to 2.0.32 or the latest CVS? [2002-03-23 04:59:59] [EMAIL PROTECTED] Changed the Version Number [2002-03-23 04:59:20] [EMAIL PROTECTED] !!! NOTICE: This is for 4.2.0RC1 !! ./configure works fine. During make: var_unserializer.c: In function `php_var_unserialize': var_unserializer.c:300: warning: comparison is always false due to limited range of data type and the other error: Making all in sapi make[1]: Entering directory `/root/php-4.2.0RC1/sapi' Making all in apache2filter make[2]: Entering directory `/root/php-4.2.0RC1/sapi/apache2filter' make[3]: Entering directory `/root/php-4.2.0RC1/sapi/apache2filter' /bin/sh /root/php-4.2.0RC1/libtool --silent --mode=compile gcc -I. -I/root/php-4.2.0RC1/sapi/apache2filter -I/root/php-4.2.0RC1/main -I/root/php-4.2.0RC1 -I/www/include -I/root/php-4.2.0RC1/Zend -I/root/php-4.2.0RC1/ext/xml/expat -D_REENTRANT -I/root/php-4.2.0RC1/TSRM -g -O2 -pthread -DZTS -prefer-pic -c sapi_apache2.c sapi_apache2.c: In function `php_register_hook': sapi_apache2.c:473: `AP_FTYPE_RESOURCE' undeclared (first use in this function) sapi_apache2.c:473: (Each undeclared identifier is reported only once sapi_apache2.c:473: for each function it appears in.) make[3]: *** [sapi_apache2.lo] Error 1 make[3]: Leaving directory `/root/php-4.2.0RC1/sapi/apache2filter' make[2]: *** [all-recursive] Error 1 make[2]: Leaving directory `/root/php-4.2.0RC1/sapi/apache2filter' make[1]: *** [all-recursive] Error 1 make[1]: Leaving directory `/root/php-4.2.0RC1/sapi' make: *** [all-recursive] Error 1 -- Edit this bug report at http://bugs.php.net/?id=16229&edit=1
#21063 [Fbk->NoF]: unable to load php with -imap and imap-ssl
ID: 21063 Updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] -Status: Feedback +Status: No Feedback Bug Type: Apache2 related Operating System: Slackware 8.1 PHP Version: 4.2.3 New Comment: No feedback was provided for this bug for over 2 weeks, so it is being suspended automatically. If you are able to provide the information that was originally requested, please do so and change the status of the bug back to "Open". Previous Comments: [2002-12-22 00:57:38] [EMAIL PROTECTED] Please try using this CVS snapshot: http://snaps.php.net/php4-latest.tar.gz For Windows: http://snaps.php.net/win32/php4-win32-latest.zip [2002-12-17 05:47:20] [EMAIL PROTECTED] apache 2.0.43 php 4.2.3 wu imap 2002.332 openssl 0.9.6h ./configure --with-apxs2=/usr/local/apache2/bin/apxs --with-mysql=/usr/local/mysql --with-imap=/root/install/imap-2002 --with-imap-ssl=/usr/local/ssl compiles without any error when trying to use new module : Cannot load /usr/local/apache2/modules/libphp4.so into server: /usr/local/apache2/modules/libphp4.so: undefined symbol: RAND_seed configuring with imap but without imap-ssl works fine, apache loads module without complaints 4.3.0RC3 fails on configure : checking whether SSL libraries are needed for c-client... /usr/local/ssl/lib checking whether IMAP works... no configure: error: build test failed. Please check the config.log for details. root@r:~/install/php-4.3.0RC3# tail -n 92 config.log configure:35246: checking whether SSL libraries are needed for c-client configure:35407: checking whether IMAP works configure:35440: gcc -o conftest -g -O2 -Wl,-rpath,/root/install/imap-2002/c-client -L/root/install/imap-2002/c-client -Wl,-rpath,/usr/local/ssl/lib -L/usr/local/ssl/lib conftest.c -lcrypto -lssl -lc-client -lcrypt -lcrypt -lresolv -lm -ldl -lnsl -lcrypt 1>&5 /root/install/imap-2002/c-client/libc-client.a(osdep.o): In function `ssl_onceonlyinit': /root/install/imap-2002/c-client/osdep.c:268: the use of `tmpnam' is dangerous, better use `mkstemp' /root/install/imap-2002/c-client/osdep.c:281: undefined reference to `RAND_seed' /root/install/imap-2002/c-client/osdep.c:286: undefined reference to `SSL_library_init' /root/install/imap-2002/c-client/libc-client.a(osdep.o): In function `ssl_start_work': /root/install/imap-2002/c-client/osdep.c:388: undefined reference to `TLSv1_client_method' /root/install/imap-2002/c-client/osdep.c:388: undefined reference to `SSLv23_client_method' /root/install/imap-2002/c-client/osdep.c:388: undefined reference to `SSL_CTX_new' /root/install/imap-2002/c-client/osdep.c:391: undefined reference to `SSL_CTX_ctrl' /root/install/imap-2002/c-client/osdep.c:395: undefined reference to `SSL_CTX_set_verify' /root/install/imap-2002/c-client/osdep.c:397: undefined reference to `SSL_CTX_set_default_verify_paths' /root/install/imap-2002/c-client/osdep.c:398: undefined reference to `SSL_new' /root/install/imap-2002/c-client/osdep.c:400: undefined reference to `BIO_new_socket' /root/install/imap-2002/c-client/osdep.c:401: undefined reference to `SSL_set_bio' /root/install/imap-2002/c-client/osdep.c:402: undefined reference to `SSL_set_connect_state' /root/install/imap-2002/c-client/osdep.c:404: undefined reference to `SSL_state' /root/install/imap-2002/c-client/osdep.c:404: undefined reference to `SSL_ctrl' /root/install/imap-2002/c-client/osdep.c:405: undefined reference to `SSL_write' /root/install/imap-2002/c-client/osdep.c:410: undefined reference to `SSL_get_peer_certificate' /root/install/imap-2002/c-client/libc-client.a(osdep.o): In function `ssl_getdata': /root/install/imap-2002/c-client/osdep.c:577: undefined reference to `SSL_get_fd' /root/install/imap-2002/c-client/osdep.c:580: undefined reference to `SSL_pending' /root/install/imap-2002/c-client/osdep.c:604: undefined reference to `SSL_read' /root/install/imap-2002/c-client/osdep.c:604: undefined reference to `SSL_get_error' /root/install/imap-2002/c-client/libc-client.a(osdep.o): In function `ssl_server_init': /root/install/imap-2002/c-client/osdep.c:760: undefined reference to `ERR_load_crypto_strings' /root/install/imap-2002/c-client/osdep.c:762: undefined reference to `SSL_load_error_strings' /root/install/imap-2002/c-client/osdep.c:769: undefined reference to `TLSv1_server_method' /root/install/imap-2002/c-client/osdep.c:769: undefined reference to `SSLv23_server_method' /root/install/imap-2002/c-client/osdep.c:769: undefined reference to `SSL_CTX_new' /root/install/imap-2002/c-client/osdep.c:774: undefined reference to `SSL_CTX_ctrl' /root/install/imap-2002/c-client/osdep.c:771: undefined reference to `SSL_CTX_set_cipher_list' /root/install/imap-2002/c-client/osdep.c:771: undefined reference to `SSL_CTX_use_cert
#21162 [Fbk->NoF]: Can't get date from INFORMIX VIEW
ID: 21162
Updated by: [EMAIL PROTECTED]
Reported By: [EMAIL PROTECTED]
-Status: Feedback
+Status: No Feedback
Bug Type: Informix related
Operating System: AIX4.3.3
PHP Version: 4.2.3
New Comment:
No feedback was provided for this bug for over 2 weeks, so it is
being suspended automatically. If you are able to provide the
information that was originally requested, please do so and change
the status of the bug back to "Open".
Previous Comments:
[2002-12-23 10:43:49] [EMAIL PROTECTED]
Please try using this CVS snapshot:
http://snaps.php.net/php4-latest.tar.gz
For Windows:
http://snaps.php.net/win32/php4-win32-latest.zip
[2002-12-23 05:04:31] [EMAIL PROTECTED]
I'm trying to get date from VIEW using ifx_query or ifx_prepare
(ifx_do). Every time those functions return me result_id=0
...
$q_zlec="SELECT * FROM v_zlec";
$rez_zlec=ifx_query($q_zlec,$conn_id);
printf("Rez:%d", $rez_zlec); <== always 0
Przemek
--
Edit this bug report at http://bugs.php.net/?id=21162&edit=1
#21102 [Fbk->NoF]: stat, lstat fail if filesize larger than 2 GB
ID: 21102 Updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] -Status: Feedback +Status: No Feedback Bug Type: *Directory/Filesystem functions Operating System: solaris PHP Version: 4.2.3 New Comment: No feedback was provided for this bug for over 2 weeks, so it is being suspended automatically. If you are able to provide the information that was originally requested, please do so and change the status of the bug back to "Open". Previous Comments: [2002-12-22 00:55:50] [EMAIL PROTECTED] Please try using this CVS snapshot: http://snaps.php.net/php4-latest.tar.gz For Windows: http://snaps.php.net/win32/php4-win32-latest.zip [2002-12-19 18:52:37] [EMAIL PROTECTED] ~ if the file /tmp/very_large_file is larger than 2 GB, php reports the error: Warning: stat failed for /tmp/very_large_file (errno=79 - Value too large for defined data type) php_4.2.3 is compiled as an apache_1.3.27 module -- Edit this bug report at http://bugs.php.net/?id=21102&edit=1
#21127 [Fbk->NoF]: CSRSS.exe 100%
ID: 21127 Updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] -Status: Feedback +Status: No Feedback Bug Type: Performance problem Operating System: Windows XP PHP Version: 4.3.0RC3 New Comment: No feedback was provided for this bug for over 2 weeks, so it is being suspended automatically. If you are able to provide the information that was originally requested, please do so and change the status of the bug back to "Open". Previous Comments: [2002-12-28 13:31:54] [EMAIL PROTECTED] Please try using this CVS snapshot: http://snaps.php.net/php4-latest.tar.gz For Windows: http://snaps.php.net/win32/php4-win32-latest.zip [2002-12-20 22:17:54] [EMAIL PROTECTED] Whenever someone uploads to my FTP server, I use PHP to execute my scripts. Now, although I haven't pinpointed the problem yet, it seems like PHP is causing CSRSS.exe (Windows' client/server runtime server subsystem), a system process, to jump up to 100% CPU usage. I'll try looking into the problem in more detail, but I just thought I'd post this up for now. -- Edit this bug report at http://bugs.php.net/?id=21127&edit=1
#21206 [Fbk->NoF]: nesting level and recursive errors on make test... php fails
ID: 21206 Updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] -Status: Feedback +Status: No Feedback Bug Type: Compile Failure Operating System: RH Linux 7.2 PHP Version: 4.3.0RC4 New Comment: No feedback was provided for this bug for over 2 weeks, so it is being suspended automatically. If you are able to provide the information that was originally requested, please do so and change the status of the bug back to "Open". Previous Comments: [2002-12-28 01:24:16] [EMAIL PROTECTED] The failed test was incorrect and is no longer present in 4.3.0. The other problem maybe due to the fact that your php.ini directives tell php to load shared extensions that are now either compiled into PHP core or were compiled for previous versions. This could resolve in all kinds of erroneous behaviour. Check your php.ini for the extensions you load dynamically and try to determine which one (or more) is reponsible. [2002-12-28 01:21:40] [EMAIL PROTECTED] I've also experienced this problem with the release version of PHP 4.3.0 on Redhat 7.2 My configure string is as follows './configure' 'i386-redhat-linux' '--prefix=/usr' '--exec-prefix=/usr' '--bindir=/usr/bin' '--sbindir=/usr/sbin' '--sysconfdir=/etc' '--datadir=/usr/share' '--includedir=/usr/include' '--libdir=/usr/lib' '--libexecdir=/usr/libexec' '--localstatedir=/var' '--sharedstatedir=/usr/com' '--mandir=/usr/share/man' '--infodir=/usr/share/info' '--prefix=/usr' '--with-config-file-path=/etc' '--enable-force-cgi-redirect' '--disable-debug' '--enable-pic' '--disable-rpath' '--enable-inline-optimization' '--with-bz2' '--with-db3' '--with-curl' '--with-dom=/usr' '--with-exec-dir=/usr/bin' '--with-freetype-dir=/usr' '--with-png-dir=/usr' '--with-gd' '--enable-gd-native-ttf' '--with-ttf' '--with-gdbm' '--with-gettext=shared' '--with-ncurses' '--with-gmp' '--with-iconv-dir=/usr' '--with-jpeg-dir=/usr' '--with-openssl' '--with-pear' '--with-png' '--with-pspell-dir=/usr' '--with-regex=system' '--with-xml' '--with-expat-dir=/usr' '--with-zlib' '--with-layout=GNU' '--enable-bcmath' '--enable-debugger' '--enable-exif' '--enable-ftp=shared' '--enable-magic-quotes' '--enable-sockets' '--enable-sysvsem=shared' '--enable-sysvshm=shared' '--enable-discard-path' '--enable-track-vars' '--enable-trans-sid' '--enable-yp' '--enable-wddx' '--without-oci8' '--with-imap=shared' '--with-imap-ssl' '--with-kerberos=/usr/kerberos' '--with-ldap=shared' '--with-mysql=/usr' '--with-pgsql=shared' '--with-snmp=shared,/usr' '--with-snmp=shared' '--enable-ucd-snmp-hack' '--with-unixODBC=shared' '--enable-memory-limit' '--enable-bcmath' '--enable-shmop' '--enable-versioning' '--enable-calendar' '--enable-dbx' '--enable-dio' '--enable-mcal' '--enable-mbstring' '--enable-mbstr-enc-trans' '--disable-experimental-zts' '--with-apxs=/usr/sbin/apxs' [2002-12-26 19:54:03] [EMAIL PROTECTED] Well I have also tried using 4.4.0-dev and same issue. Now if I delete or move my original php.ini file and run I get one error still and it causes the same problem. If I install it any site using php fails. The error i get using make test if I delete the php.ini file is = FAILED TEST SUMMARY - Bug #20993 (referenced array key, makes array global) [tests/lang/bug20993.phpt] = [2002-12-26 17:31:57] [EMAIL PROTECTED] Warning: Nesting level too deep - recursive dependency? in Unknown on line 0 That error shows several times during the make test part of the install. During the install the ./configure... and make does ok with no errors. Then doing a make test fails on almost every test it performs. If I continue to do a make install afterwards it breaks the server down so that most to all sites using php do not work. I have verified this with the latest stable release, 4.3.0-dev, 4.3.0RC2, 4.3.0RC3, and now 4.3.0RC4. Right now I am running 4.2.4-dev and is working fine. I have also tried a few different configure commands to hopefully resolve this issue but with no luck. Current configure... './configure' 'i386-redhat-linux' '--prefix=/usr' '--exec-prefix=/usr' '--bindir=/usr/bin' '--sbindir=/usr/sbin' '--sysconfdir=/etc' '--datadir=/usr/share' '--includedir=/usr/include' '--libdir=/usr/lib' '--libexecdir=/usr/libexec' '--localstatedir=/var' '--sharedstatedir=/usr/com' '--mandir=/usr/share/man' '--infodir=/usr/share/info' '--prefix=/usr' '--with-config-file-path=/etc' '--enable-force-cgi-redirect' '--disable-debug' '--enable-pic' '--disa
#21231 [Fbk->NoF]: ./configure fails on cURL check
ID: 21231 Updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] -Status: Feedback +Status: No Feedback Bug Type: Compile Failure Operating System: Linux - Red Hat 7.3 PHP Version: 4.3.0 New Comment: No feedback was provided for this bug for over 2 weeks, so it is being suspended automatically. If you are able to provide the information that was originally requested, please do so and change the status of the bug back to "Open". Previous Comments: [2002-12-28 05:19:20] [EMAIL PROTECTED] Check also config.log which may have some information on why the check failed... Derick [2002-12-28 01:14:53] [EMAIL PROTECTED] I have no trouble compiling PHP 4.3 against curl 7.10.2, it is possible that curl library is not in the path or the path you've specified is incorrect. Try putting the output of 'curl-config --prefix' as the value for --with-curl. Ex: --with-curl=`curl-config --prefix [2002-12-27 22:17:57] [EMAIL PROTECTED] Successfully obtained the PHP 4.3.0 release from anonymous CVS. ./buildconf ran successfully, however, ./configure fails with the following error: "checking for cURL 7.9.8 or greater... configure: error: cURL version 7.9.8 or later is required to compile php with cURL support" I updated cURL with the latest version (7.10.2) as evidenced by: "[root@server php4]# curl -V curl 7.10.2 (i686-pc-linux-gnu) libcurl/7.10.2 OpenSSL/0.9.6b zlib/1.1.3" however, I still get the error when attempting to run ./configure. -- Edit this bug report at http://bugs.php.net/?id=21231&edit=1
#21293 [Fbk->NoF]: imap_fetchstructure incomplet return
ID: 21293 Updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] -Status: Feedback +Status: No Feedback Bug Type: Feature/Change Request Operating System: Debian GNU/Linux Sid PHP Version: 4.2.3 New Comment: No feedback was provided for this bug for over 2 weeks, so it is being suspended automatically. If you are able to provide the information that was originally requested, please do so and change the status of the bug back to "Open". Previous Comments: [2002-12-30 11:50:38] [EMAIL PROTECTED] Please try using this CVS snapshot: http://snaps.php.net/php4-latest.tar.gz For Windows: http://snaps.php.net/win32/php4-win32-latest.zip [2002-12-30 11:09:40] [EMAIL PROTECTED] I using a Debian packages. I update php4 and php4-imap an 'imap_fetchstructure' no return all part in messaje. libc6 2.3.1-8 php4 4.2.3-8 php4-dbase 4.2.1-1 php4-dev 4.2.3-8 php4-domxml4.2.1-3 php4-gd2 4.2.1-2 php4-imap 4.2.3-8 php4-mysql 4.2.1-3 php4-pear 4.1.2-4 php4-pgsql 4.2.1-2 -- Edit this bug report at http://bugs.php.net/?id=21293&edit=1
#21667 [NEW]: Compilation error in sapi_module_struct
From: [EMAIL PROTECTED] Operating system: Solaris8 PHP version: 4CVS-2003-01-15 (stable) PHP Bug Type: Compile Failure Bug description: Compilation error in sapi_module_struct I have got error in compilation: Environment is: PHP Version (Updated at 2003/01/15 18:20 GMT+2) >cat CVS/Tag TPHP_4_3 Compillator: Sun WorkShop 6 update 2 C 5.3 2001/05/15 Error if independed of configure string. Error in compilation of Apache2Filer is: /bin/bash libtool --silent --mode=compile /opt/SUNWspro/bin/cc -Xa -xF -xCC -Isapi/apache2filter/ -I/usr/local/src/work/php4/sapi/apache2filter/ -DPHP_ATOM_INC -I/usr/local/src/work/php4/include -I/usr/local/src/work/php4/main -I/usr/local/src/work/php4 -I/usr/local/include/apache2 -I/usr/local/src/work/php4/Zend -I/usr/local/include -I/usr/local/include/freetype2 -I/usr/local/include/mysql -I/usr/local/src/work/php4/ext/xml/expat -D_POSIX_PTHREAD_SEMANTICS -D_REENTRANT -DAPACHE_XLATE -D_POSIX_PTHREAD_SEMANTICS -D_REENTRANT -I/usr/local/src/work/php4/TSRM -xtarget=ultra -xarch=v8plus -xO5 -xstrconst -xdepend -Xa -xildoff -dalign -D_REENTRANT -xspace -mr -mt -DZTS -prefer-pic -c /usr/local/src/work/php4/sapi/apache2filter/sapi_apache2.c -o sapi/apache2filter/sapi_apache2.lo "/usr/local/src/work/php4/sapi/apache2filter/sapi_apache2.c", line 318: too many struct/union initializers "/usr/local/src/work/php4/sapi/apache2filter/sapi_apache2.c", line 319: too many struct/union initializers cc: acomp failed for /usr/local/src/work/php4/sapi/apache2filter/sapi_apache2.c *** Error code 1 Same error for CLI version: /bin/bash libtool --silent --mode=compile /opt/SUNWspro/bin/cc -Xa -xF -xCC -Isapi/cli/ -I/usr/local/src/work/php4/sapi/cli/ -DPHP_ATOM_INC -I/usr/local/src/work/php4/include -I/usr/local/src/work/php4/main -I/usr/local/src/work/php4 -I/usr/local/include/apache2 -I/usr/local/src/work/php4/Zend -I/usr/local/include -I/usr/local/include/freetype2 -I/usr/local/include/mysql -I/usr/local/src/work/php4/ext/xml/expat -D_POSIX_PTHREAD_SEMANTICS -D_REENTRANT -DAPACHE_XLATE -D_POSIX_PTHREAD_SEMANTICS -D_REENTRANT -I/usr/local/src/work/php4/TSRM -xtarget=ultra -xarch=v8plus -xO5 -xstrconst -xdepend -Xa -xildoff -dalign -D_REENTRANT -xspace -mr -mt -DZTS -prefer-pic -c /usr/local/src/work/php4/sapi/cli/php_cli.c -o sapi/cli/php_cli.lo "/usr/local/src/work/php4/sapi/cli/php_cli.c", line 284: too many struct/union initializers cc: acomp failed for /usr/local/src/work/php4/sapi/cli/php_cli.c *** Error code 1 make: Fatal error: Command failed for target `sapi/cli/php_cli.lo' Reason: Wrong count of 'NULL' in sapi_module_struct, defined in modules (sapi/apache2filter/sapi_apache2.c and sapi/cli/php_cli.c) and STANDARD_SAPI_MODULE_PROPERTIES definition (defined in main/SAPI.h). Sollution: >cvs diff "sapi/apache2filter/sapi_apache2.c" sapi/cli/php_cli.c Index: sapi/apache2filter/sapi_apache2.c === RCS file: /repository/php4/sapi/apache2filter/sapi_apache2.c,v retrieving revision 1.91.2.4 diff -u -r1.91.2.4 sapi_apache2.c --- sapi/apache2filter/sapi_apache2.c 7 Jan 2003 15:23:45 - 1.91.2.4 +++ sapi/apache2filter/sapi_apache2.c 15 Jan 2003 17:38:10 - @@ -312,8 +312,8 @@ NULL, /* php_ini_path_override */ - NULL, /* Block interruptions */ - NULL, /* Unblock interruptions */ + // NULL, /* Block interruptions */+ // NULL, /* Unblock interruptions */ STANDARD_SAPI_MODULE_PROPERTIES }; Index: sapi/cli/php_cli.c === RCS file: /repository/php4/sapi/cli/php_cli.c,v retrieving revision 1.51.2.6 diff -u -r1.51.2.6 php_cli.c --- sapi/cli/php_cli.c 8 Jan 2003 00:44:58 - 1.51.2.6 +++ sapi/cli/php_cli.c 15 Jan 2003 17:38:10 - @@ -277,8 +277,8 @@ sapi_cli_register_variables,/* register server variables */ sapi_cli_log_message, /* Log message */ - NULL, /* Block interruptions */ - NULL, /* Unblock interruptions */ + // NULL,/* Block interruptions */ + // NULL,/* Unblock interruptions */ STANDARD_SAPI_MODULE_PROPERTIES }; WBR, Alex -- Edit bug report at http://bugs.php.net/?id=21667&edit=1 -- Try a CVS snapshot: http://bugs.php.net/fix.php?id=21667&r=trysnapshot Fixed in CVS:
#21667 [Com]: Compilation error in sapi_module_struct
ID: 21667 Comment by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] Status: Feedback Bug Type: Compile Failure Operating System: Solaris8 PHP Version: 4CVS-2003-01-15 (stable) New Comment: CVS tree is up ./buildconf execute cvsclean on my system. Manual calculation: Structure _sapi_module_struct in main/SAPI.h (from http://cvs.php.net/co.php/php4/main/SAPI.h?r=1.87.2.3) has 27 items. Definition STANDARD_SAPI_MODULE_PROPERTIES in main/SAPI.h has 8 items. Stricture apache2_sapi_module in sapi/apache2filter/sapi_apache2.c ( http://cvs.php.net/co.php/php4/sapi/apache2filter/sapi_apache2.c?r=1.91.2.4) has 21 items + STANDARD_SAPI_MODULE_PROPERTIES. 21 + 8 = 29 and not eq 27... http://cvs.php.net/diff.php/php4/main/SAPI.h?r1=1.87.2.2&r2=1.87.2.3&ty=u Previous Comments: [2003-01-15 11:50:50] [EMAIL PROTECTED] Did you use an updated CVS tree or an fresh one? If the first, then please run ./cvsclean && ./buildconf or checkout a fresh tree. Derick [2003-01-15 11:42:32] [EMAIL PROTECTED] I have got error in compilation: Environment is: PHP Version (Updated at 2003/01/15 18:20 GMT+2) >cat CVS/Tag TPHP_4_3 Compillator: Sun WorkShop 6 update 2 C 5.3 2001/05/15 Error if independed of configure string. Error in compilation of Apache2Filer is: /bin/bash libtool --silent --mode=compile /opt/SUNWspro/bin/cc -Xa -xF -xCC -Isapi/apache2filter/ -I/usr/local/src/work/php4/sapi/apache2filter/ -DPHP_ATOM_INC -I/usr/local/src/work/php4/include -I/usr/local/src/work/php4/main -I/usr/local/src/work/php4 -I/usr/local/include/apache2 -I/usr/local/src/work/php4/Zend -I/usr/local/include -I/usr/local/include/freetype2 -I/usr/local/include/mysql -I/usr/local/src/work/php4/ext/xml/expat -D_POSIX_PTHREAD_SEMANTICS -D_REENTRANT -DAPACHE_XLATE -D_POSIX_PTHREAD_SEMANTICS -D_REENTRANT -I/usr/local/src/work/php4/TSRM -xtarget=ultra -xarch=v8plus -xO5 -xstrconst -xdepend -Xa -xildoff -dalign -D_REENTRANT -xspace -mr -mt -DZTS -prefer-pic -c /usr/local/src/work/php4/sapi/apache2filter/sapi_apache2.c -o sapi/apache2filter/sapi_apache2.lo "/usr/local/src/work/php4/sapi/apache2filter/sapi_apache2.c", line 318: too many struct/union initializers "/usr/local/src/work/php4/sapi/apache2filter/sapi_apache2.c", line 319: too many struct/union initializers cc: acomp failed for /usr/local/src/work/php4/sapi/apache2filter/sapi_apache2.c *** Error code 1 Same error for CLI version: /bin/bash libtool --silent --mode=compile /opt/SUNWspro/bin/cc -Xa -xF -xCC -Isapi/cli/ -I/usr/local/src/work/php4/sapi/cli/ -DPHP_ATOM_INC -I/usr/local/src/work/php4/include -I/usr/local/src/work/php4/main -I/usr/local/src/work/php4 -I/usr/local/include/apache2 -I/usr/local/src/work/php4/Zend -I/usr/local/include -I/usr/local/include/freetype2 -I/usr/local/include/mysql -I/usr/local/src/work/php4/ext/xml/expat -D_POSIX_PTHREAD_SEMANTICS -D_REENTRANT -DAPACHE_XLATE -D_POSIX_PTHREAD_SEMANTICS -D_REENTRANT -I/usr/local/src/work/php4/TSRM -xtarget=ultra -xarch=v8plus -xO5 -xstrconst -xdepend -Xa -xildoff -dalign -D_REENTRANT -xspace -mr -mt -DZTS -prefer-pic -c /usr/local/src/work/php4/sapi/cli/php_cli.c -o sapi/cli/php_cli.lo "/usr/local/src/work/php4/sapi/cli/php_cli.c", line 284: too many struct/union initializers cc: acomp failed for /usr/local/src/work/php4/sapi/cli/php_cli.c *** Error code 1 make: Fatal error: Command failed for target `sapi/cli/php_cli.lo' Reason: Wrong count of 'NULL' in sapi_module_struct, defined in modules (sapi/apache2filter/sapi_apache2.c and sapi/cli/php_cli.c) and STANDARD_SAPI_MODULE_PROPERTIES definition (defined in main/SAPI.h). Sollution: >cvs diff "sapi/apache2filter/sapi_apache2.c" sapi/cli/php_cli.c Index: sapi/apache2filter/sapi_apache2.c === RCS file: /repository/php4/sapi/apache2filter/sapi_apache2.c,v retrieving revision 1.91.2.4 diff -u -r1.91.2.4 sapi_apache2.c --- sapi/apache2filter/sapi_apache2.c 7 Jan 2003 15:23:45 - 1.91.2.4 +++ sapi/apache2filter/sapi_apache2.c 15 Jan 2003 17:38:10 - @@ -312,8 +312,8 @@ NULL, /* php_ini_path_override */ - NULL, /* Block interruptions */ - NULL, /* Unblock interruptions */ + // NULL, /* Block interruptions */+ // NULL, /* Unblock interruptions */ STANDARD_SAPI_MODULE_PROPERTIES }; Index: sapi/cli/php_cli.c ==
#19634 [Fbk->NoF]: Mapping of .html and .htm files fails
ID: 19634 Updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] -Status: Feedback +Status: No Feedback Bug Type: IIS related Operating System: Windows 2k SP3 PHP Version: 4.2.3 New Comment: No feedback was provided for this bug for over 2 weeks, so it is being suspended automatically. If you are able to provide the information that was originally requested, please do so and change the status of the bug back to "Open". Previous Comments: [2002-12-31 04:25:37] [EMAIL PROTECTED] Please try PHP 4.3.0. [2002-12-01 11:40:14] [EMAIL PROTECTED] Mapping .html to ASP works so i'm assuming it's a problem with PHP and IIS [2002-11-30 20:53:05] [EMAIL PROTECTED] Is this an IIS problem or a PHP problem? [2002-09-27 07:41:44] [EMAIL PROTECTED] "It is a virtual directory that the file extensions are being mapped to" should read "Website" not virtual directory, that the file extension is being mapped to (rather than it being global accross all websites) [2002-09-27 07:40:06] [EMAIL PROTECTED] This is with IIS 5 on windows 2000. It is a virtual directory that the file extensions are being mapped to. The setup version of PHP was the setup.exe file. For this website I went to the properties->home directory->configuration->app mappings and added a new .html mapping to php.exe in my php directory. Php is installed at c:\php In my php.ini file i have aside from the default settings: cgi.force_redirect = 0 extension_dir = C:/PHP/extensions display_errors = Off error_log = syslog extension=php_mssql.dll 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/19634 -- Edit this bug report at http://bugs.php.net/?id=19634&edit=1
#21047 [Fbk->NoF]: Query to float fields don't return the decimal part
ID: 21047
Updated by: [EMAIL PROTECTED]
Reported By: [EMAIL PROTECTED]
-Status: Feedback
+Status: No Feedback
Bug Type: Sybase-ct (ctlib) related
Operating System: Linux RedHat8.0
PHP Version: 4CVS-2002-12-16 (stable)
New Comment:
No feedback was provided for this bug for over 2 weeks, so it is
being suspended automatically. If you are able to provide the
information that was originally requested, please do so and change
the status of the bug back to "Open".
Previous Comments:
[2002-12-31 02:23:51] [EMAIL PROTECTED]
Cool! The best way would be to supply a patch which you can make with:
diff -u original_file.c new_file.c > /tmp/file.c.patch
and send put it online somewhere.
Thanks!
Derick
[2002-12-30 23:59:19] [EMAIL PROTECTED]
I've fixed this error by changing the source but how do I post the fix
to the site for inclusion in a future build?
Please assist?
David Hargreave
IT Manager
SportOdds Systems Pty Limited
www.sportodds.com
[2002-12-16 11:05:37] [EMAIL PROTECTED]
Hi PHP people, first as all thank's for a great software, well I'm
testing the new php-4.3.0 in my Redhat 8.0 box, httpd-2.0.40-13,
phpCVS-2002-12-16(stable), I built rpms of this versión using sybase-ct
with freetds-0.60, I had in the past the same freetds but with
php-4.2.4-dev and everyhing works ok, but now when I query float fields
of a Microsoft sql server dont't return the decimal part of my float
numbers and this is very important to me, I get just the integer part.
Here it goes my configuration...
'./configure' '--host=i686-pc-linux-gnu' '--build=i686-pc-linux-gnu'
'--target=i686-redhat-linux-gnu' '--program-prefix=' '--prefix=/usr'
'--exec-prefix=/usr' '--bindir=/usr/bin' '--sbindir=/usr/sbin'
'--sysconfdir=/etc' '--datadir=/usr/share' '--includedir=/usr/include'
'--libdir=/usr/lib' '--libexecdir=/usr/libexec' '--localstatedir=/var'
'--sharedstatedir=/usr/com' '--mandir=/usr/share/man'
'--infodir=/usr/share/info' '--prefix=/usr'
'--with-config-file-path=/etc' '--enable-force-cgi-redirect'
'--disable-debug' '--enable-pic' '--disable-rpath'
'--enable-inline-optimization' '--with-bz2' '--with-db3' '--with-curl'
'--with-dom=/usr' '--with-exec-dir=/usr/bin' '--with-freetype-dir=/usr'
'--with-png-dir=/usr' '--with-gd' '--enable-gd-native-ttf' '--with-ttf'
'--with-gdbm' '--with-gettext' '--with-pdflib=shared'
'--with-tiff-dir=/usr' '--with-ncurses' '--with-gmp' '--with-iconv'
'--enable-xslt=shared' '--with-jpeg-dir=/usr' '--with-openssl'
'--with-png' '--with-pspell' '--with-regex=system' '--with-xml'
'--with-expat-dir=/usr' '--with-zlib' '--with-layout=GNU'
'--enable-bcmath' '--enable-exif' '--enable-ftp'
'--enable-magic-quotes' '--enable-safe-mode' '--enable-sockets'
'--enable-sysvsem' '--enable-sysvshm' '--enable-discard-path'
'--enable-track-vars' '--enable-trans-sid' '--enable-yp'
'--enable-wddx' '--without-oci8' '--with-pear=/usr/share/pear'
'--with-imap=shared' '--with-imap-ssl' '--with-kerberos=/usr/kerberos'
'--with-ldap=shared' '--with-mcal=shared,/usr'
'--with-mcrypt=shared,/usr' '--with-mhash=shared,/usr'
'--with-mysql=shared,/usr' '--with-pgsql=shared'
'--with-snmp=shared,/usr' '--with-snmp=shared'
'--with-sybase-ct=shared,/usr' '--with-xslt-sablot=shared,/usr'
'--with-sablot-js=shared,/usr' '--enable-ucd-snmp-hack'
'--with-unixODBC=shared' '--enable-memory-limit' '--enable-bcmath'
'--enable-shmop' '--enable-versioning' '--enable-calendar'
'--enable-dbx' '--enable-dio' '--enable-mcal'
'--with-apxs2=/usr/sbin/apxs'
Here the sript I use.. to query
$idres=mssql_query ("SELECT
NUMDOC,FECHA,DESCCONCI,DESCRIPCION,DEBE,HABER,BRUTO,PAGO FROM submayor
WHERE CODAREA='$Area' and FECHA>=convert(DATETIME,'$fdesde',102) and
FECHA<=convert(DATETIME,'$fhasta',102) order by FECHA",$id);
}
$cant=mssql_num_rows ($idres);
$TOTD=0;
$TOTH=0;
$TOTI=0;
$TOTP=0;
for ($i =1; $i <= $cant; $i++) {
$row = mssql_fetch_array ($idres);
$NUMDOC=$row["NUMDOC"];
$FECHCOB=$row["FECHA"];
$DESCCLI=$row["DESCCONCI"];
$OBSERVAC=$row["DESCRIPCION"];
$DEBE=$row["DEBE"];
$HABER=$row["HABER"];
$BRUTO=$row["BRUTO"];
$PAGO=$row["PAGO"];
}//end for
DEBE HABER BRUTO PAGO are float fields
Bye Aliet
--
Edit this bug report at http://bugs.php.net/?id=21047&edit=1
#21667 [Com]: Compilation error in sapi_module_struct
ID: 21667 Comment by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] Status: Feedback Bug Type: Compile Failure Operating System: Solaris8 PHP Version: 4CVS-2003-01-15 (stable) Assigned To: sas New Comment: Compiled without error. Thanks. Previous Comments: [2003-01-15 15:27:38] [EMAIL PROTECTED] Please update your checkout now, this should be fixed now. [2003-01-15 14:09:37] [EMAIL PROTECTED] Sascha broke it, he can propably fix it too.. [2003-01-15 12:31:01] [EMAIL PROTECTED] CVS tree is up ./buildconf execute cvsclean on my system. Manual calculation: Structure _sapi_module_struct in main/SAPI.h (from http://cvs.php.net/co.php/php4/main/SAPI.h?r=1.87.2.3) has 27 items. Definition STANDARD_SAPI_MODULE_PROPERTIES in main/SAPI.h has 8 items. Stricture apache2_sapi_module in sapi/apache2filter/sapi_apache2.c ( http://cvs.php.net/co.php/php4/sapi/apache2filter/sapi_apache2.c?r=1.91.2.4) has 21 items + STANDARD_SAPI_MODULE_PROPERTIES. 21 + 8 = 29 and not eq 27... http://cvs.php.net/diff.php/php4/main/SAPI.h?r1=1.87.2.2&r2=1.87.2.3&ty=u [2003-01-15 11:50:50] [EMAIL PROTECTED] Did you use an updated CVS tree or an fresh one? If the first, then please run ./cvsclean && ./buildconf or checkout a fresh tree. Derick [2003-01-15 11:42:32] [EMAIL PROTECTED] I have got error in compilation: Environment is: PHP Version (Updated at 2003/01/15 18:20 GMT+2) >cat CVS/Tag TPHP_4_3 Compillator: Sun WorkShop 6 update 2 C 5.3 2001/05/15 Error if independed of configure string. Error in compilation of Apache2Filer is: /bin/bash libtool --silent --mode=compile /opt/SUNWspro/bin/cc -Xa -xF -xCC -Isapi/apache2filter/ -I/usr/local/src/work/php4/sapi/apache2filter/ -DPHP_ATOM_INC -I/usr/local/src/work/php4/include -I/usr/local/src/work/php4/main -I/usr/local/src/work/php4 -I/usr/local/include/apache2 -I/usr/local/src/work/php4/Zend -I/usr/local/include -I/usr/local/include/freetype2 -I/usr/local/include/mysql -I/usr/local/src/work/php4/ext/xml/expat -D_POSIX_PTHREAD_SEMANTICS -D_REENTRANT -DAPACHE_XLATE -D_POSIX_PTHREAD_SEMANTICS -D_REENTRANT -I/usr/local/src/work/php4/TSRM -xtarget=ultra -xarch=v8plus -xO5 -xstrconst -xdepend -Xa -xildoff -dalign -D_REENTRANT -xspace -mr -mt -DZTS -prefer-pic -c /usr/local/src/work/php4/sapi/apache2filter/sapi_apache2.c -o sapi/apache2filter/sapi_apache2.lo "/usr/local/src/work/php4/sapi/apache2filter/sapi_apache2.c", line 318: too many struct/union initializers "/usr/local/src/work/php4/sapi/apache2filter/sapi_apache2.c", line 319: too many struct/union initializers cc: acomp failed for /usr/local/src/work/php4/sapi/apache2filter/sapi_apache2.c *** Error code 1 Same error for CLI version: /bin/bash libtool --silent --mode=compile /opt/SUNWspro/bin/cc -Xa -xF -xCC -Isapi/cli/ -I/usr/local/src/work/php4/sapi/cli/ -DPHP_ATOM_INC -I/usr/local/src/work/php4/include -I/usr/local/src/work/php4/main -I/usr/local/src/work/php4 -I/usr/local/include/apache2 -I/usr/local/src/work/php4/Zend -I/usr/local/include -I/usr/local/include/freetype2 -I/usr/local/include/mysql -I/usr/local/src/work/php4/ext/xml/expat -D_POSIX_PTHREAD_SEMANTICS -D_REENTRANT -DAPACHE_XLATE -D_POSIX_PTHREAD_SEMANTICS -D_REENTRANT -I/usr/local/src/work/php4/TSRM -xtarget=ultra -xarch=v8plus -xO5 -xstrconst -xdepend -Xa -xildoff -dalign -D_REENTRANT -xspace -mr -mt -DZTS -prefer-pic -c /usr/local/src/work/php4/sapi/cli/php_cli.c -o sapi/cli/php_cli.lo "/usr/local/src/work/php4/sapi/cli/php_cli.c", line 284: too many struct/union initializers cc: acomp failed for /usr/local/src/work/php4/sapi/cli/php_cli.c *** Error code 1 make: Fatal error: Command failed for target `sapi/cli/php_cli.lo' Reason: Wrong count of 'NULL' in sapi_module_struct, defined in modules (sapi/apache2filter/sapi_apache2.c and sapi/cli/php_cli.c) and STANDARD_SAPI_MODULE_PROPERTIES definition (defined in main/SAPI.h). Sollution: >cvs diff "sapi/apache2filter/sapi_apache2.c" sapi/cli/php_cli.c Index: sapi/apache2filter/sapi_apache2.c === RCS file: /repository/php4/sapi/apache2filter/sapi_apache2.c,v retrieving revision 1.91.2.4 diff -u -r1.91.2.4 sapi_apache2.c --- sapi/apache2filter/sapi_apache2.c 7 Jan 2003 15:23:45 - 1.91.2.4 +++ sapi/apache2filter/sapi_apache2.c 15 Jan 2003 17:38:10 - @@ -312,8 +312,8 @@ NULL, /* php_ini_path_override */ - NULL,
#21342 [Fbk->NoF]: Compile error
ID: 21342 Updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] -Status: Feedback +Status: No Feedback Bug Type: Compile Failure Operating System: Solaris 8/sparc PHP Version: 4.3.0 New Comment: No feedback was provided for this bug for over 2 weeks, so it is being suspended automatically. If you are able to provide the information that was originally requested, please do so and change the status of the bug back to "Open". Previous Comments: [2003-01-07 09:42:56] [EMAIL PROTECTED] Please try using this CVS snapshot: http://snaps.php.net/php4-latest.tar.gz For Windows: http://snaps.php.net/win32/php4-win32-latest.zip Looks like this was fixed/changed in code already. Give it a try and let us know. [2003-01-02 13:06:55] [EMAIL PROTECTED] php-4.3.0/ext/gd/gd.c: In function `zif_imageloadfont': php-4.3.0/ext/gd/gd.c:609: incompatible types in assignment php-4.3.0/ext/gd/gd.c:610: incompatible type for argument 2 of `_php_stream_seek' php-4.3.0/ext/gd/gd.c:611: invalid operands to binary - php-4.3.0/ext/gd/gd.c:612: incompatible type for argument 2 of `_php_stream_seek' OS - Solaris 8/sparc GCC 3.1 GD 2.0.1 with gif support freetype 2.1.0 Configure options: './configure' '--enable-rule=EAPI' '--with-apxs=/usr/local/apache/bin/apxs' ... '--with-gd=/usr' '--with-jpeg-dir=/usr/local' '--with-png-dir=/usr/local' '--with-freetype-dir=/usr/local' '--enable-gd-native-ttf' -- Edit this bug report at http://bugs.php.net/?id=21342&edit=1
#21323 [Fbk->NoF]: Session not initialised or not destroyed
ID: 21323 Updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] -Status: Feedback +Status: No Feedback Bug Type: Apache2 related Operating System: RedHat 8 PHP Version: 4.3.0 New Comment: No feedback was provided for this bug for over 2 weeks, so it is being suspended automatically. If you are able to provide the information that was originally requested, please do so and change the status of the bug back to "Open". Previous Comments: [2003-01-07 10:03:02] [EMAIL PROTECTED] Not enough information was provided for us to be able to handle this bug. Please re-read the instructions at http://bugs.php.net/how-to-report.php If you can provide more information, feel free to add it to this bug and change the status back to "Open". Thank you for your interest in PHP. [2003-01-01 22:50:14] [EMAIL PROTECTED] i have the same problem. i use php4.3, apache2.0.43, redhat7.1 i think it should be fix ASAP. thanx. [2003-01-01 20:11:27] [EMAIL PROTECTED] I installed PHP 4.3.0 just after Apache 2.0.43 All was working except sessions. The problem is the following : When I auth myself, it reloads the same page but some info change to show I'm logged in. (in normal case) With Apache2, PHP 4.3.0, the session wasn't initialized. The problem has occured with XoopS 1.3.7 With the latest CVS files (4.4.0-dev), all's working well. Hope this helps -- Edit this bug report at http://bugs.php.net/?id=21323&edit=1
#21336 [Fbk->NoF]: Session sometime can't function
ID: 21336 Updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] -Status: Feedback +Status: No Feedback Bug Type: Session related Operating System: Win 2000 Server PHP Version: 4.3.0 New Comment: No feedback was provided for this bug for over 2 weeks, so it is being suspended automatically. If you are able to provide the information that was originally requested, please do so and change the status of the bug back to "Open". Previous Comments: [2003-01-08 17:21:21] [EMAIL PROTECTED] Not enough information was provided for us to be able to handle this bug. Please re-read the instructions at http://bugs.php.net/how-to-report.php If you can provide more information, feel free to add it to this bug and change the status back to "Open". Thank you for your interest in PHP. A sample of the session code you're using and the session section from the php.ini might help us a lot more in debugging this. [2003-01-06 14:42:23] [EMAIL PROTECTED] I have difinately seen this as well. I was able to go back to 4.2.3 and made sure to replace the php.ini file with my old version and all is well again, but 4.3.0 will not handle sessions for me. [2003-01-02 19:22:39] [EMAIL PROTECTED] i'm confuse about it now. Not just on 4.3.0, 4.2.3 seem got this problem too. After changed 4.2.3: i have open two browser, one seem everything alright. but one got the same problem. everytime open new session. if the code error. two browser must got the same problem. Mike [2003-01-02 07:29:02] [EMAIL PROTECTED] I'm using session between two pages. But sometime the 4.3.0 can't read the pervious session and then second page was created the new session. And i was confirmed this bug only on 4.3.0 Because i was changed back to 4.2.3. The session error didn't appeared anymore. -- Edit this bug report at http://bugs.php.net/?id=21336&edit=1
#21375 [Fbk->NoF]: Changes in configure.in do not allow the creation of a sane configure
ID: 21375 Updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] -Status: Feedback +Status: No Feedback Bug Type: Compile Failure Operating System: Solaris 8 PHP Version: 4CVS-2003-01-02 (dev) New Comment: No feedback was provided for this bug for over 2 weeks, so it is being suspended automatically. If you are able to provide the information that was originally requested, please do so and change the status of the bug back to "Open". Previous Comments: [2003-01-08 21:27:17] [EMAIL PROTECTED] (to be verified, someone ELSE needs to be able to reproduce this :) Please try the older autoconf/automake. autoconf versions above 2.13 really are buggy. And make sure you get rid of all the old files of those tools (autoconf,automake,libtool) before you install them. [2003-01-08 20:00:03] [EMAIL PROTECTED] No, I had not changed anything in this box since the last time I compiled from CVS back in October. I have changed things while trying to check if a newer autoconf, etc. helped. Running the command line you suggested I get: ./cvsclean && ./buildconf using default Zend directory buildconf: checking installation... buildconf: autoconf version 2.57 (ok) buildconf: Your version of autoconf likely contains buggy cache code. Running cvsclean for you. To avoid this, install autoconf-2.13 and automake-1.5. buildconf: automake version 1.7.2 (ok) buildconf: libtool version 1.4 (ok) rebuilding configure configure.in:831: warning: AC_PROG_LIBTOOL is m4_require'd but is not m4_defun'd configure.in:146: error: possibly undefined macro: AC_MSG_RESULT If this token and others are legitimate, please use m4_pattern_allow. See the Autoconf documentation. configure.in:295: error: possibly undefined macro: AC_DEFINE configure.in:1064: error: possibly undefined macro: AC_PROG_LIBTOOL configure:100072: error: possibly undefined macro: _LT_AC_TRY_DLOPEN_SELF rebuilding acconfig.h rebuilding main/php_config.h.in configure.in:831: m4: Undefined macro `AC_PROG_LIBTOOL' So autoconf 2.57 is buggy but 2.13 is not? Should I downgrade? Just to make doubly sure I did not have anything weird in my local CVS copy I did a fresh checkout of 'php4' (in /tmp/test/php4), and rerun the line above: % cd /tmp/test/php4 % ./cvsclean && ./buildconf using default Zend directory buildconf: checking installation... buildconf: autoconf version 2.57 (ok) buildconf: Your version of autoconf likely contains buggy cache code. Running cvsclean for you. To avoid this, install autoconf-2.13 and automake-1.5. buildconf: automake version 1.7.2 (ok) buildconf: libtool version 1.4 (ok) rebuilding configure configure.in:831: warning: AC_PROG_LIBTOOL is m4_require'd but is not m4_defun'd configure.in:146: error: possibly undefined macro: AC_MSG_RESULT If this token and others are legitimate, please use m4_pattern_allow. See the Autoconf documentation. configure.in:295: error: possibly undefined macro: AC_DEFINE configure.in:1064: error: possibly undefined macro: AC_PROG_LIBTOOL configure:99670: error: possibly undefined macro: _LT_AC_TRY_DLOPEN_SELF rebuilding acconfig.h rebuilding main/php_config.h.in configure.in:831: m4: Undefined macro `AC_PROG_LIBTOOL' Any ideas on where to look about the (possible) messed up libtool? I had not used autoconf too much, but it is weird that 2.13 is not buggy but a later (current) version is. [2003-01-08 17:42:19] [EMAIL PROTECTED] Did you change anything in your setup before this started? And are all those tools installed with same prefix? Are you sure your CVS checkout is clean? Here's the output I got with latest CVS (HEAD): # ./cvsclean && ./buildconf using default Zend directory buildconf: checking installation... buildconf: autoconf version 2.13 (ok) buildconf: automake version 1.4-p5 (ok) buildconf: libtool version 1.4 (ok) rebuilding configure rebuilding acconfig.h rebuilding main/php_config.h.in It looks like that your libtool installation is not quite okay.. [2003-01-06 13:25:44] [EMAIL PROTECTED] More information: (using CVS from today 2003-01-06) I had installed the following versions automake 1.4 libtool 1.4 autoconf 2.13 Gnu m4 1.4 which according to buil/buildcheck.sh should be OK (and which indeed used to build from CVS w/o trouble) To try and see if it will work w/ a new version, I installed: autoconf 2.57 automake 1.7.2 and then I rerun: % ./buildconf using default Zend directory buildconf: checking installation... buildconf: autoconf version 2.57 (ok) buildconf: Yo
#21319 [Fbk->NoF]: the PHP Script Interpreter crashes.
ID: 21319 Updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] -Status: Feedback +Status: No Feedback Bug Type: Scripting Engine problem Operating System: windows xp PHP Version: 4.3.0 New Comment: No feedback was provided for this bug for over 2 weeks, so it is being suspended automatically. If you are able to provide the information that was originally requested, please do so and change the status of the bug back to "Open". Previous Comments: [2003-01-08 13:34:41] [EMAIL PROTECTED] Hi, sorry I haven't been able to isolate in sort, but I found out this much : Installing 4.3.0 by default enables the php_iisfunc.dll extension in the php.ini file. (Using Windows XP and IIS). I'm not aware of using this functionality and when I remove the use of the php_iisfunc.dll (comment the line) the error doen't occur. Hopefully this can be of some use. /Rene' [2003-01-08 13:27:31] [EMAIL PROTECTED] Don't quote me on this, but I believe this bug is related to several other bugs which have been reported since 4.3.0. There *appears* to be an issue with garbage collection when the interpreter is in the final stages of shutdown (script exit). I can't be more specific because it's related to a portion of the PHP Core which I'm not qualified to debug and is a heisenbug in the most classical sense. Rest assured though that there ARE developers working on this issue. Any additional information you can provide such as backtraces and short, simple pieces of code which reproduce the error will aid in the isolation and irradication of this bug. [2003-01-07 17:46:07] [EMAIL PROTECTED] In order to look into the problem we would need a short and complete script that reproduces the problem. Without that there is very little information to go on. [2003-01-07 14:05:53] [EMAIL PROTECTED] i withdraw my speculation about the die construct beeing the problem; i have a script that does.. something (checks urls & downloads them via fsockopen) 20 times in a for loop from 1 to 20.. sometimes there is an error when downloading, and naturally, to move on to the next url, i use the continue construct (or whatever it's called). I run my scripts from the command prompt with a batch script that runs "PHP SCRIPTNAME.PHP" over and over in an infinite loop.. since the php script is executed in a loop, it wouldn't really matter if you call continue or die since the next url in the database would be processed either way.. Now this should be interesting; NOT A SINGLE CRASH, has ever occurred ever since i've started using die instead of continue on download errors.. and you're still not responding.. osman darcan [2003-01-07 13:56:48] [EMAIL PROTECTED] I am using Apache and yes, it may be the same problem, what i don't understand is why these guys dont respond, i would really like to know if they're into the problem or if they haven't even read my messages yet.. a simple "we're looking into the problem" would be fine.. but nooo.. 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/21319 -- Edit this bug report at http://bugs.php.net/?id=21319&edit=1
#20920 [Fbk->NoF]: mssql.datetimeconvert=0 doesn't work for smalldatetime
ID: 20920
Updated by: [EMAIL PROTECTED]
Reported By: [EMAIL PROTECTED]
-Status: Feedback
+Status: No Feedback
Bug Type: MSSQL related
Operating System: Windows 2000
PHP Version: 4CVS-2002-12-10 (dev)
New Comment:
No feedback was provided for this bug for over 2 weeks, so it is
being suspended automatically. If you are able to provide the
information that was originally requested, please do so and change
the status of the bug back to "Open".
Previous Comments:
[2003-01-09 12:22:41] [EMAIL PROTECTED]
Please try using this CVS snapshot:
http://snaps.php.net/php4-latest.tar.gz
For Windows:
http://snaps.php.net/win32/php4-win32-latest.zip
The handling of boolean ini settings did not always work due to wrong
initialization of data types. This has been fixed in cvs.
[2002-12-10 05:39:48] [EMAIL PROTECTED]
When setting:
ini_set('mssql.datetimeconvert', 0);
fields of type 'smalldatetime' are still converted to a
local date format. The above setting only seems to apply
to fields of type 'datetime'.
For example, leaving 'mssql.datetimeconvert = 1' and
displaying two fields DATETIME and SMALLDATETIME would
result in:
Dec 31 2002 12:00AM // DATETIME
Dec 31 2002 12:00AM // SMALLDATETIME
whereas, setting 'mssql.datetimeconvert = 0' would result
in:
2002-12-31 00:00:00 // DATETIME
Dec 31 2002 12:00AM // SMALLDATETIME
See also: http://bugs.php.net/bug.php?id=12655
--
Edit this bug report at http://bugs.php.net/?id=20920&edit=1
#21485 [Fbk->NoF]: feof() doesn't returns true on a socket stream
ID: 21485
Updated by: [EMAIL PROTECTED]
Reported By: [EMAIL PROTECTED]
-Status: Feedback
+Status: No Feedback
Bug Type: Sockets related
Operating System: Win2K/Linux
PHP Version: 4.3.0
Assigned To: wez
New Comment:
No feedback was provided for this bug for over 2 weeks, so it is
being suspended automatically. If you are able to provide the
information that was originally requested, please do so and change
the status of the bug back to "Open".
Previous Comments:
[2003-01-09 04:33:57] [EMAIL PROTECTED]
The following works for me:
$fp = fsockopen("localhost", 25);
stream_set_blocking($fp, false);
fwrite($fp, "QUIT\r\n");
while(!feof($fp)) {
$data = fgets($fp);
var_dump($data);
}
echo "\nAll done\n";
Under Win2000, WinXP, Linux2.4.19 (with IPv6), FreeBSD4.5 (with
IPv6)...
Not verified at all for me.
[2003-01-09 04:23:45] [EMAIL PROTECTED]
The following works for me:
$fp = fsockopen("localhost", 25);
stream_set_blocking($fp, false);
fwrite($fp, "QUIT\r\n");
while(!feof($fp)) {
$data = fgets($fp);
var_dump($data);
}
echo "\nAll done\n";
Remember that feof() will only return true when there is no more data
in the internal buffer held by the stream, so you need to drain off any
input by consuming it all first.
[2003-01-09 04:05:25] [EMAIL PROTECTED]
The nature of non-blocking sockets means that your script must always
be prepared to handle a false or zero length return from fgets/fread,
so I'm not worried about that aspect.
However, the feof() does seem to be a problem.
Looking into it...
[2003-01-09 02:48:19] [EMAIL PROTECTED]
I've noticed that I need the sleep() in order to retrieve the data.
The behaviour with blocking/non blocking sockets haven't changed
though, its still the same in php 4.3.0 as it were in previous php
versions.
What has changed is the feof() that never return true.
Regards
/Bjarne
[2003-01-08 21:40:39] [EMAIL PROTECTED]
It seems that socket_set_blocking($fp,FALSE); results in other peculiar
behaviour.
When connecting to SMTP server, the server sends some data across the
socket right away, usually something identifying the server.
$fp = fsockopen("mail_server", 25);
var_dump(fgets($fp, 1024));
fclose($fp);
returns the server identify string
$fp = fsockopen("mail_server", 25);
socket_set_blocking($fp,FALSE);
var_dump(fgets($fp, 1024));
fclose($fp);
returns (false)
$fp = fsockopen("mail_server", 25);
sleep(1);
socket_set_blocking($fp,FALSE);
var_dump(fgets($fp, 1024));
fclose($fp);
returns identify string.
The position of the sleep() call can be after socket_set_blocking() as
well.
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/21485
--
Edit this bug report at http://bugs.php.net/?id=21485&edit=1
#19201 [Fbk->NoF]: htmlspecialchars, et al crashes when called with quote_style
ID: 19201 Updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] -Status: Feedback +Status: No Feedback Bug Type: Reproducible crash Operating System: Digital Unix 4.0G PHP Version: 4.2.2 New Comment: No feedback was provided for this bug for over 2 weeks, so it is being suspended automatically. If you are able to provide the information that was originally requested, please do so and change the status of the bug back to "Open". Previous Comments: [2003-01-10 12:35:12] [EMAIL PROTECTED] % gcc -v Reading specs from /usr/local/lib/gcc-lib/alphaev56-dec-osf4.0g/3.2/specs Configured with: ../gcc-3.2/configure Thread model: single gcc version 3.2 [2003-01-10 12:23:44] [EMAIL PROTECTED] Which compiler (and version) did you use to build the PHP binary? Some old compilers may produce bogus codes that cause unaligned access. [2003-01-10 10:48:48] [EMAIL PROTECTED] Still crashes with PHP 4.3.0. I do not have a license for dbx so I can't provide a backtrace, but running the example above from the command line against the cgi binary produces the following: Unaligned access pid=25896 va=0x1400c4cec pc=0x120244758 ra=0x1200bda78 inst=0xb429 Unaligned access pid=25896 va=0x11fffdb7c pc=0x120236d64 ra=0x120237408 inst=0xb42c Segmentation fault [2002-09-23 08:09:20] [EMAIL PROTECTED] No feedback was provided. The bug is being suspended because we assume that you are no longer experiencing the problem. If this is not the case and you are able to provide the information that was requested earlier, please do so and change the status of the bug back to "Open". Thank you. [2002-08-30 13:18:04] [EMAIL PROTECTED] Forgot to say that I can not reproduce this with php 4.2.0-dev (march 7) or php 4.3.0-dev (august 25). They both show this result: &"'<> The remainder of the comments for this report are too long. To view the rest of the comments, please view the bug report online at http://bugs.php.net/19201 -- Edit this bug report at http://bugs.php.net/?id=19201&edit=1
#20782 [Fbk->NoF]: Segmentation fault using oracle 8.1.7
ID: 20782 Updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] -Status: Feedback +Status: No Feedback Bug Type: OCI8 related Operating System: Linux RH7.3 (ker:2.4.18-3smp) PHP Version: 4.3.0RC2 New Comment: No feedback was provided for this bug for over 2 weeks, so it is being suspended automatically. If you are able to provide the information that was originally requested, please do so and change the status of the bug back to "Open". Previous Comments: [2003-01-15 13:31:13] [EMAIL PROTECTED] I am told by my server guru that we did link it through libpthread. Any other ideas? [2003-01-10 13:28:27] [EMAIL PROTECTED] And if you're using Apache, is it linked with libpthread? Instructions here: http://www.php.net/manual/en/ref.oci8.php [2003-01-10 13:06:09] [EMAIL PROTECTED] I have the same problem. I am using PHP v4.1.2 with Oracle 8.1.7. Even doing a simple insert or select causes this problem. [2002-12-03 06:18:35] [EMAIL PROTECTED] The only one that is not set is LD_PRELOAD. All the other are ok. I'm sending u a backtrace. [2002-12-03 03:48:31] [EMAIL PROTECTED] Just to make sure..did you have all the environment vars set? Check this: http://www.php.net/manual/en/ref.oci8.php The remainder of the comments for this report are too long. To view the rest of the comments, please view the bug report online at http://bugs.php.net/20782 -- Edit this bug report at http://bugs.php.net/?id=20782&edit=1
#21568 [Fbk->NoF]: The memory could not be "read".
ID: 21568 Updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] -Status: Feedback +Status: No Feedback Bug Type: Apache related Operating System: Windows 2000 SP3 PHP Version: 4.3.0 New Comment: No feedback was provided for this bug for over 2 weeks, so it is being suspended automatically. If you are able to provide the information that was originally requested, please do so and change the status of the bug back to "Open". Previous Comments: [2003-01-10 12:38:55] [EMAIL PROTECTED] Not enough information was provided for us to be able to handle this bug. Please re-read the instructions at http://bugs.php.net/how-to-report.php If you can provide more information, feel free to add it to this bug and change the status back to "Open". Thank you for your interest in PHP. [2003-01-10 09:53:34] [EMAIL PROTECTED] I have Windows 2000 SP3 & Apache 1.3.27. When I starting php.exe without starting Apache or Apache without PHP (as additional module) they both working properly. BUT when I starting Apache with PHP (as additional module) : Apache.exe - application error The instruction at "0x012110c3" referenced memory at "0x". The memory could not be "read". Click on OK to terminate the program. HELP ME PLEASE! My life without PHP - isn't normally life. Devils_advocatE, mailto: [EMAIL PROTECTED] -- Edit this bug report at http://bugs.php.net/?id=21568&edit=1
#21559 [Fbk->NoF]: Fatal error: Nesting level too deep - recursive dependency? in Unknown on line
ID: 21559 Updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] -Status: Feedback +Status: No Feedback Bug Type: *General Issues Operating System: redhat 8 PHP Version: 4.3.0 New Comment: No feedback was provided for this bug for over 2 weeks, so it is being suspended automatically. If you are able to provide the information that was originally requested, please do so and change the status of the bug back to "Open". Previous Comments: [2003-01-10 14:12:42] [EMAIL PROTECTED] so it's not PDF related at all..? Can you try and reduce those configure options to minimum to see what actually is causing this. [2003-01-10 13:50:00] [EMAIL PROTECTED] ./configure' '--with-pdflib=/usr/local' '--with-snmp=shared,/usr' '--with-snmp=shared' '--enable-ucd-snmp-hack' '--with-tiff-dir=/usr/local/' '--host=i686-pc-linux-gnu' '--build=i686-pc-linux-gnu' '--target=i386-redhat-linux-gnu' '--program-prefix=' '--prefix=/usr' '--exec-prefix=/usr' '--bindir=/usr/bin' '--sbindir=/usr/sbin' '--sysconfdir=/etc' '--datadir=/usr/share' '--includedir=/usr/include' '--libdir=/usr/lib' '--libexecdir=/usr/libexec' '--localstatedir=/var' '--sharedstatedir=/usr/com' '--mandir=/usr/share/man' '--infodir=/usr/share/info' '--prefix=/usr' '--with-config-file-path=/etc' '--enable-force-cgi-redirect' '--disable-debug' '--enable-pic' '--disable-rpath' '--enable-inline-optimization' '--with-bz2' '--with-db3' '--with-curl' '--with-dom=/usr' '--with-exec-dir=/usr/bin' '--with-freetype-dir=/usr' '--with-png-dir=/usr' '--with-gd' '--enable-gd-native-ttf' '--with-ttf' '--with-gdbm' '--with-gettext' '--with-ncurses' '--with-gmp' '--with-iconv' '--with-jpeg-dir=/usr' '--with-openssl' '--with-png' '--with-pspell' '--with-regex=system' '--with-xml' '--with-expat-dir=/usr' '--with-zlib' '--with-layout=GNU' '--enable-bcmath' '--enable-exif' '--enable-ftp' '--enable-magic-quotes' '--enable-safe-mode' '--enable-sockets' '--enable-sysvsem' '--enable-sysvshm' '--enable-discard-path' '--enable-track-vars' '--enable-trans-sid' '--enable-yp' '--enable-wddx' '--without-oci8' '--with-pear=/usr/share/pear' '--with-imap=shared' '--with-imap-ssl' '--with-kerberos=/usr/kerberos' '--with-ldap=shared' '--with-mysql=shared,/usr' '--with-pgsql=shared' '--with-unixODBC=shared' '--enable-memory-limit' '--enable-bcmath' '--enable-shmop' '--enable-versioning' '--enable-calendar' '--enable-dbx' '--enable-dio' '--enable-mcal' '--with-apxs2=/usr/sbin/apxs' I get Nesting Level Too Deep on everything, I tried downloading the snap shot you mentioned, but it gave errors on the configure -- everything works, just a nasty error. [2003-01-09 19:33:30] [EMAIL PROTECTED] I can not reproduce this with latest stable snapshot (from http://snaps.php.net) and using PDFlib 4.0.3. How did you configure both PHP and pdflib? [2003-01-09 18:38:38] [EMAIL PROTECTED] Fatal error: Nesting level too deep - recursive dependency? in Unknown on line 0 Perhaps it does not deal with php? but i do get this error creating any pdf document Running the example from the documentation web site will produce the error in 4.3 php pdflib-4.0.3 is what i have installed -- it will still create the document, and that is fine, but it gives this nasty error... no matter what i have tried .. it spits it out when creating a pdf... finished"; ?> -- Edit this bug report at http://bugs.php.net/?id=21559&edit=1
#21385 [Fbk->NoF]: php execution stops during processing
ID: 21385 Updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] -Status: Feedback +Status: No Feedback Bug Type: iPlanet related Operating System: solaris 2.6 PHP Version: 4.3.0 New Comment: No feedback was provided for this bug for over 2 weeks, so it is being suspended automatically. If you are able to provide the information that was originally requested, please do so and change the status of the bug back to "Open". Previous Comments: [2003-01-07 09:47:03] [EMAIL PROTECTED] setting to feedback [2003-01-03 06:39:23] [EMAIL PROTECTED] Can you please give more details so we can try to reproduce the problem to verify it's really PHP related? Try to run the scripts from the CLI too if you can and backtrace. Thank you. [2003-01-03 05:36:38] [EMAIL PROTECTED] We are working on Iplanet 6.0 SP2. Some of our php pages are doing complex statement on Oracle database, and then can take more than a minute. But as soon as nothing is sent back to php (or the webserver) in less than 10 seconds, the webserver stop to load the page. We have set the max_execution_time to 60, and nothing change. We have tested the same pages on apache, and everything runs fine. -- Edit this bug report at http://bugs.php.net/?id=21385&edit=1
#21293 [Fbk->NoF]: imap_fetchstructure incomplet return
ID: 21293 Updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] -Status: Feedback +Status: No Feedback Bug Type: Feature/Change Request Operating System: Debian GNU/Linux Sid PHP Version: 4.2.3 New Comment: No feedback was provided for this bug for over 2 weeks, so it is being suspended automatically. If you are able to provide the information that was originally requested, please do so and change the status of the bug back to "Open". Previous Comments: [2003-01-15 06:42:00] [EMAIL PROTECTED] Not enough information was provided for us to be able to handle this bug. Please re-read the instructions at http://bugs.php.net/how-to-report.php If you can provide more information, feel free to add it to this bug and change the status back to "Open". Thank you for your interest in PHP. [2003-01-15 06:40:51] [EMAIL PROTECTED] This no return de content of parts with yhe MIME-Version is not specificated. [2003-01-15 01:00:04] [EMAIL PROTECTED] No feedback was provided for this bug for over 2 weeks, so it is being suspended automatically. If you are able to provide the information that was originally requested, please do so and change the status of the bug back to "Open". [2002-12-30 11:50:38] [EMAIL PROTECTED] Please try using this CVS snapshot: http://snaps.php.net/php4-latest.tar.gz For Windows: http://snaps.php.net/win32/php4-win32-latest.zip [2002-12-30 11:09:40] [EMAIL PROTECTED] I using a Debian packages. I update php4 and php4-imap an 'imap_fetchstructure' no return all part in messaje. libc6 2.3.1-8 php4 4.2.3-8 php4-dbase 4.2.1-1 php4-dev 4.2.3-8 php4-domxml4.2.1-3 php4-gd2 4.2.1-2 php4-imap 4.2.3-8 php4-mysql 4.2.1-3 php4-pear 4.1.2-4 php4-pgsql 4.2.1-2 -- Edit this bug report at http://bugs.php.net/?id=21293&edit=1
#21656 [Fbk->NoF]: fclose() don't close the socket
ID: 21656
Updated by: [EMAIL PROTECTED]
Reported By: [EMAIL PROTECTED]
-Status: Feedback
+Status: No Feedback
Bug Type: Sockets related
Operating System: Linux (Slackware)
PHP Version: 4.3.0
New Comment:
No feedback was provided for this bug for over 2 weeks, so it is
being suspended automatically. If you are able to provide the
information that was originally requested, please do so and change
the status of the bug back to "Open".
Previous Comments:
[2003-01-15 21:24:40] [EMAIL PROTECTED]
Please read this:
http://bugs.php.net/bugs-generating-backtrace.php
and then run your httpd under gdb as described in the section "if you
can't get a core file".
** make sure your PHP is compiled with --enable-debug **
When you get the script to hang, press CTRL-C to interrupt and then
type "bt full".
copy-and-paste the backtrace into a text file, and make a tar ball from
it, along with the script that you were running to cause the problem,
and put it online somewhere that I can download it.
Thanks!
[2003-01-15 20:55:47] [EMAIL PROTECTED]
Thanks, it goes better... but it is still not perfect.
I can (nearly) reproduce the behavior with port 25 of any of
[205.158.62.23], [205.158.62.25], [205.158.62.27], [205.158.62.41]
while waiting fo smtp greetings
after $fp = fsockopen returns a valid $fp
$buffer = fgets ($fp);
$tstatus = stream_get_meta_data ($fp);
$tstatus["eof"] evaluates to TRUE
I then try to fclose($fp) but the script hangs there (cf. supra)
[2003-01-15 17:56:40] [EMAIL PROTECTED]
Please try using this CVS snapshot:
http://snaps.php.net/php4-STABLE-latest.tar.gz
For Windows:
http://snaps.php.net/win32/php4-win32-STABLE-latest.zip
There was a problem with the errstr parameter to fsockopen that has
been fixed in the STABLE snapshots.
Please try one of those and report back here.
Also, please read the docs for stream_get_meta_data()
and make sure that you understand the difference between
the eof property listed there and the return value of the
feof() function.
[2003-01-15 17:45:48] [EMAIL PROTECTED]
I am running PHP 4.3, RedHat Linux 7.3, Apache-1.3.27-2 and have still
the problem :
1-$fp = fsockopen ($tiphost[$i],25,&$errno,&$errstr,&$TimeOut);
2-$tstatus = stream_get_meta_data ($fp);
3-if ($tstatus["eof"]) {
4- $output = '114 Connection unexpectedly closed';
5-}
6-$err = fclose ($fp);
At line 6 it goes (sometimes) wrong, I guess for the same reason as
described here and I get Apache PIDs running for days now...
I tried set_time_limit () but as fclose() is "out" of PHP (I think) it
does not make the job :-(
/server-status gives for example :
M CPU SSReq
K 34.48 74295 280513
which means the server child is in Keepalive mode, used 34.48 secs of
CPU (stalled), not working for 74295 secs (growing), and have been
working for 280513 secs (stalled)
[2003-01-15 08:02:46] [EMAIL PROTECTED]
Not enough information was provided for us to be able
to handle this bug. Please re-read the instructions at
http://bugs.php.net/how-to-report.php
If you can provide more information, feel free to add it
to this bug and change the status back to "Open".
Thank you for your interest in PHP.
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/21656
--
Edit this bug report at http://bugs.php.net/?id=21656&edit=1
#21647 [Fbk->NoF]: make test gives loop error
ID: 21647 Updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] -Status: Feedback +Status: No Feedback Bug Type: *General Issues Operating System: solaris 8 PHP Version: 4.3.0 New Comment: No feedback was provided for this bug for over 2 weeks, so it is being suspended automatically. If you are able to provide the information that was originally requested, please do so and change the status of the bug back to "Open". Previous Comments: [2003-01-15 03:27:17] [EMAIL PROTECTED] Please try using this CVS snapshot: http://snaps.php.net/php4-STABLE-latest.tar.gz For Windows: http://snaps.php.net/win32/php4-win32-STABLE-latest.zip [2003-01-14 23:50:11] [EMAIL PROTECTED] SED is gnu also [2003-01-14 23:49:10] [EMAIL PROTECTED] gcc 3.2.1 with gnu ld and solaris 8 with latest patches apache 2.0.43 and php 4.3.0 compile with --with-apxs2=/PATH_TO_APXS or anything and I get this loop are after make make test and this is what I get ( I am not running php in safe mode) PHP Notice: ob_end_clean() [http://www.php.net/ref.outcontrol]: failed to delete buffer default output handler. in /export/home/imiller/php-4.3.0/run-tests.php on line 48 PHP Notice: ob_end_clean() [http://www.php.net/ref.outcontrol]: failed to delete buffer default output handler. in /export/home/imiller/php-4.3.0/run-tests.php on line 48 PHP Notice: ob_end_clean() [http://www.php.net/ref.outcontrol]: failed to delete buffer default output handler. in /export/home/imiller/php-4.3.0/run-tests.php on line 48 PHP Notice: ob_end_clean() [http://www.php.net/ref.outcontrol]: failed to delete buffer default output handler. in /export/home/imiller/php-4.3.0/run-tests.php on line 48 PHP Notice: ob_end_clean() [http://www.php.net/ref.outcontrol]: failed to delete buffer default output handler. in /export/home/imiller/php-4.3.0/run-tests.php on line 48 PHP Notice: ob_end_clean() [http://www.php.net/ref.outcontrol]: failed to delete buffer default output handler. in /export/home/imiller/php-4.3.0/run-tests.php on line 48 PHP Notice: ob_end_clean() [http://www.php.net/ref.outcontrol]: failed to delete buffer default output handler. in /export/home/imiller/php-4.3.0/run-tests.php on line 48 PHP Notice: ob_end_clean() [http://www.php.net/ref.outcontrol]: failed to delete buffer default output handler. in /export/home/imiller/php-4.3.0/run-tests.php on line 48 PHP Notice: ob_end_clean() [http://www.php.net/ref.outcontrol]: failed to delete buffer default output handler. in /export/home/imiller/php-4.3.0/run-tests.php ?? added question marks -- Edit this bug report at http://bugs.php.net/?id=21647&edit=1
#20551 [Fbk->NoF]: Output compression causes segfaults (ob_gzhandler)
ID: 20551
Updated by: [EMAIL PROTECTED]
Reported By: [EMAIL PROTECTED]
-Status: Feedback
+Status: No Feedback
Bug Type: Apache related
Operating System: RedHat 7.2
PHP Version: 4.3.0RC3
New Comment:
No feedback was provided for this bug for over 2 weeks, so it is
being suspended automatically. If you are able to provide the
information that was originally requested, please do so and change
the status of the bug back to "Open".
Previous Comments:
[2003-01-15 20:46:50] [EMAIL PROTECTED]
Please try using this CVS snapshot:
http://snaps.php.net/php4-STABLE-latest.tar.gz
For Windows:
http://snaps.php.net/win32/php4-win32-STABLE-latest.zip
[2002-12-12 15:06:41] [EMAIL PROTECTED]
Reclassifying since it is the Apache module code where the actual
segfaults occur.
Short version: SG(server_context) is not checked for null before
dereferencing it in sapi_apache_header_handler() while it is checked in
other functions.
[2002-12-06 09:30:55] [EMAIL PROTECTED]
Finally.
In file:
sapi/apache/mod_php4.c
The crash is in sapi_apache_header_handler(). This line is apparently
not guaranteed:
request_rec *r = (request_rec *) SG(server_context);
As r is dereferenced and not valid some small percent of the time. It
may be indicative of some other error. Further investigation as to why
needs to be done.
I added a few other checks while tracking this bug down. Here is the
function as I have it now. No more segfaults in the error_log. The line
to note is the check for !r. Also, I don't think it hurts to check for
null in other places (!sapi_header || !sapi_header->header).
/* {{{ sapi_apache_header_handler
*/
int sapi_apache_header_handler(sapi_header_struct *sapi_header,
sapi_headers_struct *sapi_headers TSRMLS_DC)
{
char *header_name, *header_content, *p;
request_rec *r = (request_rec *) SG(server_context);
if (!sapi_header) {
return 0;
}
if (!sapi_header->header) {
return 0;
}
header_name = sapi_header->header;
header_content = strchr(header_name, ':');
if (!header_content || !r) {
efree(sapi_header->header);
return 0;
}
header_name =
estrndup(header_name,header_content-header_name);
if (!header_name){
return 0;
}
do {
header_content++;
} while (*header_content==' ');
if (!strcasecmp(header_name, "Content-Type")) {
r->content_type = pstrdup(r->pool, header_content);
} else if (!strcasecmp(header_name, "Set-Cookie")) {
table_add(r->headers_out, header_name,
header_content);
} else if (sapi_header->replace) {
table_set(r->headers_out, header_name,
header_content);
} else {
table_add(r->headers_out, header_name,
header_content);
efree(header_name);
efree(sapi_header->header);
return 0; /* don't use the default SAPI mechanism, Apache
duplicates this functionality */
}
/* }}} */
[2002-12-05 18:34:16] [EMAIL PROTECTED]
OK, I was able to have gbb attach to one of the 500 children and wait
for a segault. This is version 4.2.3, as this is from our production
site (late at night I'll try and do the same for a full debug version
of 4.3RC2):
Program received signal SIGSEGV, Segmentation fault.
0x080a9b2c in sapi_apache_header_handler ()
(gdb) bt
#0 0x080a9b2c in sapi_apache_header_handler ()
#1 0x080af403 in sapi_add_header_ex ()
#2 0x080b5700 in zif_ob_gzhandler ()
#3 0x08124392 in call_user_function_ex ()
#4 0x080b20f9 in php_end_ob_buffer ()
#5 0x080b23bb in php_end_ob_buffers ()
#6 0x080ac0a7 in php_request_shutdown ()
#7 0x081530d8 in run_cleanups ()
#8 0x08151ec8 in ap_clear_pool ()
#9 0x08151f28 in ap_destroy_pool ()
#10 0x08151e9b in ap_clear_pool ()
#11 0x0815e92b in child_main ()
#12 0x0815ef0b in make_child ()
#13 0x0815f1e9 in perform_idle_server_maintenance ()
#14 0x0815f69a in standalone_main ()
#15 0x0815fc2c in main ()
[2002-12-04 17:59:13] [EMAIL PROTECTED]
status -> open, updated version.
(please, don't use 'Add Comment' when you edit your own submission..use
'Edit Submission')
The remainder of the comments for this report are too long. To view
the rest of the comments, please view the bug report online at
http://bugs.php.net/20551
--
Edit this
#21670 [Fbk->NoF]: Time limit for fgets()
ID: 21670 Updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] -Status: Feedback +Status: No Feedback Bug Type: Feature/Change Request Operating System: Linux PHP Version: 4.3.0 New Comment: No feedback was provided for this bug for over 2 weeks, so it is being suspended automatically. If you are able to provide the information that was originally requested, please do so and change the status of the bug back to "Open". Previous Comments: [2003-01-15 12:46:30] [EMAIL PROTECTED] Not enough information was provided for us to be able to handle this bug. Please re-read the instructions at http://bugs.php.net/how-to-report.php If you can provide more information, feel free to add it to this bug and change the status back to "Open". Thank you for your interest in PHP. Note that you can also use stream_select(). [2003-01-15 12:37:51] [EMAIL PROTECTED] I need to set a timelimit for fgets() function. It may be very useful or important in some cases (especially for CLI). Unfortunately, set_time_limit() doesn't work. -- Edit this bug report at http://bugs.php.net/?id=21670&edit=1
#13809 [Fbk->NoF]: Openlink 3.2 and 4.0 odbc_do and single quotes
ID: 13809
Updated by: [EMAIL PROTECTED]
Reported By: [EMAIL PROTECTED]
-Status: Feedback
+Status: No Feedback
Bug Type: ODBC related
Operating System: SCO Openserver 5.0.5 & RH Lnux 7
PHP Version: 4.0.6
New Comment:
No feedback was provided for this bug for over 2 weeks, so it is
being suspended automatically. If you are able to provide the
information that was originally requested, please do so and change
the status of the bug back to "Open".
Previous Comments:
[2003-01-19 19:00:14] [EMAIL PROTECTED]
Please try using this CVS snapshot:
http://snaps.php.net/php4-STABLE-latest.tar.gz
For Windows:
http://snaps.php.net/win32/php4-win32-STABLE-latest.zip
Removing ahill assigned to status, and asking to try a newer version
[2002-05-22 15:22:24] [EMAIL PROTECTED]
Assigning to Andrew
[2002-05-13 18:18:18] [EMAIL PROTECTED]
did some examination on this, and I believe it lies in the OpenLink
software... as I see the same problem here, but not on my Windows
emulation. Andrew any chance you can take a look into this further?
[2001-10-24 05:19:44] [EMAIL PROTECTED]
Came across this issue when doing my data conversions. If the fields
have single quotes in them, odbc_do fails.
I have tested this against the Openlink 3.2 and 4.1 SDK's and found
that using odbc_prepare works fine.
Basic Script
SQL: $sql";
$results = odbc_do($conn,$sql);
if ($results) {
while (odbc_fetch_into($results,$row)) {
echo $row[0]." ".$row[1]." ".$row[2]."\n";
}
}
$sql="SELECT ID,Category,description FROM card_type WHERE description
LIKE '%PEP%'";
echo "SQL: $sql";
$results = odbc_do($conn,$sql);
if ($results) {
while (odbc_fetch_into($results,$row)) {
echo $row[0]." ".$row[1]." ".$row[2]."\n";
}
}
$sql='SELECT ID,Category,description FROM card_type WHERE description
LIKE "%PEP%"';
echo "SQL: $sql";
$results = odbc_do($conn,$sql);
if ($results) {
while (odbc_fetch_into($results,$row)) {
echo $row[0]." ".$row[1]." ".$row[2]."\n";
}
}
$sql='SELECT ID,Category,description FROM card_type WHERE
description="PEPPERELL\'S"';
echo "SQL: $sql";
$results = odbc_do($conn,$sql);
if ($results) {
while (odbc_fetch_into($results,$row)) {
echo $row[0]." ".$row[1]." ".$row[2]."\n";
}
}
$sql="SELECT ID,Category,description FROM card_type WHERE
description=\"PEPPERELL'S\"";
echo "SQL: $sql";
$results = odbc_do($conn,$sql);
if ($results) {
while (odbc_fetch_into($results,$row)) {
echo $row[0]." ".$row[1]." ".$row[2]."\n";
}
}
/*
Output
--
SQL: SELECT ID,Category,description FROM card_type WHERE
description='IMPEYS'
355 Other Item IMPEYS
SQL: SELECT ID,Category,description FROM card_type WHERE description
LIKE '%PEP%'
177 Other Item PEPPERELL'S
SQL: SELECT ID,Category,description FROM card_type WHERE description
LIKE "%PEP%"
Warning: SQL error: [OpenLink][ODBC][Driver]Syntax error or access, SQL
state 37000 in SQLExecDirect in /usr/local/.WWW/WEBS/_odbc/test.php3 on
line 42
SQL: SELECT ID,Category,description FROM card_type WHERE
description="PEPPERELL'S"
Warning: SQL error: [OpenLink][ODBC][Driver]Syntax error or access, SQL
state 37000 in SQLExecDirect in /usr/local/.WWW/WEBS/_odbc/test.php3 on
line 50
SQL: SELECT ID,Category,description FROM card_type WHERE
description="PEPPERELL'S"
Warning: SQL error: [OpenLink][ODBC][Driver]Syntax error or access, SQL
state 37000 in SQLExecDirect in /usr/local/.WWW/WEBS/_odbc/test.php3 on
line 58
*/
?>
--
Edit this bug report at http://bugs.php.net/?id=13809&edit=1
#21629 [Fbk->NoF]: very strange bug happens only once in a while
ID: 21629 Updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] -Status: Feedback +Status: No Feedback Bug Type: *Directory/Filesystem functions Operating System: Red Hat Linux 7.2 (Enigma) PHP Version: 4.3.0 New Comment: No feedback was provided for this bug for over 2 weeks, so it is being suspended automatically. If you are able to provide the information that was originally requested, please do so and change the status of the bug back to "Open". Previous Comments: [2003-01-19 23:47:04] [EMAIL PROTECTED] Please let us know if the reinstalling fixes this problem. [2003-01-18 14:36:23] [EMAIL PROTECTED] No, I can not reproduce this on any other machine. Perhaps one of the libraries on the machine is creating all these problems. On the other hand, I really have no tools to find which one, because the occurence is so rare (a few times in 24 hours, but not rare enough for my client to complain, and not even rare enough for my own standards). I am going to reformat this box and install Debian on it, and use the latest stable version of php available on the debian stable update channel. Should you have any suggestions, or even want to access the box to check some stuff, I am available on this email, and also online on ICQ 104495. Thanks, Aric [2003-01-17 20:10:50] [EMAIL PROTECTED] Are you able to reproduce this on any OTHER machine? [2003-01-16 19:51:38] [EMAIL PROTECTED] Some kind person forwarded me to bug number 21310. I have already SEEN this bug as stated before. This is not the same problem! As the subject says, Inclusion works, both absolute and relative. It works well for 5 hours, then one include will fail, will work again very well for 2 more hours, then, again some relative include failes! This is NOT a constant behavior, because if it was, I'm not such an idiot that I wouldn't be able to track it down! My trouble is that it only happens once every few hours, and is unrelated to anything. I made sure the kernel has enough file descriptors, and made sure there is enough space left on the device, and CPU load is never over 0.2! This is definitely a bug, and even if it is not a bug, the error reporting for it is definitely obscure and insucificient. The include path was indeed set to "0" for some reason, and I have changed it in my php.ini to ".:./". This has not helped much. I performed a super-fresh compilation of 4.3.0, without relying on any external software/extension. Whoever manages to shed some light on this will get my most sincere gratitude, as it is a heavy burden on the soul to have such a problem. Thanks again, Aric [2003-01-15 03:17:21] [EMAIL PROTECTED] The include_path in your phpinfo.php output is a bit strange: include_path 0 .:./ What do you have it set as in your php.ini? (in /usr/local/lib/php.ini) 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/21629 -- Edit this bug report at http://bugs.php.net/?id=21629&edit=1
#20302 [Fbk->NoF]: Leaked Descriptors
ID: 20302 Updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] -Status: Feedback +Status: No Feedback Bug Type: Scripting Engine problem Operating System: Linux 2.4.18 PHP Version: 4.2.2 New Comment: No feedback was provided for this bug for over 2 weeks, so it is being suspended automatically. If you are able to provide the information that was originally requested, please do so and change the status of the bug back to "Open". Previous Comments: [2003-01-20 21:54:41] [EMAIL PROTECTED] Could you please check this with using PHP 4.3.0 and Apache 1.3.27 if it's any better? Also, PHP 4.3.0 builds a CLI binary always, it would be nice to know also if that has the same leaks..(you don't have to _install_ php to do that? :) [2002-12-08 11:11:59] [EMAIL PROTECTED] >It would be nice if you could give an exact >description of what descriptors are open for you. The main problem is with apache 2.x. The listing is huge. There are 2 descriptors per website on the machine + main error log + main access log just being leaked by mod_cgi. When testing mod_php, I found 3 additional descriptors being leaked. I guess I incorrectly assumed that this was a php problem. If php does not police or cleanup the environment that php applications run under, then I guess this bug report can be closed. I will also make the apache team aware of this issue, too. My feelings are that apache 2.x really has some problems. If you are curious about the leaked descriptors, visit : http://www.web-insights.net/env_audit The env_audit program has full description and ready to use php script for testing this. There is also a 50 page report that can be downloaded from that page that gives more detail than I can list here. >BTW: The opened script fd can be leaked without >any security impact. Maybe and maybe not. If a hole is found in php, people could use this to overwrite a page making a temporary security problem more permanent. To do this requires first finding another exploit, then you might be able to use this for more mischief. Unless there's a compelling reason not to do so, I would close the fd or set the FD_CLOEXEC flag. My testing calls a program external to PHP using the passthru() function. This external program should not have access to PHP files. So, I leave it to your team. I won't object to closing this bug report if you feel the issue truly lies with apache 2.x. Thanks for looking at it. [2002-12-05 13:09:27] [EMAIL PROTECTED] It would be nice if you could give an exact description of what descriptors are open for you. Like a directory listing ... ls -la /proc/pidofapache/fd BTW: The opened script fd can be leaked without any security impact. And it is an apache bug that the fds are leaked. PHP does no accept (its the apache child that accepts). And mysql etc... sockets are opened by the mysqlclient libs... these are responsible for setting the close on exec flag, not PHP. [2002-12-05 07:27:02] [EMAIL PROTECTED] I got the e-mail stating to try the latest tarball. I downloaded it and grep'ed around. I am not sure how to build a rpm of php that is 100% compatible with RedHat 8.0. The e-mail back was terse and didn't say the problem was replicated or fixed. The tarball has no CHANGELOG. Grep'ing did not show FD_CLOEXEC. Since I am not sure about building a rpm and I cannot find what the fix was, how am I to provide feedback? Was the problem replicated? Did your testing show its now fixed? What files were changed? Are there diffs of the affected code? [2002-12-04 18:16:22] [EMAIL PROTECTED] No feedback was provided. The bug is being suspended because we assume that you are no longer experiencing the problem. If this is not the case and you are able to provide the information that was requested earlier, please do so and change the status of the bug back to "Open". Thank you. The remainder of the comments for this report are too long. To view the rest of the comments, please view the bug report online at http://bugs.php.net/20302 -- Edit this bug report at http://bugs.php.net/?id=20302&edit=1
#22029 [Fbk->NoF]: Segfault on startup using ZE2
ID: 22029 Updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] -Status: Feedback +Status: No Feedback Bug Type: Zend Engine 2 problem Operating System: Redhat PHP Version: 5CVS-2003-02-03 (dev) New Comment: No feedback was provided for this bug for over 2 weeks, so it is being suspended automatically. If you are able to provide the information that was originally requested, please do so and change the status of the bug back to "Open". Previous Comments: [2003-02-03 08:38:48] [EMAIL PROTECTED] excuse me, but from what build was that java.so from? [2003-02-03 08:35:22] [EMAIL PROTECTED] Yep, you were right it was my php.ini file. I was loading java.so from it. I'll make it suspended because the engine shouldn't crash regardless of the situation, if you want I'll dig into it more and find out the details about that module (only one I was loading). [2003-02-03 08:23:07] [EMAIL PROTECTED] What version of libc? and are you sure that any shared extensions are disabled in php.ini? [2003-02-03 07:30:41] [EMAIL PROTECTED] ZE2 is segfaulting on startup in the PHP5 HEAD as well as the snapshot from last Monday (I didn't bother trying go to farther back then that). Checked the other segfault bugs that came up, and configured with --disable-all to make sure it wasn't an automatically turned on module.. Here is the BT: #0 0x081114b4 in zend_register_functions (scope=0x0, functions=0x4001a260, function_table=0x0, type=1) at /home/php/php4-ze2/Zend/zend_API.c:1099 #1 0x08111704 in zend_register_module (module=0x400237a0) at /home/php/php4-ze2/Zend/zend_API.c:1172 #2 0x080941a5 in php_dl (file=0x8183ee8, type=1, return_value=0xb860) at /home/php/php4-ze2/ext/standard/dl.c:242 #3 0x080ee128 in php_load_function_extension_cb (arg=0x8183ee8) at /home/php/php4-ze2/main/php_ini.c:247 #4 0x08108a35 in zend_llist_apply (l=0x8175c3c, func=0x80ee114 ) at /home/php/php4-ze2/Zend/zend_llist.c:190 #5 0x080ee5aa in php_ini_delayed_modules_startup () at /home/php/php4-ze2/main/php_ini.c:499 #6 0x080eb0bc in php_module_startup (sf=0x8174ac0, additional_modules=0x0, num_additional_modules=0) at /home/php/php4-ze2/main/main.c:1284 #7 0x08132530 in main (argc=1, argv=0xbaf4) at /home/php/php4-ze2/sapi/cli/php_cli.c:480 #8 0x400c8306 in __libc_start_main (main=0x8132420 , argc=1, ubp_av=0xbaf4, init=0x8063128 <_init>, fini=0x8133140 <_fini>, rtld_fini=0x4000d2dc <_dl_fini>, stack_end=0xbaec) at ../sysdeps/generic/libc-start.c:129 -- Edit this bug report at http://bugs.php.net/?id=22029&edit=1
#21996 [Fbk->NoF]: apache 1.3.27 crashes with most php-scripts
ID: 21996 Updated by: [EMAIL PROTECTED] Reported By: webmaster at infinity-board dot de -Status: Feedback +Status: No Feedback Bug Type: Apache related Operating System: Windows XP SP1 PHP Version: 5CVS-2003-02-01 (dev) New Comment: No feedback was provided for this bug for over 2 weeks, so it is being suspended automatically. If you are able to provide the information that was originally requested, please do so and change the status of the bug back to "Open". Previous Comments: [2003-02-04 07:49:12] [EMAIL PROTECTED] Please try more recent snapshot. Nobody else has reported this so I suspect you either had a broken build or it's something wrong in your system. Did you try the reboot yet? :) [2003-02-04 06:16:24] webmaster at infinity-board dot de I only have tha newest php4ts.dll in \system32 and no extensions. I don't use any extensions. [2003-02-04 05:38:51] [EMAIL PROTECTED] Most important thing is to make sure you really have only one php4ts.dll in your system and that it's from the latest snapshot package. Also, the extra dlls needed by some extensions need to be up-to-date. Sometimes a reboot is also needed after installation.. [2003-02-03 16:33:13] [EMAIL PROTECTED] Sorry, I missed that you are on windows. Did you remember to move extensions to windows\system32 ? If you did, could you please provide a short script to reproduce this ? [2003-02-01 10:00:24] [EMAIL PROTECTED] Please read this: http://bugs.php.net/bugs-generating-backtrace.php And submit a backtrace (you need to compile PHP with --enable-debug ) And a short reproduce script too. 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/21996 -- Edit this bug report at http://bugs.php.net/?id=21996&edit=1
#14209 [Fbk->NoF]: tux sapi doesn't work when using virtual hosts
ID: 14209 Updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] -Status: Feedback +Status: No Feedback Bug Type: Other web server Operating System: SuSE7.1/kernel-2.4.10/tux-2.1.0 PHP Version: 4.0CVS-2001-11-24 New Comment: No feedback was provided for this bug for over 2 weeks, so it is being suspended automatically. If you are able to provide the information that was originally requested, please do so and change the status of the bug back to "Open". Previous Comments: [2002-10-28 06:42:40] [EMAIL PROTECTED] Please try using this CVS snapshot: http://snaps.php.net/php4-latest.tar.gz For Windows: http://snaps.php.net/win32/php4-win32-latest.zip [2001-11-24 11:12:27] [EMAIL PROTECTED] [yep, I know it's quite experimental that extension,just want to contribute to make it work] If I do virtual_server=0 then it works just fine. When it's on (1) it cannot resolve the filename. I guess when doing: file_handle.filename = SG(request_info).path_translated; [php_tux.c:279] that path is only relative to document root and doesn't contain the virtual server name? -- Edit this bug report at http://bugs.php.net/?id=14209&edit=1
#18963 [Fbk->NoF]: Reproducable crash with simple string functions.
ID: 18963 Updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] -Status: Feedback +Status: No Feedback Bug Type: Scripting Engine problem Operating System: IRIX64 6.5.16f IP25 PHP Version: 4.3.0-dev New Comment: No feedback was provided for this bug for over 2 weeks, so it is being suspended automatically. If you are able to provide the information that was originally requested, please do so and change the status of the bug back to "Open". Previous Comments: [2002-10-28 11:02:53] [EMAIL PROTECTED] Please try using this CVS snapshot: http://snaps.php.net/php4-latest.tar.gz For Windows: http://snaps.php.net/win32/php4-win32-latest.zip [2002-08-21 01:13:40] [EMAIL PROTECTED] I didn't have any problems compiling 4.2.2 or 4.2.1, just the latest snap version gave the problems. It was easily resolved by putting some full paths in. [2002-08-20 23:09:34] [EMAIL PROTECTED] Sounds very suspicious of a bad install of Apache on the headers part. [2002-08-20 23:02:28] [EMAIL PROTECTED] I had problems with a number of apache includes, I had to edit some headers and put in the explicit paths, it didn't seem able to find the proper paths for some headers "os.h, ap_*.h, etc" [2002-08-20 22:12:16] [EMAIL PROTECTED] what sort of problems did you have compiling this? Also updating version 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/18963 -- Edit this bug report at http://bugs.php.net/?id=18963&edit=1
#19363 [Fbk->NoF]: PHP safe mode security problem
ID: 19363 Updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] -Status: Feedback +Status: No Feedback Bug Type: Filesystem function related Operating System: Linux 2.4.2-2smp PHP Version: 4.2.2 New Comment: No feedback was provided for this bug for over 2 weeks, so it is being suspended automatically. If you are able to provide the information that was originally requested, please do so and change the status of the bug back to "Open". Previous Comments: [2002-10-28 10:56:12] [EMAIL PROTECTED] Please try using this CVS snapshot: http://snaps.php.net/php4-latest.tar.gz For Windows: http://snaps.php.net/win32/php4-win32-latest.zip [2002-09-11 19:52:41] [EMAIL PROTECTED] Upgraded to php 4.3.3 --> still having the same problem [2002-09-11 18:57:50] [EMAIL PROTECTED] Hello, using apache 1.3.26, I have safe mode on I have a simple single-line script: safemode.php safemode is owned by wbr:wbr and newsletter.html is owned by root:root as you can see -rw-r--r--1 root root22161 Sep 12 00:17 newsletter.html -rw-r--r--1 wbr wbr43 Sep 12 01:24 safemode.php safemode.php execution simply return 'Resource id #1' without errors related to safe mode, even if the owner of the files is not the same If I change the owner of safemode.php $ chown nobody:nobody safemode.php and reload safemode.php I get the expected warning: Warning: SAFE MODE Restriction in effect. The script whose uid is 99 is not allowed to access newsletter.html owned by uid If I change the user back to wbr:wbr --> No warning Helpful info: $ cat /etc/passwd |grep wbr wbr:x:501:501::/www/wbr:/bin/bash $ cat /usr/local/lib/php.ini |grep safe_mode |grep -v "^;" safe_mode = On safe_mode_gid = Off safe_mode_include_dir = "/usr/local/lib/php" safe_mode_exec_dir = safe_mode_allowed_env_vars = PHP_ safe_mode_protected_env_vars = LD_LIBRARY_PATH sql.safe_mode = Off Hope can help Thanks a lot Edoardo Serra -- Edit this bug report at http://bugs.php.net/?id=19363&edit=1
#19656 [Fbk->NoF]: FastCGI : Wrong SCRIPT_NAME and SCRIPT_FILENAME
ID: 19656
Updated by: [EMAIL PROTECTED]
Reported By: [EMAIL PROTECTED]
-Status: Feedback
+Status: No Feedback
Bug Type: Other web server
Operating System: Linux 2.4.19
PHP Version: 4.2.3
New Comment:
No feedback was provided for this bug for over 2 weeks, so it is
being suspended automatically. If you are able to provide the
information that was originally requested, please do so and change
the status of the bug back to "Open".
Previous Comments:
[2002-10-28 18:51:45] [EMAIL PROTECTED]
It doesn't work :
Fatal error: input in flex scanner failed in - on line 1
Sorry... am I missing something ?
--elk
[2002-10-28 10:46:11] [EMAIL PROTECTED]
Please try using this CVS snapshot:
http://snaps.php.net/php4-latest.tar.gz
For Windows:
http://snaps.php.net/win32/php4-win32-latest.zip
[2002-09-29 07:22:52] [EMAIL PROTECTED]
I don't think this hack still works for PHP < 4.2 because there is no
_SERVER vars... aie...
[2002-09-29 06:54:42] [EMAIL PROTECTED]
When running PHP under FastCGI (with Suexec wrapper enabled), the
variables _SERVER["SCRIPT_NAME"] and _SERVER["SCRIPT_FILENAME"] are
returning the path and filename of the PHP-FCGI binary instead of the
path and filename of the current executing script, that is, the values
of _ENV["SCRIPT_NAME"] and _ENV["SCRIPT_FILENAME"] respectively. This
breaks a lot of scripts relying on just $SCRIPT_NAME and
$SCRIPT_FILENAME;
ie, when setting up this in httpd.conf :
ScriptAlias /fcgi-bin/ /usr/local/apache/bin/
SetHandler fastcgi-script
AddType application/x-httpd-php .php .php3 .php4
Action application/x-httpd-php /fcgi-bin/php.fcgi
When called from a script,
$SCRIPT_NAME becomes : /fcgi-bin/php.fcgi
$SCRIPT_FILENAME becomes : /usr/local/apache/bin/php.fcgi
Versions :
PHP 4.2.3 compiled with --with-fastcgi
mod_fastcgi 2.2.12
Apache 1.3.26
I modified sapi/fastcgi.c to register the correct _SERVER vars, and it
works OK. At line 164, add :
php_register_variable("SCRIPT_NAME",
(SG(request_info).request_uri ? SG(request_info).request_uri:""),
track_vars_array TSRM
LS_CC);
php_register_variable("SCRIPT_FILENAME",
(SG(request_info).path_translated ?
SG(request_info).path_translated:""), track_var
s_array TSRMLS_CC);
Best,
[EMAIL PROTECTED]
--
Edit this bug report at http://bugs.php.net/?id=19656&edit=1
#13035 [Fbk->NoF]: 404 on a .php results in SERVER ERROR when using php as a cgi
ID: 13035 Updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] -Status: Feedback +Status: No Feedback Bug Type: Other web server Operating System: Linux 2.4.6 PHP Version: 4.2.3 New Comment: No feedback was provided for this bug for over 2 weeks, so it is being suspended automatically. If you are able to provide the information that was originally requested, please do so and change the status of the bug back to "Open". Previous Comments: [2002-11-01 09:34:17] [EMAIL PROTECTED] OK, I downloaded and built yesterday's CVS snapshot (php4-200210311500) and the problem is still present: pointing the PHP CGI to a non-existing .php file produces no output, which results in a "missing HTTP headers" error in the Apache error_log. I did not submit the original bug, so I'm not able to reopen this bug myself. BTW, I tried this with an old PHP 3.0.16 CGI to see what it used to do, and PHP3 would produce the following output when pointed to a non-existing PHP file... not quite as good as a real 404 error, but better than nothing: X-Powered-By: PHP/3.0.16 Content-type: text/html Fatal error: Unable to open ttt.php in - on line 0 [2002-10-29 04:24:46] [EMAIL PROTECTED] Please try using this CVS snapshot: http://snaps.php.net/php4-latest.tar.gz For Windows: http://snaps.php.net/win32/php4-win32-latest.zip [2002-10-28 23:27:23] [EMAIL PROTECTED] Please try using this CVS snapshot: http://snaps.php.net/php4-latest.tar.gz For Windows: http://snaps.php.net/win32/php4-win32-latest.zip Reopen to confirm if the problem is in 4.3.0-dev [2002-10-24 08:35:35] [EMAIL PROTECTED] I would like the PHP developers to please consider reopening this bug. I don't think it is bogus. It still happens with PHP 4.2.x: The problem is simple: when using PHP as a CGI and pointing to a non-existing PHP file, instead of a 404 error we receive an empty page or a 500 - Internal Server error from the PHP CGI due to missing HTTP headers. I think the solution is that the PHP CGI should be modified to return a 404 error header when it cannot find the .php file that it is being pointed to. [2002-06-13 18:04:46] [EMAIL PROTECTED] Sorry, but the bug system is not the appropriate forum for asking support questions. 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 Thank you for your interest in PHP. The remainder of the comments for this report are too long. To view the rest of the comments, please view the bug report online at http://bugs.php.net/13035 -- Edit this bug report at http://bugs.php.net/?id=13035&edit=1
#14508 [Fbk->NoF]: Strange default of safe_mode_exec_dir
ID: 14508 Updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] -Status: Feedback +Status: No Feedback Bug Type:PHP options/info functions PHP Version: 4.1.0 New Comment: No feedback was provided for this bug for over 2 weeks, so it is being suspended automatically. If you are able to provide the information that was originally requested, please do so and change the status of the bug back to "Open". Previous Comments: [2002-10-29 16:56:44] [EMAIL PROTECTED] Please try using this CVS snapshot: http://snaps.php.net/php4-latest.tar.gz For Windows: http://snaps.php.net/win32/php4-win32-latest.zip [2001-12-14 05:14:17] [EMAIL PROTECTED] The default for safe_mode_exec_dir is "1". Why? It's hardwired into the source. You cannot override it with --with-exec-dir - this sets PHP_SAFE_MODE_EXEC_DIR and main/main.c has a test for SAFE_MODE_EXEC_DIR, but that's not used anywhere. Proposed fix is to change main/main.c with s/SAVE_MODE_EXEC_DIR/PHP_SAFE_MODE_EXEC_DIR/ and chaning the dafault to use this macro -- Edit this bug report at http://bugs.php.net/?id=14508&edit=1
#19113 [Fbk->NoF]: HTTP status 200 returned on HTTP CONNECT when mod_proxy not in use
ID: 19113 Updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] -Status: Feedback +Status: No Feedback Bug Type: Apache related Operating System: FreeBSD 4.6.2 PHP Version: 4.2.2 New Comment: No feedback was provided for this bug for over 2 weeks, so it is being suspended automatically. If you are able to provide the information that was originally requested, please do so and change the status of the bug back to "Open". Previous Comments: [2002-10-31 11:39:18] [EMAIL PROTECTED] Please try using this CVS snapshot: http://snaps.php.net/php4-latest.tar.gz For Windows: http://snaps.php.net/win32/php4-win32-latest.zip [2002-10-03 13:56:31] [EMAIL PROTECTED] I'm using PHP 4.2.2 and Apache 1.3.26 on RedHat 7.1 I can't get it to act properly at all (renaming the index file didn't work) DirectoryIndex index.html index.php index.htm I have 5 files and 3 directories in the root directory, the only file that is an index is index.html. I tried renaming that to 2index.html , but the CONNECT request just returned a 404. $SERVER['REQUEST_METHOD'] was 'CONNECT' when it parsed index.html, if that's any help. Chris P.S. When I voted on this bug I accidentaly stated it was a different version of PHP when it was in fact the same version. [2002-09-25 15:14:59] [EMAIL PROTECTED] This bug also applies to PHP 4.2.3. [2002-09-23 19:49:30] [EMAIL PROTECTED] A follow-up to the "quick-fix" configuration addition I posted: Despite working around the problem, it seems to partially mess up the default deny/allow setup that Apache comes with by default. For example, using those configuration directives globally will result in allow/deny directives to seemingly have no effect. So please, be cautious when using the configuration fix. This is just more proof that this bug need to be fixed on the Apache level or the PHP4 level (depending on where it is). [2002-08-26 15:14:58] [EMAIL PROTECTED] I believe the following to be a severe bug which relates directly to PHP4 and Apache 1.3: For those of you unfamiliar with HTTP, there is an HTTP command called "CONNECT" which is intended for use with HTTP proxying. Via telnet, one can test for proxy capability by doing the following (input is in bold): $ telnet www.somehost.com 80 Trying ###.###.###.###... Connected to www.somehost.com. Escape character is '^]'. CONNECT www.google.com:80 HTTP/1.0 Host: www.somehost.com Now hit [Enter] twice. If your Apache configuration is proper (and without mod_proxy installed), you should get the following response: HTTP/1.1 405 Method Not Allowed However, this is where the bug shows up. Here are the pre-requisites for it to appear: Must have PHP4 module loaded. Must have index.php listed in Apache DocumentIndex directive. Must have index.php file in the DocumentRoot of the website you're connecting to (in the above example, www.somehost.com). The result of the above HTTP CONNECT when all of the above pre-requistes are met: HTTP/1.1 200 OK [HTTP headers here] [Contents of parsed index.php here; as if visiting the website!] An HTTP response code of 200 should only be sent when the request was legitimate -- a HTTP CONNECT should not be legitimate just because the website in question has an index.php file. You can literally rename index.php to something else (even index.html!) and a correct HTTP status of 405 is returned. I have read the HTTP RFC in full, and it is fairly vague when it comes to dealing with HTTP CONNECT -- however, the Status code section applies to all sections, therefore a Status code of 200 on an HTTP CONNECT when mod_proxy is not loaded is incorrect. Again, this only happens with mod_php4 installed. So why is this a big deal? Well, a slew of online services use proxy scanners to ensure legitimate clients are being used to communicate with their servers; proxy scanners are also used for IRC. The scanners look for a status code of 200 on an HTTP CONNECT. There is a workaround, which is to add the following to your server configuration: Order deny,allow Deny from all This bug may be directly related to bug #17424. Footnote: If this is traced back to be a flaw in Apache's DSO code, then I expect to see it reported as such, so I can forward this entire thread on to the Apache team and make them deal with it. Thanks. -- Edit this bug report at http://bugs.php.net/?id=19113&edit=1
#19886 [Fbk->NoF]: readfile, fread, fpassthru won't work with large files!!!
ID: 19886
Updated by: [EMAIL PROTECTED]
Reported By: [EMAIL PROTECTED]
-Status: Feedback
+Status: No Feedback
Bug Type: Filesystem function related
Operating System: Windows, any Version
PHP Version: 4CVS-2002-10-13
New Comment:
No feedback was provided for this bug for over 2 weeks, so it is
being suspended automatically. If you are able to provide the
information that was originally requested, please do so and change
the status of the bug back to "Open".
Previous Comments:
[2002-10-31 07:59:35] [EMAIL PROTECTED]
Thank you for this bug report. To properly diagnose the problem, we
need a backtrace to see what is happening behind the scenes. To
find out how to generate a backtrace, please read
http://bugs.php.net/bugs-generating-backtrace.php
Once you have generated a backtrace, please submit it to this bug
report and change the status back to "Open". Thank you for helping
us make PHP better.
[2002-10-31 07:01:23] [EMAIL PROTECTED]
The problem can be reproduced using Apache/Win32 using the script
posted at 13 Oct 10:19am.
I tried the newest snapshot (31-Oct-2002 03:28). Furthermore, the
previous snaps and different release versions (>4.2.2) don't work. I
deleted versions < 4.2.1, so I can't test them any more.
[2002-10-31 05:17:56] [EMAIL PROTECTED]
I'm experiencing something similar on Linux Apache using Version 4.1.2.
As far as I know it worked before I upgraded from an earlier version.
My code looks like this:
$file="/path/to/file";
$fp = fopen($file, "r");
$size=filesize($file);
$contents = fread($fp, $size);
fclose($fp);
Header("Content-Type: $type");
Header("Content-Disposition: attachment; filename=$downloadname");
header("Content-Length: $size");
header("Content-Transfer-Encoding: binary");
echo $contents;
filesize() is reporting the size properly. The code works perfectly
for smaller files, but the fread() fails for files larger than 19 MB or
so and I got a page cannot be displayed error. All the files being
downloaded are PDF files.
[2002-10-31 04:34:57] [EMAIL PROTECTED]
None of them has been used (output buffering or ob_gzhandler, or
zlib.output_compression or transparent SID/session rewriting). The
fopen() -> $val = fread()-> echo $val worked fine. The response was
much quicker.
Never minad... I have solved the problem otherwise. And the data have
moved to a differen server with higher capacity.
Regards SelfMan
[2002-10-29 19:13:28] [EMAIL PROTECTED]
and did you try the most recent snapshot as I suggested
on the 13 Oct?
And could you reproduce the issue using a different web server?
The remainder of the comments for this report are too long. To view
the rest of the comments, please view the bug report online at
http://bugs.php.net/19886
--
Edit this bug report at http://bugs.php.net/?id=19886&edit=1
#14897 [Fbk->NoF]: "unable to fork" - cause & solution (well, at least for me)
ID: 14897 Updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] -Status: Feedback +Status: No Feedback Bug Type: Program Execution Operating System: Windows 2000 PHP Version: 4.1.1 New Comment: No feedback was provided for this bug for over 2 weeks, so it is being suspended automatically. If you are able to provide the information that was originally requested, please do so and change the status of the bug back to "Open". Previous Comments: [2002-10-31 14:51:10] [EMAIL PROTECTED] Please try using this CVS snapshot: http://snaps.php.net/php4-latest.tar.gz For Windows: http://snaps.php.net/win32/php4-win32-latest.zip [2002-01-21 07:16:43] [EMAIL PROTECTED] re enable access to cmd.exe for php: if you are using IIS, then PHP will be run using the IWAM_ account. so you would have to set the right for cmd.exe to include this account. if you are using a different web server, then I have no idea what account would need access to cmd.exe re stopping php from prepending "cmd /c ": not that I know of, and hence the bug report that I posted requesting the developers changing it. [2002-01-21 06:32:42] [EMAIL PROTECTED] Is there a way to enable access to cmd.exe so that it is only available to php.exe? Or a way of stopping php prepending "cmd.exe /c " in front of any calls to exec? thanks. [2002-01-17 19:40:26] [EMAIL PROTECTED] this is a suggestion to the developers to do, because the only way for a script writer to solve this is to enabled access to cmd.exe which many would perfer to not have to do. [2002-01-17 05:56:27] [EMAIL PROTECTED] clarification: is this a suggestion of a way to fix the problem myself (so I can call programs), or a suggestion to the developers? 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/14897 -- Edit this bug report at http://bugs.php.net/?id=14897&edit=1
#17314 [Fbk->NoF]: CGI error with doc_root as in php.ini_dist
ID: 17314 Updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] -Status: Feedback +Status: No Feedback Bug Type: IIS related Operating System: Win XP Pro PHP Version: 4.3.0 dev New Comment: No feedback was provided for this bug for over 2 weeks, so it is being suspended automatically. If you are able to provide the information that was originally requested, please do so and change the status of the bug back to "Open". Previous Comments: [2002-10-31 11:55:53] [EMAIL PROTECTED] Please try using this CVS snapshot: http://snaps.php.net/php4-latest.tar.gz For Windows: http://snaps.php.net/win32/php4-win32-latest.zip [2002-07-01 16:08:43] [EMAIL PROTECTED] Veryfied with 4.3.0 snapshot of yesterday. Still the same phenomen. [2002-06-03 14:26:47] [EMAIL PROTECTED] No, I'm sure it's not cgi.force-redirect. The behaviour is changing when commenting out doc_root. Have verified it again. However, I didn't have the problem on a NT 4.0 Server SP6a with IIS 4. Christoph [2002-06-03 12:32:58] [EMAIL PROTECTED] Can't reproduce. Are you sure this is not actually the problem with having cgi.force_redirect set to 1 ? [2002-05-20 14:26:15] [EMAIL PROTECTED] PHP as CGI with IIS 5.1 doesn't work (CGI error) if doc_root is left as it is in php.ini-dist doc_root = However it works if doc_root is commented out: ; doc_root = Same for php.ini-recommended There's also a thread on that in the php-install mailing list. Christoph -- Edit this bug report at http://bugs.php.net/?id=17314&edit=1
#14877 [Fbk->NoF]: HTTP_FDF_DATA not available
ID: 14877 Updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] -Status: Feedback +Status: No Feedback Bug Type: FDF related Operating System: XP Pro PHP Version: 4.3 dev Assigned To: hholzgra New Comment: No feedback was provided for this bug for over 2 weeks, so it is being suspended automatically. If you are able to provide the information that was originally requested, please do so and change the status of the bug back to "Open". Previous Comments: [2002-11-03 11:15:37] [EMAIL PROTECTED] Please try using this CVS snapshot: http://snaps.php.net/php4-latest.tar.gz For Windows: http://snaps.php.net/win32/php4-win32-latest.zip [2002-10-30 15:48:18] [EMAIL PROTECTED] The last one that I tried and that worked was 4.07dev from July,3 2001. Then a dev version from beginning of January 2002 was not working with other symptoms (see original bug report). I then only tried again recently when Hartmut asked me to do so. Meanwhile other people were mailing and asked me if I found a solution as they've had the same problems. [2002-10-29 17:06:01] [EMAIL PROTECTED] What was the version of PHP with which it didn't crash? [2002-10-29 13:36:29] [EMAIL PROTECTED] I did so with snaps from today, same error. If you can use a .mdmp-File (MS-Dump) I can send it. No other extensions loaded, php -i (CLI) at the command line quits with the same error as long as php_fdf.dll is enabled. [2002-10-28 10:43:10] [EMAIL PROTECTED] Try erasing all old versions/files, then re-test... The remainder of the comments for this report are too long. To view the rest of the comments, please view the bug report online at http://bugs.php.net/14877 -- Edit this bug report at http://bugs.php.net/?id=14877&edit=1
#19979 [Fbk->NoF]: Makefile: 'install' target doesn't invoke 'all' or something
ID: 19979 Updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] -Status: Feedback +Status: No Feedback Bug Type: Compile Failure Operating System: FreeBSD 4.7-STABLE PHP Version: 4CVS-2002-10-18 New Comment: No feedback was provided for this bug for over 2 weeks, so it is being suspended automatically. If you are able to provide the information that was originally requested, please do so and change the status of the bug back to "Open". Previous Comments: [2002-11-03 19:53:49] [EMAIL PROTECTED] php-cgi will be installed unless you explicitly specify that you do not want it to be installed via the --disable-cgi flag. The 2nd is likely due to stale configure or config.cache. Grab a clean copy of the CVS, do cvsclean (just to be on the safe side). ./buildconf ./configure make install (It is of course better to do make and then make install as two seperate steps). [2002-10-18 09:01:55] [EMAIL PROTECTED] 1) why does it try to install php-cgi 2) why doesn't make install do the same thing as make && make install? roman@freepuppy ~/install/php4 1049:0 > ./configure --prefix=/home/roman/php --disable-all --enable-cli ... roman@freepuppy ~/install/php4 1050:0 > make install ... /bin/sh libtool --silent --mode=link gcc -g -O2 -prefer-non-pic -static -rpath /usr/home/roman/install/php4/libsext/standard/array.lo ext/standard/base64.lo ext/standard/basic_functions.lo ext/standard/browscap.lo ext/standard/crc32.lo ext/standard/crypt.lo ext/standard/cyr_convert.lo ext/standard/datetime.lo ext/standard/dir.lo ext/standard/dl.lo ext/standard/dns.lo ext/standard/exec.lo ext/standard/file.lo ext/standard/filestat.lo ext/standard/flock_compat.lo ext/standard/formatted_print.lo ext/standard/fsock.lo ext/standard/head.lo ext/standard/html.lo ext/standard/image.lo ext/standard/info.lo ext/standard/iptc.lo ext/standard/lcg.lo ext/standard/link.lo ext/standard/mail.lo ext/standard/math.lo ext/standard/md5.lo ext/standard/metaphone.lo ext/standard/microtime.lo ext/standard/pack.lo ext/standard/pageinfo.lo ext/standard/parsedate.lo ext/standard/quot_print.lo ext/standard/rand.lo ext/standard/reg.lo ext/standard/soundex.lo ext/standard/string.lo ext/standard/scanf.lo ext/standard/syslog.lo ext/standard/type.lo ext/standard/uniqid.lo ext/standard/url.lo ext/standard/url_scanner.lo ext/standard/var.lo ext/standard/versioning.lo ext/standard/assert.lo ext/standard/strnatcmp.lo ext/standard/levenshtein.lo ext/standard/incomplete_class.lo ext/standard/url_scanner_ex.lo ext/standard/ftp_fopen_wrapper.lo ext/standard/http_fopen_wrapper.lo ext/standard/php_fopen_wrapper.lo ext/standard/credits.lo ext/standard/css.lo ext/standard/var_unserializer.lo ext/standard/ftok.lo ext/standard/aggregation.lo ext/standard/sha1.lo regex/regcomp.lo regex/regexec.lo regex/regerror.lo regex/regfree.lo TSRM/TSRM.lo TSRM/tsrm_strtok_r.lo TSRM/tsrm_virtual_cwd.lo main/main.lo main/snprintf.lo main/spprintf.lo main/php_sprintf.lo main/safe_mode.lo main/fopen_wrappers.lo main/alloca.lo main/php_ini.lo main/SAPI.lo main/rfc1867.lo main/php_content_types.lo main/strlcpy.lo main/strlcat.lo main/mergesort.lo main/reentrancy.lo main/php_variables.lo main/php_ticks.lo main/streams.lo main/network.lo main/php_open_temporary_file.lo main/php_logos.lo main/output.lo main/memory_streams.lo main/user_streams.lo Zend/zend_language_parser.lo Zend/zend_language_scanner.lo Zend/zend_ini_parser.lo Zend/zend_ini_scanner.lo Zend/zend_alloc.lo Zend/zend_compile.lo Zend/zend_constants.lo Zend/zend_dynamic_array.lo Zend/zend_execute_API.lo Zend/zend_highlight.lo Zend/zend_llist.lo Zend/zend_opcode.lo Zend/zend_operators.lo Zend/zend_ptr_stack.lo Zend/zend_stack.lo Zend/zend_variables.lo Zend/zend.lo Zend/zend_API.lo Zend/zend_extensions.lo Zend/zend_hash.lo Zend/zend_list.lo Zend/zend_indent.lo Zend/zend_builtin_functions.lo Zend/zend_sprintf.lo Zend/zend_ini.lo Zend/zend_qsort.lo Zend/zend_multibyte.lo Zend/zend_execute.lo sapi/cgi/cgi_main.lo sapi/cgi/getopt.lo main/internal_functions.lo -lcrypt -lm -lcrypt -o libphp4.la Installing PHP SAPI module cp: sapi/cgi/php-cgi: No such file or directory *** Error code 1 Stop in /usr/home/roman/install/php4. -- Edit this bug report at http://bugs.php.net/?id=19979&edit=1
#18699 [Fbk->NoF]: php.ini problems
ID: 18699 Updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] -Status: Feedback +Status: No Feedback Bug Type: Apache2 related Operating System: Windows NT 5.0 build 2195 PHP Version: 4.2.2 New Comment: No feedback was provided for this bug for over 2 weeks, so it is being suspended automatically. If you are able to provide the information that was originally requested, please do so and change the status of the bug back to "Open". Previous Comments: [2002-11-03 10:55:09] [EMAIL PROTECTED] Please try using this CVS snapshot: http://snaps.php.net/php4-latest.tar.gz For Windows: http://snaps.php.net/win32/php4-win32-latest.zip [2002-08-02 05:49:26] [EMAIL PROTECTED] Installed with Apache 2.0.39, as a module. Bot in install.txt and when you run phpinfo() it says you should put the php.ini file in your system dir c:\winnt. If the php.ini file is put there, it isn't used. It has to be put in c:\winnt\system32 where php4ts.dll is to work. But then in phpinfo it says "Configuration File (php.ini) Path C:\WINNT\php.ini" though it is in c:\WINNT\system32\. -- Edit this bug report at http://bugs.php.net/?id=18699&edit=1
#19567 [Fbk->NoF]: Access Violation at memory address 77F83941
ID: 19567 Updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] -Status: Feedback +Status: No Feedback Bug Type: IIS related Operating System: Windoes 2000 SP2 PHP Version: 4.2.3 New Comment: No feedback was provided for this bug for over 2 weeks, so it is being suspended automatically. If you are able to provide the information that was originally requested, please do so and change the status of the bug back to "Open". Previous Comments: [2002-11-03 10:51:24] [EMAIL PROTECTED] Please try using this CVS snapshot: http://snaps.php.net/php4-latest.tar.gz For Windows: http://snaps.php.net/win32/php4-win32-latest.zip [2002-09-25 16:50:34] [EMAIL PROTECTED] Thanks. I think this is entirely possible. I have tried to check the error on apache but am on work time and we are a microsoft shop. So i'm stuck with IIS. The rest of php seems to work fine except for the print array function that crashes the web server. oh well [2002-09-25 04:21:49] [EMAIL PROTECTED] I don't know phpMySearch but since you mention php_curl, it could be the same problem with CURL as described in bug 19301. Just a thought. It could also be something completely different. [2002-09-24 18:11:52] [EMAIL PROTECTED] changed status [2002-09-24 17:45:43] [EMAIL PROTECTED] Tried the latest snapshot. Still get the same error. this is the output from the spider.php file start: http://csmtemlst-web/development URL = (begin >)=> http://csmtemlst-web/development need parse start load PHP has encountered an Access Violation at 77F83941 The web server is a Compaq ProLiant DL360 G2 Dual processor Any ideas 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/19567 -- Edit this bug report at http://bugs.php.net/?id=19567&edit=1
#6585 [Fbk->NoF]: OCILogOff
ID: 6585 Updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] -Status: Feedback +Status: No Feedback Bug Type: OCI8 related Operating System: Linux 2.2.17 PHP Version: 4.0.2 New Comment: No feedback was provided for this bug for over 2 weeks, so it is being suspended automatically. If you are able to provide the information that was originally requested, please do so and change the status of the bug back to "Open". Previous Comments: [2002-11-03 11:21:25] [EMAIL PROTECTED] Please try using this CVS snapshot: http://snaps.php.net/php4-latest.tar.gz For Windows: http://snaps.php.net/win32/php4-win32-latest.zip [2001-01-08 05:25:56] [EMAIL PROTECTED] it still happens - but the current design (reusing server-connectiond for multiple logins on the _same_ page) doesn't make it easy to implement. [2001-01-07 19:27:09] [EMAIL PROTECTED] Does this happen with PHP 4.0.4 ?? --Jani [2000-09-06 18:16:09] [EMAIL PROTECTED] OCILogOff has to be put back in place. If a user initiates a persistent connection to the server, and the DBA changes any of the procedures/functions within the database, the connection has to be closed and reopened. As it stands right now, when the above happens, the entire web server needs to be restarted. Additionally, if the server is restarted in the middle of the connection, oci_ping does not work correctly. That is, it doesn't recognize correctly that the connection has died and it needs to reconnect, thus spitting out error messages back to the user. -- Edit this bug report at http://bugs.php.net/?id=6585&edit=1
#14886 [Fbk->NoF]: Access Violation in error handler with PEAR DB (ISAPI)
ID: 14886
Updated by: [EMAIL PROTECTED]
Reported By: [EMAIL PROTECTED]
-Status: Feedback
+Status: No Feedback
Bug Type: IIS related
Operating System: Win2000
PHP Version: 4.1.1
New Comment:
No feedback was provided for this bug for over 2 weeks, so it is
being suspended automatically. If you are able to provide the
information that was originally requested, please do so and change
the status of the bug back to "Open".
Previous Comments:
[2002-11-03 11:16:05] [EMAIL PROTECTED]
Please try using this CVS snapshot:
http://snaps.php.net/php4-latest.tar.gz
For Windows:
http://snaps.php.net/win32/php4-win32-latest.zip
[2002-01-07 01:20:21] [EMAIL PROTECTED]
I have simplified the crash to the following script (note that $obj is
null). The bug does not happen when $testmysql = false.
test start";
if ($testmysql) {
$conn = mysql_connect('localhost','root');
}
$obj->run();
print "test end";
?>
I had to run "ab -n2 -c10 " several times before problems
started to occur on a W2k IIS server receiving no other visitors and
had just been restarted.
This is ApacheBench, Version 1.3c <$Revision: 1.45 $> apache-1.3
Copyright (c) 1996 Adam Twiss, Zeus Technology Ltd,
http://www.zeustech.net/
Copyright (c) 1998-2000 The Apache Group, http://www.apache.org/
Server Software:Microsoft-IIS/5.0
Server Hostname:jaguar
Server Port:80
Document Path: /php/err.php
Document Length:145 bytes
Concurrency Level: 10
Time taken for tests: 184.950 seconds
Complete requests: 2
Failed requests:556
(Connect: 0, Length: 556, Exceptions: 0)
Non-2xx responses: 555
Total transferred: 5504927 bytes
HTML transferred: 2847858 bytes
Requests per second:108.14
Transfer rate: 29.76 kb/s received
Connnection Times (ms)
min avg max
Connect:0 022
Processing: 490 466
Total: 490 488
[2002-01-06 06:15:53] [EMAIL PROTECTED]
I ran ApacheBench on a PEAR DB script (see below), and IIS (ISAPI mode)
will die eventually. It is so bad that often "iisreset" is unable to
restart IIS.
The ab command I used:
ab -n1 -c10
with the following results:
This is ApacheBench, Version 1.3c <$Revision: 1.45 $> apache-1.3
Copyright (c) 1996 Adam Twiss, Zeus Technology Ltd,
http://www.zeustech.net/
Copyright (c) 1998-2000 The Apache Group, http://www.apache.org/
Server Software:Microsoft-IIS/5.0
Server Hostname:jaguar
Server Port:80
Document Path: /lens/adodb/peartest.php
Document Length:142 bytes
Concurrency Level: 10
Time taken for tests: 269.158 seconds
Complete requests: 1
Failed requests:5272
(Connect: 0, Length: 5272, Exceptions: 0)
Non-2xx responses: 1868
Total transferred: 1891906 bytes
HTML transferred: 769177 bytes
Requests per second:37.15
Transfer rate: 7.03 kb/s received
Connnection Times (ms)
min avg max
Connect:0 0 5
Processing: 2 268 2771
Total: 2 268 2776
The interesting thing is that the crash only happens when an invalid
SQL statement is entered in the script below(notice the column
"badcolumn" which does not exist). If a valid SQL statement is entered
("badcolumn" is removed), no crash occurs, and ApacheBench runs fine.
So I guess it is some problem with PHP's error-handler or MySQL
extension not being thread safe. No dll extensions were installed.
Standard pre-compiled PHP downloaded from php.net was used.
John Lim
=== THE SCRIPT ===
query('select
badcolumn,productid,productname,unitsinstock,unitprice from
products');
while (DB_OK === $rs->fetchInto($fields)) {
$id=$fields[0];
$name=$fields[1];
$unitsinstock=$fields[2];
$unitprice=$fields[3];
print "$id, $name, $unitsinstock, $unitprice";
}
$rs->free();
?>
--
Edit this bug report at http://bugs.php.net/?id=14886&edit=1
#19343 [Fbk->NoF]: array_rand does not return keys randomly
ID: 19343
Updated by: [EMAIL PROTECTED]
Reported By: [EMAIL PROTECTED]
-Status: Feedback
+Status: No Feedback
Bug Type: Arrays related
Operating System: WinXP
PHP Version: 4.2.3
New Comment:
No feedback was provided for this bug for over 2 weeks, so it is
being suspended automatically. If you are able to provide the
information that was originally requested, please do so and change
the status of the bug back to "Open".
Previous Comments:
[2002-11-04 18:43:17] [EMAIL PROTECTED]
Please try using this CVS snapshot:
http://snaps.php.net/php4-latest.tar.gz
For Windows:
http://snaps.php.net/win32/php4-win32-latest.zip
I've just tested this function using latest CVS (unstable) in Windows
XP. The code from your example has worked properly. Therefor I am
closing the bug report.
[2002-11-04 16:34:28] [EMAIL PROTECTED]
I see that another person has reproduced the bug. In my original
submission I specified my OS as Windows XP. [EMAIL PROTECTED] may have not
tested the function on windows, therefore I think it warrants
reopening. My example is sufficient to quickly reproduce the bug.
[2002-10-04 17:23:37] [EMAIL PROTECTED]
Well - I experienced the same problems (array_rand() is [still] not
random) in a Windows environment as [EMAIL PROTECTED] does. I actually
was looking forward to a new release as this 'bug' was reported to be
corrected and found the 4.2.3 release to act the same wrong way than
'before'.
This must be a problem on the Windows side, for in the Linux
environment I really get random values ...
[2002-09-17 22:08:34] [EMAIL PROTECTED]
Sorry, but the bug system is not the appropriate forum for asking
support questions. 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
Thank you for your interest in PHP.
I've tried this a few dosen times and the results were quite random.
Please keep in mind that with a small array, such as the one in your
example, there are only 24 possible combinations. Which means, that on
average every 24th run you'll get an 'unsorted' array.
[2002-09-10 14:09:42] [EMAIL PROTECTED]
I called array_rand($my_array, count($my_array)). I expected array_rand
to return the keys of $my_array in random order. I actually received
the keys in almost the same order each time. $my_array was a 4 element
array and the third element's key never changed position. I tried using
srand also, but it produced same results. On an older version of
php(4.1.2) the function worked as expected.
script on WinXP php4.2.3:
$numbers = range (1,4);
$rand_keys = array_rand ($numbers, count($numbers));
foreach ($rand_keys as $val) {
print $numbers[$val]."\n";
}
--
Edit this bug report at http://bugs.php.net/?id=19343&edit=1
#20260 [Fbk->NoF]: Cookies set on Remote Host but not on localhost
ID: 20260
Updated by: [EMAIL PROTECTED]
Reported By: [EMAIL PROTECTED]
-Status: Feedback
+Status: No Feedback
Bug Type: Session related
Operating System: Windows 2000 Professional
PHP Version: 4.2.1
New Comment:
No feedback was provided for this bug for over 2 weeks, so it is
being suspended automatically. If you are able to provide the
information that was originally requested, please do so and change
the status of the bug back to "Open".
Previous Comments:
[2002-11-05 09:58:43] [EMAIL PROTECTED]
Please try using this CVS snapshot:
http://snaps.php.net/php4-latest.tar.gz
For Windows:
http://snaps.php.net/win32/php4-win32-latest.zip
[2002-11-05 09:55:11] [EMAIL PROTECTED]
I installed php as a module on apache2 folllowing the standard set up.
I have a user logon screen which works on a remote server but not when
developing and testing on a stand alone machine that is a local server.
I hold the username and passwords on mysql and ask the user for their
username and password which gets sent to another .php page which first
of all sets the following cookies
setcookie("email",$email,time()+1800);
setcookie ("password",$password,time()+1800);
Then verifies this against the database and if succesfull redirects to
the 'members area' where the cookies are set again otherwise it
redirects to a logout page. [Which is where i get sent on the local
machine]
I have tried the following formats for the setcookie and all
combinations including setting the expiry time to 8000.
setcookie("email",$_POST["email"],time()+1800);
setcookie ("password",$_POST["password"],time()+1800);
setcookie("email",$email,"time()+1800");
setcookie ("password",$password,"time()+1800");
The database authentication is being succeful, it is just that the
cookies are not being set on the local machine, as when I hit the
members area I set the email value to another variable, set the cooies
as before, then alert() the old value [before the $email was reset by
the new setcookie() command.
I have the following lines set in my php.ini
register_globals = On
variables_order = "EGPCS"
Do you have any idea why my local machine is not setting the cookies???
Please help
--
Edit this bug report at http://bugs.php.net/?id=20260&edit=1
#20422 [Fbk->NoF]: transaction function to MSSQL server
ID: 20422
Updated by: [EMAIL PROTECTED]
Reported By: [EMAIL PROTECTED]
-Status: Feedback
+Status: No Feedback
Bug Type: Feature/Change Request
Operating System: LINUX
PHP Version: 4.2.3
New Comment:
No feedback was provided for this bug for over 2 weeks, so it is
being suspended automatically. If you are able to provide the
information that was originally requested, please do so and change
the status of the bug back to "Open".
Previous Comments:
[2002-11-14 03:48:37] [EMAIL PROTECTED]
because I need test after each query, if it OK or not. If I have a PHP
code for ex. Interbase I write
ibase_tran();
ibase_query();
..
ibase_commit();
and It's all
[2002-11-14 03:42:46] [EMAIL PROTECTED]
What is wrong with running a query like mssql_query("BEGIN
TRANSACTION") ?
[2002-11-14 03:41:38] [EMAIL PROTECTED]
I need function for MSSQL server for transaction, like mssql_tran,
mssql_commit, mssql_rollback. Thank you very much for your work on this
problem. It´s will be important function for me .
--
Edit this bug report at http://bugs.php.net/?id=20422&edit=1
#20742 [NEW]: function to check if dir is allowed through open_basedir-directive
From: [EMAIL PROTECTED]
Operating system: Linux
PHP version: 4.2.3
PHP Bug Type: Feature/Change Request
Bug description: function to check if dir is allowed through open_basedir-directive
I needed to check, whether a directory is allowed through open_basedir..
This should be in the php-functions.
My solution (not tested under windows):
function inOpenBasedir($dir) {
$openBasedir = ini_get('open_basedir');
if (empty($openBasedir)) {
return true;
}
foreach (explode(':', $openBasedir) as $basedir)
{
if( strlen($basedir) > strlen($dir) )
{
// Check, if only a '\' is needed at the end of $dir
if( $basedir == ($dir . "/") )
{
return true;
}
}
else
{
// Check if basedir and dir are the same..
if( $basedir == $dir )
{
return true;
}
else
{
// open_basedir can be a prefix -> checking whether
// dir starts with basedir or not
if( strncmp($basedir, $dir, strlen($basedir)) == 0)
{
return true;
}
}
}
}
return false;
}
--
Edit bug report at http://bugs.php.net/?id=20742&edit=1
--
Try a CVS snapshot: http://bugs.php.net/fix.php?id=20742&r=trysnapshot
Fixed in CVS: http://bugs.php.net/fix.php?id=20742&r=fixedcvs
Fixed in release: http://bugs.php.net/fix.php?id=20742&r=alreadyfixed
Need backtrace: http://bugs.php.net/fix.php?id=20742&r=needtrace
Try newer version: http://bugs.php.net/fix.php?id=20742&r=oldversion
Not developer issue:http://bugs.php.net/fix.php?id=20742&r=support
Expected behavior: http://bugs.php.net/fix.php?id=20742&r=notwrong
Not enough info:http://bugs.php.net/fix.php?id=20742&r=notenoughinfo
Submitted twice:http://bugs.php.net/fix.php?id=20742&r=submittedtwice
register_globals: http://bugs.php.net/fix.php?id=20742&r=globals
PHP 3 support discontinued: http://bugs.php.net/fix.php?id=20742&r=php3
Daylight Savings: http://bugs.php.net/fix.php?id=20742&r=dst
IIS Stability: http://bugs.php.net/fix.php?id=20742&r=isapi
#20542 [Fbk->NoF]: 0+0=4G on aix4.3 (64bits)
ID: 20542
Updated by: [EMAIL PROTECTED]
Reported By: [EMAIL PROTECTED]
-Status: Feedback
+Status: No Feedback
Bug Type: Math related
Operating System: aix 4.3.3.0
PHP Version: 4.2.3
New Comment:
No feedback was provided for this bug for over 2 weeks, so it is
being suspended automatically. If you are able to provide the
information that was originally requested, please do so and change
the status of the bug back to "Open".
Previous Comments:
[2002-11-27 18:54:59] [EMAIL PROTECTED]
Could this be an issue with the C library used on AIX? On a 64 bit
platform (64sparc) I cannot replicate the problem using PHP 4.2.3.
[2002-11-22 02:47:23] [EMAIL PROTECTED]
I am sorry but on this specific platform
does result in 4294967294, really!
And as well.
[2002-11-21 17:25:14] [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.
string cancatination is done using . not , in PHP.
Results in 0 on any platform.
[2002-11-21 05:45:55] [EMAIL PROTECTED]
Script:
Output of script on php 4.2.3:
0+0=4294967294
which is equal to 2^32-2
(Output of script on php 4.1.2 and 4.0.6:
0+0=4294967296
which is equal to 2^32).
In general, all simple additions and multiplications produce huge
numbers:
0+0=4294967294
0+1=4294967295
1+0=4294967295
1+1=4294967296
0-0=0
0-1=-1
1-0=1
1-1=0
0*0=3.5178585246345E+18
0*1=3.5178585265101E+18
1*0=3.5178585265101E+18
1*1=3.5178585283857E+18
0/1=0
1/1=1
2/1=2
2/2=1
Installation issues
# gcc -v
Reading specs from
/usr/local/lib/gcc-lib/rs6000-ibm-aix4.3.3.0/2.95.3/specs
gcc version 2.95.3 20010315 (release)
# make -v
GNU Make version 3.79.1, by Richard Stallman and Roland McGrath.
Built for rs6000-ibm-aix4.3.3.0
# tar -xf apache_1.3.20.tar
# cd apache_1.3.20
# ./configure --enable-module=most
# cd ..
# tar -xf php-4.2.3.tar
# cd php-4.2.3
# ./configure --without-mysql --with-apache=../apache_1.3.20
--enable-static --with-iodbc=/usr/local --enable-track-vars
# make
# make install
# cd ..
# cd apache_1.3.20
# configure --enable-module=most
--activate-module=src/modules/php4/libphp4.a
# make
# make install
I don't know if it is very relevant but the rs6000 on which aix4.3 is
running
is a 64bits machine. The c program
int main()
{
printf("long=%dbits\n",8*sizeof(long));
return 0;
}
outputs 'long=64bits' when compiled with 'cc -q64', while when
compiled
with 'gcc' it outputs 'long=32bits'.
Thanks very much in advance,
Rein van Vliet
--
Edit this bug report at http://bugs.php.net/?id=20542&edit=1
#20703 [Fbk->NoF]: session object's array is restored corruptly
ID: 20703
Updated by: [EMAIL PROTECTED]
Reported By: [EMAIL PROTECTED]
-Status: Feedback
+Status: No Feedback
Bug Type: Session related
Operating System: debian woody latest
PHP Version: 4.2.2
New Comment:
No feedback was provided for this bug for over 2 weeks, so it is
being suspended automatically. If you are able to provide the
information that was originally requested, please do so and change
the status of the bug back to "Open".
Previous Comments:
[2002-11-29 00:57:17] [EMAIL PROTECTED]
Not enough information was provided for us to be able
to handle this bug. Please re-read the instructions at
http://bugs.php.net/how-to-report.php
If you can provide more information, feel free to add it
to this bug and change the status back to "Open".
Thank you for your interest in PHP.
[2002-11-28 13:57:59] [EMAIL PROTECTED]
I'am not sure, if this is a in bug php, could be in my code, but I have
looked my code over and over and could not find anything...
So I describe my problem:
I have a session object, and it has an array variable.
In the code I do some array_shift, and array_push on one of the
elements of this array, wich is also an array. And I do something like
this:
"get" return by reference from the session objects array:
$keyArray=&$object->get("key");
then I do array_shift, and array_push to maintain a FIFO like thing to
store the previous pagenames.
Now the problem:
normally this works in a number of pages, but in case of one page it
acts strangely: for some reason an extra element into the array appears
like this:
normally the array values should change when going from page5 to page6
from (now I am on page5):
page1
page2
page3
page4
page5
into (here there is a request for a new page: page6):
page2
page3
page4
page5
page6
but instead !!! it changes to:
page1
page5
page1
page6
page1
I tried to track down where this happens, and I found out, that is
happening between the __sleep and __wakeup methods, which would mean,
that serialize, and unserialize does not work correctly.
Another wery strange thing is that this work perfecly on the local
development server, which runs the same version of php...
so that's it... I am going mad now! bye..
--
Edit this bug report at http://bugs.php.net/?id=20703&edit=1
#20720 [Fbk->NoF]: ps_files_cleanup_dir
ID: 20720 Updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] -Status: Feedback +Status: No Feedback Bug Type: Session related Operating System: Windows 2000 Server PHP Version: 4.2.3 New Comment: No feedback was provided for this bug for over 2 weeks, so it is being suspended automatically. If you are able to provide the information that was originally requested, please do so and change the status of the bug back to "Open". Previous Comments: [2002-12-04 08:51:49] [EMAIL PROTECTED] I've got the same symptoms, only system is diffrent. I'm using PLD Linux 1.0 (kernel 2.4.19) with PHP 4.2.3 Info displayed on my page (it is shown only ocassionaly, not every time): Notice: ps_files_cleanup_dir: opendir(/var/run/php) failed: Permission denied (13) in /home/php-include/default/ThLogin.inc on line 55 Line 55 contains a session_start(); only. Below are some infos generated by phpInfo: (maybe this will help somebody) SystemLinux ep09 2.2.21 #1 SMP Mon Aug 19 22:15:18 UTC 2002 i686 Pentium_III_(Coppermine) unknown PLD Linux Build DateOct 21 2002 15:26:41 Configure Command './configure' 'LDFLAGS=-s' 'CFLAGS=-O2 -march=i686 -DEAPI=1 -I/usr/X11R6/include' 'CXXFLAGS=-O2 -march=i686' 'FFLAGS=-O2 -march=i686' 'CPPFLAGS=' 'CC=i686-pld-linux-gcc' 'CXX=g++' '--build=i686-pld-linux' '--prefix=/usr' '--exec-prefix=/usr' '--bindir=/usr/bin' '--sbindir=/usr/sbin' '--sysconfdir=/etc/php' '--datadir=/usr/share' '--includedir=/usr/include' '--libdir=/usr/lib' '--libexecdir=/usr/lib' '--localstatedir=/var' '--sharedstatedir=/usr/com' '--mandir=/usr/share/man' '--infodir=/usr/share/info' '--with-apxs=/usr/sbin/apxs' '--with-config-file-path=/etc/php' '--with-exec-dir=/usr/bin' '--disable-debug' '--enable-bcmath=shared' '--enable-calendar=shared' '--disable-cli' '--enable-ctype=shared' '--enable-dba=shared' '--enable-dbx=shared' '--enable-dio=shared' '--enable-exif=shared' '--enable-ftp=shared' '--enable-gd-native-ttf' '--enable-magic-quotes' '--enable-mbstring=shared' '--disable-mbstr-enc-trans' '--enable-mbregex' '--enable-overload=shared' '--disable-pcntl' '--enable-posix=shared' '--enable-session' '--enable-shared' '--enable-shmop=shared' '--enable-sysvsem=shared' '--enable-sysvshm=shared' '--enable-track-vars' '--enable-trans-sid' '--enable-safe-mode' '--enable-sockets=shared' '--enable-ucd-snmp-hack' '--enable-wddx=shared' '--enable-xml=shared' '--enable-xslt=shared' '--enable-yp=shared' '--with-bz2=shared' '--with-cpdflib=shared' '--with-crack=shared' '--with-curl=shared' '--without-db2' '--with-db3' '--with-dbase=shared' '--with-dom=shared' '--with-dom-xslt=shared' '--with-dom-exslt=shared' '--with-expat-dir=shared,/usr' '--with-iconv=shared' '--with-filepro=shared' '--with-freetype-dir=shared' '--with-gettext=shared' '--with-gd=shared' '--with-gdbm' '--with-gmp=shared' '--with-hyperwave=shared' '--with-imap=shared' '--with-imap-ssl' '--with-jpeg-dir=shared,/usr' '--with-ldap=shared' '--with-mcal=shared,/usr' '--with-mcrypt=shared' '--with-mhash=shared' '--with-ming=shared' '--with-mm' '--with-mnogosearch=shared,/usr' '--with-msession=shared' '--with-mysql=shared,/usr' '--with-mysql-sock=/var/lib/mysql/mysql.sock' '--with-openssl=shared' '--with-pcre-regex=shared' '--with-pdflib=shared' '--with-pear=/usr/share/pear' '--with-pgsql=shared,/usr' '--with-png-dir=shared,/usr' '--with-pspell=shared' '--with-recode=shared' '--with-regex=php' '--with-sablot-js=shared,no' '--with-snmp=shared' '--with-sybase-ct=shared,/usr' '--with-t1lib=shared' '--with-tiff-dir=shared,/usr' '--with-unixODBC=shared' '--with-xmlrpc=shared,/usr' '--with-xslt-sablot=shared' '--with-yaz=shared' '--with-zip=shared' '--with-zlib=shared' '--with-zlib-dir=shared' [2002-11-29 06:29:02] [EMAIL PROTECTED] Please try using this CVS snapshot: http://snaps.php.net/php4-latest.tar.gz For Windows: http://snaps.php.net/win32/php4-win32-latest.zip [2002-11-29 06:19:12] [EMAIL PROTECTED] I a simple script i got the following error notice. Notice: ps_files_cleanup_dir: opendir(F:\php\sessions) failed: Invalid argument (22) in ... on line 11 On line eleven in this script only a session_start() is called. The permissions are set correctly, because the script is able to write, edit and delete the session files with the filesystem functions. I asked in the german php newsgroup and they told me, that this could be a bug. Systeminformation: -- PHP-Version : 4.2.3 Operatingsystem : Windows 2000 Advanced Server WebServer : IIS 5.0 Sessionsettings: -- session.save_handler = files session.save_path = F:\php\sessions session.use_cookies = 1 session.name = sid se
#20704 [Fbk->NoF]: reproducible crash
ID: 20704 Updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] -Status: Feedback +Status: No Feedback Bug Type: MSSQL related Operating System: Windows2000+SP3/Dual PHP Version: 4.3.0RC2 New Comment: No feedback was provided for this bug for over 2 weeks, so it is being suspended automatically. If you are able to provide the information that was originally requested, please do so and change the status of the bug back to "Open". Previous Comments: [2002-11-29 00:58:26] [EMAIL PROTECTED] Not enough information was provided for us to be able to handle this bug. Please re-read the instructions at http://bugs.php.net/how-to-report.php If you can provide more information, feel free to add it to this bug and change the status back to "Open". Thank you for your interest in PHP. [2002-11-28 22:05:07] [EMAIL PROTECTED] Good news: 4.2.3 doesn't crash so far. I upgraded because after some time I would randomly get Access Violations. But I prefer to have a few here and there than 100% of the time . [2002-11-28 22:04:19] [EMAIL PROTECTED] Could you show the smallest possible version of the script, which causes the problem? [2002-11-28 14:30:33] [EMAIL PROTECTED] I just tried ISAPI with RC2; first script load is Ok, resubmit and it's an access violation. [2002-11-28 14:16:28] [EMAIL PROTECTED] It's a flat PHP setup with only mssql module loaded. Since the last MSSQL2000 (SP2+hotfix) and MDAC 2.7, SQL queries returning more than a few results crash (either Access Violation using ISAPI, or no output at all with php-cgi.exe past the mssql_query() call). Each time I install a different php build, the first script load will output something before dying in the middle of returning results; reloading the page will give CGI errors. Weird thing is, calling php.exe on the command line works each time; calling php-cgi.exe doesn't (problem described above show up). I can't even move those scripts to Unix, since some are using mssql_next_result() which Sybase doesn't provide. Ouch! It looks like using PHP to talk to MSSQL is not a good idea on any OS. Thanks for your help, -Martin -- Edit this bug report at http://bugs.php.net/?id=20704&edit=1
#17302 [Fbk->NoF]: can't pass result sets between functions
ID: 17302
Updated by: [EMAIL PROTECTED]
Reported By: [EMAIL PROTECTED]
-Status: Feedback
+Status: No Feedback
Bug Type: MSSQL related
Operating System: W2K
PHP Version: 4.2.1
New Comment:
No feedback was provided for this bug for over 2 weeks, so it is
being suspended automatically. If you are able to provide the
information that was originally requested, please do so and change
the status of the bug back to "Open".
Previous Comments:
[2002-12-03 13:53:44] [EMAIL PROTECTED]
Two lines from your sample code indicates that you are calling
'get_company_list' but the function is named 'get_company_db'. Could
this be the problem ?
[2002-05-17 23:08:42] [EMAIL PROTECTED]
Using PHP 4.2.1 on Apache in W2K, connecting to MSSQL7 also on W2K. The
db connection seems to work fine and I get data returned. The problem
is when I try to split the data retrieval in one function, and then
pass the result set back to another script. No data gets returned and
my script hangs for a while. If I run the retrieval in-line with the
display script, things are fine.
//* Does work *//
$conn = db_connect_user();
if ($conn==false)
return false;
$result = mssql_query("select id, name, db_name
from rm_company", $conn);
//Loop through and gather the info about the orders for this customer
$count = mssql_num_rows($result);
for($i = 0; $i < $count; $i++) {
$company_list[$i][0]=mssql_result($result,$i,0);
$company_list[$i][1]=mssql_result($result,$i,1);
$company_list[$i][2]=mssql_result($result,$i,2);
}
if(!($company_list==false))
{
$list_count = count($company_list);
// etc.
**
//*Does not work*//
..top of script..
$company_list = get_company_list();
if(!($company_list==false))
{
$list_count = count($company_list);
..further down script/in another script (have tried both)..
function get_company_db()
{ $conn = db_connect_user();
if ($conn==false)
return false;
$result = mssql_query("select id, name, db_name
from rm_company", $conn);
if (!$result)
return false; // not found
else if (mssql_num_rows($result)==0)
return false; // no orders found
else
{
//Loop through and gather the info about the orders for this
customer
{
$count = mssql_num_rows($result);
for($i = 0; $i < $count; $i++) {
$company_list[$i][0]=mssql_result($result,$i,0);
$company_list[$i][1]=mssql_result($result,$i,1);
$company_list[$i][2]=mssql_result($result,$i,2);
}
}
return $company_list;
}
}
--
Edit this bug report at http://bugs.php.net/?id=17302&edit=1
#18744 [Fbk->NoF]: blob_add has max limit of 64k
ID: 18744 Updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] -Status: Feedback +Status: No Feedback Bug Type: InterBase related Operating System: Redhat 7.3 PHP Version: 4.2.2 New Comment: No feedback was provided for this bug for over 2 weeks, so it is being suspended automatically. If you are able to provide the information that was originally requested, please do so and change the status of the bug back to "Open". Previous Comments: [2002-12-04 22:52:20] [EMAIL PROTECTED] Please try using this CVS snapshot: http://snaps.php.net/php4-latest.tar.gz For Windows: http://snaps.php.net/win32/php4-win32-latest.zip [2002-08-05 14:42:22] [EMAIL PROTECTED] The ibase_blob_add functionality wraps the Interbase blob add functionality, which will only allow up to 64k of data to be added at any one time dut to an unsigned short variable. This means that if a chunk of data is > than 64k, you have to split it into < 64k chunks and run multiple adds. While this is not a problem, it seems that this functionality would be better used in the actual PHP source. It shouldn't be too hard a fix - just split the incoming string into < 64k chunks and run the add in a loop. For example, we discovered that a 145k string was being truncated by the ibase_blob_add function. At the very least, the ibase_blob_add function should throw a warning if the data is > 64k. This 64k limit is not documented, and has been a source of much confusion. It would be very helpful if this change were implemented. -- Edit this bug report at http://bugs.php.net/?id=18744&edit=1
#20795 [Fbk->NoF]: Memory_limit not respected
ID: 20795 Updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] -Status: Feedback +Status: No Feedback Bug Type: Scripting Engine problem Operating System: Windows XP Pro/BSDi/FreeBSD PHP Version: 4.4CVS2002-12-03 New Comment: No feedback was provided for this bug for over 2 weeks, so it is being suspended automatically. If you are able to provide the information that was originally requested, please do so and change the status of the bug back to "Open". Previous Comments: [2002-12-03 16:45:00] [EMAIL PROTECTED] Oki, I have check (but i was sure): Configuration File (php.ini) Path C:\WINDOWS\php.ini And the file have the right name and the right location. In all case, i suppose that normally, i should have a default value of memory_limit and max_execution_time displayed by phpinfo(). And it's not the case. (Note that this values are displayed under Linux with Apache/1.3.23, PHP Version 4.1.2) [2002-12-03 12:06:20] [EMAIL PROTECTED] Please check (with phpinfo()) if the location of your php.ini file is correct (and watch the troubles with the file extensions in windows, the best thing to check if the file actually has the name 'php.ini' (and not 'php.ini.ini') is to check it in a DOS prompt. Derick [2002-12-03 12:02:24] [EMAIL PROTECTED] I know this is hard to believe, but the max_execution_time part is not a bug. See the NOTE at: http://www.php.net/set_time_limit The larger part of the execution is done by MySQL. max_execution_time, is the time that php keeps the processor busy - not the 'real' time. Leaving open for the memory_limit, which I reported myself not to be working in http://bugs.php.net/20738. I'll add any comments on that here. Updated summary and version. [2002-12-03 11:36:21] [EMAIL PROTECTED] Hi i'm using Apache/1.3.26 (Win32) PHP/4.2.3, with mysql.exe Ver 11.18 Distrib 3.23.52, for Win95/Win98 (i32) 1) PhpInfo() don't give me the memory_limit that I set on default value. Non memory_limit appear on the page even though the php.ini file contain a definition. 2) PhpInfo() also don't give me the max_execution_time, witch is also setted. 3) When I execute an big sql query (2 lines) (It was a mystake of course!!!) the memory grow up and grow up ... After more time than the max_execution_time, system blow up and apache is killed !!! I see in the task manager that memory in use by apache was up than 300Mo. And before the execution it was 5 or 6 Mo. 4) I will complete this report with the sql request made, but i notice that after stoping the html request mysqld-nt continue to work (100% of CPU_1) more than 10 minutes and apache also. I stop the daemon before they stop themself. I hope i was clear (im french and my english is poor). -- Edit this bug report at http://bugs.php.net/?id=20795&edit=1
#20813 [Fbk->NoF]: opendir() returns errno22 with UNC path
ID: 20813
Updated by: [EMAIL PROTECTED]
Reported By: [EMAIL PROTECTED]
-Status: Feedback
+Status: No Feedback
Bug Type: Directory function related
Operating System: NT4SP6 IIS
PHP Version: 4.2.3
New Comment:
No feedback was provided for this bug for over 2 weeks, so it is
being suspended automatically. If you are able to provide the
information that was originally requested, please do so and change
the status of the bug back to "Open".
Previous Comments:
[2002-12-04 17:53:46] [EMAIL PROTECTED]
Please try using this CVS snapshot:
http://snaps.php.net/php4-latest.tar.gz
For Windows:
http://snaps.php.net/win32/php4-win32-latest.zip
[2002-12-04 13:12:41] [EMAIL PROTECTED]
Just installed fresh 4.2.3 ISAPI on Win2000 and still produces same
error. Does this have something to do with the target UNC?
[2002-12-04 10:44:27] [EMAIL PROTECTED]
Bug #9354 also produces same result
Bug #6445 is the same problem
Bug #12699 is the same problem
Bug #12524 is the same problem
Is this only NT4???
[2002-12-04 10:34:08] [EMAIL PROTECTED]
if ($handle = opendir("//server/share")) {
while ($file = readdir($handle)) {
echo "$file";
}
closedir($handle);
}
produces:
Warning: OpenDir: Invalid argument (errno 22)
I have tried setting the UNC share permissions to both Everyone - Read
and Everyone - Full Control and it does not matter.
--
Edit this bug report at http://bugs.php.net/?id=20813&edit=1
#20641 [Fbk->NoF]: Numeric type returns invalid result using ibase_fetch_row/ibase_fetch_object
ID: 20641
Updated by: [EMAIL PROTECTED]
Reported By: [EMAIL PROTECTED]
-Status: Feedback
+Status: No Feedback
Bug Type: InterBase related
Operating System: Windows NT / Firebird 1.0
PHP Version: 4.2.3
New Comment:
No feedback was provided for this bug for over 2 weeks, so it is
being suspended automatically. If you are able to provide the
information that was originally requested, please do so and change
the status of the bug back to "Open".
Previous Comments:
[2002-12-04 22:49:33] [EMAIL PROTECTED]
Please try using this CVS snapshot:
http://snaps.php.net/php4-latest.tar.gz
For Windows:
http://snaps.php.net/win32/php4-win32-latest.zip
[2002-11-26 04:38:19] [EMAIL PROTECTED]
Numeric type returns invalid result using
ibase_fetch_row/ibase_fetch_object (Windows NT).
Numbers stored as an InterBase/Firebird numeric/decimal datatype
beyond
the bounds of the PHP integer type (> 2147483647), do not return a
float
type but cause an overflow
Example:
2303511415 (decimal 10,0) returns -1991455881
PHP/Firebird example script:
$sql = "create table temp (large_number numeric(10,0))";
$result = ibase_query($sql,connection());
if (!$result) {
exit;
}
ibase_commit();
$sql = "INSERT INTO temp VALUES (2303511415)";
$result = ibase_query($sql,connection());
if (!$result) {
exit;
}
$sql = "SELECT large_number FROM temp WHERE large_number =
2303511415";
$result = ibase_query($sql,connection());
if (!$result) {
exit;
}
while ($row = ibase_fetch_row($result)) {
print($row[0]);
}
ibase_free_result($result);
$sql = "drop table temp";
$result = ibase_query($sql,connection());
if (!$result) {
exit;
}
ibase_commit();
[2002-11-26 03:24:19] [EMAIL PROTECTED]
Numeric type returns invalid result using
ibase_fetch_row/ibase_fetch_object (Windows NT).
Numbers stored as an InterBase/Firebird numeric/decimal datatype beyond
the bounds of the PHP integer type (> 2147483647), do not return a
float type but cause an overflow
Example:
2303511415 (decimal 10,0) returns -1991455881
PHP/Firebird example script:
$sql = "create table temp (large_number numeric(10,0))";
$result = ibase_query($sql,connection());
if (!$result) {
exit;
}
$sql = "INSERT INTO temp VALUES (2303511415)";
$result = ibase_query($sql,connection());
if (!$result) {
exit;
}
$sql = "SELECT large_number FROM temp WHERE large_number =
2303511415";
$result = ibase_query($sql,connection());
if (!$result) {
exit;
}
while ($row = ibase_fetch_row($result)) {
print($row[0]);
}
--
Edit this bug report at http://bugs.php.net/?id=20641&edit=1
#20604 [Fbk->NoF]: PHP CLI exists always with Segmantation Fault
ID: 20604 Updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] -Status: Feedback +Status: No Feedback Bug Type: *General Issues Operating System: Linux Debian Sarge PHP Version: 4CVS-2002-11-24 (dev) New Comment: No feedback was provided for this bug for over 2 weeks, so it is being suspended automatically. If you are able to provide the information that was originally requested, please do so and change the status of the bug back to "Open". Previous Comments: [2002-12-06 00:44:33] [EMAIL PROTECTED] argh the error is on php 4.2.3 too but i don't have session.auto_start=1 =( [2002-12-05 09:58:19] [EMAIL PROTECTED] Do you have 'session.auto_start=1' in your php.ini ? (or php-cli.ini) Does this happen with PHP 4.2.3? [2002-12-05 00:26:04] [EMAIL PROTECTED] still have this error with same backtrace =( [2002-12-04 18:18:42] [EMAIL PROTECTED] Please try using this CVS snapshot: http://snaps.php.net/php4-latest.tar.gz For Windows: http://snaps.php.net/win32/php4-win32-latest.zip [2002-11-24 05:11:18] [EMAIL PROTECTED] i installed now the libc6-dbg package and put /usr/lib/debug in LD_LIBRARY_PATH and now is the error in another function of libc Program received signal SIGSEGV, Segmentation fault. [Switching to Thread 1024 (LWP 26000)] 0x403367d0 in main_arena () from /usr/lib/debug/libc.so.6 (gdb) bt #0 0x403367d0 in main_arena () from /usr/lib/debug/libc.so.6 #1 0x403367c0 in main_arena () from /usr/lib/debug/libc.so.6 #2 0x403367c0 in main_arena () from /usr/lib/debug/libc.so.6 #3 0x403367c8 in main_arena () from /usr/lib/debug/libc.so.6 #4 0x403367b0 in main_arena () from /usr/lib/debug/libc.so.6 #5 0x403367a8 in main_arena () from /usr/lib/debug/libc.so.6 #6 0x403367a0 in main_arena () from /usr/lib/debug/libc.so.6 #7 0x40336798 in main_arena () from /usr/lib/debug/libc.so.6 #8 0x40336790 in main_arena () from /usr/lib/debug/libc.so.6 #9 0x081a4560 in ?? () The remainder of the comments for this report are too long. To view the rest of the comments, please view the bug report online at http://bugs.php.net/20604 -- Edit this bug report at http://bugs.php.net/?id=20604&edit=1
#20825 [Fbk->NoF]: browser's get confused with session's id
ID: 20825 Updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] -Status: Feedback +Status: No Feedback Bug Type: Session related Operating System: win2000 PHP Version: 4.2.3 New Comment: No feedback was provided for this bug for over 2 weeks, so it is being suspended automatically. If you are able to provide the information that was originally requested, please do so and change the status of the bug back to "Open". Previous Comments: [2002-12-05 09:34:25] [EMAIL PROTECTED] Please try using this CVS snapshot: http://snaps.php.net/php4-latest.tar.gz For Windows: http://snaps.php.net/win32/php4-win32-latest.zip [2002-12-05 09:33:30] [EMAIL PROTECTED] I'm using cookies, yes. [2002-12-05 09:31:21] [EMAIL PROTECTED] I go to re-explain the problem, because i didn't this the last time (sorrie). Sometimes (i don't know when this occurs, it seems randomly) when there are somebody in my page, and other try to login, then the last one get the current value that have the session of other user. I only see the possible bug, usign IE. Thx (and sorrie if i'm get confused too and this isn't a bug) [2002-12-05 08:43:25] [EMAIL PROTECTED] Do you by any chance mean that you're opening several IE windows? And you're using cookies? [2002-12-05 08:19:49] [EMAIL PROTECTED] Not enough information was provided for us to be able to handle this bug. Please re-read the instructions at http://bugs.php.net/how-to-report.php If you can provide more information, feel free to add it to this bug and change the status back to "Open". Thank you for your interest in PHP. Please provide a __short__ and __self-contained__ example script, that will reproduce the bug. Additionally, try the latest snapshot: http://snaps.php.net/php4-latest.tar.gz For Windows: http://snaps.php.net/win32/php4-win32-latest.zip There are quite a few session related fixes in those snapshots, so it may be already fixed. 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/20825 -- Edit this bug report at http://bugs.php.net/?id=20825&edit=1
#17088 [Fbk->NoF]: GET/POST variables not registered
ID: 17088 Updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] -Status: Feedback +Status: No Feedback Bug Type: Scripting Engine problem Operating System: WindowsXP Pro PHP Version: 4.2.0 New Comment: No feedback was provided for this bug for over 2 weeks, so it is being suspended automatically. If you are able to provide the information that was originally requested, please do so and change the status of the bug back to "Open". Previous Comments: [2002-12-06 19:34:14] [EMAIL PROTECTED] Should have added that there were some fixes made for CGI just recently that might fix this too.. [2002-12-06 19:33:37] [EMAIL PROTECTED] Please try using this CVS snapshot: http://snaps.php.net/php4-latest.tar.gz For Windows: http://snaps.php.net/win32/php4-win32-latest.zip [2002-05-10 08:09:40] [EMAIL PROTECTED] ... and the answer is: COnfiguration error. While struggling with the cgi.force_redirect I had started using the command-line version to parse .php files. Obviously enough there were no entries in $_GET, $_POST et al. Since there were at least 3 of us Bozos who did that, perhaps it's worth a mention in the documentation or FAQ. [2002-05-09 20:14:08] [EMAIL PROTECTED] Please see also bug # 16848 with similar difficulty running on Linux. Also note that I have this problem on OmniHTTPd on Windows 98 (which I tried after the above comment on Xitami). With similar problems on 2 operating systems and 3 servers it looks to me like either a real PHP problem or a configuration error of some kind. [2002-05-08 10:06:04] [EMAIL PROTECTED] Good point. Whatever it is, it seems no one with enough knowledge cares about it and steps forward and starts digging where the problem is. 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/17088 -- Edit this bug report at http://bugs.php.net/?id=17088&edit=1
#20791 [Fbk->NoF]: Strange output of values in array through form (Japanese)
ID: 20791 Updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] -Status: Feedback +Status: No Feedback Bug Type: Output Control Operating System: FreeBSD 4.4 PHP Version: 4.2.3 New Comment: No feedback was provided for this bug for over 2 weeks, so it is being suspended automatically. If you are able to provide the information that was originally requested, please do so and change the status of the bug back to "Open". Previous Comments: [2002-12-03 08:39:32] [EMAIL PROTECTED] Not enough information was provided for us to be able to handle this bug. Please re-read the instructions at http://bugs.php.net/how-to-report.php If you can provide more information, feel free to add it to this bug and change the status back to "Open". Thank you for your interest in PHP. [2002-12-03 08:33:13] [EMAIL PROTECTED] I found a bug (probably) in output of array though form submit. When submiting with checkbox which has Japanese-character- value, output of array is strange. Some character in head of value is gone I foound it doesn't happen in case values are not multi- byte character. -- Edit this bug report at http://bugs.php.net/?id=20791&edit=1
#13763 [Fbk->NoF]: SQL Compute
ID: 13763 Updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] -Status: Feedback +Status: No Feedback Bug Type: Sybase-ct (ctlib) related Operating System: LINUX REDHAT 7 PHP Version: 4.2.1 New Comment: No feedback was provided for this bug for over 2 weeks, so it is being suspended automatically. If you are able to provide the information that was originally requested, please do so and change the status of the bug back to "Open". Previous Comments: [2002-12-07 01:40:04] [EMAIL PROTECTED] Please try using this CVS snapshot: http://snaps.php.net/php4-latest.tar.gz For Windows: http://snaps.php.net/win32/php4-win32-latest.zip [2002-05-14 14:36:32] [EMAIL PROTECTED] Reopening on user request. [2002-05-14 13:50:38] [EMAIL PROTECTED] Still needed with 4.2.1 PS : please change status from Bogus to Open [2002-04-23 08:41:41] [EMAIL PROTECTED] Still needed with 4.2.0 PS : please change status from Bogus to Open [2002-01-13 17:43:37] [EMAIL PROTECTED] I've the same problem. Please resolve this bug. Thanks. for more info, see bugs #11475 and #13475, #13735, #12074 There's a lot of problem to retrieve multi-result-set from store procedures (example : sp_help with rules or data types) So, the solution is to develop #12074 or test/apply the patchs from #11475 & #13735, #13475 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/13763 -- Edit this bug report at http://bugs.php.net/?id=13763&edit=1
#15632 [Fbk->NoF]: MSSQL querys cause major problems
ID: 15632 Updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] -Status: Feedback +Status: No Feedback Bug Type: MSSQL related Operating System: Windows 2000 PHP Version: 4.1.1 New Comment: No feedback was provided for this bug for over 2 weeks, so it is being suspended automatically. If you are able to provide the information that was originally requested, please do so and change the status of the bug back to "Open". Previous Comments: [2002-12-07 01:52:10] [EMAIL PROTECTED] Please try using this CVS snapshot: http://snaps.php.net/php4-latest.tar.gz For Windows: http://snaps.php.net/win32/php4-win32-latest.zip [2002-04-20 19:56:55] [EMAIL PROTECTED] After some hasling with the configuration, I have found a solution (for both mod_php and CGI) in setting the mssql.compatability_mode option to 'Off': mssql.compatability_mode = Off I also noticed this bugreport, with the same solution: http://bugs.php.net/bug.php?id=15890 [2002-04-20 19:06:29] [EMAIL PROTECTED] I experience the same problem using Apache 1.3.20 on Windows 2000. The bug shows with mod_php and PHP as CGI (both 4.1.2). SQL Server 2000 (Dev. Ed.) is installed on the same machine. Connecting to the server and selecting a database is no problem, but any call to mssql_query() causes PHP to crash. I find no messages in the errorlog (except for a 'Premature end of script headers' with the CGI version). Interesting is the fact that mssql_query() behaves as expected (no errors) only if the query returns 0 rows. [2002-02-20 17:09:38] [EMAIL PROTECTED] Additonal info: This occurs under apache as well, but I get an internal script error. The problem occurs when a call to mssql_query matches at least one row. If a query does not match anything, PHP does not crash. But if it does, it crashes. [2002-02-20 14:16:09] [EMAIL PROTECTED] Reopened. 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/15632 -- Edit this bug report at http://bugs.php.net/?id=15632&edit=1
#20254 [Fbk->NoF]: imap_header() crash with bad Reply-To
ID: 20254
Updated by: [EMAIL PROTECTED]
Reported By: [EMAIL PROTECTED]
-Status: Feedback
+Status: No Feedback
Bug Type: IMAP related
Operating System: Linux (2.4.18)
PHP Version: 4.3.0-dev
New Comment:
No feedback was provided for this bug for over 2 weeks, so it is
being suspended automatically. If you are able to provide the
information that was originally requested, please do so and change
the status of the bug back to "Open".
Previous Comments:
[2002-12-07 16:06:38] [EMAIL PROTECTED]
Please try using this CVS snapshot:
http://snaps.php.net/php4-latest.tar.gz
For Windows:
http://snaps.php.net/win32/php4-win32-latest.zip
[2002-12-02 13:51:15] [EMAIL PROTECTED]
hello.
similar problem, imap_header() crash, but with other condition - long
To: header
php 4.2.3 as CLI,libc-client: 4.7-c2
bug can be reproduced with message containing following header:
To: Someone <[EMAIL PROTECTED]>,
Someone2 <[EMAIL PROTECTED]>,
...
Someone144
I didn't test actual threshold, it could be smaller then 144.
test script:
$imap=imap_open("{localhost:143}INBOX","user","pass");
if (!$imap)
echo "connect failed\n";
$header=imap_header($imap,1);
backtrace:
Program received signal SIGSEGV, Segmentation fault.
0x3d0f86 in malloc () from /lib/libc.so.6
(gdb) bt
#0 0x3d0f86 in malloc () from /lib/libc.so.6
#1 0x3d0ca4 in malloc () from /lib/libc.so.6
#2 0x80c723c in _emalloc (size=12) at zend_alloc.c:165
#3 0x53e39e in _php_imap_parse_address (addresslist=0x817bfe0,
fulladdress=0xbd870ec8, paddress=0x818476c) at php_imap.c:3632
#4 0x53e62e in _php_make_header_object (myzvalue=0x8178c3c,
en=0x817ce58)
at php_imap.c:3666
#5 0x536dbd in zif_imap_headerinfo (ht=2, return_value=0x8178c3c,
this_ptr=0x0, return_value_used=1) at php_imap.c:1631
#6 0x497d99 in zend_assign_to_variable_reference ()
from /usr/local/Zend/lib/ZendOptimizer.so
#7 0x4a1144 in zend_oe () from /usr/local/Zend/lib/ZendOptimizer.so
#8 0x80d3fb8 in zend_execute_scripts (type=8, retval=0x0,
file_count=3)
at zend.c:812
#9 0x805f81d in php_execute_script (primary_file=0xbd873388) at
main.c:1383
#10 0x805d6e3 in main (argc=2, argv=0xbd873404) at cgi_main.c:778
#11 0x37c0bf in __libc_start_main () from /lib/libc.so.6
[2002-11-14 22:39:24] [EMAIL PROTECTED]
I'm in another situation.
I configured php with uw-imap c-client, but
courier-imap server is running.
Stopping courier-imap server and, Test with uw-iamp server, there was
no crash.
Test with courier-imap server again, here backtrace report.
(gdb) bt
#0 0x403b480e in _zval_ptr_dtor (zval_ptr=0x0,
__zend_filename=0x4046de00
"/usr/local/src/php4-200211030600/Zend/zend_variables.c",
__zend_lineno=167)
at /usr/local/src/php4-200211030600/Zend/zend_execute_API.c:291
#1 0x403be4d2 in _zval_ptr_dtor_wrapper (zval_ptr=0x0) at
/usr/local/src/php4-200211030600/Zend/zend_variables.c:167
#2 0x403c5a01 in zend_hash_destroy (ht=0x812eacc) at
/usr/local/src/php4-200211030600/Zend/zend_hash.c:543
#3 0x403be19a in _zval_dtor (zvalue=0x812ea8c,
__zend_filename=0x4046d6a0
"/usr/local/src/php4-200211030600/Zend/zend_execute_API.c",
__zend_lineno=293)
at /usr/local/src/php4-200211030600/Zend/zend_variables.c:60
#4 0x403b4839 in _zval_ptr_dtor (zval_ptr=0x811c820,
__zend_filename=0x4046de00
"/usr/local/src/php4-200211030600/Zend/zend_variables.c",
__zend_lineno=167)
at /usr/local/src/php4-200211030600/Zend/zend_execute_API.c:293
#5 0x403be4d2 in _zval_ptr_dtor_wrapper (zval_ptr=0x811c820) at
/usr/local/src/php4-200211030600/Zend/zend_variables.c:167
#6 0x403c5a01 in zend_hash_destroy (ht=0x404da80c) at
/usr/local/src/php4-200211030600/Zend/zend_hash.c:543
#7 0x403b433e in shutdown_executor () at
/usr/local/src/php4-200211030600/Zend/zend_execute_API.c:186
#8 0x403bf70f in zend_deactivate () at
/usr/local/src/php4-200211030600/Zend/zend.c:625
#9 0x40387bd3 in php_request_shutdown (dummy=0x0) at
/usr/local/src/php4-200211030600/main/main.c:913
#10 0x403d6dfa in apache_php_module_main (r=0x8114ad4,
display_source_mode=0)
at /usr/local/src/php4-200211030600/sapi/apache/sapi_apache.c:61
#11 0x403d7c48 in send_php (r=0x8114ad4, display_source_mode=0,
filename=0x8116614 "/home/www/test.php")
at /usr/local/src/php4-200211030600/sapi/apache/mod_php4.c:556
#12 0x403d7cb5 in send_parsed_php (r=0x8114ad4) at
/usr/local/src/php4-200211030600/sapi/apache/mod_php4.c:571
#13 0x08054823 in ap_invoke_handler ()
#14 0x08069ca7 in process_request_internal ()
#15 0x08069d08 in ap_process_request ()
#16 0x08060a79 in child_main ()
#17 0x08060c48 in make_child ()
#18 0x08060dbc in startup_children ()
#19 0x08061434
#16277 [Fbk->NoF]: Multiple statement in a query cause subsequent queries to fail
ID: 16277
Updated by: [EMAIL PROTECTED]
Reported By: [EMAIL PROTECTED]
-Status: Feedback
+Status: No Feedback
Bug Type: MSSQL related
Operating System: NT4
PHP Version: 4.1.2
New Comment:
No feedback was provided for this bug for over 2 weeks, so it is
being suspended automatically. If you are able to provide the
information that was originally requested, please do so and change
the status of the bug back to "Open".
Previous Comments:
[2002-12-07 01:52:50] [EMAIL PROTECTED]
Please try using this CVS snapshot:
http://snaps.php.net/php4-latest.tar.gz
For Windows:
http://snaps.php.net/win32/php4-win32-latest.zip
[2002-03-26 08:45:52] [EMAIL PROTECTED]
RTFBR ;) it is MS SQL, not mySQL
[2002-03-26 08:01:58] [EMAIL PROTECTED]
RTM! You can only run one query per call to mysql_query()!
[2002-03-25 22:49:13] [EMAIL PROTECTED]
I am creating tables and indexes in a few places. To make life a
little easier I want to create a table and it's indexes in one go.
The following code fails:
$queries[0]["query_string"]="CREATE TABLE objects (
[id] integer IDENTITY (1,1) PRIMARY KEY,
[type] varchar(16) DEFAULT '' NOT NULL,
[object] text,
[vtype] varchar(16) DEFAULT '' NOT NULL,
[lastchanged] TIMESTAMP);
CREATE INDEX objects_lastchanged ON objects (lastchanged);";
$queries[1]["query_string"]="CREATE TABLE nodes (
path varchar(127) DEFAULT '' NOT NULL PRIMARY KEY,
parent varchar(127) DEFAULT '' NOT NULL,
object numeric(11) DEFAULT '0' NOT NULL,
priority numeric(11) DEFAULT '0' NOT NULL
);";
while ((list($key, $query)=each($queries)) && (!$error)) {
echo $query["query_string"];
$exec=mssql_query($query["query_string"]);
}
But if I separate out the create index into a separate query it works
fine.
--
Edit this bug report at http://bugs.php.net/?id=16277&edit=1
#18534 [Fbk->NoF]: ifx_close() leaves open session
ID: 18534
Updated by: [EMAIL PROTECTED]
Reported By: [EMAIL PROTECTED]
-Status: Feedback
+Status: No Feedback
Bug Type: Informix related
Operating System: Sun Solaris 8
PHP Version: 4.2.1
New Comment:
No feedback was provided for this bug for over 2 weeks, so it is
being suspended automatically. If you are able to provide the
information that was originally requested, please do so and change
the status of the bug back to "Open".
Previous Comments:
[2002-12-07 01:44:11] [EMAIL PROTECTED]
Please try using this CVS snapshot:
http://snaps.php.net/php4-latest.tar.gz
For Windows:
http://snaps.php.net/win32/php4-win32-latest.zip
[2002-07-24 05:55:36] [EMAIL PROTECTED]
When working with tranaztions. ifx_close() does not close session.
I have following script:
If i dont execute $result=ifx_query("rollback work;", $db); and just
call ifx_close session is not closed and autmatic rollback is not
executed (as it must be) but connection to Informix database stays with
lock on this row.
Usualy you must have rollback or commit; But to avoid problems with bad
code or other coding probs after calling ifx_close() session must be
rolled back and closed.
Martins Junkers
--
Edit this bug report at http://bugs.php.net/?id=18534&edit=1
#19588 [Fbk->NoF]: Problems with smallmoney datatype
ID: 19588
Updated by: [EMAIL PROTECTED]
Reported By: [EMAIL PROTECTED]
-Status: Feedback
+Status: No Feedback
Bug Type: MSSQL related
Operating System: Windows XP Pro
PHP Version: 4.2.3
New Comment:
No feedback was provided for this bug for over 2 weeks, so it is
being suspended automatically. If you are able to provide the
information that was originally requested, please do so and change
the status of the bug back to "Open".
Previous Comments:
[2002-12-07 01:38:38] [EMAIL PROTECTED]
Please try using this CVS snapshot:
http://snaps.php.net/php4-latest.tar.gz
For Windows:
http://snaps.php.net/win32/php4-win32-latest.zip
[2002-09-25 04:37:25] [EMAIL PROTECTED]
Information as of phpinfo():
PHP Version 4.2.3
System Windows NT 5.1 build 2600
Build Date Sep 6 2002 10:38:51
Server API CGI
Debug Build no
Thread Safety enabled
mssql
MSSQL Support enabled
Library version 7.0
Directive Local Value Master Value
mssql.allow_persistent On On
mssql.batchsize 0 0
mssql.compatability_mode Off Off
mssql.connect_timeout 5 5
mssql.datetimeconvert On On
mssql.max_links Unlimited Unlimited
mssql.max_persistent 10 10
mssql.min_error_severity 10 10
mssql.min_message_severity 10 10
mssql.textlimit Server default Server default
mssql.textsize Server default Server default
mssql.timeout 60 60
Zend Optimizer installed
_ENV["SERVER_SOFTWARE"] Microsoft-IIS/5.1
_ENV["PROCESSOR_IDENTIFIER"] x86 Family 6 Model 4 Stepping 2,
AuthenticAMD
Running with MS SQL 7.0 Desktop Edition (I don't know whether this
appears with MS SQL 2000).
**
Report:
When selecting more than a small amount of rows (approx. 10) using
mssql_query from a table including a smallmoney column, the script will
immediately abort execution. This problem does not appear when using
decimal(9,2) columns instead of smallmoney. Thus, a possible workaround
for me was to CAST the smallmoney-column to decimal ("SELECT CAST (
value decimal(9,2))" instead of "SELECT value").
TIA for your time, best wishes,
Falk
--
Edit this bug report at http://bugs.php.net/?id=19588&edit=1
#17788 [Fbk->NoF]: service hangup
ID: 17788 Updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] -Status: Feedback +Status: No Feedback Bug Type: IIS related Operating System: windowsxp PHP Version: 4.2.1 New Comment: No feedback was provided for this bug for over 2 weeks, so it is being suspended automatically. If you are able to provide the information that was originally requested, please do so and change the status of the bug back to "Open". Previous Comments: [2002-12-07 01:41:33] [EMAIL PROTECTED] Please try using this CVS snapshot: http://snaps.php.net/php4-latest.tar.gz For Windows: http://snaps.php.net/win32/php4-win32-latest.zip [2002-10-01 10:43:07] [EMAIL PROTECTED] It appears that this problem has been identified by Microsoft as well. http://support.microsoft.com/default.aspx?scid=KB;EN-US;Q319179&; The solution they provide is to remove php as an isapi and run it as a cgi. Not very informative as to why this happpens. [2002-06-16 12:10:23] [EMAIL PROTECTED] i have two problems running php - it is not possible to stop the w3svc (web server) service when the php engine was at least once accessed. and the second one - when the php engine was accessed it is not possible to open directory properties in windows (in the 'properties' dialog there are some informations from IIS, settings for web sharing etc. so it may be the same bug as the first one. -- Edit this bug report at http://bugs.php.net/?id=17788&edit=1
#20629 [Fbk->NoF]: Exception
ID: 20629
Updated by: [EMAIL PROTECTED]
Reported By: [EMAIL PROTECTED]
-Status: Feedback
+Status: No Feedback
Bug Type: IIS related
Operating System: Windows 2000
PHP Version: 4.2.3
New Comment:
No feedback was provided for this bug for over 2 weeks, so it is
being suspended automatically. If you are able to provide the
information that was originally requested, please do so and change
the status of the bug back to "Open".
Previous Comments:
[2002-12-07 01:26:03] [EMAIL PROTECTED]
Please try using this CVS snapshot:
http://snaps.php.net/php4-latest.tar.gz
For Windows:
http://snaps.php.net/win32/php4-win32-latest.zip
[2002-11-25 14:10:20] [EMAIL PROTECTED]
$oPermChecker = new COM("MSWC.PermissionChecker");
$result = $oPermChecker->HasAccess("c:\boot.ini");
The above code generates the following error :
Warning: Invoke() failed: Exception occurred. Source:
MSWC.PermissionChecker.1 Description: No such interface supported in
c:\inetpub\wwwroot\test.php on line 2
The same code under ASP works fine under the same IIS configuration. I
have created a fresh install of Win2KSvr and PHP to test with all
service packs.
--
Edit this bug report at http://bugs.php.net/?id=20629&edit=1
#19670 [Fbk->NoF]: 64bit Oracle installation fails
ID: 19670 Updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] -Status: Feedback +Status: No Feedback Bug Type: OCI8 related Operating System: Solaris 2.8 PHP Version: 4.2.3 New Comment: No feedback was provided for this bug for over 2 weeks, so it is being suspended automatically. If you are able to provide the information that was originally requested, please do so and change the status of the bug back to "Open". Previous Comments: [2002-12-07 16:51:54] [EMAIL PROTECTED] Please try using this CVS snapshot: http://snaps.php.net/php4-latest.tar.gz For Windows: http://snaps.php.net/win32/php4-win32-latest.zip [2002-10-13 13:54:36] [EMAIL PROTECTED] 1. Experienced similar but slightly different issue. On Oracle 9i (9.2.0) under HP-UX 11i (11.11) the 64 bit libraries are installed in ORACLE_HOME/lib and the 32 bit libraries are in ORACLE_HOME/lib32. This results in obvious link failures when trying to build a 32 bit version of PHP. 2. There are obvious work arounds to force linkage against the correct libraries, however it would be nice if there were a config option to override the Oracle library directory. [2002-10-01 01:02:52] [EMAIL PROTECTED] Yes, again this is the standard installation path of Oracle 8i. For more information about disk layout of Oracle 8i 64bit read the Product Notes section in 'Oracle 8i Release Notes' available under: http://download-east.oracle.com/docs/pdf/A90156_01.pdf [2002-09-30 10:43:37] [EMAIL PROTECTED] I understand what your claiming the bug is, thats not the issue. What I'm questioning is the validity of the bug, in the sense that my local 64bit Oracle install doesn't use the lib64 notation, but still uses the lib. Which may mean that my install is borked, but thus my asking. [2002-09-30 09:36:00] [EMAIL PROTECTED] Yes, this is a standard install of Oracle 8. All 32 bit Libraries are in $ORACLE_HOME/lib and 64 bit Libraries in $ORACLE_HOME/lib64 The problem is the configure script, which is not aware of compiling 64 bit - so the wrong library path is set. The actual wayaround is to edit the configure script accordingly vi configure :1,$s-OCI8_DIR\/lib-OCI8_DIR\/lib64-g :wq This works - but there should be a better solution in future. 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/19670 -- Edit this bug report at http://bugs.php.net/?id=19670&edit=1
#19541 [Fbk->NoF]: mssql_connect fails under stress
ID: 19541
Updated by: [EMAIL PROTECTED]
Reported By: [EMAIL PROTECTED]
-Status: Feedback
+Status: No Feedback
Bug Type: MSSQL related
Operating System: Windows NT4(SP6)
PHP Version: 4.2.3
New Comment:
No feedback was provided for this bug for over 2 weeks, so it is
being suspended automatically. If you are able to provide the
information that was originally requested, please do so and change
the status of the bug back to "Open".
Previous Comments:
[2002-12-07 01:38:08] [EMAIL PROTECTED]
Please try using this CVS snapshot:
http://snaps.php.net/php4-latest.tar.gz
For Windows:
http://snaps.php.net/win32/php4-win32-latest.zip
[2002-09-23 17:22:22] [EMAIL PROTECTED]
I switched to CGI and I can confirm that the error doesn't occur
anymore. However, as I expected I've run into some serious performance
problems under heavy load (CPU usage extremely high, script execution
timeouts etc.). Therefore I'd really like to see this working under
ISAPI as well.
Does this error suggest that the mssql extension has problems with
thread safety?
My opinion is that if ISAPI was stable and working well, it would be a
major break-through for the PHP in Windows platforms. I honestly hope
PHP group is taking Windows platforms seriously and putting effort to
them.
[2002-09-21 10:40:49] [EMAIL PROTECTED]
I have found out that mssql_connect fails under stress. I'm using PHP
4.2.3/ISAPI on IIS4/NT4(SP6). MSSQL 7.0 Server is a dedicated dual
processor server with NT4(SP6). I've installed MDAC 2.7 RTM on the web
server and performance setting is set to foreground applications (read
bug: 9852).
I've despertately searched solution to this problem, since the site I'm
running is on production state already. I experienced this bug with PHP
4.2.2 at first then moved on to 4.2.3 without any change to the
problem. The error occurs on a line:
$dbconn = mssql_connect($dbalias,$dbuser,$dbpw);
and application log entry for the error is:
The description for Event ID ( 2000 ) in Source ( c-client ) could not
be found. It contains the following insertion string(s): , PHP
Warning: MS SQL: Unable to connect to server: *dbname* in *path* on
line x.
I'm using TCP/IP protocol, however I've tried named pipes and
multiprotocol without help. I've tried to work around this problem and
I found out that usually this error occurs when several users are
trying to connect to the database simultaneously. I managed to reduce
the appearance of the error with the code:
function usleepWindows($usec)
{
$start = gettimeofday();
do
{
$stop = gettimeofday();
$timePassed = 100 * ($stop['sec'] - $start['sec'])
+ $stop['usec'] - $start['usec'];
}
while ($timePassed < $usec);
}
$tries=11;
$totaldelay=0;
// Set db connection
$dbconn = mssql_connect($dbalias,$dbuser,$dbpw);
while(!$dbconn){
if ($tries<=0){
echo "Database failed to respond.";
$fp = fopen("c:\\logs\\conn_failed.log","a");
fputs($fp, gmdate("M d Y H:i:s") . ": db connection failed. Total
delay: $totaldelay. From: $REMOTE_HOST.\r\n");
fclose($fp);
exit;
}
$delay=mt_rand(8, 15);
usleepWindows($delay);
$conn = mssql_connect($dbalias,$dbuser,$dbpw);
$tries--;
$totaldelay += $delay;
}
The function usleepWindows was found from
http://www.php.net/manual/en/function.usleep.php.
I haven't tried the CGI yet and wouldn't want to since it will surely
suffocate the web server under load. ISAPI is far more superior and my
other experiences of it are very positive.
I hope to find a solid answer to this problem as it very critical to my
site.
--
Edit this bug report at http://bugs.php.net/?id=19541&edit=1
#17563 [Fbk->NoF]: PHP has encountered an Access Violation at 77XXXXX
ID: 17563 Updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] -Status: Feedback +Status: No Feedback Bug Type: MSSQL related Operating System: WIN2K PHP Version: 4.2.1 New Comment: No feedback was provided for this bug for over 2 weeks, so it is being suspended automatically. If you are able to provide the information that was originally requested, please do so and change the status of the bug back to "Open". Previous Comments: [2002-12-07 01:43:29] [EMAIL PROTECTED] Please try using this CVS snapshot: http://snaps.php.net/php4-latest.tar.gz For Windows: http://snaps.php.net/win32/php4-win32-latest.zip [2002-11-30 20:39:12] [EMAIL PROTECTED] Can you please be very specific about your table and column names. The ODBC driver doesn't handle odd names very well. There's a big difference between: SELECT * FROM froo SELECT * FROM [FR oO] [2002-08-25 23:54:30] [EMAIL PROTECTED] Yes, try that first, after recreate the data field, I have no problem afterwards. You can use the mssql.dll if you want~ I use that in all time, I don't like ODBC, [2002-08-25 00:51:28] [EMAIL PROTECTED] Hi I Have this problem Too I use an Odbc conennection on Win2000 prof and IIS ver 5 I try to fetch some data from my database by this lines : $query="Select username,name,family,Sex,pic,pic_type ,about from [users]"; ... ... $username = odbc_result($result, 1); $name = odbc_result($result, 2); this page is work probebly at first time but after some refreshing I recive "PHP has encountered an Access Violation at X" only at this page and other .php page is work probebly; I install PHP on my computer in ISAPI mode in my users table "Pic_type" and "about" allow null I rename these fieldes but not effect . you say I remove this field's and add them again ? is it effective? I try it but not sure thank's [2002-06-08 20:28:34] [EMAIL PROTECTED] Server Version: MSSQL Server 2000 Operating System: WIN2K Server Database Details: The error field is smallmoney, allow null. Error Solution: I've tried rename it with other field which is also 'smallmoney' and 'allow null', but problem does not solve this way. The only way to solve this problem is to remove that field and create another new field again. Notice: Notice that the field works fine inside the MSSQL server's 'Query Analyzer', no error occur inside MSSQL server itself, but it produce error with the PHP engine. How does the bug act like: This error might not hang the whole php engine in first few times you recieve the message "PHP has encountered an Access Violation at ", but it will eventually hang when you load that page few more times. 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/17563 -- Edit this bug report at http://bugs.php.net/?id=17563&edit=1
#18939 [Fbk->NoF]: Access violation in php4ts.dll running as a servlet
ID: 18939 Updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] -Status: Feedback +Status: No Feedback Bug Type: Servlet related Operating System: Windows 2000 Pro SP2 PHP Version: 4.2.2 New Comment: No feedback was provided for this bug for over 2 weeks, so it is being suspended automatically. If you are able to provide the information that was originally requested, please do so and change the status of the bug back to "Open". Previous Comments: [2002-12-08 17:16:22] [EMAIL PROTECTED] Please try using this CVS snapshot: http://snaps.php.net/php4-latest.tar.gz For Windows: http://snaps.php.net/win32/php4-win32-latest.zip [2002-10-28 06:37:51] [EMAIL PROTECTED] RH 7.2 Linux 2.4.7.10 PHP 4.2.3 TOMCAT4.1.12 COCOON2.0.3 JSDK1.4.1 It seems to work but . I Am enable to run the JAVA extension or PHP as servlet correctly, for the last test of PHP I try to work with PHP as a servlet. It seems there is a problem with the send () native method of PHP : (this call is created inside the servlet.java class from php.../sapi/servlet/ ) => Public native send(string requestMethod, String QueryString, String pathInfo, String PathTranslated, String contentType, int contentLength, String authUser, boolean display_sourc_mode). As developed in the the bug id : 16402, I've also place libphp4.so inside /usr/java/j2sdk1.4.1/jre/lib with the related correction to the LD_LIBRARY_PATH. I understand that JAVA waiting for a php4.so, but it start to work only through a soft link => ln -s libphp4.so php4.so if I rename directly libphp4.so as php4.so it does not find any php4 in library.java.path java.lang.UnsatisfiedLinkError: no php4 in java.library.path With a soft link , It seems to work with the following file It's OK it works... several time, no problem on the other hand if I try : The Virtual machine crashes each time With the the message than the exception was detected in the native code outside the VM unexpected Signal: 11 occured at PC=0x4EA8A5BF Function=zend_hash_index_update_or_next_insert+0x3B library=/i386/libphp4.so Is it a bug in the virtual machine ? I'm circumspect about that ! The ouput is not a well-formed XML tree ? But I don't know Marcel [2002-08-17 17:58:36] [EMAIL PROTECTED] Just marking as "Open" again... [2002-08-17 11:46:43] [EMAIL PROTECTED] The log file contains *exactly* the same information I pasted in the original submission. I would not think Resin per se is the problem, as I managed to see the output of with it. From my experience, a crash in native code like this one can only result from a bug in the native code or possibly a bug in the JVM. [2002-08-16 12:47:40] [EMAIL PROTECTED] The microsoft page does not exist, but I am running Win2k IIS/PHP-4.2.2 here, and have not seen this issue. I consider that bogus. As for the initial report running as a servlet, I haven't any experience with this webserver... nor do I know if PHP really even works with it (non-documented). Can you place the error message from hs_err_pid1892.log in the bug report though as well? 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/18939 -- Edit this bug report at http://bugs.php.net/?id=18939&edit=1
#19399 [Fbk->NoF]: Problem with method call - please report this bug
ID: 19399
Updated by: [EMAIL PROTECTED]
Reported By: [EMAIL PROTECTED]
-Status: Feedback
+Status: No Feedback
Bug Type: Scripting Engine problem
Operating System: Linux & Win2000
PHP Version: 4.2.3
New Comment:
No feedback was provided for this bug for over 2 weeks, so it is
being suspended automatically. If you are able to provide the
information that was originally requested, please do so and change
the status of the bug back to "Open".
Previous Comments:
[2002-12-08 10:47:45] [EMAIL PROTECTED]
Please try using this CVS snapshot:
http://snaps.php.net/php4-latest.tar.gz
For Windows:
http://snaps.php.net/win32/php4-win32-latest.zip
I can not reproduce this with PHP 4.3.0-dev..
[2002-12-06 00:31:51] The Anarcat <[EMAIL PROTECTED]>
Also note that morphing the code into:
function seek_and_destroy($where_ary) {
if (!isset($this)) {
$foo = new ecdGroupedNews();
} else {
$foo = $this;
}
supressees the warning, of course, so it is a proper workaround, for
me.
[2002-12-06 00:29:12] [EMAIL PROTECTED]
I have had a similar situation when assigning to $this:
function seek_and_destroy($where_ary) {
if (!isset($this)) {
$this = new ecdGroupedNews(); // this is the line where the warning
is pointing to
}
...
}
this yields:
Warning: Problem with method call - please report this bug in
/usr/home/anarcat/data/web_pages/www/anarcat.ath.cx/php/ecdGroupedNews.inc.php
on line 44
well, it's not *exactly* the same thing, but there is a similarity:
both problems occur when referencing $this in shadowy conditions (ie.
unset($this)).
[2002-09-14 00:20:42] [EMAIL PROTECTED]
I get the following error message:
Warning: Problem with method call - please report this bug in line
xyz.
This error message comes from /Zend/zend_execute.c, line 1638.
This error occurs in our applications framework with many intermingled
classes on both Linux and Windows 2000 Boxes (I have not checked on
Solaris yet). I have not been able to produce a simple set of classes
producing this error. The basic structure of what our code is doing
is:
class CUi {
function httpHeader($p_disableGzHandler = false) {
}
function htmlHead($p_subDirs = false) {
if ( ! isset($this) ) {
// this is the static pseudo initialization
$this->m_subDirs = $p_subDirs;
}
CUi::httpHeader(); // this is the line where the error occurs
}
}
CUi::httpHeader();
If I move the CUi:httpHeader() call done from within htmlHead() above
"if (! isset($this) )" the error does not occur.
I am sorry to not be able to provide better information. I would not
have reported this bug, but it explicitly asks to report it, so here we
go.
--
Edit this bug report at http://bugs.php.net/?id=19399&edit=1
#16411 [Fbk->NoF]: CGI application misbehaved by not returning a complete set of
ID: 16411 Updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] -Status: Feedback +Status: No Feedback Bug Type: MSSQL related Operating System: Windows 2000 PHP Version: 4.1.2 New Comment: No feedback was provided for this bug for over 2 weeks, so it is being suspended automatically. If you are able to provide the information that was originally requested, please do so and change the status of the bug back to "Open". Previous Comments: [2002-12-18 06:43:19] [EMAIL PROTECTED] I have the same problem. Platform: PHP different versions, SQL Server 2000 and Windows 2000. I see it a lot when the server is busy, or when two requests are made really fast after another. Really need a solution for this. [2002-12-13 11:25:11] [EMAIL PROTECTED] i'm also experiencing this error with win xp, mssql 2000, and php 4.3.0 rc3. is it a problem with php, or with the mssql libraries? [2002-12-08 10:31:33] [EMAIL PROTECTED] Please try using this CVS snapshot: http://snaps.php.net/php4-latest.tar.gz For Windows: http://snaps.php.net/win32/php4-win32-latest.zip [2002-12-02 19:59:17] [EMAIL PROTECTED] Database connections are all transient. In the original code, I did not close the connections because php would do that at the end of script. But as I was in doubt, I later made a close right before calling the function header() but the same problem happened. I also made another test: in the script I just opened and immediately right after colsed it. The same bug happened. When I removed that tiny chunk of code, every thing worked just fine. [2002-12-02 19:57:52] [EMAIL PROTECTED] Database connections are all transient. In the original code, I did not close the connections because php would do that at the end of script. But as I was in doubt, I later made a close right before calling the function header() but the same problem happened. I also made another test: in the script I just opened and immediately right after colsed it. The same bug happened. When I removed that tiny chunk of code, every thing worked just fine. 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/16411 -- Edit this bug report at http://bugs.php.net/?id=16411&edit=1
#15333 [Fbk->NoF]: strndup access violation
ID: 15333 Updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] -Status: Feedback +Status: No Feedback Bug Type: IIS related Operating System: Windows 2000 Pro PHP Version: 4.3.0-dev New Comment: No feedback was provided for this bug for over 2 weeks, so it is being suspended automatically. If you are able to provide the information that was originally requested, please do so and change the status of the bug back to "Open". Previous Comments: [2002-12-08 17:32:41] [EMAIL PROTECTED] Please try using this CVS snapshot: http://snaps.php.net/php4-latest.tar.gz For Windows: http://snaps.php.net/win32/php4-win32-latest.zip There was patch commited to the CVS on 2002/12/02 that may have solved the problem. [2002-12-01 16:19:51] [EMAIL PROTECTED] I can easily reproduce this. With a simple 5 refreshes kills PHP and inetinfo. I have narrowed it down to a auto_prepend_file setting in php.ini. With that setting disabled then I cannot crash it. Hope this helps. [2002-11-27 14:37:58] [EMAIL PROTECTED] We had the same "php4ts!zend_strndup + 0x2B + 0xA05CB1AD." error on our win2k server iis5 and php4.2.1. Stan.nospam, and maybe others as well mentioned about setting isapi filters. We added an isapi filter pointing to the same php4isapi.dll as in the apps mappings. The application which was hanging every 5 minutes before, didn't hang since (which is for 4 days now) [2002-11-27 09:16:04] [EMAIL PROTECTED] Same issue, and even worse: since the last MS updates (IIS, SQL, MDAC), I get a bunch of access violations that I almost never got before. And running manually php.cgi causes the script to quit at the first SQL request, without warning/errors. It says 'missing cgi headers' when running under php-cgi. I tried 4.3.0RC1, 4.3.0-dev, 4.4.0-dev (yesterday's snapshots), all the same result. Any PHP developper using a dual cpu Win2K platform could test/fix this? [2002-11-20 14:30:05] [EMAIL PROTECTED] Add me to the list of people experiencing this. After a little while of switching back and forth from AV to working it goes to not responding at all. :-( 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/15333 -- Edit this bug report at http://bugs.php.net/?id=15333&edit=1
#20104 [Fbk->NoF]: unhandled exception with multiple requests
ID: 20104 Updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] -Status: Feedback +Status: No Feedback Bug Type: Apache related Operating System: win2k PHP Version: 4CVS-2002-10-26 New Comment: No feedback was provided for this bug for over 2 weeks, so it is being suspended automatically. If you are able to provide the information that was originally requested, please do so and change the status of the bug back to "Open". Previous Comments: [2002-12-08 17:04:00] [EMAIL PROTECTED] Please try using this CVS snapshot: http://snaps.php.net/php4-latest.tar.gz For Windows: http://snaps.php.net/win32/php4-win32-latest.zip [2002-10-26 10:51:00] [EMAIL PROTECTED] Seems to be a threadsafe issue in latest cvs + apache builds (apache 1.3.26 + php cvs) NTDLL.DLL!77fcb032() > php4ts_debug.dll!_emalloc(unsigned int size=10, char * __zend_filename=0x0087dd80, unsigned int __zend_lineno=226, char * __zend_orig_filename=0x, unsigned int __zend_orig_lineno=0) Line 154 + 0x3e C php4ts_debug.dll!_estrdup(const char * s=0x00f08440, char * __zend_filename=0x0087dd80, unsigned int __zend_lineno=226, char * __zend_orig_filename=0x, unsigned int __zend_orig_lineno=0) Line 335 + 0x19 C php4ts_debug.dll!sapi_get_default_content_type(void * * * tsrm_ls=0x00fad4b0) Line 226 + 0x1dC php4apache.dll!php_apache_get_default_mimetype(request_rec * r=0x010ce978, void * * * tsrm_ls=0x00fad4b0) Line 457 + 0xaC php4apache.dll!send_php(request_rec * r=0x010ce978, int display_source_mode=0, char * filename=0x010cf458) Line 544 + 0xd C php4apache.dll!send_parsed_php(request_rec * r=0x010ce978) Line 571 + 0xd C ApacheCore.dll!6ff64887() Occurs with debug php build, with any script (e.g. . issue ONLY occurs with multiple simultaneous requests( where multiple is as few as 2 simultaneous requests). -- Edit this bug report at http://bugs.php.net/?id=20104&edit=1
#20569 [Fbk->NoF]: Apache fails when restarting
ID: 20569 Updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] -Status: Feedback +Status: No Feedback Bug Type: Apache2 related Operating System: Linux 2.4.19 (Debian) PHP Version: 4.3.0RC1 New Comment: No feedback was provided for this bug for over 2 weeks, so it is being suspended automatically. If you are able to provide the information that was originally requested, please do so and change the status of the bug back to "Open". Previous Comments: [2002-12-08 16:10:44] [EMAIL PROTECTED] Please try using this CVS snapshot: http://snaps.php.net/php4-latest.tar.gz For Windows: http://snaps.php.net/win32/php4-win32-latest.zip Just a side note support for Apache 2 is experimental and this is especially true if you are using the worker model. [2002-11-25 02:54:54] [EMAIL PROTECTED] It only happens when php filter is loaded. I also recall that the same behavior we had on FreeBSD 5.0 (developers preview) using PHP 4.3.0pre2 but i cannot confirm it because this setup is no longer available to me. [2002-11-23 16:11:18] [EMAIL PROTECTED] Does this happen when PHP dso module is not loaded? [2002-11-22 06:12:27] [EMAIL PROTECTED] Apache 2.0.43 (worker model) PHP: ./configure --with-mysql --with-dom --with-dom-xslt --with-apxs2=/usr/bin/apxs2 --with-zlib --disable-ctype "apache2ctl restart" does: [notice] SIGHUP received. Attempting to restart [notice] seg fault or similar nasty error detected in the parent process stoping and then starting apache doesn't generate this error. only restarting fails. -- Edit this bug report at http://bugs.php.net/?id=20569&edit=1
#20849 [Fbk->NoF]: POST data submitted by UNIX Netscape 4+ (Mozilla 1+) won't fill *_POST array
ID: 20849
Updated by: [EMAIL PROTECTED]
Reported By: [EMAIL PROTECTED]
-Status: Feedback
+Status: No Feedback
Bug Type: *General Issues
Operating System: win2k adv server SP3
PHP Version: 4.3.0RC2
New Comment:
No feedback was provided for this bug for over 2 weeks, so it is
being suspended automatically. If you are able to provide the
information that was originally requested, please do so and change
the status of the bug back to "Open".
Previous Comments:
[2002-12-06 20:28:53] [EMAIL PROTECTED]
Please don't send me any private emails but add the information HERE so
that other people can see it too.
Thank you. (and short example script is around 10-15 lines MAX)
[2002-12-06 06:21:51] [EMAIL PROTECTED]
I can't really reproduce this..(posting even this form with NS4 on
Linux, and as you can see, it works fine).
Please add a short example script here (complete one).
You can also try the latest STABLE snapshot from http://snaps.php.net/
(and make sure you replace ALL the existing files with the new ones.
Especially php4ts.dll)
[2002-12-05 18:05:14] [EMAIL PROTECTED]
Tried to submit a form via POST method to the server
(apache 1.3.27). Then wanted to have the submitted data
just be viewed by the script.
while(list($key, $value) = each($_REQUEST)) {
echo "field '$key', value '$value' ";
}
I only get the session_id or GET data when submitting
the form with an UNIX Netscape 4+. Windows Versions
work properly. Netscape 3 on both platforms is doing
a great job as well as the KDE Konqueror.
I even tried the $_POST and $HTTP_POST_VARS arrays.
Nothing in there but the sessionID. Posts in news-
groups didn't help, people only say, they'd have the
same problem.
Seven
--
Edit this bug report at http://bugs.php.net/?id=20849&edit=1
#16496 [Fbk->NoF]: Stored Procedure Parameters is_null issue
ID: 16496
Updated by: [EMAIL PROTECTED]
Reported By: [EMAIL PROTECTED]
-Status: Feedback
+Status: No Feedback
Bug Type: MSSQL related
Operating System: Win2000
PHP Version: 4.1.2
New Comment:
No feedback was provided for this bug for over 2 weeks, so it is
being suspended automatically. If you are able to provide the
information that was originally requested, please do so and change
the status of the bug back to "Open".
Previous Comments:
[2002-12-07 01:53:06] [EMAIL PROTECTED]
Please try using this CVS snapshot:
http://snaps.php.net/php4-latest.tar.gz
For Windows:
http://snaps.php.net/win32/php4-win32-latest.zip
[2002-04-08 11:54:31] [EMAIL PROTECTED]
The problem is with executing a stored procedure with a null-value
varchar output parameter.
Steps...
1) create any SP that has a varchar(200) input/output param
e.g.
create procedure Test
(
@TestVarchar varchar(200) = null output
)
as
select @TestVarchar = 'Successful parameter feedback';
2) Run stored procedure using following statements...
$ConnectionObj = mssql_connect($DB_SERVER_NAME, $DB_USER,
$DB_PASSWORD);
$aStatement = mssql_init("dbo.test", $ConnectionObj);
mssql_bind($aStatement, "RETVAL", &$RetVal, SQLINT4);
mssql_bind($aStatement, "@TestVarchar", &$Value, SQLVARCHAR, TRUE,
TRUE, 200);
$ExecResult = mssql_execute($aStatement);
When PHP executes the SP it defines the parameter as VARCHAR(0) when it
should be VARCHAR(200).
I've run SQL Profiler and it shows...
declare @P1 varchar(0)
set @P1=NULL
exec dbo.test @P1 output
select @P1
when it should be
declare @P1 varchar(200)
set @P1=NULL
exec dbo.test @P1 output
select @P1
If you change the bind statement so that the @TestVarchar parameter is
not null then the whole thing works.
--
Edit this bug report at http://bugs.php.net/?id=16496&edit=1
#18429 [Fbk->NoF]: mssql_query() crashes on stored procedure using a cursor on query that contains
ID: 18429 Updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] -Status: Feedback +Status: No Feedback Bug Type: MSSQL related Operating System: Win2000 PHP Version: 4.3.0-dev New Comment: No feedback was provided for this bug for over 2 weeks, so it is being suspended automatically. If you are able to provide the information that was originally requested, please do so and change the status of the bug back to "Open". Previous Comments: [2002-12-08 10:34:39] [EMAIL PROTECTED] Please try using this CVS snapshot: http://snaps.php.net/php4-latest.tar.gz For Windows: http://snaps.php.net/win32/php4-win32-latest.zip [2002-07-19 14:45:37] [EMAIL PROTECTED] I download apache 1.3.26 from www.apache.org and latest PHP from listed URL, but it doesn't work. PHP still crashes. Both installed on Win 2000 Advanced Server. [2002-07-19 12:10:56] [EMAIL PROTECTED] This is the snapshot for 4.3.0-dev: http://snaps.php.net/win32/php4-win32-latest.zip DO NOT REPLY unless you have _NEW_ information. DO NOT TOUCH the version anymore Also note that Apache2 is NOT stable for ANY use yet. Use Apache 1.3.26 which is proven to actually work (with PHP) [2002-07-19 09:56:33] [EMAIL PROTECTED] I'm very sorry, I have to find PHP version, which do that correctly, so I've tried all available versions. Latest versions too. In combobox on 'Bugs Report - New' are only 4.1.2, 4.2.0, 4.2.1 and 4CVS-2002-07-19 versions selectable. Because of both latest versions (stable 4.2.2-dev and 4.3.0-dev) was uploaded to server snaps.php.net 2002/07/19, so I choose version 4CVS-2002-07-19. I've tried new update of latest stable version (http://snaps.php.net/win32/php4-win32-STABLE-latest.zip), and it is still not work. May be it is caused with my bad configuration of Apache/PHP. Because of this little misunderstanding, I'm not sure, which version you are modifying, so I don't know, which one I need to download. Could you, please, send me, if it is corrected and which archive I should to download. Thank you for your patient. [2002-07-19 08:52:13] [EMAIL PROTECTED] please don't change the version to earlier if you already confirmed it to happen with the LATEST.. 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/18429 -- Edit this bug report at http://bugs.php.net/?id=18429&edit=1
#20864 [Fbk->NoF]: Cc/Bcc fields don't seem to work
ID: 20864 Updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] -Status: Feedback +Status: No Feedback Bug Type: Mail related Operating System: Windows 2000 PHP Version: 4.2.3 New Comment: No feedback was provided for this bug for over 2 weeks, so it is being suspended automatically. If you are able to provide the information that was originally requested, please do so and change the status of the bug back to "Open". Previous Comments: [2002-12-08 02:39:07] [EMAIL PROTECTED] Are you sure your php.ini is even read? Is it in correct place? Is it with correct NAME..(common problem, people tend to name it php.ini.ini on Windows) [2002-12-07 10:10:43] [EMAIL PROTECTED] I seem to have been misunderstood. I tried using the referred devel snapshot and I always get the "PHP CGI cannot be accessed directly [...]" message, even with the parameters shown above. Can anybody tell me what else might be wrong (note: I haven't had these problems with any other PHP release before..) [2002-12-07 02:55:26] [EMAIL PROTECTED] In my case, Cc: and Bcc: work now (dev and stable snapshots on winXP). Christoph [2002-12-06 18:31:06] [EMAIL PROTECTED] So does the mail work now? [2002-12-06 12:35:48] [EMAIL PROTECTED] Addendum to last comment: php-cgi.exe does not make the request hang forever. Sorry about that. All the other info still stands. 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/20864 -- Edit this bug report at http://bugs.php.net/?id=20864&edit=1
#16548 [Fbk->NoF]: exec or system a daemon will catch the port for this session
ID: 16548 Updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] -Status: Feedback +Status: No Feedback Bug Type: Scripting Engine problem Operating System: RED HAT Linux 7.2 PHP Version: 4.1.2 & 4.3.0 New Comment: No feedback was provided for this bug for over 2 weeks, so it is being suspended automatically. If you are able to provide the information that was originally requested, please do so and change the status of the bug back to "Open". Previous Comments: [2002-12-07 01:54:32] [EMAIL PROTECTED] Please try using this CVS snapshot: http://snaps.php.net/php4-latest.tar.gz For Windows: http://snaps.php.net/win32/php4-win32-latest.zip [2002-09-29 11:04:07] [EMAIL PROTECTED] this bug does not relate to session module. [2002-09-26 10:43:24] [EMAIL PROTECTED] Related to #15642 and #15529. [2002-09-19 12:45:59] [EMAIL PROTECTED] Updating Version [2002-04-24 07:49:02] [EMAIL PROTECTED] Sorry i forgot that now _mprshut doesn't blocks the Apache. But _mprshut is still listening on port 80 after running this script ha-server (_mrshut is called in it): _mprshut 3989 root 16u IPv4 85958 TCP *:www (LISTEN) (output from lsof) PHP Version 4.3.0-dev 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/16548 -- Edit this bug report at http://bugs.php.net/?id=16548&edit=1
#18648 [Fbk->NoF]: Single entry form POST gives incorrect variable content
ID: 18648
Updated by: [EMAIL PROTECTED]
Reported By: [EMAIL PROTECTED]
-Status: Feedback
+Status: No Feedback
Bug Type: Apache2 related
Operating System: All
PHP Version: 4.3.0-dev/4.4.0-dev
New Comment:
No feedback was provided for this bug for over 2 weeks, so it is
being suspended automatically. If you are able to provide the
information that was originally requested, please do so and change
the status of the bug back to "Open".
Previous Comments:
[2002-12-09 12:48:23] [EMAIL PROTECTED]
Please try using this CVS snapshot:
http://snaps.php.net/php4-latest.tar.gz
For Windows:
http://snaps.php.net/win32/php4-win32-latest.zip
Small note for win32 users, the snapshot containing this patch will not
be avaliable for a few hours (1 hour for latest CVS, 7 hours for
STABLE).
[2002-12-08 05:01:28] [EMAIL PROTECTED]
Hi guys, I'm having the same problem on Win32 platform.
CODE
Page 1:
USA-United States
-All-
Page 2:
if (isset($HTTP_POST_VARS["marketframe"])) {
$strCountryCode = $HTTP_POST_VARS["marketframe"];
}
I get the value
$strCountryCode = "USAmarketframe=USA"
Also tried using $_POST but same result, using the GET method it works
fine.
OS Version: Windows 2000 Adv. Server SP3
Web Server: Apache 2.0.43
PHP Version: 4.3.0-dev (Oct 20 2002 16:11:45), API Filter, accessing MS
SQL Server 7
[2002-12-06 11:30:07] [EMAIL PROTECTED]
Oops, I should have meant php_strtok_r() replaces the delimiter "=" by
"\0".
[2002-12-06 11:26:40] [EMAIL PROTECTED]
[EMAIL PROTECTED]: IMO the change you pointed out has nothing to do
with this problem because the leading php_strtok_r() replaces delimiter
"=" by " ".
By the way I suspect this problem is an apache2 bug, not a php one
though I wasn't able to reproduce this problem. I have received two
similar PR, of which both reporters use Apache2.
[Report #1: RHLinux 8.0 / Apache 2.0.43 / PHP-4.3.0RC1]
This was reported in the Japanese PHP users' list. Please refer to
http://ns1.php.gr.jp/pipermail/php-users/2002-November/011656.html if
you can read Japanese.
[Report #2: RHLinux 7.2 / Apache 2.0.43 / PHP-4.3.0RC2]
"form post results in duplicitous $_REQUEST"
http://bugs.php.net/20823
[2002-12-02 07:51:35] [EMAIL PROTECTED]
I can't reproduce this problem using identical RPMs on Red Hat Linux
8.0 - this bug seems hard to trigger.
[EMAIL PROTECTED] - any further insight would be appreciated. I can't
find anything on the CVS logs about fixes for Tru64. There is one fix
to main/php_variables.c:
2002-09-07 Yasuo Ohgaki <[EMAIL PROTECTED]>
...
* main/php_variables.c: Fixed POST/GET/COOKIE var handling
but this seems to concern NUL-terminated strings in field values, unles
I'm mistaken.
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=18648&edit=1
#20874 [Fbk->NoF]: socket_read on Multihomed Windows XP crashes PHP
ID: 20874
Updated by: [EMAIL PROTECTED]
Reported By: [EMAIL PROTECTED]
-Status: Feedback
+Status: No Feedback
Bug Type: Sockets related
Operating System: Windows XP
PHP Version: 4.3.0RC2
New Comment:
No feedback was provided for this bug for over 2 weeks, so it is
being suspended automatically. If you are able to provide the
information that was originally requested, please do so and change
the status of the bug back to "Open".
Previous Comments:
[2002-12-09 09:22:53] [EMAIL PROTECTED]
Please try using this CVS snapshot:
http://snaps.php.net/php4-latest.tar.gz
For Windows:
http://snaps.php.net/win32/php4-win32-latest.zip
[2002-12-07 15:09:06] [EMAIL PROTECTED]
I downgraded the PHP version on this server to 4.2.2
It now works properly on this version.
It crashes on socket_read();
The parameters I am using in my Application are:
socket_read($this->sock[1],2048);
Like I said, the Example Aplication from the PHP Manual for a WWW
Client also crashes, also on socket_read.
[2002-12-07 14:52:22] [EMAIL PROTECTED]
Can you isolate the function that crashes & with what parameters? So
far, I was unable to reproduce the crash using the test servers I have
here.
[2002-12-07 04:21:59] [EMAIL PROTECTED]
I have written a couple OO-PHP based TCP clients for a Proprietary PHP
Socket Server that create a web based interface to certin aspects of
an
unnamed server.
This week, we had some hardware trouble, and we ended up moving one
server to Windows XP instead of Windows 2000. It was a clean
format.(new hd)
After some intial re-installation, I have found, that anytime I call
the
socket_read function PHP promptly crashes. The exact same code worked
on the same hardware running windows 2000, and the code also works
completely on Slackware-9.0(current).
The only thing that is unquie about this server is that it is
Multihomed
to about 30 different IP addresses.
This is repeatable. 100% everytime, using Apache2 Module, Apache13
Module, and the CLI interfaces to PHP.
The example script for a TCP Client on the Sockets Documentation also
crashes PHP:
TCP/IP Connection\n";
/* Get the port for the WWW service. */
$service_port = getservbyname ('www', 'tcp');
/* Get the IP address for the target host. */
$address = gethostbyname ('www.example.com');
/* Create a TCP/IP socket. */
$socket = socket_create (AF_INET, SOCK_STREAM, 0);
if ($socket < 0) {
echo "socket_create() failed: reason: " . socket_strerror
($socket)
. "\n";
} else {
echo "OK.\n";
}
echo "Attempting to connect to '$address' on port '$service_port'...";
$result = socket_connect ($socket, $address, $service_port);
if ($result < 0) {
echo "socket_connect() failed.\nReason: ($result) " .
socket_strerror($result) . "\n";
} else {
echo "OK.\n";
}
$in = "HEAD / HTTP/1.0\r\n\r\n";
$out = '';
echo "Sending HTTP HEAD request...";
socket_write ($socket, $in, strlen ($in));
echo "OK.\n";
echo "Reading response:\n\n";
while ($out = socket_read ($socket, 2048)) {
echo $out;
}
echo "Closing socket...";
socket_close ($socket);
echo "OK.\n\n";
?>
It gets to the echo "Reading response:\n\n"; and then PHP crashes, and
I
get the Windows XP message asking if I would like to send Microsoft a
bug report. I have several times. Maybe they will respond :-)
[2002-12-07 03:24:26] [EMAIL PROTECTED]
I have written a couple OO-PHP based TCP clients for a Proprietary PHP
Socket Server that create a web based interface to certin aspects of an
unnamed server.
This week, we had some hardware trouble, and we ended up moving one
server to Windows XP instead of Windows 2000. It was a clean
format.(new hd)
After some intial re-installation, I have found, that anytime I call
the socket_read function PHP promptly crashes. The exact same code
worked on the same hardware running windows 2000, and the code also
works completely on Slackware-9.0(current).
The only thing that is unquie about this server is that it is
Multihomed to about 30 different IP addresses.
This is repeatable. 100% everytime, using Apache2 Module, Apache13
Module, and the CLI interfaces to PHP.
The example script for a TCP Client on the Sockets Documentation also
crashes PHP:
TCP/IP Connection\n";
/* Get the port for the WWW service. */
$service_port = getservbyname ('www', 'tcp');
/* Get the IP address for the target host. */
$address = gethostbyname ('www.example.com');
/* Create a TCP/IP socket. */
$socket = socket_create (AF_INET, SOCK_STREAM, 0);
if (
#20832 [Fbk->NoF]: Access Violation
ID: 20832 Updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] -Status: Feedback +Status: No Feedback Bug Type: IIS related Operating System: Wind 2000 PHP Version: 4.2.3 New Comment: No feedback was provided for this bug for over 2 weeks, so it is being suspended automatically. If you are able to provide the information that was originally requested, please do so and change the status of the bug back to "Open". Previous Comments: [2002-12-24 12:32:43] [EMAIL PROTECTED] Had similar problem with intermittent translator and/or isapi dll crashes. I would get a page with "PHP has encountered an Access Violation at xxx" and this would lock-up PHP totally. I took the advise of [5 Dec 11:26am] [EMAIL PROTECTED] and got the latest dev build (4.4.0-dev) and replaced all the 4.2.3 dlls with the 4.4.0-dev dlls and this problem has cleared up. Many thanks to [EMAIL PROTECTED] for the suggestion! [2002-12-05 11:26:32] [EMAIL PROTECTED] Please try using this CVS snapshot: http://snaps.php.net/php4-latest.tar.gz For Windows: http://snaps.php.net/win32/php4-win32-latest.zip [2002-12-05 11:19:38] [EMAIL PROTECTED] Not enough information was provided for us to be able to handle this bug. Please re-read the instructions at http://bugs.php.net/how-to-report.php If you can provide more information, feel free to add it to this bug and change the status back to "Open". Thank you for your interest in PHP. [2002-12-05 11:12:45] [EMAIL PROTECTED] PHP has encountered an Access Violation at 77F64860 Get the above error ocassionally with phpwiki and phpfm Is not predictable when it happens -- Edit this bug report at http://bugs.php.net/?id=20832&edit=1
