Bug #15799 Updated: Another segfault on iconv
ID: 15799
Updated by: [EMAIL PROTECTED]
Reported By: [EMAIL PROTECTED]
-Status: Open
+Status: Analyzed
Bug Type: ICONV related
Operating System: Linux
PHP Version: 4.0CVS-2002-02-2
New Comment:
Yes true ... weird. Upon taking a closer look it seems the iconv fails
with 'Invalid or incomplete multibyte or wide character' but the error
code is not properly handled in the code in the first and therefore not
recognized. Will take a closer look later (this day ;).
Maybe you can verify if your input data really without errors?
Previous Comments:
[2002-03-11 17:40:44] [EMAIL PROTECTED]
Ah, you're right, I thought all ob_* functions that return or output
the buffer pass the data through the ob_handler first.
But even if I use it the intended way, the output is not converted.
This is the new script I used:
www.yahoo.com.tw
END;
iconv_set_encoding('input_encoding', 'BIG5');
iconv_set_encoding('internal_encoding', 'UTF-8');
iconv_set_encoding('output_encoding', 'UTF-8');
ob_start('ob_iconv_handler');
echo $text;
header('Content-Type: text/plain; charset=UTF-8');
ob_end_flush();
?>
[2002-03-11 17:10:02] [EMAIL PROTECTED]
I'm closing this because I think your code is bogus. The manual clearly
says "The function ("ob_iconv_handler") will be called when
ob_end_flush() is called, or when the output buffer is flushed to the
browser at the end of the request."
So, if you call ob_get_contents() and ob_end_clean() you do not get any
conversion. If you either call ob_end_flush() or just don't call any
further ob*() functions the conversion works as expected for me.
Feel free to re-open if you think I'm wrong.
[2002-03-11 05:58:19] [EMAIL PROTECTED]
Yep, saw it. Will fix this later (this day).
[2002-03-11 05:18:13] [EMAIL PROTECTED]
I see you already committed the patch to cvs and, yes, php doesn't
segfault anymore, thanks.
But unfortunately the conversion doesn't happen at all. You can try the
same script I posted earlier to reproduce it. Method 1 converts
correctly, method 2 just send the Big5 data asis.
[2002-03-10 18:01:25] [EMAIL PROTECTED]
Fixed in CVS and 4.2.0 branch.
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/15799
--
Edit this bug report at http://bugs.php.net/?id=15799&edit=1
Bug #16012: IIS + PHP + MSSQL Sessions not working right..
From: [EMAIL PROTECTED]
Operating system: Windows .NET Build 3604
PHP version: 4.1.1
PHP Bug Type: Session related
Bug description: IIS + PHP + MSSQL Sessions not working right..
When I look in the temp directory of the windows server I get ( minus the
admin):
!user|!password|
and on my linux server:
user|s:6:"---";password2|s:6:"-";admins|s:1:"1";
the lines used were:
session_register('user');
session_register('password');
--
Edit bug report at http://bugs.php.net/?id=16012&edit=1
--
Fixed in CVS:http://bugs.php.net/fix.php?id=16012&r=fixedcvs
Fixed in release:http://bugs.php.net/fix.php?id=16012&r=alreadyfixed
Need backtrace: http://bugs.php.net/fix.php?id=16012&r=needtrace
Try newer version: http://bugs.php.net/fix.php?id=16012&r=oldversion
Not developer issue: http://bugs.php.net/fix.php?id=16012&r=support
Expected behavior: http://bugs.php.net/fix.php?id=16012&r=notwrong
Not enough info: http://bugs.php.net/fix.php?id=16012&r=notenoughinfo
Submitted twice: http://bugs.php.net/fix.php?id=16012&r=submittedtwice
Bug #14151 Updated: Installed/Compiled Php4.0.6 with Oracle9i on Linux Red Hat7.2
ID: 14151
Updated by: [EMAIL PROTECTED]
Reported By: [EMAIL PROTECTED]
-Status: Feedback
+Status: No Feedback
Bug Type: OCI8 related
Operating System: Linux Red Hat 7.2
PHP Version: 4.0.6
New Comment:
No feedback was provided for this bug for over a month, 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-02-07 08:20:34] [EMAIL PROTECTED]
what is you configure line?
also what re the last 10 lines of the outpit of your configure?
[2002-02-07 03:03:01] [EMAIL PROTECTED]
today I tried installing php4.1.1 on RedHat7.2 with Oracle9i
but it gives an error "unsupported version " . I went through a
documentation where in it said that 4.1.1 has all fixups .the is a patch
to fix this bug in php4.0.6 too but i donot find any help for php4.1.1
.
can I have any help on this ??
regards
jags
[2001-12-21 19:42:23] [EMAIL PROTECTED]
I followed backtrace report Instructions:
First:I stop apache server by using following comand under root
privilage
#/usr/local/apache/bin/apachectl stop
/usr/local/apache/bin/apachectl stop: httpd stopped
Second Under root privilage run httpd - X under gdb with:
#gdb /usr/local/apache/bin/httpd
GNU gdb Red Hat Linux (5.1-1)
Copyright 2001 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public License, and you
are
welcome to change it and/or distribute copies of it under certain
conditions.
Type "show copying" to see the conditions.
There is absolutely no warranty for GDB. Type "show warranty" for
details.
This GDB was configured as "i386-redhat-linux"...
(gdb) run -X
Starting program: /usr/local/apache/bin/httpd -X
[New Thread 1024 (LWP 1971)]
After that I use web browser and access server to force the crash. I am
surprised that I can connect with oracle server well. The only thing is
the speed for access web is very slow. There is no gdb prompt appear,
and
there is no any message indication that there is a crash.
Following is php script to authorize into oracle:
/* Global Vars **/
$user = "";
$pswd = "xxx";
$dbase = "(DESCRIPTION =
(ADDRESS_LIST =
(ADDRESS = (PROTOCOL = TCP)(HOST = hermes.campus.uidaho.edu)(PORT
= 1521))
)
(CONNECT_DATA =
(SERVICE_NAME = oracle.campus.uidaho.edu)
)
)";
function dbConnect()
{
global $user, $pswd, $dbase;
$con = OCILogon($user, $pswd, $dbase);
if( OCIError($con) )
ErrorAndExit( "Could not create connection to the database."
);
else
return $con;
}
[2001-12-21 14:05:20] [EMAIL PROTECTED]
Can you generate a backtrace?
(http://bugs.php.net/bugs-generating-backtrace.php)
[2001-12-21 13:01:41] [EMAIL PROTECTED]
If you visit from following URL:
http://kellinux.cs.uidaho.edu/cs461/login.php
you can find php can access my oracle9i EE database well. The php script
on this machine(kellinux.cs.uidaho.edu) is the same one from previous
machine (hermes.campus.uidaho.edu). They both visit the Oracle9i
database server on hermes.campus.uidaho.edu.
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/14151
--
Edit this bug report at http://bugs.php.net/?id=14151&edit=1
Bug #14481 Updated: PHP 4.1.0 fails to compile with curl 7.9.2
ID: 14481 Updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] Status: Closed Bug Type: Compile Failure Operating System: Linux (RH 7.0) PHP Version: 4.1.0 New Comment: This still does not fix the problem. I've tried reinstalling CuRL-7.9.2 and it did not fix the problem after I tried recompiling PHP. HeLP! Previous Comments: [2001-12-13 22:32:08] [EMAIL PROTECTED] you have an old version of cURL (ie, you've incorrectly installed curl 7.9.2). Please properly upgrade and you should have no problems. -Sterling - Sterling..we have this nice web interface for updating bug reports.. Please use it. [2001-12-13 06:55:33] [EMAIL PROTECTED] PHP fails to compile with curl 7.9.2 ./configure --prefix=/etc --with-apache=/usr/src/Apachetoolbox-1.5.45/apache_1.3.22 --enable-exif --enable-track-vars --with-calendar=shared --enable-safe-mode --enable-magic-quotes --enable-trans-sid --enable-wddx --enable-ftp --with-gd=/etc --with-zlib --enable-gd-native-tt --with-t1lib=/etc/lib/php/t1libs --with-jpeg-dir=/etc --with-png-dir=/etc --with-zlib-dir=/etc --with-ttf --with-freetype-dir=/etc --with-mcrypt --with-openssl --with-mysql=/usr --enable-xslt --with-dom --with-xslt-sablot --with-curl (no errors) make fails with error curl.c: In function `zm_startup_curl': curl.c:147: `CURLOPT_SSL_VERIFYHOST' undeclared (first use in this function) curl.c:147: (Each undeclared identifier is reported only once curl.c:147: for each function it appears in.) curl.c:176: `CURLOPT_COOKIEJAR' undeclared (first use in this function) curl.c:177: `CURLOPT_SSL_CIPHER_LIST' undeclared (first use in this function) curl.c: In function `zif_curl_setopt': curl.c:671: `CURLOPT_SSL_VERIFYHOST' undeclared (first use in this function) curl.c:694: `CURLOPT_COOKIEJAR' undeclared (first use in this function) curl.c:695: `CURLOPT_SSL_CIPHER_LIST' undeclared (first use in this function) curl.c:797: `CURLFORM_COPYNAME' undeclared (first use in this function) curl.c:798: `CURLFORM_FILE' undeclared (first use in this function) curl.c:798: `CURLFORM_END' undeclared (first use in this function) curl.c:802: `CURLFORM_PTRCONTENTS' undeclared (first use in this function) make[3]: *** [curl.lo] Error 1 make[3]: Leaving directory `/usr/src/Apachetoolbox-1.5.45/src/php-4.1.0/ext/curl' make[2]: *** [all-recursive] Error 1 make[2]: Leaving directory `/usr/src/Apachetoolbox-1.5.45/src/php-4.1.0/ext/curl' make[1]: *** [all-recursive] Error 1 make[1]: Leaving directory `/usr/src/Apachetoolbox-1.5.45/src/php-4.1.0/ext' make: *** [all-recursive] Error 1 the same works for php 4.0.6 -- Edit this bug report at http://bugs.php.net/?id=14481&edit=1
Bug #15580 Updated: sapi_apache2.c fails to compile with Apache 2.0.28
ID: 15580 Updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] Status: Open Bug Type: Apache2 related Operating System: Debian 3.0 PHP Version: 4.0CVS-2002-02-15 New Comment: same with Slackware 8.0 + fixes PHP 4.1.1, 4.1.2, Apache 2.0.32, Linux 2.4.18 Making all in sapi make[1]: Entering directory `/usr/src/php-4.1.2/sapi' Making all in apache2filter make[2]: Entering directory `/usr/src/php-4.1.2/sapi/apache2filter' make[3]: Entering directory `/usr/src/php-4.1.2/sapi/apache2filter' /bin/sh /usr/src/php-4.1.2/libtool --silent --mode=compile /usr/src/php-4.1.2/meta_ccld -I. -I/usr/src/php-4.1.2/sapi/apache2filter -I/usr/src/php-4.1.2/main -I/usr/src/php-4.1.2 -I/usr/local/apache2/include -I/usr/src/php-4.1.2/Zend -I/usr/src/php-4.1.2/ext/mysql/libmysql -I/usr/src/php-4.1.2/ext/xml/expat -D_REENTRANT -I/usr/src/php-4.1.2/TSRM -DTHREAD=1 -g -O2 -pthread -DZTS -prefer-pic -c sapi_apache2.c sapi_apache2.c: In function `php_apache_sapi_register_variables': sapi_apache2.c:148: warning: initialization discards qualifiers from pointer target type sapi_apache2.c: In function `php_input_filter': sapi_apache2.c:247: incompatible type for argument 4 of `ap_get_brigade' sapi_apache2.c:247: too few arguments to function `ap_get_brigade' sapi_apache2.c: In function `php_register_hook': sapi_apache2.c:408: warning: passing arg 2 of `ap_register_input_filter' from incompatible pointer type make[3]: *** [sapi_apache2.lo] Error 1 make[3]: Leaving directory `/usr/src/php-4.1.2/sapi/apache2filter' make[2]: *** [all-recursive] Error 1 make[2]: Leaving directory `/usr/src/php-4.1.2/sapi/apache2filter' make[1]: *** [all-recursive] Error 1 make[1]: Leaving directory `/usr/src/php-4.1.2/sapi' make: *** [all-recursive] Error 1 Previous Comments: [2002-02-25 04:35:01] [EMAIL PROTECTED] Same problem with apache 2.0.32 and php 4.1.1 on RedHat 7.2 ( kernel2.4.13). [2002-02-22 16:32:44] [EMAIL PROTECTED] Wish I had a sollution but I can only make things worse: Apache2.0.32(the released beta) and PHP4.1.1 give the same error... [2002-02-15 18:12:13] [EMAIL PROTECTED] Okay, here we go: since 2.0.28 didn't work, I tried to compile PHP 20020215 with 2.0.32-alpha and it did at least compile ;-) But this led into another problem. Starting Apache succeeds without php module loaded, but leads to strange behaviour if the module has been enabled. It's hard to explain: the main Apache process is started, but doesn't create any child processes or threads. It doesn't react to signals, nor responds to telnet requests. Hmm, so I took the latest Apache CVS and simplified all configure options. Same result. I've no idea where to search for any hints on how to solve this. I know that Apache 2 support in PHP is still under heavy development, but any hints 'd be appreciated. Please let me know if I shall provide further information. Summary: Apache latest CVS, vanilla config with php4 enabled Configure options: --with-mpm=worker \ --prefix=/usr/local/ap2 \ --enable-module=so PHP latest CVS, configure options: --with-apxs2=/usr/local/ap2/bin/apxs GNU ld version 2.11.92.0.12.3 20011121 Debian/GNU Linux gcc 2.95.4 ltmain.sh (GNU libtool) 1.4.2a (1.922.2.79 2001/11/28 21:50:31) TIA Victor [2002-02-15 15:57:15] [EMAIL PROTECTED] Try the latest CVS version of Apache2 as well. I built 2 days ago without a problem. Let me know if that helps. Sean [2002-02-15 15:26:42] [EMAIL PROTECTED] Hello folks, today I tried to compile latest PHP with Apache 2.0.28, since PHP 4.1.1 seems to have some variable export problem. Configure goes fine, but make bails out with the following error messages: make[3]: Entering directory `/data/home/vf/ap2/build/php/sapi/apache2filter' /bin/sh /home/vf/ap2/build/php/libtool --silent --mode=compile gcc -I. -I/home/vf/ap2/build/php/sapi/apache2filter -I/home/vf/ap2/build/php/main -I/home/vf/ap2/build/php -I/usr/local/ap2/include -I/home/vf/ap2/build/php/Zend -I/home/vf/ap2/build/php/ext/mysql/libmysql -I/home/vf/ap2/build/php/ext/xml/expat -D_REENTRANT -I/home/vf/ap2/build/php/TSRM -DTHREAD=1 -g -O2 -pthread -DZTS -prefer-pic -c sapi_apache2.c sapi_apache2.c: In function `php_input_filter': sapi_apache2.c:252: incompatible type for argument 4 of `ap_get_brigade' sapi_apache2.c:252: too many arguments to function `ap_get_brigade' sapi_apache2.c:259: incompatible type for argument 4 of `ap_get_brigade' sapi_apache2.c:259: too many arguments to function `ap_get_brigade' sapi_apache2.c: In function `php_register_hook': s
Bug #16011 Updated: --enable-bcmath link error
ID: 16011 Updated by: [EMAIL PROTECTED] -Summary: --with-bcmath link error Reported By: [EMAIL PROTECTED] Status: Open Bug Type: Compile Failure Operating System: Mac OS X 10.1.3 PHP Version: 4.0CVS-2002-03-11 New Comment: wrong configure argument in title :\ Previous Comments: [2002-03-11 22:24:33] [EMAIL PROTECTED] Configure Line: ./configure --with-ldap=/usr/local --with-xml --enable-shared --enable-versioning --enable-trans-id --enable-t rack-vars --enable-ftp --with-mysql --with-pdflib=/usr/local --with-zlib-dir=/usr/local --with-png-dir=/usr/lo cal --with-jpeg-dir=/usr/local --with-gd=/usr/local --with-tiff-dir=/usr/local --with-apxs=/usr/sbin/apxs --en able-openbase_module --with-pgsql=/Library/PostgreSQL --with-curl=/usr/local --with-pspell=/usr/local/pspell - -enable-exif --enable-wddx --enable-mbstring --enable-mbstr-enc-trans --with-iconv=/usr/local/iconv --enable-b cmath Yields the following output during the final link phase: /usr/bin/ld: multiple definitions of symbol __bc_Free_list ext/bcmath/libbcmath/src/add.lo definition of __bc_Free_list in section (__DATA,__common) ext/bcmath/libbcmath/src/div.lo definition of __bc_Free_list in section (__DATA,__common) ext/bcmath/libbcmath/src/init.lo definition of __bc_Free_list in section (__DATA,__data) /usr/bin/ld: multiple definitions of symbol __one_ ext/bcmath/bcmath.lo definition of __one_ in section (__DATA,__common) ext/bcmath/libbcmath/src/init.lo definition of __one_ in section (__DATA,__common) /usr/bin/ld: multiple definitions of symbol __two_ ext/bcmath/bcmath.lo definition of __two_ in section (__DATA,__common) ext/bcmath/libbcmath/src/init.lo definition of __two_ in section (__DATA,__common) /usr/bin/ld: multiple definitions of symbol __zero_ ext/bcmath/bcmath.lo definition of __zero_ in section (__DATA,__common) ext/bcmath/libbcmath/src/init.lo definition of __zero_ in section (__DATA,__common) ext/bcmath/libbcmath/src/neg.lo definition of __bc_Free_list in section (__DATA,__common) ext/bcmath/libbcmath/src/outofmem.lo definition of __bc_Free_list in section (__DATA,__common) ext/bcmath/libbcmath/src/raisemod.lo definition of __bc_Free_list in section (__DATA,__common) ext/bcmath/libbcmath/src/rt.lo definition of __bc_Free_list in section (__DATA,__common) ext/bcmath/libbcmath/src/sub.lo definition of __bc_Free_list in section (__DATA,__common) ext/bcmath/libbcmath/src/compare.lo definition of __bc_Free_list in section (__DATA,__common) ext/bcmath/libbcmath/src/divmod.lo definition of __bc_Free_list in section (__DATA,__common) ext/bcmath/libbcmath/src/int2num.lo definition of __bc_Free_list in section (__DATA,__common) ext/bcmath/libbcmath/src/num2long.lo definition of __bc_Free_list in section (__DATA,__common) ext/bcmath/libbcmath/src/output.lo definition of __bc_Free_list in section (__DATA,__common) ext/bcmath/libbcmath/src/recmul.lo definition of __bc_Free_list in section (__DATA,__common) ext/bcmath/libbcmath/src/sqrt.lo definition of __bc_Free_list in section (__DATA,__common) ext/bcmath/libbcmath/src/zero.lo definition of __bc_Free_list in section (__DATA,__common) ext/bcmath/libbcmath/src/debug.lo definition of __bc_Free_list in section (__DATA,__common) ext/bcmath/libbcmath/src/doaddsub.lo definition of __bc_Free_list in section (__DATA,__common) ext/bcmath/libbcmath/src/nearzero.lo definition of __bc_Free_list in section (__DATA,__common) ext/bcmath/libbcmath/src/num2str.lo definition of __bc_Free_list in section (__DATA,__common) ext/bcmath/libbcmath/src/raise.lo definition of __bc_Free_list in section (__DATA,__common) ext/bcmath/libbcmath/src/rmzero.lo definition of __bc_Free_list in section (__DATA,__common) ext/bcmath/libbcmath/src/str2num.lo definition of __bc_Free_list in section (__DATA,__common) make: *** [libphp4.la] Error 1 This is also the case with 4.1.2 stable. -- Edit this bug report at http://bugs.php.net/?id=16011&edit=1
Bug #16011: --with-bcmath link error
From: [EMAIL PROTECTED] Operating system: Mac OS X 10.1.3 PHP version: 4.0CVS-2002-03-11 PHP Bug Type: Compile Failure Bug description: --with-bcmath link error Configure Line: ./configure --with-ldap=/usr/local --with-xml --enable-shared --enable-versioning --enable-trans-id --enable-t rack-vars --enable-ftp --with-mysql --with-pdflib=/usr/local --with-zlib-dir=/usr/local --with-png-dir=/usr/lo cal --with-jpeg-dir=/usr/local --with-gd=/usr/local --with-tiff-dir=/usr/local --with-apxs=/usr/sbin/apxs --en able-openbase_module --with-pgsql=/Library/PostgreSQL --with-curl=/usr/local --with-pspell=/usr/local/pspell - -enable-exif --enable-wddx --enable-mbstring --enable-mbstr-enc-trans --with-iconv=/usr/local/iconv --enable-b cmath Yields the following output during the final link phase: /usr/bin/ld: multiple definitions of symbol __bc_Free_list ext/bcmath/libbcmath/src/add.lo definition of __bc_Free_list in section (__DATA,__common) ext/bcmath/libbcmath/src/div.lo definition of __bc_Free_list in section (__DATA,__common) ext/bcmath/libbcmath/src/init.lo definition of __bc_Free_list in section (__DATA,__data) /usr/bin/ld: multiple definitions of symbol __one_ ext/bcmath/bcmath.lo definition of __one_ in section (__DATA,__common) ext/bcmath/libbcmath/src/init.lo definition of __one_ in section (__DATA,__common) /usr/bin/ld: multiple definitions of symbol __two_ ext/bcmath/bcmath.lo definition of __two_ in section (__DATA,__common) ext/bcmath/libbcmath/src/init.lo definition of __two_ in section (__DATA,__common) /usr/bin/ld: multiple definitions of symbol __zero_ ext/bcmath/bcmath.lo definition of __zero_ in section (__DATA,__common) ext/bcmath/libbcmath/src/init.lo definition of __zero_ in section (__DATA,__common) ext/bcmath/libbcmath/src/neg.lo definition of __bc_Free_list in section (__DATA,__common) ext/bcmath/libbcmath/src/outofmem.lo definition of __bc_Free_list in section (__DATA,__common) ext/bcmath/libbcmath/src/raisemod.lo definition of __bc_Free_list in section (__DATA,__common) ext/bcmath/libbcmath/src/rt.lo definition of __bc_Free_list in section (__DATA,__common) ext/bcmath/libbcmath/src/sub.lo definition of __bc_Free_list in section (__DATA,__common) ext/bcmath/libbcmath/src/compare.lo definition of __bc_Free_list in section (__DATA,__common) ext/bcmath/libbcmath/src/divmod.lo definition of __bc_Free_list in section (__DATA,__common) ext/bcmath/libbcmath/src/int2num.lo definition of __bc_Free_list in section (__DATA,__common) ext/bcmath/libbcmath/src/num2long.lo definition of __bc_Free_list in section (__DATA,__common) ext/bcmath/libbcmath/src/output.lo definition of __bc_Free_list in section (__DATA,__common) ext/bcmath/libbcmath/src/recmul.lo definition of __bc_Free_list in section (__DATA,__common) ext/bcmath/libbcmath/src/sqrt.lo definition of __bc_Free_list in section (__DATA,__common) ext/bcmath/libbcmath/src/zero.lo definition of __bc_Free_list in section (__DATA,__common) ext/bcmath/libbcmath/src/debug.lo definition of __bc_Free_list in section (__DATA,__common) ext/bcmath/libbcmath/src/doaddsub.lo definition of __bc_Free_list in section (__DATA,__common) ext/bcmath/libbcmath/src/nearzero.lo definition of __bc_Free_list in section (__DATA,__common) ext/bcmath/libbcmath/src/num2str.lo definition of __bc_Free_list in section (__DATA,__common) ext/bcmath/libbcmath/src/raise.lo definition of __bc_Free_list in section (__DATA,__common) ext/bcmath/libbcmath/src/rmzero.lo definition of __bc_Free_list in section (__DATA,__common) ext/bcmath/libbcmath/src/str2num.lo definition of __bc_Free_list in section (__DATA,__common) make: *** [libphp4.la] Error 1 This is also the case with 4.1.2 stable. -- Edit bug report at http://bugs.php.net/?id=16011&edit=1 -- Fixed in CVS:http://bugs.php.net/fix.php?id=16011&r=fixedcvs Fixed in release:http://bugs.php.net/fix.php?id=16011&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=16011&r=needtrace Try newer version: http://bugs.php.net/fix.php?id=16011&r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=16011&r=support Expected behavior: http://bugs.php.net/fix.php?id=16011&r=notwrong Not enough info: http://bugs.php.net/fix.php?id=16011&r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=16011&r=submittedtwice
Bug #16010: phpinfo manual page bad grammar
From: [EMAIL PROTECTED] Operating system: n/a PHP version: 4.1.2 PHP Bug Type: Documentation problem Bug description: phpinfo manual page bad grammar on http://www.php.net/manual/en/function.phpinfo.php, in the "phpinfo() options" table: Loaded modules and there respective settings. should be: Loaded modules and their respective settings. (is this the right place to report this sort of error?) S -- Edit bug report at http://bugs.php.net/?id=16010&edit=1 -- Fixed in CVS:http://bugs.php.net/fix.php?id=16010&r=fixedcvs Fixed in release:http://bugs.php.net/fix.php?id=16010&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=16010&r=needtrace Try newer version: http://bugs.php.net/fix.php?id=16010&r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=16010&r=support Expected behavior: http://bugs.php.net/fix.php?id=16010&r=notwrong Not enough info: http://bugs.php.net/fix.php?id=16010&r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=16010&r=submittedtwice
Bug #15595 Updated: imap routines hang when "To" header is too large
ID: 15595
Updated by: [EMAIL PROTECTED]
-Summary: imap routines hang when "To" header is too large
Reported By: [EMAIL PROTECTED]
-Status: Open
+Status: Feedback
Bug Type: IMAP related
Operating System: Solaris-i86
PHP Version: 4.1.1
New Comment:
Try the latest _c-client_ library, not PHP.
As this is most likely not bug in PHP but in the
c-client library itself.
--Jani
Previous Comments:
[2002-03-11 20:52:16] [EMAIL PROTECTED]
We upgraded last week to 4.1.2, the problem still occurs.
[2002-03-11 09:37:31] [EMAIL PROTECTED]
First of all you should try with the latest c-client.
--Jani
[2002-03-11 04:47:56] [EMAIL PROTECTED]
Is there anything I can do to help this along? We've been bitten twice
by this in the last few days.
[2002-02-18 18:09:33] [EMAIL PROTECTED]
An exact script is difficult. (I've spent a day or two trying to pin it
down to a simple routine, not with any great success).
However, it looks like
$h = @imap_header($imp->stream, imap_msgno($imp->stream, $msgnum));
is hanging with a message that has to header of about 4K (again, this
probably violates rfc822, but it shouldn't hang like it does).
$imp->stream is constructed like this (as you'd expect):
$connstr = '{' . $this->server . ':' . $this->port . '}' .
$this->mailbox;
$this->stream = @imap_open($connstr, $this->user, $this->pass);
Thanks.
[2002-02-18 08:29:31] [EMAIL PROTECTED]
Can you provide a simple sample script?
The remainder of the comments for this report are too long. To view
the rest of the comments, please view the bug report online at
http://bugs.php.net/15595
--
Edit this bug report at http://bugs.php.net/?id=15595&edit=1
Bug #14734 Updated: new superglobals ($_SERVER, etc.) not documented
ID: 14734 Updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] -Status: Open +Status: Closed Bug Type: Documentation problem Operating System: Win XP PHP Version: 4.1.0 New Comment: This has been fixed in CVS. FWIW, I think that if $PHP_SELF is to be documented outside of the $_SERVER list, it should be worded carefully to prevent users wondering why $PHP_SELF isn't available in the global scope. Torben Previous Comments: [2002-03-11 20:56:51] [EMAIL PROTECTED] This has been fixed in CVS. FWIW, I think that if $PHP_SELF is to be documented outside of the $_SERVER list, it should be worded carefully to prevent users wondering why $PHP_SELF isn't available in the global scope. Torben [2002-01-04 01:16:40] [EMAIL PROTECTED] but $PHP_SELF is also a special variable, so I think also listing it out of any collection is a good thing. [2001-12-28 11:35:45] [EMAIL PROTECTED] Tested again. Yes you are right. It would be good to have it listed only in _SERVER, as the other vars. [2001-12-28 10:29:47] [EMAIL PROTECTED] It's printed in _SERVER too (apache 1.3.22/php 4.1.0). [2001-12-28 10:17:17] [EMAIL PROTECTED] Just a note: in the PHP 4.1.0 phpinfo() output, all the predefined vars are printed as _SERVER and _ENV members, except PHP_SELF, it is printed alone, and not in any array. This must be corrected! 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/14734 -- Edit this bug report at http://bugs.php.net/?id=14734&edit=1
Bug #14734 Updated: new superglobals ($_SERVER, etc.) not documented
ID: 14734 Updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] Status: Open Bug Type: Documentation problem Operating System: Win XP PHP Version: 4.1.0 New Comment: This has been fixed in CVS. FWIW, I think that if $PHP_SELF is to be documented outside of the $_SERVER list, it should be worded carefully to prevent users wondering why $PHP_SELF isn't available in the global scope. Torben Previous Comments: [2002-01-04 01:16:40] [EMAIL PROTECTED] but $PHP_SELF is also a special variable, so I think also listing it out of any collection is a good thing. [2001-12-28 11:35:45] [EMAIL PROTECTED] Tested again. Yes you are right. It would be good to have it listed only in _SERVER, as the other vars. [2001-12-28 10:29:47] [EMAIL PROTECTED] It's printed in _SERVER too (apache 1.3.22/php 4.1.0). [2001-12-28 10:17:17] [EMAIL PROTECTED] Just a note: in the PHP 4.1.0 phpinfo() output, all the predefined vars are printed as _SERVER and _ENV members, except PHP_SELF, it is printed alone, and not in any array. This must be corrected! [2001-12-28 10:05:28] [EMAIL PROTECTED] Valid point. I'm reopening this as a documentation problem. 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/14734 -- Edit this bug report at http://bugs.php.net/?id=14734&edit=1
Bug #15595 Updated: imap routines hang when "To" header is too large
ID: 15595
Updated by: [EMAIL PROTECTED]
-Summary: imap routines hang when "To" header is too large
Reported By: [EMAIL PROTECTED]
-Status: Feedback
+Status: Open
Bug Type: IMAP related
Operating System: Solaris-i86
PHP Version: 4.1.1
New Comment:
We upgraded last week to 4.1.2, the problem still occurs.
Previous Comments:
[2002-03-11 09:37:31] [EMAIL PROTECTED]
First of all you should try with the latest c-client.
--Jani
[2002-03-11 04:47:56] [EMAIL PROTECTED]
Is there anything I can do to help this along? We've been bitten twice
by this in the last few days.
[2002-02-18 18:09:33] [EMAIL PROTECTED]
An exact script is difficult. (I've spent a day or two trying to pin it
down to a simple routine, not with any great success).
However, it looks like
$h = @imap_header($imp->stream, imap_msgno($imp->stream, $msgnum));
is hanging with a message that has to header of about 4K (again, this
probably violates rfc822, but it shouldn't hang like it does).
$imp->stream is constructed like this (as you'd expect):
$connstr = '{' . $this->server . ':' . $this->port . '}' .
$this->mailbox;
$this->stream = @imap_open($connstr, $this->user, $this->pass);
Thanks.
[2002-02-18 08:29:31] [EMAIL PROTECTED]
Can you provide a simple sample script?
[2002-02-18 04:23:34] [EMAIL PROTECTED]
The starting point for this was that our webmail (customised IMP)would
crash if the "To" header was too large. Probably the header violates
rfc822, but php should be able to cope, or at least fail gracefully and
not hang.
We are running php built with the imap4.5 uwash c-client, with ldap,
with mysql. Apache is built with mods rewrite, mime_magic, the lastest
fastcgi, the latest modssl. The fastcgi connection is used for most
pages rendered from our site.
Playing around with truss led us to suspect mime_header_decode was at
fault, ie:
php_if_imap_mime_header_decode+0x6d3: movl (%ebx),%edx
Now, in getting a gdb backtrace, things got very wierd. Below is the
output - but it occurs not only when we try to read the email with the
oversized to header, but when I try to do something mundane like parse
the whole mailbox.
So maybe there are two problems, needless to say - I hope the truss
line is useful, because I wouldn't rely on the gdb backtrace.
Thanks.
Program received signal SIGPIPE, Broken pipe.
0xdfee1f3b in _writev ()
(gdb) bt
#0 0xdfee1f3b in _writev ()
#1 0x80b2254 in ssl_io_unregister ()
#2 0x81ba5f4 in ap_hook_call ()
#3 0x81b9d41 in ap_hook_call ()
#4 0x8196641 in ap_bfilbuf ()
#5 0x8196a6c in ap_bfilbuf ()
#6 0x8196b38 in ap_bwrite ()
#7 0x816537e in php_mergesort ()
#8 0x8166ec5 in php_mergesort ()
#9 0x816749d in php_mergesort ()
#10 0x8197ddb in ap_invoke_handler ()
#11 0x81ac451 in ap_some_auth_required ()
#12 0x81ac4b0 in ap_process_request ()
#13 0x81a3ad1 in ap_child_terminate ()
#14 0x81a3c80 in ap_child_terminate ()
#15 0x81a3ddb in ap_child_terminate ()
#16 0x81a43d8 in ap_child_terminate ()
#17 0x81a4b9b in main ()
#18 0x809b947 in _start ()
--
Edit this bug report at http://bugs.php.net/?id=15595&edit=1
Bug #15316 Updated: Segmentation fault on Interbase blob creation
ID: 15316
Updated by: [EMAIL PROTECTED]
Reported By: [EMAIL PROTECTED]
-Status: Feedback
+Status: Open
Bug Type: InterBase related
Operating System: Linux 2.4.17-xfs
PHP Version: 4.1.1
New Comment:
Does any of this information help? I see that there are now
others reporting this bug, so perhaps it can be combined with
those.
Previous Comments:
[2002-02-21 20:46:50] [EMAIL PROTECTED]
Well, I got pretty close to getting a backtrace, but ran
across what appears to be a bug in gdb. Either that, or
I am just not finding the proper documentation.
I can get a gdb attached to the proper thread, via:
/usr/sbin/apache.dbg
gdb /usr/sbin/apache.dbg
(gdb) attach
(gdb) continue
but when
I "continue" it, it gives me a message like "Cannot find
thread 2049: invalid thread handle".
Now, I may be doing something wrong, but I sure can't
tell what.
[2002-02-21 18:59:10] [EMAIL PROTECTED]
Incidentally, I have tried every which way to get a core dump,
but even after running apache on port 1025 as a non-root
user, and checking permissions on the CoreDumpDirectory, no
core file is created.
So, I tried attaching gdb to specific processes, but for some
reason, when I attach gdb to a particular process, the process no
longer accepts
connections. Any hints?
[2002-02-21 17:55:53] [EMAIL PROTECTED]
Still unable to generate a backtrace, but running strace reveals this:
[pid 27126] recv(5,
"\0\0\0\t\377\377\377\377\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0"..., 8192, 0) =
32
[pid 27126] semop(32769, 0xbfffb5f8, 2) = 0
[pid 27126] semop(32769, 0xbfffb5fc, 1) = 0
[pid 27126] send(5, "\0\0\0C\0\0\0\5\0\0\0\2", 12, 0) = 12
[pid 27126] select(6, [5], NULL, NULL, {60, 0}) = 1 (in [5], left {60,
0})
[pid 27126] recv(5,
"\0\0\0\t\377\377\377\377\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0"..., 8192, 0) =
32
[pid 27126] semop(32769, 0xbfffb5f8, 2) = 0
[pid 27126] semop(32769, 0xbfffb5fc, 1) = 0
[pid 27126] open("/www/heritage.legacyunlimited.com/pages/footer.php",
O_RDONLY|O_LARGEFILE) = 8
[pid 27126] getcwd("/www/heritage.legacyunlimited.com/pages/customize",
4095) = 50
[pid 27126] lstat64("/www", {st_mode=S_IFDIR|0775, st_size=4096, ...})
= 0
[pid 27126] lstat64("/www/heritage.legacyunlimited.com",
{st_mode=S_IFDIR|0775, st_size=156, ...}) = 0
[pid 27126] lstat64("/www/heritage.legacyunlimited.com/pages",
{st_mode=S_IFDIR|0775, st_size=4096, ...}) = 0
[pid 27126]
lstat64("/www/heritage.legacyunlimited.com/pages/footer.php",
{st_mode=S_IFREG|0664,
st_size=4322, ...}) = 0
[pid 27126] ioctl(8, SNDCTL_TMR_TIMEBASE, 0xbfffb67c) = -1 EINVAL
(Invalid argument)
[pid 27126] fstat64(8, {st_mode=S_IFREG|0664, st_size=4322, ...}) = 0
[pid 27126] old_mmap(NULL, 4096, PROT_READ|PROT_WRITE,
MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x40277000
[pid 27126] read(8, "\0\0\0\310\7\0\0[\0"..., 1024) =
1024
[pid 27126] lseek(6, 16, SEEK_SET) = 16
[pid 27126] read(6, "\0\0\0\0\0\0\0\0\1\0\0\0<\0\0\0arithmetic
excep"..., 1024)
= 1024
[pid 27126] --- SIGSEGV (Segmentation fault) ---
[pid 27125] <... select resumed> ) = ? ERESTARTNOHAND (To be
restarted)
[pid 27125] --- SIGCHLD (Child exited) ---
[2002-02-13 12:04:14] [EMAIL PROTECTED]
Having trouble getting apache to listen to a port when
run under gdb. Will keep trying.
Can't seem to get a core file any other way.
[2002-02-01 04:15:20] [EMAIL PROTECTED]
Can you provide a backtrace? (see
http://bugs.php.net/bugs-generating-backtrace.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/15316
--
Edit this bug report at http://bugs.php.net/?id=15316&edit=1
Bug #14998 Updated: Can't name a class 'Directory'
ID: 14998 Updated by: [EMAIL PROTECTED] -Summary: Can't name a class 'Directory' Reported By: [EMAIL PROTECTED] -Status: Open +Status: Closed Bug Type: Documentation problem Operating System: Red Hat Linux 7.0 PHP Version: 4.0.5 New Comment: This bug has been fixed in CVS. Previous Comments: [2002-03-04 11:47:28] [EMAIL PROTECTED] This one just bit me for 20 minutes as well. A documentation change would be quite helpful (Also, I think this is something that would generally be happier in PEAR or similar, but that's a diffrent problem :). [2002-01-11 13:54:29] [EMAIL PROTECTED] See http://www.php.net/manual/en/function.get-declared-classes.php. It is predefined. Should be pointed out more clearly, -> documentation problem. [2002-01-11 12:17:37] [EMAIL PROTECTED] For example, given the code: PHP gives the error: "Cannot redeclare class directory". Maybe the the dir() function/class interferes?? Configuration: './configure' '--prefix=/usr' '--with-apxs=/usr/sbin/apxs' '--with-exec-dir=/usr/bin' '--with-config-file-path=/etc/httpd' '--with-regex=system' '--enable-debugger' '--enable-magic-quotes' '--enable-sysvshm' '--with-dom' '--enable-force-cgi-redirect' '--enable-sigchild' '--with-wddx' '--enable-inline-optimization' '--with-gnu-ld' '--enable-bcmath' '--enable-crypt' '--with-xml' '--with-sablot' '--enable-dbg=shared' '--with-dbg-profiler' Thanks. -- Edit this bug report at http://bugs.php.net/?id=14998&edit=1
Bug #15943 Updated: Viewing .phps Crashes with php.ini-recommended
ID: 15943 Updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] Status: Analyzed Bug Type: Unknown/Other Function Operating System: FreeBSD PHP Version: 4.1.2 New Comment: I've found which php.ini directive is the culprit here. output_buffering = 4096 If this is set to Off, there are no problems. Just some added info. Maybe someone could elaborate on why this happens, and if there is a work around? Thanks, Hans Previous Comments: [2002-03-07 21:40:48] [EMAIL PROTECTED] I could some more details? For one, why it should be removed, and two what in the php.ini file breaks the .phps functionality? Using .phps is very useful.. I would think only having show_source() would be clunky, as you'd need another script to just display others. [2002-03-07 21:36:31] [EMAIL PROTECTED] This is known issue but I don't know if this is reported. I think phps feature should be removed. (Thoes who know issues understand why :) Use show_source() instead. [2002-03-07 21:00:26] [EMAIL PROTECTED] I've installed 4.1.2 and everything works fine with the latest Apache release on the latest FreeBSD release. However, when I try to view a .phps page, the connection to the browser closes abruptly. I was using the supplied php.ini-recommended, and after playing around for a while, saw that using php.ini-dist cleared the problem up. I've looked at both php.ini's supplied with the source, but can't see any difference that would effect this. How can using php.ini-recommended (doesn't work) versus php.ini-dist (works) make a difference, and how can this be straightened out? Thank you, Hans -- Edit this bug report at http://bugs.php.net/?id=15943&edit=1
Bug #15913 Updated: imagettftext will not work
ID: 15913 Updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] Status: Open Bug Type: GD related Operating System: Windows2000 PHP Version: 4.1.1 New Comment: I get strange errors like the following: PHP Warning: ¸/ª in c:\myfiles\websites\skin\functions.php on line 88 PHP Warning: /ª in c:\myfiles\websites\skin\functions.php on line 79 PHP Warning: h/ª in c:\myfiles\websites\skin\functions.php on line 79 when trying to call: ImageTTFText ($im, 13, 0, 12, 14, $nav_text_off, $navFontPath, $navText); where $navFontPath is: $navFontPath = "/skin/fonts/".$navFont.".ttf"; Where /skin is in my webroot. Please help!!! I am running Apache on Win2000 with PHP 4.1.1 and php_gd2.dll Previous Comments: [2002-03-06 15:30:08] [EMAIL PROTECTED] imagettftext does not work when using php_gd2.dll with PHP 4.1.1. The function works fine when using gd_dll with PHP4.1.1. -- Edit this bug report at http://bugs.php.net/?id=15913&edit=1
Bug #16009: Apache/SAPI Compile Error
From: [EMAIL PROTECTED]
Operating system: Redhat Linux 6.2
PHP version: 4.1.2
PHP Bug Type: Compile Failure
Bug description: Apache/SAPI Compile Error
Log below.
It appears PHP 4.1.2 doesn't like apache 1.3.23...?
Configure command (dir variables are defined in a shell
include I use for convenience):
./configure \
--prefix=${PHP_MOD_PREFIX_DIR} \
--with-config-file-path=${APACHE_PREFIX_DIR}/conf \
--with-apache=../${APACHE_DIR} \
--enable-ftp \
--with-zlib \
--enable-bcmath \
--enable-calendar \
--with-jpeg-dir=/usr/lib \
--with-imlib=/usr/local/lib/ \
--with-iconv=/usr/local/lib \
--with-tiff-dir=/usr/lib \
--with-oci8=${ORACLE_DIR} \
--with-sapdb=/opt/sapdb/interfaces/odbc \
--with-mhash=${MHASH_PREFIX_DIR} \
--with-mcrypt=${MCRYPT_PREFIX_DIR} \
--with-dom=${LIBXML2_PREFIX_DIR} \
--enable-xslt --with-xslt-sablot=${SAB_PREFIX_DIR}
\
--with-curl=${CURL_PREFIX_DIR} \
--with-expat-dir=${EXPAT_PREFIX_DIR} \
--enable-wddx \
--enable-memory-limit \
--with-mm=${MM_PREFIX_DIR} \
--enable-debug=no
---
Log:
make[2]: Entering directory
`/root/bc_install/packages/php-4.1.2.mod/sapi/apache'
make[3]: Entering directory
`/root/bc_install/packages/php-4.1.2.mod/sapi/apache'
gcc -I.
-I/root/bc_install/packages/php-4.1.2.mod/sapi/apache
-I/root/bc_install/packages/php-4.1.2.mod/main
-I/root/bc_install/packages/php-4.1.2.mod
-I/root/bc_install/packages/apache_1.3.23/src/include
-I/root/bc_install/packages/apache_1.3.23/src/os/unix
-I/root/bc_install/packages/php-4.1.2.mod/Zend
-I/usr/local/curl/include
-I/usr/local/libxml2/include/libxml2 -I/usr/local/include
-I/usr/local/mcrypt/include -I/usr/local/mhash/include
-I/root/bc_install/packages/php-4.1.2.mod/ext/mysql/libmysq
l -I/u01/oracle/product/8.1.6/rdbms/public
-I/u01/oracle/product/8.1.6/rdbms/demo
-I/u01/oracle/product/8.1.6/network/public
-I/opt/sapdb/interfaces/odbc/incl -I/usr/local/mm/include
-I/usr/local/expat/include -I/usr/local/Sablot/include
-I/root/bc_install/packages/apache_1.3.23/src/include
-I/root/bc_install/packages/apache_1.3.23/src/os/unix
-I/root/bc_install/packages/php-4.1.2.mod/TSRM -g -O2 -c
sapi_apache.c && touch sapi_apache.lo
In file included from
/root/bc_install/packages/apache_1.3.23/src/include/ap_conf
ig.h:77,
from
/root/bc_install/packages/apache_1.3.23/src/include/httpd.h
:72,
from sapi_apache.c:32:
/root/bc_install/packages/apache_1.3.23/src/include/ap_conf
ig_auto.h:6: unterminated `#if' conditional
In file included from
/root/bc_install/packages/apache_1.3.23/src/include/httpd.h
:72,
from sapi_apache.c:32:
/root/bc_install/packages/apache_1.3.23/src/include/ap_conf
ig.h:1386: warning: `XtOffsetOf' redefined
/root/bc_install/packages/php-4.1.2.mod/main/php.h:342:
warning: this is the location of the previous definition
make[3]: *** [sapi_apache.lo] Error 1
make[3]: Leaving directory
`/root/bc_install/packages/php-4.1.2.mod/sapi/apache'
make[2]: *** [all-recursive] Error 1
make[2]: Leaving directory
`/root/bc_install/packages/php-4.1.2.mod/sapi/apache'
make[1]: *** [all-recursive] Error 1
make[1]: Leaving directory
`/root/bc_install/packages/php-4.1.2.mod/sapi'
make: *** [all-recursive] Error 1
--
Edit bug report at http://bugs.php.net/?id=16009&edit=1
--
Fixed in CVS:http://bugs.php.net/fix.php?id=16009&r=fixedcvs
Fixed in release:http://bugs.php.net/fix.php?id=16009&r=alreadyfixed
Need backtrace: http://bugs.php.net/fix.php?id=16009&r=needtrace
Try newer version: http://bugs.php.net/fix.php?id=16009&r=oldversion
Not developer issue: http://bugs.php.net/fix.php?id=16009&r=support
Expected behavior: http://bugs.php.net/fix.php?id=16009&r=notwrong
Not enough info: http://bugs.php.net/fix.php?id=16009&r=notenoughinfo
Submitted twice: http://bugs.php.net/fix.php?id=16009&r=submittedtwice
Bug #16008 Updated: #include syntax error in ext/imap/php_imap.h
ID: 16008
Updated by: [EMAIL PROTECTED]
Reported By: [EMAIL PROTECTED]
-Status: Open
+Status: Closed
Bug Type: Compile Failure
Operating System: Tru64 Unix 4.0g
PHP Version: 4.1.2
New Comment:
Fixed in CVS, thanks! It will be in 4.2.0 and higher.
Derick
Previous Comments:
[2002-03-11 18:05:49] [EMAIL PROTECTED]
When IMAP support is turned on at configure stage, the out-of-the-box
file ext/imap/php_imap.h causes compile failure on lines 42, 43, 45 and
46 when using the native cc compiler. This is because the #include
statements on those lines are not started in the first column. Support
for starting preprocessor statements to the right of column one is not
supported in non-gcc compilers, thus the error.
Here is a quick Bourne shell script that will detect and fix the
error.
#!/bin/sh
#
BADFILE="ext/imap/php_imap.h"
BADIMAP=`grep ' #' $BADFILE`;
if [ "x$BADIMAP" != "x" ]; then
echo "Fixing $BADFILE"
$DFILE="${BADFILE}.orig"
mv $BADFILE $DFILE
sed '/^ #/s/^ #/#/' < $DFILE >$BADFILE
fi
If you retype this rather than cut-and-paste, be careful to note the
spaces in the strings on the grep and sed lines. The use of shell vars
is so that this piece of script can be extended or looped to fix other
such bogons in the code.
--
Edit this bug report at http://bugs.php.net/?id=16008&edit=1
Bug #16008: #include syntax error in ext/imap/php_imap.h
From: [EMAIL PROTECTED]
Operating system: Tru64 Unix 4.0g
PHP version: 4.1.2
PHP Bug Type: Compile Failure
Bug description: #include syntax error in ext/imap/php_imap.h
When IMAP support is turned on at configure stage, the out-of-the-box file
ext/imap/php_imap.h causes compile failure on lines 42, 43, 45 and 46 when
using the native cc compiler. This is because the #include statements on
those lines are not started in the first column. Support for starting
preprocessor statements to the right of column one is not supported in
non-gcc compilers, thus the error.
Here is a quick Bourne shell script that will detect and fix the error.
#!/bin/sh
#
BADFILE="ext/imap/php_imap.h"
BADIMAP=`grep ' #' $BADFILE`;
if [ "x$BADIMAP" != "x" ]; then
echo "Fixing $BADFILE"
$DFILE="${BADFILE}.orig"
mv $BADFILE $DFILE
sed '/^ #/s/^ #/#/' < $DFILE >$BADFILE
fi
If you retype this rather than cut-and-paste, be careful to note the
spaces in the strings on the grep and sed lines. The use of shell vars is
so that this piece of script can be extended or looped to fix other such
bogons in the code.
--
Edit bug report at http://bugs.php.net/?id=16008&edit=1
--
Fixed in CVS:http://bugs.php.net/fix.php?id=16008&r=fixedcvs
Fixed in release:http://bugs.php.net/fix.php?id=16008&r=alreadyfixed
Need backtrace: http://bugs.php.net/fix.php?id=16008&r=needtrace
Try newer version: http://bugs.php.net/fix.php?id=16008&r=oldversion
Not developer issue: http://bugs.php.net/fix.php?id=16008&r=support
Expected behavior: http://bugs.php.net/fix.php?id=16008&r=notwrong
Not enough info: http://bugs.php.net/fix.php?id=16008&r=notenoughinfo
Submitted twice: http://bugs.php.net/fix.php?id=16008&r=submittedtwice
Bug #16007 Updated: Want quick shortcut for
ID: 16007
Updated by: [EMAIL PROTECTED]
Reported By: [EMAIL PROTECTED]
-Status: Open
+Status: Closed
Bug Type: Feature/Change Request
Operating System: n/a
PHP Version: 4.1.2
New Comment:
Easily done, write your own function 'h($a) { return
htmlspecialchars($a);}', your call could then look like ''
Previous Comments:
[2002-03-11 17:55:41] [EMAIL PROTECTED]
Often, I'm left writing things like:
It'd be nice if PHP let you write this instead:
with the echo and htmlspecialchars implied. Or at least the echo
implied.
--
Edit this bug report at http://bugs.php.net/?id=16007&edit=1
Bug #16007: Want quick shortcut for
From: [EMAIL PROTECTED] Operating system: n/a PHP version: 4.1.2 PHP Bug Type: Feature/Change Request Bug description: Want quick shortcut for Often, I'm left writing things like: It'd be nice if PHP let you write this instead: with the echo and htmlspecialchars implied. Or at least the echo implied. -- Edit bug report at http://bugs.php.net/?id=16007&edit=1 -- Fixed in CVS:http://bugs.php.net/fix.php?id=16007&r=fixedcvs Fixed in release:http://bugs.php.net/fix.php?id=16007&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=16007&r=needtrace Try newer version: http://bugs.php.net/fix.php?id=16007&r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=16007&r=support Expected behavior: http://bugs.php.net/fix.php?id=16007&r=notwrong Not enough info: http://bugs.php.net/fix.php?id=16007&r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=16007&r=submittedtwice
Bug #13383 Updated: The specified CGI application misbehaved by not returning a complete set of HTT
ID: 13383 Updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] Status: Open Bug Type: InterBase related Operating System: Windows 2000 with IIS 5.0 PHP Version: 4.0.6 New Comment: I got the same error just with a fresh installation of PHP 4.1.1 on Windows 2000 Professional, and IIS 5.0; I can actually reproduce the error; also, I don't think is InterBase related, or for that matter, any application specific related issue. Problem --- Just trying to run a simple test; such as PHP Test "; ?> will cause the error message "CGI Error The specified CGI application misbehaved by not returning a complete set of HTTP headers. The headers it did return are:" to be displayed; the actual source code of this page is Error in CGI Application CGI ErrorThe specified CGI application misbehaved by not returning a complete set of HTTP headers. The headers it did return are: Note the double tags. The parsed output for the above example from php is PHP Test Hello World Solution The problem goes away by checking the 'Check that files exist' option in the Application Extension Mapping for PHP file extensions, such as '.php'. Previous Comments: [2001-09-21 20:27:44] [EMAIL PROTECTED] " ; /*$blobid = ibase_blob_create() ; ibase_blob_add($blobid, $data) ; $blob_id_save = ibase_blob_close($blobid) ;*/ ibase_close($dbh) ; ?> -- Edit this bug report at http://bugs.php.net/?id=13383&edit=1
Bug #15799 Updated: Another segfault on iconv
ID: 15799
Updated by: [EMAIL PROTECTED]
Reported By: [EMAIL PROTECTED]
-Status: Closed
+Status: Open
Bug Type: ICONV related
Operating System: Linux
PHP Version: 4.0CVS-2002-02-2
New Comment:
Ah, you're right, I thought all ob_* functions that return or output
the buffer pass the data through the ob_handler first.
But even if I use it the intended way, the output is not converted.
This is the new script I used:
www.yahoo.com.tw
END;
iconv_set_encoding('input_encoding', 'BIG5');
iconv_set_encoding('internal_encoding', 'UTF-8');
iconv_set_encoding('output_encoding', 'UTF-8');
ob_start('ob_iconv_handler');
echo $text;
header('Content-Type: text/plain; charset=UTF-8');
ob_end_flush();
?>
Previous Comments:
[2002-03-11 17:10:02] [EMAIL PROTECTED]
I'm closing this because I think your code is bogus. The manual clearly
says "The function ("ob_iconv_handler") will be called when
ob_end_flush() is called, or when the output buffer is flushed to the
browser at the end of the request."
So, if you call ob_get_contents() and ob_end_clean() you do not get any
conversion. If you either call ob_end_flush() or just don't call any
further ob*() functions the conversion works as expected for me.
Feel free to re-open if you think I'm wrong.
[2002-03-11 05:58:19] [EMAIL PROTECTED]
Yep, saw it. Will fix this later (this day).
[2002-03-11 05:18:13] [EMAIL PROTECTED]
I see you already committed the patch to cvs and, yes, php doesn't
segfault anymore, thanks.
But unfortunately the conversion doesn't happen at all. You can try the
same script I posted earlier to reproduce it. Method 1 converts
correctly, method 2 just send the Big5 data asis.
[2002-03-10 18:01:25] [EMAIL PROTECTED]
Fixed in CVS and 4.2.0 branch.
[2002-03-09 15:34:13] [EMAIL PROTECTED]
I've sent a patch to jan (wouldn't make sense to paste here as long
lines get broken) and I'm pretty sure it's the right fix. I bet the
current code never really worked the way it was written.
Anyway I'm for deprecating iconv_(set|get)_encoding. All it does is
changing INI settigns which can be easily read and set with
ini_get("iconv.input_encoding") or ini_set(). However I don't know what
the general consesus in in such situations. The two functions just seem
redundant to me.
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/15799
--
Edit this bug report at http://bugs.php.net/?id=15799&edit=1
Bug #15307 Updated: Segmentation fault if cURL tries to get a page and the server returns nothing.
ID: 15307 Updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] -Status: Assigned +Status: Closed Bug Type: cURL related Operating System: Linux 2.4.x PHP Version: 4.1.1 Assigned To: sterling New Comment: This is fixed in 4.1.2 (I believe) or CVS most definitely... Previous Comments: [2002-03-01 10:38:05] [EMAIL PROTECTED] Same problem here. But: same code on another machine works just fine. Only differences: working one:curl --version curl 7.9.2 (i686-pc-linux-gnu) libcurl 7.9.2 (OpenSSL 0.9.6a) not-working one: curl --version curl 7.9.3 (i686-pc-linux-gnu) libcurl 7.9.3 (OpenSSL 0.9.5) [2002-02-20 02:54:47] [EMAIL PROTECTED] I've experienced the same problem. Additionally info: it works fine with PHP 4.0.6. [2002-01-30 22:22:29] [EMAIL PROTECTED] Oops - that's wrong; the OpenSSL option is installed in libcurl, but this particular segfault happened using plain old http. [2002-01-30 22:17:12] [EMAIL PROTECTED] One more thing - I'm using https protocol for the transfer. [2002-01-30 22:14:25] [EMAIL PROTECTED] I found this behavior while building a client-server system that uses cURL to get data from the server; when my server-side script didn't return anything at all, it caused the client side Apache process to actually die with a signal 11. I have the latest libcurl and the latest PHP, and I've just tried updating Apache to see if that affects the behavior (it doesn't, but it seemed like a good excuse to get my development system up to date). The only option I'm using for cURL is CURLOPT_RETURNTRANSFER. I'm not sure if this means anything, but if I run cURL from the command line, it doesn't segfault when visiting the same totally empty URL. Thanks for PHP! It's good, fast, AND cheap -- Edit this bug report at http://bugs.php.net/?id=15307&edit=1
Bug #16003 Updated: Access Denied when loading ldap extension
ID: 16003 Updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] -Status: Open +Status: Bogus Bug Type: Reproducible crash Operating System: Win2K PHP Version: 4.1.1 New Comment: The bug system is not the appropriate forum for asking support questions. For a list of a range of more appropriate places to ask for help using PHP, please visit http://www.php.net/support.php Previous Comments: [2002-03-11 15:56:16] [EMAIL PROTECTED] Win2K server, running IIS with PHP 4.1.1 when I try to load the ldap extension, I get a message that says "Unable to load dynamic library 'd:\php\extensions/php_ldap.dll' - Access is denied." I don't think it is talking about windows file permissions, because Internet Guest, Guest and Everyone user accounts have full control on the file, and all folders containg the file. -- Edit this bug report at http://bugs.php.net/?id=16003&edit=1
Bug #10585 Updated: Php can't connect to MySQL database
ID: 10585 Updated by: [EMAIL PROTECTED] -Summary: Php can't connect to MySQL database Reported By: [EMAIL PROTECTED] -Status: Feedback +Status: Closed Bug Type: MySQL related Operating System: redhat 7 PHP Version: 4.0.5 New Comment: This is fixed. --Jani Previous Comments: [2002-03-11 15:53:02] [EMAIL PROTECTED] The security patch from redhat apparently causes this problem (possibly among other things). Editing the socket entry in the php.ini file fixes the problem. My version is 4.0.6-12. [2002-03-06 22:14:12] [EMAIL PROTECTED] And what is your PHP version? [2002-03-06 15:38:52] [EMAIL PROTECTED] Edit the mysql socket entry in the php.ini file and restart the httpd. Try this: mysql.default_socket = /var/lib/mysql/mysql.sock [2001-05-01 20:24:30] [EMAIL PROTECTED] There was a bug in the configure. Should be fixed in CVS now. --Jani [2001-05-01 14:53:20] [EMAIL PROTECTED] most likely a configuration error ask a support forum like [EMAIL PROTECTED] 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/10585 -- Edit this bug report at http://bugs.php.net/?id=10585&edit=1
Bug #15799 Updated: Another segfault on iconv
ID: 15799
Updated by: [EMAIL PROTECTED]
Reported By: [EMAIL PROTECTED]
-Status: Assigned
+Status: Closed
Bug Type: ICONV related
Operating System: Linux
PHP Version: 4.0CVS-2002-02-2
Assigned To: mfischer
New Comment:
I'm closing this because I think your code is bogus. The manual clearly
says "The function ("ob_iconv_handler") will be called when
ob_end_flush() is called, or when the output buffer is flushed to the
browser at the end of the request."
So, if you call ob_get_contents() and ob_end_clean() you do not get any
conversion. If you either call ob_end_flush() or just don't call any
further ob*() functions the conversion works as expected for me.
Feel free to re-open if you think I'm wrong.
Previous Comments:
[2002-03-11 05:58:19] [EMAIL PROTECTED]
Yep, saw it. Will fix this later (this day).
[2002-03-11 05:18:13] [EMAIL PROTECTED]
I see you already committed the patch to cvs and, yes, php doesn't
segfault anymore, thanks.
But unfortunately the conversion doesn't happen at all. You can try the
same script I posted earlier to reproduce it. Method 1 converts
correctly, method 2 just send the Big5 data asis.
[2002-03-10 18:01:25] [EMAIL PROTECTED]
Fixed in CVS and 4.2.0 branch.
[2002-03-09 15:34:13] [EMAIL PROTECTED]
I've sent a patch to jan (wouldn't make sense to paste here as long
lines get broken) and I'm pretty sure it's the right fix. I bet the
current code never really worked the way it was written.
Anyway I'm for deprecating iconv_(set|get)_encoding. All it does is
changing INI settigns which can be easily read and set with
ini_get("iconv.input_encoding") or ini_set(). However I don't know what
the general consesus in in such situations. The two functions just seem
redundant to me.
[2002-03-09 11:19:45] [EMAIL PROTECTED]
The segfaults still happen even after the recent changes in the iconv
extension and the output buffering code.
Here is a small script to reproduce it. Method 1 (commented out) works
fine, method 2 segfaults.
www.yahoo.com.tw
END;
// Method 1: Works!
/*
$src = 'BIG5';
$dst = 'UTF-8';
$rc = iconv($src, $dst, $text);
header('Content-Type: text/plain; charset=UTF-8');
echo $rc;
*/
// Method 2: Segfaults!
iconv_set_encoding('input_encoding', 'BIG5');
iconv_set_encoding('internal_encoding', 'UTF-8');
iconv_set_encoding('output_encoding', 'UTF-8');
ob_start('ob_iconv_handler');
echo $text;
$rc = ob_get_contents();
ob_end_clean();
header('Content-Type: text/plain; charset=UTF-8');
echo $rc;
?>
Since the line numbers changed since my initial report and I use a
different script (above), here's also an updated bt:
Program received signal SIGSEGV, Segmentation fault.
0x4010621a in chunk_free (ar_ptr=0x7a62e850, p=0x404ea168) at
malloc.c:3049
3049malloc.c: No such file or directory.
(gdb) bt
#0 0x4010621a in chunk_free (ar_ptr=0x7a62e850, p=0x404ea168) at
malloc.c:3049
#1 0x401061bf in free () at malloc.c:2952
#2 0x403744ec in zif_iconv_set_encoding () at iconv.c:267
#3 0x40317077 in execute () at ./zend_execute.c:959
#4 0x40328fb4 in zend_execute_scripts () at zend.c:373
#5 0x4033cea7 in php_execute_script () at main.c:1309
#6 0x40337240 in apache_php_module_main () at sapi_apache.c:100
#7 0x403381d8 in send_php (r=0x81825a0, display_source_mode=0,
filename=0x81841a8 "/usr/local/httpd/htdocs/headhorde/iconv.php")
at mod_php4.c:575
#8 0x40338263 in send_parsed_php (r=0x81825a0) at mod_php4.c:590
#9 0x8055250 in ap_invoke_handler ()
#10 0x80677bc in ap_some_auth_required ()
#11 0x8067833 in ap_process_request ()
#12 0x805fd27 in ap_child_terminate ()
#13 0x805fed5 in ap_child_terminate ()
#14 0x8060016 in ap_child_terminate ()
#15 0x8060628 in ap_child_terminate ()
#16 0x8060e95 in main ()
#17 0x400cca8e in __libc_start_main () at
../sysdeps/generic/libc-start.c:93
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/15799
--
Edit this bug report at http://bugs.php.net/?id=15799&edit=1
Bug #16006 Updated: ODBC data transfer
ID: 16006 Updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] -Status: Open +Status: Feedback Bug Type: ODBC related Operating System: RedHat 7.2 PHP Version: 4.1.2 New Comment: Marking as feedback. Previous Comments: [2002-03-11 17:04:29] [EMAIL PROTECTED] I suggest you try this with iODBC, as a comparison. www.iodbc.org Best regards, Andrew Hill OpenLink Software [2002-03-11 16:55:28] [EMAIL PROTECTED] Hello there. Is there maximum limit of data ( SQL query ) that can be send via odbc? I've been exerimenting with inserting large text into database and noticed that sent queries larger than 8190 byte are cause to error: SQL error: [unixODBC]Requested value changed., SQL state 01S02 in SQLExecDirect in /path/scriptname while sending queries larger than 8190 byte from DataManager ( unixODBC client ) works just fine. So, problem looks in PHP... Now I wonder if it's a bug or some configuration errors? ( I'm not expert ) Second problem - Recieving binary data via ODBC. Selected binary data corrupted... ( Less in size ) functions odbc_binmode() and odbc_longreadlen() did not help. while selecting the same data via builtin Postgres functions works fine. -- Edit this bug report at http://bugs.php.net/?id=16006&edit=1
Bug #16006 Updated: ODBC data transfer
ID: 16006 Updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] Status: Open Bug Type: ODBC related Operating System: RedHat 7.2 PHP Version: 4.1.2 New Comment: I suggest you try this with iODBC, as a comparison. www.iodbc.org Best regards, Andrew Hill OpenLink Software Previous Comments: [2002-03-11 16:55:28] [EMAIL PROTECTED] Hello there. Is there maximum limit of data ( SQL query ) that can be send via odbc? I've been exerimenting with inserting large text into database and noticed that sent queries larger than 8190 byte are cause to error: SQL error: [unixODBC]Requested value changed., SQL state 01S02 in SQLExecDirect in /path/scriptname while sending queries larger than 8190 byte from DataManager ( unixODBC client ) works just fine. So, problem looks in PHP... Now I wonder if it's a bug or some configuration errors? ( I'm not expert ) Second problem - Recieving binary data via ODBC. Selected binary data corrupted... ( Less in size ) functions odbc_binmode() and odbc_longreadlen() did not help. while selecting the same data via builtin Postgres functions works fine. -- Edit this bug report at http://bugs.php.net/?id=16006&edit=1
Bug #16006: ODBC data transfer
From: [EMAIL PROTECTED] Operating system: RedHat 7.2 PHP version: 4.1.2 PHP Bug Type: ODBC related Bug description: ODBC data transfer Hello there. Is there maximum limit of data ( SQL query ) that can be send via odbc? I've been exerimenting with inserting large text into database and noticed that sent queries larger than 8190 byte are cause to error: SQL error: [unixODBC]Requested value changed., SQL state 01S02 in SQLExecDirect in /path/scriptname while sending queries larger than 8190 byte from DataManager ( unixODBC client ) works just fine. So, problem looks in PHP... Now I wonder if it's a bug or some configuration errors? ( I'm not expert ) Second problem - Recieving binary data via ODBC. Selected binary data corrupted... ( Less in size ) functions odbc_binmode() and odbc_longreadlen() did not help. while selecting the same data via builtin Postgres functions works fine. -- Edit bug report at http://bugs.php.net/?id=16006&edit=1 -- Fixed in CVS:http://bugs.php.net/fix.php?id=16006&r=fixedcvs Fixed in release:http://bugs.php.net/fix.php?id=16006&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=16006&r=needtrace Try newer version: http://bugs.php.net/fix.php?id=16006&r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=16006&r=support Expected behavior: http://bugs.php.net/fix.php?id=16006&r=notwrong Not enough info: http://bugs.php.net/fix.php?id=16006&r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=16006&r=submittedtwice
Bug #16005: Conflict between OpenLDAP and Oracle
From: [EMAIL PROTECTED] Operating system: Solaris 8/Intel PHP version: 4.1.2 PHP Bug Type: LDAP related Bug description: Conflict between OpenLDAP and Oracle PHP dumps core when compiled with both LDAP and OCI8. The reason is the Oracle client libraries include an LDAP library, and PHP is calling the Oracle ldap_modify_s instead of the OpenLDAP ldap_modify_s. We are using OpenLDAP 1.2.11 and Oracle 8.1.6. Short-term workaround: use LD_PRELOAD, e.g. add: LD_PRELOAD=/usr/local/ldap/lib/libldap.so export LD_PRELOAD to your Apache start scripts. Here is the gdb backtrace: (gdb) r -X -f /usr/local/apache/conf/httpd-kefta.conf Starting program: /usr/local/apache/bin/httpd -X -f /usr/local/apache/conf/httpd -kefta.conf [New LWP 1] [New LWP 2] [New LWP 3] warning: Lowest section in /usr/lib/libintl.so.1 is .dynamic at 0074 [New LWP 4] warning: Lowest section in /usr/lib/libintl.so.1 is .dynamic at 0074 Program received signal SIGSEGV, Segmentation fault. 0xde589e0a in gsleenSBerPrintf () from /export/home/oracle/lib/libclntsh.so.8.0 (gdb) bt #0 0xde589e0a in gsleenSBerPrintf () from /export/home/oracle/lib/libclntsh.so.8.0 #1 0xde580234 in gslcmom_Modify () from /export/home/oracle/lib/libclntsh.so.8.0 #2 0xde57d8e7 in ldap_modify_s () from /export/home/oracle/lib/libclntsh.so.8.0 #3 0xdee2f440 in php_ldap_do_modify (ht=3, return_value=0x81f5d0c, this_ptr=0x0, return_value_used=0, oper=2) at ldap.c:1364 #4 0xdee2f5e1 in zif_ldap_modify (ht=3, return_value=0x81f5d0c, this_ptr=0x0, return_value_used=0) at ldap.c:1399 #5 0xdedd51b9 in execute (op_array=0x8195fc0) at ./zend_execute.c:1590 #6 0xdedd540c in execute (op_array=0x819296c) at ./zend_execute.c:1630 #7 0xdede66b0 in zend_execute_scripts (type=8, retval=0x0, file_count=3) at zend.c:814 #8 0xdedf98c1 in php_execute_script (primary_file=0x8047808) at main.c:1307 #9 0xdedf3d4a in apache_php_module_main (r=0x818a750, display_source_mode=0) at sapi_apache.c:90 #10 0xdedf4f00 in send_php (r=0x818a750, display_source_mode=0, filename=0x818c338 "/usr/local/apache/htdocs/mail/mailforward.php") at mod_php4.c:575 #11 0xdedf4f73 in send_parsed_php (r=0x818a750) at mod_php4.c:590 #12 0x8088945 in ap_invoke_handler (r=0x818a750) at http_config.c:517 #13 0x809e794 in process_request_internal (r=0x818a750) at http_request.c:1308 #14 0x809e7fe in ap_process_request (r=0x818a750) at http_request.c:1324 ---Type to continue, or q to quit---q Quit (gdb) i sym Here is the final link stage in compiling PHP. Please note -lldap is supplied before -lclntsh, and thus OpenLDAP should resolve first, but apparently this is not the case: /bin/sh /home/majid/src/php-4.1.2/libtool --silent --mode=link gcc -I. -I/home/ majid/src/php-4.1.2/ -I/home/majid/src/php-4.1.2/main -I/home/majid/src/php-4.1. 2 -I/usr/local/ldap/include -I/export/home/oracle/rdbms/demo -I/export/home/orac le/network/public -Iexpat/xmltok -Iexpat/xmlparse -Iimap-4.7c/c-client -I/usr/lo cal/apache/include -I/home/majid/src/php-4.1.2/Zend -I/usr/local/include/freetyp e -I/usr/local/include -I/usr/local/ldap/include -I/usr/local/mysql/include/mysq l -I/export/home/oracle/rdbms/public -I/export/home/oracle/rdbms/demo -I/export/ home/oracle/network/public -I/home/majid/src/php-4.1.2/ext/xml/expat -D_POSIX_P THREAD_SEMANTICS -DSOLARIS2=280 -DMOD_SSL=208106 -DEAPI -DEAPI_MM -DUSE_EXPAT -I /home/majid/src/php-4.1.2/TSRM -g -DEAPI -prefer-pic -o libphp4.la -rpath /hom e/majid/src/php-4.1.2/libs -export-symbols /home/majid/src/php-4.1.2/sapi/apache /php.sym -avoid-version -L/usr/ucblib -L/usr/local/lib/gcc-lib/i386-pc-solaris2. 8/2.95.2 -L/usr/local/lib -L/usr/local/ldap/lib -L/usr/local/mysql/lib/mysql -L/ export/home/oracle/lib -R /usr/ucblib -R /usr/local/lib/gcc-lib/i386-pc-solaris 2.8/2.95.2 -R /usr/local/lib -R /usr/local/ldap/lib -R /usr/local/mysql/lib/mysq l -R /export/home/oracle/lib stub.lo Zend/libZend.la sapi/apache/libsapi.la m ain/libmain.la regex/libregex.la ext/gd/libgd.la ext/imap/libimap.la ext/ldap/ libldap.la ext/mhash/libmhash.la ext/mysql/libmysql.la ext/oci8/liboci8.la ext/p cre/libpcre.la ext/posix/libposix.la ext/session/libsession.la ext/standard/libs tandard.la ext/xml/libxml.la TSRM/libtsrm.la -L/usr/local/ldap/lib -L/usr/local /lib -lgd -lmhash -llber -lldap -L/export/home/oracle/lib -lclient8 -lclntsh -L/ usr/local/mysql/lib/mysql -lmysqlclient -lpam -limap -ldl -lm -lthread -laio -le lf -ldl -lgen -lnsl -lsocket -lmysqlclient -lmhash -lldap -llber -lcrypt -lpam - lgd -lttf -lcrypt -lresolv -lresolv -lresolv -lm -ldl -lnsl -lsocket -lsocket -l gcc -lcrypt -lclntsh -- Edit bug report at http://bugs.php.net/?id=16005&edit=1 -- Fixed in CVS:http://bugs.php.net/fix.php?id=16005&r=fixedcvs Fixed in release:http://bugs.php.net/fix.php?id=16005&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=16005&r
Bug #16004: @imap_msgno() and @imap_header() display warnings
From: [EMAIL PROTECTED] Operating system: Linux PHP version: 4.1.2 PHP Bug Type: IMAP related Bug description: @imap_msgno() and @imap_header() display warnings When processing an email with a header of 'To: ""<>', imap_msgno() and imap_header give errors of "Unexpected characters at end of address: <> (errflg=3) in Unknown on line 0", even when I call the functions with an @ preceding the function name to surpress error output. -- Edit bug report at http://bugs.php.net/?id=16004&edit=1 -- Fixed in CVS:http://bugs.php.net/fix.php?id=16004&r=fixedcvs Fixed in release:http://bugs.php.net/fix.php?id=16004&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=16004&r=needtrace Try newer version: http://bugs.php.net/fix.php?id=16004&r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=16004&r=support Expected behavior: http://bugs.php.net/fix.php?id=16004&r=notwrong Not enough info: http://bugs.php.net/fix.php?id=16004&r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=16004&r=submittedtwice
Bug #15112 Updated: failed to compile extension modules as a dso
ID: 15112 Updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] Status: Feedback Bug Type: Compile Failure Operating System: NetBSD/Alpha-1.5.2 PHP Version: 4.1.1 New Comment: Build php using latest snapshot: php4-200203111200.tar.gz It's now building shared extensions fine. However, httpd refuses to run and exits without any error messages when attempting to run it. Previous Comments: [2002-03-09 13:20:07] [EMAIL PROTECTED] Could you please try latest CVS snapshot from http://snaps.php.net/ ? [2002-02-28 09:57:47] [EMAIL PROTECTED] Seeing the same problems with php-4.1.2 [2002-01-19 04:29:24] [EMAIL PROTECTED] # NetBSD/Alpha 1.5.2 PHP-4.1.1 # # Building the CGI export LDFLAGS="-Wl,-R/usr/lib -L/usr/lib -Wl,-R/usr/pkg/lib -L/usr/pkg/lib -Wl,-R/usr/local/lib -L/usr/local/lib -Wl,--export-dynamic -Wl,--whole-archive -Wl,-lgcc -Wl,--no-whole-archive" ./configure \ --prefix=/usr/local_install/php-4.1.1 \ --with-config-file-path=/usr/local/etc \ --with-regex=system \ --with-gettext=shared,/usr/pkg \ --with-pgsql=shared,/usr/local \ --with-mysql=shared,/usr/pkg \ --with-pcre-regex \ --with-gd=shared,/usr/local \ --with-jpeg-dir=shared,/usr/pkg \ --with-png-dir=shared,/usr/pkg \ --with-xpm-dir=shared,/usr/pkg \ --with-ttf=shared,/usr/pkg \ --with-freetype-dir=shared,/usr/pkg \ --with-zlib-dir=/usr \ --enable-gd-native-ttf \ --enable-sysvsem=shared \ --enable-sysvshm=shared \ --enable-sockets=shared \ --enable-xml=shared \ --enable-trans-sid \ --enable-discard-path \ --enable-force-cgi-redirect \ --enable-memory-limit \ --enable-track-vars \ --without-t1lib \ --disable-static \ --enable-shared Compiles fine and all that, but the modules aren't in *.so format, instead: # ls -l /usr/local_install/php-4.1.1/lib/php/20010901 total 1291 -rw-r--r-- 1 root wheel 312754 Jan 19 03:25 gd.a -rw-r--r-- 1 root wheel 42044 Jan 19 03:25 gettext.a -rw-r--r-- 1 root wheel 169096 Jan 19 03:25 mysql.a -rw-r--r-- 1 root wheel 263840 Jan 19 03:25 pcre.a -rw-r--r-- 1 root wheel 181726 Jan 19 03:25 pgsql.a -rw-r--r-- 1 root wheel 174484 Jan 19 03:25 sockets.a -rw-r--r-- 1 root wheel 49260 Jan 19 03:25 sysvsem.a -rw-r--r-- 1 root wheel 57342 Jan 19 03:25 sysvshm.a # Seems like libtool failed somewhere? -- Edit this bug report at http://bugs.php.net/?id=15112&edit=1
Bug #16003: Access Denied when loading ldap extension
From: [EMAIL PROTECTED] Operating system: Win2K PHP version: 4.1.1 PHP Bug Type: Reproducible crash Bug description: Access Denied when loading ldap extension Win2K server, running IIS with PHP 4.1.1 when I try to load the ldap extension, I get a message that says "Unable to load dynamic library 'd:\php\extensions/php_ldap.dll' - Access is denied." I don't think it is talking about windows file permissions, because Internet Guest, Guest and Everyone user accounts have full control on the file, and all folders containg the file. -- Edit bug report at http://bugs.php.net/?id=16003&edit=1 -- Fixed in CVS:http://bugs.php.net/fix.php?id=16003&r=fixedcvs Fixed in release:http://bugs.php.net/fix.php?id=16003&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=16003&r=needtrace Try newer version: http://bugs.php.net/fix.php?id=16003&r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=16003&r=support Expected behavior: http://bugs.php.net/fix.php?id=16003&r=notwrong Not enough info: http://bugs.php.net/fix.php?id=16003&r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=16003&r=submittedtwice
Bug #16002: imagecreatetruecolor not recognizing create version of GD library
From: [EMAIL PROTECTED] Operating system: Red Hat Linux PHP version: 4.1.2 PHP Bug Type: GD related Bug description: imagecreatetruecolor not recognizing create version of GD library I rent my server from a virtual host so I do not have much control over the server. This might not be a bug but a error in them compiling it but it should be reported just in case. I had a script that was working that used imagecreatetruecolor with a older version of PHP, I think it was two versions back. Anyway, my server updated to php 4.1.2 and it 2.01 of GD and after that my script would only return this error. Fatal error: imagecreatetruecolor(): requires GD 2.0 or later in /home/member/public_html/website/admin/imgfunctions.php on line 39 As I said it is a virtual server but phpinfo produced this, './configure' '--with-mysql' '--with-apache=../apache_1.3.23' '--enable-track-vars' '--with-gd=/usr/gd-2.0.1' '--with-jpeg-dir=/usr' '--with-png-dir=/usr/local/lib' '--with-zlib-dir=/usr/local/include' This might not be a bug but an error in my server compiling the latest version of PHP. Please email me at [EMAIL PROTECTED] if an error is obvious that you can see that I can't and I will contact my host and see if that is the problem and then this bug report can be closed. -- Edit bug report at http://bugs.php.net/?id=16002&edit=1 -- Fixed in CVS:http://bugs.php.net/fix.php?id=16002&r=fixedcvs Fixed in release:http://bugs.php.net/fix.php?id=16002&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=16002&r=needtrace Try newer version: http://bugs.php.net/fix.php?id=16002&r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=16002&r=support Expected behavior: http://bugs.php.net/fix.php?id=16002&r=notwrong Not enough info: http://bugs.php.net/fix.php?id=16002&r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=16002&r=submittedtwice
Bug #10585 Updated: Php can't connect to MySQL database
ID: 10585 Updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] Status: Feedback Bug Type: MySQL related Operating System: redhat 7 PHP Version: 4.0.5 New Comment: The security patch from redhat apparently causes this problem (possibly among other things). Editing the socket entry in the php.ini file fixes the problem. My version is 4.0.6-12. Previous Comments: [2002-03-06 22:14:12] [EMAIL PROTECTED] And what is your PHP version? [2002-03-06 15:38:52] [EMAIL PROTECTED] Edit the mysql socket entry in the php.ini file and restart the httpd. Try this: mysql.default_socket = /var/lib/mysql/mysql.sock [2001-05-01 20:24:30] [EMAIL PROTECTED] There was a bug in the configure. Should be fixed in CVS now. --Jani [2001-05-01 14:53:20] [EMAIL PROTECTED] most likely a configuration error ask a support forum like [EMAIL PROTECTED] [2001-05-01 14:22:05] [EMAIL PROTECTED] mysql version 3.23.33 All MySQL connections are broken error: Warning: MySQL Connection Failed: Can't connect to local MySQL server through socket '/tmp/mysql.sock' (111) in /home/httpd/html/ion/ion/connect.php on line 4 -- Edit this bug report at http://bugs.php.net/?id=10585&edit=1
Bug #14910 Updated: --with-snmp compile failure
ID: 14910 Updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] Status: Open Bug Type: Compile Failure Operating System: Red Hat Linux 7.1 PHP Version: 4.1.1 New Comment: I am using UCD-SNMP 4.2.3 on a Red Hat 7.2 base isntallation. Can't get PHP 4.1.2 (or 4.1.1) to finish compile when using the --with-apxs option. Works fine without the --with-apxs option though. Previous Comments: [2002-03-10 05:59:03] [EMAIL PROTECTED] Hi I am installing php-4.1.2 with ucd-snmp-4.2.3 on RedHatLinux 7.2 and i am getting same type of errors. it configures correctly but in make it gives same type of errors.Is there any solution for this. Please reply back to me on my mail address if possible. [2002-03-01 05:27:41] [EMAIL PROTECTED] I'm using ucd-snmp 4.2.1 and it compiles fine, at least. [2002-02-28 22:17:14] [EMAIL PROTECTED] I am getting an identical error when compiling PHP 4.1.2 with UCD-SNMP 4.2.3 on FreeBSD. When I compile PHP for CGI/command line duties (no --with-apxs... all other options the same) with UCD snmp it compiles without errors. [2002-02-20 03:35:57] [EMAIL PROTECTED] Unreproducible with Debian GNU/Linux woody and standard Debian (dev-)packages of net-snmp, gd etc. net-snmp 4.2.3 and php 4.1.1 [2002-01-30 20:10:27] [EMAIL PROTECTED] I'm just tossing in a comment to say I'm also able to reproduce this bug report with 4.1.1 on Slack 8. 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/14910 -- Edit this bug report at http://bugs.php.net/?id=14910&edit=1
Bug #15578 Updated: using FreeTDS - Re: Now Undefined symbol: dbhead
ID: 15578 Updated by: [EMAIL PROTECTED] -Summary: PHP Causes Apache segmentation when using FreeTDS Reported By: [EMAIL PROTECTED] -Status: Feedback +Status: Open Bug Type: MSSQL related -Operating System: Linux Red Hat 7.1 +Operating System: Linux Red Hat 7.2 -PHP Version: 4.1.1 +PHP Version: 4.1.2 New Comment: Okay well now I upgraded to apache 1.3.20, and php 4.1.2 and freetds 0.53, I don't even get as far as the segmentation fault anymore because after compiling PHP with: ./configure --with-apxs --with-sybase=/usr/local/freetds --with-pspell and make and make install, apache doesn't seem to be running anymore, I do /etc/rc.d/init.d/httpd restart and the following message appears: Starting httpd: Syntax error on line 260 of /etc/httpd/conf/httpd.conf: Cannot load /etc/httpd/modules/libphp4.so into server: /etc/httpd/modules/libphp4.so: undefined symbol: dbdead[FAILED] I could not find a way to solve this problem. Previous Comments: [2002-02-25 14:44:25] [EMAIL PROTECTED] Well I tried the same thing with another configuration and it seemed to be working so I think it might be an apache related problem. I will upgrade to the latest version of Apache in the next week or so so I will get a backtrace then if the problem persists. Thank you. [2002-02-15 16:05:45] [EMAIL PROTECTED] To properly diagnose this bug, 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". [2002-02-15 15:16:45] [EMAIL PROTECTED] Hi, I need to access a MS-SQL server 2000 from a linux RH7.1 box running PHP 4.1.1 compiled with the following options: ./configure --with-sybase=/usr/local/freetds --with-apxs And freetds installed from RPM (but I also tried with the source and it didn't work either... tried FreeTDS from CVS as well). and apache 1.3.19. PHP seems to be working fine and phpinfo(); seems fine... Whenever I load a PHP script that uses any mssql_* function, the page cannot load "The page cannot be displayed"... When I check apache's error log, it reports Segmentation Fault on child process. I tried with different versions of PHP and it always crashes the same way but the Perl applications using FreeTDS to connect to the same server work just fine so it probably is a problem related to PHP. Any input ? -- Edit this bug report at http://bugs.php.net/?id=15578&edit=1
Bug #16001 Updated: File-Upload's mime-type in Opera
ID: 16001
Updated by: [EMAIL PROTECTED]
Reported By: [EMAIL PROTECTED]
-Status: Open
+Status: Closed
Bug Type: Feature/Change Request
Operating System: Linux
PHP Version: 4.1.2
New Comment:
This bug has been fixed in CVS.
Previous Comments:
[2002-03-11 13:40:16] [EMAIL PROTECTED]
There seems to be a problem when getting uploaded file's mime-type. The
problem occurs only with Opera.
The file is uploaded correctly, and then I try to check the uploaded
file's mime-type.
$userfile_type gives:
image/gif; name=\"logo3.gif\"
It should be of cource only "image/gif". And the name should be
reported only in $userfile_name, not in $userfile_type.
So I'll have to write a correction to every my scripts involved with
file-uploads.
Correction I have made:
list ($userfile_type) = split(";", $userfile_type);
I have made an example page for uploading images, which is in the
address:
http://ihastus.net/phpbug/
--
Edit this bug report at http://bugs.php.net/?id=16001&edit=1
Bug #16001: File-Upload's mime-type in Opera
From: [EMAIL PROTECTED]
Operating system: Linux
PHP version: 4.1.2
PHP Bug Type: Feature/Change Request
Bug description: File-Upload's mime-type in Opera
There seems to be a problem when getting uploaded file's mime-type. The
problem occurs only with Opera.
The file is uploaded correctly, and then I try to check the uploaded
file's mime-type.
$userfile_type gives:
image/gif; name=\"logo3.gif\"
It should be of cource only "image/gif". And the name should be reported
only in $userfile_name, not in $userfile_type.
So I'll have to write a correction to every my scripts involved with
file-uploads.
Correction I have made:
list ($userfile_type) = split(";", $userfile_type);
I have made an example page for uploading images, which is in the
address:
http://ihastus.net/phpbug/
--
Edit bug report at http://bugs.php.net/?id=16001&edit=1
--
Fixed in CVS:http://bugs.php.net/fix.php?id=16001&r=fixedcvs
Fixed in release:http://bugs.php.net/fix.php?id=16001&r=alreadyfixed
Need backtrace: http://bugs.php.net/fix.php?id=16001&r=needtrace
Try newer version: http://bugs.php.net/fix.php?id=16001&r=oldversion
Not developer issue: http://bugs.php.net/fix.php?id=16001&r=support
Expected behavior: http://bugs.php.net/fix.php?id=16001&r=notwrong
Not enough info: http://bugs.php.net/fix.php?id=16001&r=notenoughinfo
Submitted twice: http://bugs.php.net/fix.php?id=16001&r=submittedtwice
Bug #15999 Updated: fread() hangs apache when file pointer obtained from a url parameter PHPSESSID
ID: 15999 Updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] -Status: Bogus +Status: Open Bug Type: Session related Operating System: Linux PHP Version: 4.1.0 New Comment: Ok..let's reopen this. I have no idea what you're doing but if you're not doing what I thought you were, it might be a bug..although that auto_prepend thing makes me wonder.. Please add some example scripts and what needs to be set in php.ini / httpd.conf to reproduce this. Previous Comments: [2002-03-11 12:38:04] [EMAIL PROTECTED] Why do you think that block.html is the same script ? Maybe my example is not very clear. But you are right, Apache behavior looks like infinite recursion. Let me explain again and more precisly : the script A (the one in the previous post) tries to open the url B ($url). Script C is auto_prepended (at fread instruction, right ?) and validate the access to the script B, with the session variable. If I don't use the PHPSESSID in the url parameter (and skip the test in the script C), the script is OK. If I use another parameter than PHPSESSID, the script A is OK. Same behavior with fgets, readfile, etc... Note that the script C is auto_prepended only in a subdirectory (containing only docs like B) by apache configuration ( php_value ) and of course scripts A and C are not on this directory. [2002-03-11 11:17:55] [EMAIL PROTECTED] You're calling the same script with that fopen() ? The behaviour is called 'infinite recursion' and yes, it will hang. Not a bug. --Jani [2002-03-11 10:48:52] [EMAIL PROTECTED] http://test/block.html?PHPSESSID=".session_id(); $fp = fopen($url, 'r'); // the file pointer semms to be valid $file = fread($fp,1048576); //hangs here ! echo $file; ?> hangs apache (1.3.x). Same with 4.0.2, 4.0.6 Linux (RH 6.2 and Debian 2.2), never on Win98. Other parameters don't have the same effect. -- Edit this bug report at http://bugs.php.net/?id=15999&edit=1
Bug #15782 Updated: Unsupported variant type: 8209 (0x2011)
ID: 15782
Updated by: [EMAIL PROTECTED]
Reported By: [EMAIL PROTECTED]
-Status: Open
+Status: Closed
Bug Type: COM related
Operating System: Windows 2000
PHP Version: 4.1.1
New Comment:
seems that your 'new' odbc driver treats the column data type as an
array of char instead of a string thus you get back an array (which
wasn't supported < 4.1.x) instead of a string.
but again, don't use ADO, use odbc_connect()
harald
Previous Comments:
[2002-02-28 08:49:36] [EMAIL PROTECTED]
I add that with the error message "Unsupported variant type: 8209
(0x2011)" the line which caused the error was "$field_value=$f->Value;"
[2002-02-28 08:43:01] [EMAIL PROTECTED]
Hi,
With PHP 4.0.6 on Windows 2000, i use this code :
$conn = new COM("ADODB.Connection");
$conn->Open("DRIVER={Microsoft Access Driver (*.mdb)};
DBQ=C:/bdd.mdb;");
$rs = $conn->Execute("SELECT Libellé FROM [TV/Substrat]");
$num_fields = $rs->Fields->Count();
while (!$rs->EOF)
{
for ($i=0; $i < $num_fields; $i++)
{
$f=$rs->Fields($i);
$field_value=$f->Value;
echo "$field_value\n";
}
$rs->MoveNext();
}
It works fine and the result is :
CARB
HSS
HSS-E
HSS-E5
HSS-E8
HSS-EE
HSS-ES
HSS-PM
But after installing the application software "IBM AS400 Client Access
Express", (but i can't proove actually, it's because of it), i've got
this message :
Unsupported variant type: 8209 (0x2011)
I think this software changed the ODBC drivers as i can see "Microsoft
Access Driver" and "Microsoft Access-Treiber" for example.
I updated PHP to 4.1.1 and the result for the previous code was :
Array
Array
Array
Array
Array
Array
Array
Array
When i print each element of an array i had something like this :
670650820660
720830830
720830830450690
720830830450690530
720830830450690560
720830830450690690
720830830450690830
720830830450800770
So, i understood it was ascii codes separated by "0". After applying
CHR() function to each element i have the right previous answer (CARB,
HSS, etc...).
Well, what's the trouble ?
Jean-François GAZET (France)
--
Edit this bug report at http://bugs.php.net/?id=15782&edit=1
Bug #15771 Updated: cannot pass value to image field by ado
ID: 15771
Updated by: [EMAIL PROTECTED]
Reported By: [EMAIL PROTECTED]
-Status: Open
+Status: Suspended
Bug Type: COM related
Operating System: windows
PHP Version: 4.0.6
New Comment:
hmm, this is a bit difficult because strings become usually translated
into unicode which is usually a good thing(tm) but unfortunatelly not
in this case.
as i'm actually rewriting the whole thing for php5/ZE2 i don't think
that i'll address this yet.
harald
ps: don't use ado, it's slw :)
Previous Comments:
[2002-02-27 21:29:09] [EMAIL PROTECTED]
Since PHP can support COM and I usually use php in windows,
I try to use database like mssql through ado.
All things work properly but the image datatype of mysql cannot be set
correctly.
I use it just like this
Open("Provider=sqloledb;Data Source=ndht;Initial
Catalog=printers;User Id=printers;Password=printers;");
$fp=fopen("5.gif","r") or die ("file opening error");
$content = fread ($fp, filesize ("5.gif"));
fclose ($fp);
echo filesize ("5.gif");
$rec=new COM("ADODB.recordset");
$rec->open("select * from sav",$dbconn);
$rec->addnew();
$rec->fields["datas"]->AppendChunk($content);
$rec->update();
$rec->close();
$rec=null;
$dbconn->close();
$dbconn=null;
?>
I think that windows use two type text for strings and binary for the
8bit chars, but in php string are both of
these.
So when trans the data to mssql,the variables be string of
window first, and the information were lost.
--
Edit this bug report at http://bugs.php.net/?id=15771&edit=1
Bug #15655 Updated: Variant type & COM objects
ID: 15655
Updated by: [EMAIL PROTECTED]
Reported By: [EMAIL PROTECTED]
-Status: Open
+Status: Closed
Bug Type: COM related
Operating System: WinNT SP6
PHP Version: 4.1.1
New Comment:
you shouldn't have to encapsulate the $recordset instance into a
VARIANT() object as this is done by the com layer implicitely. the
VARIANT() class is only necessary if you want multiple indirections
(e.g. you want to pass a pointer to the instance instead of the
instance itself). so passing $recordset to $object2 should be enough.
harald
ps: if you still have troubles please also test it with the cgi version
to check if it is apache related or a general com issue.
Previous Comments:
[2002-02-21 04:46:01] [EMAIL PROTECTED]
I have 2 COM objects and I want to pass 1 of them to another by
reference.
Apache 1.3.23
ddw("sterfind",$rs);
?>
when I declare $rs = new Variant() or $rs= new Variant(VT_DISPATCH)
then script works but object2 reports type mismatch
error_log raports: Premature end of script headers: c:/php/php.exe
--
Edit this bug report at http://bugs.php.net/?id=15655&edit=1
Bug #15635 Updated: COM Singleton
ID: 15635
Updated by: [EMAIL PROTECTED]
Reported By: [EMAIL PROTECTED]
-Status: Open
+Status: Feedback
Bug Type: COM related
Operating System: 2000
PHP Version: 4.1.1
New Comment:
does this component work in any other environment ?
'locks the browser' is a very wage fordable description of your problem
as the browser is in no relation with your com server. so can you look
into your servers error log or try to figure out some more details
somehow else.
i use lots of singleton objects here and i have no problems with them.
harald
Previous Comments:
[2002-02-19 18:23:25] [EMAIL PROTECTED]
I noticed that loading a COM object that has been declared as a
singleton locks up the browser. I created a simple COM object (header
follows), and if I add the SINGLETON macro to the com object, it will
hang on instantiation. If anybody has a solution, or a work around, I
would greatly appreciate it. It looks as though only simple apartment
level COM objects are acceptable. Thank you. Tom Lee
class ATL_NO_VTABLE CIt :
public CComObjectRootEx,
public CComCoClass,
public IDispatchImpl
{
public:
CIt()
{
}
DECLARE_REGISTRY_RESOURCEID(IDR_IT)
// Below macro will destroy the object
DECLARE_CLASSFACTORY_SINGLETON(CIt) // This it it!!!
DECLARE_PROTECT_FINAL_CONSTRUCT()
BEGIN_COM_MAP(CIt)
COM_INTERFACE_ENTRY(IIt)
COM_INTERFACE_ENTRY(IDispatch)
END_COM_MAP()
// IIt
public:
STDMETHOD(Now)();
protected:
};
--
Edit this bug report at http://bugs.php.net/?id=15635&edit=1
Bug #15999 Updated: fread() hangs apache when file pointer obtained from a url parameter PHPSESSID
ID: 15999 Updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] Status: Bogus Bug Type: Session related Operating System: Linux PHP Version: 4.1.0 New Comment: Why do you think that block.html is the same script ? Maybe my example is not very clear. But you are right, Apache behavior looks like infinite recursion. Let me explain again and more precisly : the script A (the one in the previous post) tries to open the url B ($url). Script C is auto_prepended (at fread instruction, right ?) and validate the access to the script B, with the session variable. If I don't use the PHPSESSID in the url parameter (and skip the test in the script C), the script is OK. If I use another parameter than PHPSESSID, the script A is OK. Same behavior with fgets, readfile, etc... Note that the script C is auto_prepended only in a subdirectory (containing only docs like B) by apache configuration ( php_value ) and of course scripts A and C are not on this directory. Previous Comments: [2002-03-11 11:17:55] [EMAIL PROTECTED] You're calling the same script with that fopen() ? The behaviour is called 'infinite recursion' and yes, it will hang. Not a bug. --Jani [2002-03-11 10:48:52] [EMAIL PROTECTED] http://test/block.html?PHPSESSID=".session_id(); $fp = fopen($url, 'r'); // the file pointer semms to be valid $file = fread($fp,1048576); //hangs here ! echo $file; ?> hangs apache (1.3.x). Same with 4.0.2, 4.0.6 Linux (RH 6.2 and Debian 2.2), never on Win98. Other parameters don't have the same effect. -- Edit this bug report at http://bugs.php.net/?id=15999&edit=1
Bug #16000: fpassthru and timeouts
From: [EMAIL PROTECTED]
Operating system: 2000 Server
PHP version: 4.1.2
PHP Bug Type: Output Control
Bug description: fpassthru and timeouts
There seems to be a timeout problems with using fpassthru.
Code :
header( "Content-type: application/octet-stream" );
header( "Content-Length: $c_ByteSize" );
header( "Content-Disposition: attachment; filename=\"$F\"" );
$fp = fopen("D:\\CarrierFTP_Files\\".odbc_result($result,
"FilePath").$F,"r") or die("Can't find file.");
fpassthru($fp);
When the person starts getting the file, after 5 min 2 sec it quits and
tells me it has finished.
I have increased timeouts everywhere, but it never gets the file.
Suggestions on this?
--
Edit bug report at http://bugs.php.net/?id=16000&edit=1
--
Fixed in CVS:http://bugs.php.net/fix.php?id=16000&r=fixedcvs
Fixed in release:http://bugs.php.net/fix.php?id=16000&r=alreadyfixed
Need backtrace: http://bugs.php.net/fix.php?id=16000&r=needtrace
Try newer version: http://bugs.php.net/fix.php?id=16000&r=oldversion
Not developer issue: http://bugs.php.net/fix.php?id=16000&r=support
Expected behavior: http://bugs.php.net/fix.php?id=16000&r=notwrong
Not enough info: http://bugs.php.net/fix.php?id=16000&r=notenoughinfo
Submitted twice: http://bugs.php.net/fix.php?id=16000&r=submittedtwice
Bug #15999 Updated: fread() hangs apache when file pointer obtained from a url parameter PHPSESSID
ID: 15999 Updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] -Status: Open +Status: Bogus Bug Type: Session related Operating System: Linux PHP Version: 4.1.0 New Comment: You're calling the same script with that fopen() ? The behaviour is called 'infinite recursion' and yes, it will hang. Not a bug. --Jani Previous Comments: [2002-03-11 10:48:52] [EMAIL PROTECTED] http://test/block.html?PHPSESSID=".session_id(); $fp = fopen($url, 'r'); // the file pointer semms to be valid $file = fread($fp,1048576); //hangs here ! echo $file; ?> hangs apache (1.3.x). Same with 4.0.2, 4.0.6 Linux (RH 6.2 and Debian 2.2), never on Win98. Other parameters don't have the same effect. -- Edit this bug report at http://bugs.php.net/?id=15999&edit=1
Bug #15998 Updated: Difference in mail() function in PHP 4.1.2, causes delay in sending mail.
ID: 15998 Updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] -Status: Open +Status: Bogus Bug Type: Mail related Operating System: Linux/Unix Redhat PHP Version: 4.1.2 Previous Comments: [2002-03-11 11:13:13] [EMAIL PROTECTED] The servers are responding fine. Sendmail was working fine from the command line, before AND after the PHP upgrade, but the php mail() command was taking a VERY long time until I added all the IP details to /etc/hosts. Now it works fine. [2002-03-11 11:00:05] [EMAIL PROTECTED] There were no code changes to the mail() function code between 4.1.0 and 4.1.2. And even if there was, all mail() does is open a pipe to your sendmail or equivalent mail delivery program. PHP does not try to do any domain name resolution on the addresses so this DNS delay you are experiencing can not possibly be PHP related as the DNS resolution is done by the external mail delivery program. You probably changed something else on your system. Check your /etc/resolv.conf and make sure the DNS servers listed there are responding quickly. [2002-03-11 10:36:47] [EMAIL PROTECTED] There appears to be a difference between the way mail() works between 4.1.0 and 4.1.2. This can cause scripts which worked perfectly in PHP 4.1.0 to take as much as a minute to excecute in PHP 4.1.2. I upgraded using a pkg file from pkgmaster.com for a Cobalt RAQ4 server, and I have spoken to another PHP user using Redhat 7 who has experienced the same issue. Basically PHP mail() functions were taking as long as a minute to excecute, when prior to the upgrade they took seconds. We found that while we had no problems with PHP 4.1.0, we had to add all our IP's into the /etc/hosts file to cure the problem experienced with 4.1.2. Config is: System Linux rev66.cobalt 2.2.16C28_III #1 Mon Jul 30 22:07:58 PDT 2001 i586 unknown Build Date Feb 27 2002 Configure Command './configure' '--prefix=/usr' '--with-apxs=/usr/sbin/apxs' '--with-gd' '--with-gettext=/usr' '--enable-safe-mode' '--with-config-file-path=/etc/httpd' '--with-exec-dir=/usr/bin' '--with-zlib' '--enable-magic-quotes' '--with-regex=system' '--with-ttf' '--with-db' '--with-gdbm' '--with-mbstring' '--with-mbstr-enc-trans' '--enable-track-vars' '--enable-wddx=shared' '--enable-mm=shared' '--enable-xml' '--disable-debug' '--with-libdir=/usr/lib' '--with-db3' '--with-interbase=shared' '--with-pgsql=shared' '-- Although we have solved this issue by adding the IP's to the /etc/hosts file, it may be worth documenting this somewhere for others reference, it took a great deal of hair-pulling to get it solved! -- Edit this bug report at http://bugs.php.net/?id=15998&edit=1
Bug #15998 Updated: Difference in mail() function in PHP 4.1.2, causes delay in sending mail.
ID: 15998 Updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] -Status: Bogus +Status: Open Bug Type: Mail related Operating System: Linux/Unix Redhat PHP Version: 4.1.2 New Comment: The servers are responding fine. Sendmail was working fine from the command line, before AND after the PHP upgrade, but the php mail() command was taking a VERY long time until I added all the IP details to /etc/hosts. Now it works fine. Previous Comments: [2002-03-11 11:00:05] [EMAIL PROTECTED] There were no code changes to the mail() function code between 4.1.0 and 4.1.2. And even if there was, all mail() does is open a pipe to your sendmail or equivalent mail delivery program. PHP does not try to do any domain name resolution on the addresses so this DNS delay you are experiencing can not possibly be PHP related as the DNS resolution is done by the external mail delivery program. You probably changed something else on your system. Check your /etc/resolv.conf and make sure the DNS servers listed there are responding quickly. [2002-03-11 10:36:47] [EMAIL PROTECTED] There appears to be a difference between the way mail() works between 4.1.0 and 4.1.2. This can cause scripts which worked perfectly in PHP 4.1.0 to take as much as a minute to excecute in PHP 4.1.2. I upgraded using a pkg file from pkgmaster.com for a Cobalt RAQ4 server, and I have spoken to another PHP user using Redhat 7 who has experienced the same issue. Basically PHP mail() functions were taking as long as a minute to excecute, when prior to the upgrade they took seconds. We found that while we had no problems with PHP 4.1.0, we had to add all our IP's into the /etc/hosts file to cure the problem experienced with 4.1.2. Config is: System Linux rev66.cobalt 2.2.16C28_III #1 Mon Jul 30 22:07:58 PDT 2001 i586 unknown Build Date Feb 27 2002 Configure Command './configure' '--prefix=/usr' '--with-apxs=/usr/sbin/apxs' '--with-gd' '--with-gettext=/usr' '--enable-safe-mode' '--with-config-file-path=/etc/httpd' '--with-exec-dir=/usr/bin' '--with-zlib' '--enable-magic-quotes' '--with-regex=system' '--with-ttf' '--with-db' '--with-gdbm' '--with-mbstring' '--with-mbstr-enc-trans' '--enable-track-vars' '--enable-wddx=shared' '--enable-mm=shared' '--enable-xml' '--disable-debug' '--with-libdir=/usr/lib' '--with-db3' '--with-interbase=shared' '--with-pgsql=shared' '-- Although we have solved this issue by adding the IP's to the /etc/hosts file, it may be worth documenting this somewhere for others reference, it took a great deal of hair-pulling to get it solved! -- Edit this bug report at http://bugs.php.net/?id=15998&edit=1
Bug #15998 Updated: Difference in mail() function in PHP 4.1.2, causes delay in sending mail.
ID: 15998 Updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] -Status: Open +Status: Bogus Bug Type: Mail related Operating System: Linux/Unix Redhat PHP Version: 4.1.2 New Comment: There were no code changes to the mail() function code between 4.1.0 and 4.1.2. And even if there was, all mail() does is open a pipe to your sendmail or equivalent mail delivery program. PHP does not try to do any domain name resolution on the addresses so this DNS delay you are experiencing can not possibly be PHP related as the DNS resolution is done by the external mail delivery program. You probably changed something else on your system. Check your /etc/resolv.conf and make sure the DNS servers listed there are responding quickly. Previous Comments: [2002-03-11 10:36:47] [EMAIL PROTECTED] There appears to be a difference between the way mail() works between 4.1.0 and 4.1.2. This can cause scripts which worked perfectly in PHP 4.1.0 to take as much as a minute to excecute in PHP 4.1.2. I upgraded using a pkg file from pkgmaster.com for a Cobalt RAQ4 server, and I have spoken to another PHP user using Redhat 7 who has experienced the same issue. Basically PHP mail() functions were taking as long as a minute to excecute, when prior to the upgrade they took seconds. We found that while we had no problems with PHP 4.1.0, we had to add all our IP's into the /etc/hosts file to cure the problem experienced with 4.1.2. Config is: System Linux rev66.cobalt 2.2.16C28_III #1 Mon Jul 30 22:07:58 PDT 2001 i586 unknown Build Date Feb 27 2002 Configure Command './configure' '--prefix=/usr' '--with-apxs=/usr/sbin/apxs' '--with-gd' '--with-gettext=/usr' '--enable-safe-mode' '--with-config-file-path=/etc/httpd' '--with-exec-dir=/usr/bin' '--with-zlib' '--enable-magic-quotes' '--with-regex=system' '--with-ttf' '--with-db' '--with-gdbm' '--with-mbstring' '--with-mbstr-enc-trans' '--enable-track-vars' '--enable-wddx=shared' '--enable-mm=shared' '--enable-xml' '--disable-debug' '--with-libdir=/usr/lib' '--with-db3' '--with-interbase=shared' '--with-pgsql=shared' '-- Although we have solved this issue by adding the IP's to the /etc/hosts file, it may be worth documenting this somewhere for others reference, it took a great deal of hair-pulling to get it solved! -- Edit this bug report at http://bugs.php.net/?id=15998&edit=1
Bug #15999: fread() hangs apache when file pointer obtained from a url parameter PHPSESSID
From: [EMAIL PROTECTED] Operating system: Linux PHP version: 4.1.0 PHP Bug Type: Session related Bug description: fread() hangs apache when file pointer obtained from a url parameter PHPSESSID http://test/block.html?PHPSESSID=".session_id(); $fp = fopen($url, 'r'); // the file pointer semms to be valid $file = fread($fp,1048576); //hangs here ! echo $file; ?> hangs apache (1.3.x). Same with 4.0.2, 4.0.6 Linux (RH 6.2 and Debian 2.2), never on Win98. Other parameters don't have the same effect. -- Edit bug report at http://bugs.php.net/?id=15999&edit=1 -- Fixed in CVS:http://bugs.php.net/fix.php?id=15999&r=fixedcvs Fixed in release:http://bugs.php.net/fix.php?id=15999&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=15999&r=needtrace Try newer version: http://bugs.php.net/fix.php?id=15999&r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=15999&r=support Expected behavior: http://bugs.php.net/fix.php?id=15999&r=notwrong Not enough info: http://bugs.php.net/fix.php?id=15999&r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=15999&r=submittedtwice
Bug #15998: Difference in mail() function in PHP 4.1.2, causes delay in sending mail.
From: [EMAIL PROTECTED] Operating system: Linux/Unix Redhat PHP version: 4.1.2 PHP Bug Type: Mail related Bug description: Difference in mail() function in PHP 4.1.2, causes delay in sending mail. There appears to be a difference between the way mail() works between 4.1.0 and 4.1.2. This can cause scripts which worked perfectly in PHP 4.1.0 to take as much as a minute to excecute in PHP 4.1.2. I upgraded using a pkg file from pkgmaster.com for a Cobalt RAQ4 server, and I have spoken to another PHP user using Redhat 7 who has experienced the same issue. Basically PHP mail() functions were taking as long as a minute to excecute, when prior to the upgrade they took seconds. We found that while we had no problems with PHP 4.1.0, we had to add all our IP's into the /etc/hosts file to cure the problem experienced with 4.1.2. Config is: System Linux rev66.cobalt 2.2.16C28_III #1 Mon Jul 30 22:07:58 PDT 2001 i586 unknown Build Date Feb 27 2002 Configure Command './configure' '--prefix=/usr' '--with-apxs=/usr/sbin/apxs' '--with-gd' '--with-gettext=/usr' '--enable-safe-mode' '--with-config-file-path=/etc/httpd' '--with-exec-dir=/usr/bin' '--with-zlib' '--enable-magic-quotes' '--with-regex=system' '--with-ttf' '--with-db' '--with-gdbm' '--with-mbstring' '--with-mbstr-enc-trans' '--enable-track-vars' '--enable-wddx=shared' '--enable-mm=shared' '--enable-xml' '--disable-debug' '--with-libdir=/usr/lib' '--with-db3' '--with-interbase=shared' '--with-pgsql=shared' '-- Although we have solved this issue by adding the IP's to the /etc/hosts file, it may be worth documenting this somewhere for others reference, it took a great deal of hair-pulling to get it solved! -- Edit bug report at http://bugs.php.net/?id=15998&edit=1 -- Fixed in CVS:http://bugs.php.net/fix.php?id=15998&r=fixedcvs Fixed in release:http://bugs.php.net/fix.php?id=15998&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=15998&r=needtrace Try newer version: http://bugs.php.net/fix.php?id=15998&r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=15998&r=support Expected behavior: http://bugs.php.net/fix.php?id=15998&r=notwrong Not enough info: http://bugs.php.net/fix.php?id=15998&r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=15998&r=submittedtwice
Bug #15884 Updated: session_unregister does not work when followed by header("Location: ...")
ID: 15884
Updated by: [EMAIL PROTECTED]
-Summary: session_unregister does not work when followed by
header("Location: ...")
Reported By: [EMAIL PROTECTED]
Status: Open
Bug Type: Session related
Operating System: Linux
PHP Version: 4.1.2
New Comment:
Yup looks like the two are related. The other bug was submitted an Mar
6th, I submitted mine on Mar 5th so at least the dupe is not my fault
;)
Jochen
Previous Comments:
[2002-03-08 15:08:30] [EMAIL PROTECTED]
I believe this bug is related to bug #15909
(http://bugs.php.net/bug.php?id=15909)
[2002-03-06 12:25:09] [EMAIL PROTECTED]
> You must provide short & complete script.
> It sounds like your bug to me.
Well this issue is very to reproduce so I thought providing a script
wont be necessary. Anyway the following set of scripts will expose the
bug.
Please note that including the session handler will not be necessary if
you are not running user-defined session handlers (php.ini setting)
An explanation on how to use the scripts is below
-
file: include.php
-
file: t1.php
t2
-
file: t2.php
";
?>
t3
-
file: t3.php
t2
-
Observed behaviour:
t1 registers $myvar and displays link to t2. Follow this link
t2 shows value of $myvar and displays link to t3. Follow this link
t3 unregisters $myvar and uses header("Location: ") to redirect you to
t2
t2 shows value of $myvar - it is still "hello"
The behaviour in the last step is incorrect - since $myvar was
unregistred, its value should have been deleted from the session but
obiously is not
When you comment out the line starting with "header" in t3.php and do
the first two steps above and then click the link t3 shows $myvar will
get unregistred properly. This is why the bug has the title
"session_unregister does not work when followed by header("Location:
...")"
btw: The reason for this is not the session-handler I use, php simply
does not call the "pgsql_session_write" function if session_unregister
is followed by a header("Location: ...") statement.
best regards,
Jochen
[2002-03-06 03:04:01] [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".
You must provide short & complete script.
It sounds like your bug to me.
[2002-03-05 12:32:08] [EMAIL PROTECTED]
When followed by a
header("Location: ...");
statement session_unregister does not get properly executed.
Reproduce: Take any script that has a session_unregister in it, put a
header("Location: ...") under this statement, and see if unregistered
var gets deleted from session-storage (it does not)
Now put a session_write_close() in front of the header-statement and
watch it work properly.
If you have trouble reproducing this please don't hesitate to contact
me.
My setup:
User-Defined Session-Handler: pgsql_session_handler latest version
PHP compiled with:
./configure' '--with-mysql=/usr/local/mysql' '--with-pgsql'
'--with-ldap' '--enable-trans-sid' '--with-gd'
Exact same setup worked with php4.0.6, did not work after upgrade to
4.1.2
--
Edit this bug report at http://bugs.php.net/?id=15884&edit=1
Bug #15997 Updated: creating blank cookies
ID: 15997
Updated by: [EMAIL PROTECTED]
Reported By: [EMAIL PROTECTED]
-Status: Open
+Status: Bogus
Bug Type: HTTP related
Operating System: linux rh 7.0
PHP Version: 4.1.2
New Comment:
The bug system is not the appropriate forum for asking support
questions. For a list of a range of more appropriate places to ask
for help using PHP, please visit http://www.php.net/support.php
Previous Comments:
[2002-03-11 09:52:09] [EMAIL PROTECTED]
When i try to receive value through SetCookie() it doesn`t return any
value, but create new blank cookie in client`s browser. For example:
SetCookie("mp3");
--
Edit this bug report at http://bugs.php.net/?id=15997&edit=1
Bug #10111 Updated: e modifier alters string extraction in preg_replace
ID: 10111
Updated by: [EMAIL PROTECTED]
Reported By: [EMAIL PROTECTED]
Status: Open
Bug Type: PCRE related
Operating System: Linux Debian
PHP Version: 4.0.4pl1
New Comment:
This is a nice feature, not a bug. See my user contributed note in the
manual under preg_replace. Maybe someone should document this behavior.
Previous Comments:
[2001-04-02 08:08:30] [EMAIL PROTECTED]
A short example :
$newsitem = preg_replace('/(<([a-zA-Z-]+)
([^>]*)analyze="[0-9]*"([^>]*)>)(.*?)(<\/\\2>)/mse',
"'\\1'.transformNewsitemPart('\\5').'\\6'", $newsitem);
where I transform the text between any html tag with "analyze"
attribute.
The problem is that the preg_replace function with e modifier adds
backslashes before any " in the matched text (\\5) BEFORE the function
transformNewsitemPart is interpreted.
The behaviour is new in php 4.0.4. It was not present in php 4.0.3.
--
Edit this bug report at http://bugs.php.net/?id=10111&edit=1
Bug #15997: creating blank cookies
From: [EMAIL PROTECTED]
Operating system: linux rh 7.0
PHP version: 4.1.2
PHP Bug Type: HTTP related
Bug description: creating blank cookies
When i try to receive value through SetCookie() it doesn`t return any
value, but create new blank cookie in client`s browser. For example:
SetCookie("mp3");
--
Edit bug report at http://bugs.php.net/?id=15997&edit=1
--
Fixed in CVS:http://bugs.php.net/fix.php?id=15997&r=fixedcvs
Fixed in release:http://bugs.php.net/fix.php?id=15997&r=alreadyfixed
Need backtrace: http://bugs.php.net/fix.php?id=15997&r=needtrace
Try newer version: http://bugs.php.net/fix.php?id=15997&r=oldversion
Not developer issue: http://bugs.php.net/fix.php?id=15997&r=support
Expected behavior: http://bugs.php.net/fix.php?id=15997&r=notwrong
Not enough info: http://bugs.php.net/fix.php?id=15997&r=notenoughinfo
Submitted twice: http://bugs.php.net/fix.php?id=15997&r=submittedtwice
Bug #15595 Updated: imap routines hang when "To" header is too large
ID: 15595
Updated by: [EMAIL PROTECTED]
-Summary: imap routines hang when "To" header is too large
Reported By: [EMAIL PROTECTED]
-Status: Open
+Status: Feedback
Bug Type: IMAP related
Operating System: Solaris-i86
PHP Version: 4.1.1
New Comment:
First of all you should try with the latest c-client.
--Jani
Previous Comments:
[2002-03-11 04:47:56] [EMAIL PROTECTED]
Is there anything I can do to help this along? We've been bitten twice
by this in the last few days.
[2002-02-18 18:09:33] [EMAIL PROTECTED]
An exact script is difficult. (I've spent a day or two trying to pin it
down to a simple routine, not with any great success).
However, it looks like
$h = @imap_header($imp->stream, imap_msgno($imp->stream, $msgnum));
is hanging with a message that has to header of about 4K (again, this
probably violates rfc822, but it shouldn't hang like it does).
$imp->stream is constructed like this (as you'd expect):
$connstr = '{' . $this->server . ':' . $this->port . '}' .
$this->mailbox;
$this->stream = @imap_open($connstr, $this->user, $this->pass);
Thanks.
[2002-02-18 08:29:31] [EMAIL PROTECTED]
Can you provide a simple sample script?
[2002-02-18 04:23:34] [EMAIL PROTECTED]
The starting point for this was that our webmail (customised IMP)would
crash if the "To" header was too large. Probably the header violates
rfc822, but php should be able to cope, or at least fail gracefully and
not hang.
We are running php built with the imap4.5 uwash c-client, with ldap,
with mysql. Apache is built with mods rewrite, mime_magic, the lastest
fastcgi, the latest modssl. The fastcgi connection is used for most
pages rendered from our site.
Playing around with truss led us to suspect mime_header_decode was at
fault, ie:
php_if_imap_mime_header_decode+0x6d3: movl (%ebx),%edx
Now, in getting a gdb backtrace, things got very wierd. Below is the
output - but it occurs not only when we try to read the email with the
oversized to header, but when I try to do something mundane like parse
the whole mailbox.
So maybe there are two problems, needless to say - I hope the truss
line is useful, because I wouldn't rely on the gdb backtrace.
Thanks.
Program received signal SIGPIPE, Broken pipe.
0xdfee1f3b in _writev ()
(gdb) bt
#0 0xdfee1f3b in _writev ()
#1 0x80b2254 in ssl_io_unregister ()
#2 0x81ba5f4 in ap_hook_call ()
#3 0x81b9d41 in ap_hook_call ()
#4 0x8196641 in ap_bfilbuf ()
#5 0x8196a6c in ap_bfilbuf ()
#6 0x8196b38 in ap_bwrite ()
#7 0x816537e in php_mergesort ()
#8 0x8166ec5 in php_mergesort ()
#9 0x816749d in php_mergesort ()
#10 0x8197ddb in ap_invoke_handler ()
#11 0x81ac451 in ap_some_auth_required ()
#12 0x81ac4b0 in ap_process_request ()
#13 0x81a3ad1 in ap_child_terminate ()
#14 0x81a3c80 in ap_child_terminate ()
#15 0x81a3ddb in ap_child_terminate ()
#16 0x81a43d8 in ap_child_terminate ()
#17 0x81a4b9b in main ()
#18 0x809b947 in _start ()
--
Edit this bug report at http://bugs.php.net/?id=15595&edit=1
Bug #15991 Updated: Undefined symbol "mysql_drop_db"
ID: 15991 Updated by: [EMAIL PROTECTED] -Summary: Undefined symbol "mysql_drop_db" Reported By: [EMAIL PROTECTED] Status: Feedback Bug Type: MySQL related Operating System: FreeBSD 4.5 PHP Version: 4.0CVS-2002-03-11 New Comment: Do you happen to have some old mysql version in your system? ie. you might have older libs somewhere in the libpath which are found before the new ones. --Jani Previous Comments: [2002-03-11 06:04:13] [EMAIL PROTECTED] mysql-4.0.1-alpha (libmysqlclient.so.11) ./configure --disable-cli --with-exec-dir=/usr/local/php/bin --with-mnogosearch=/usr/local/mnsh --enable-inline-optimization --with-freetype-dir=/usr/local --enable-trans-sid --enable-versioning --enable-ftp --with-xml --with-magic-quotes --enable-track-vars --enable-gd-native-ttf --with-png-dir=/usr/local --with-apxs=/usr/local/apache/bin/apxs --with-gd=/usr/local --with-jpeg-dir=/usr/local --with-gettext=/usr/local --with-bz2=/usr/local --with-zlib=/usr/local --with-mysql=/usr/local/mysql --enable-calendar --enable-safe-mode --enable-sysvsem --enable-sysvshm --with-config-file-path=/usr/local/php/ --with-exec-dir=/usr/local/php/bin --with-mod_charset --enable-bcmath [2002-03-11 05:34:37] [EMAIL PROTECTED] What is your configure line? What is your version of libmysqlclient (if you're using an other client than the built-in)? [2002-03-11 04:09:34] [EMAIL PROTECTED] Cannot load /usr/local/apache/libexec/libphp4.so into server: /usr/local/apache/ libexec/libphp4.so: Undefined symbol "mysql_drop_db" ./apachectl start: httpd could not be started -- Edit this bug report at http://bugs.php.net/?id=15991&edit=1
Bug #15992 Updated: Segmentation fault (11)
ID: 15992 Updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] -Status: Feedback +Status: Open Bug Type: InterBase related Operating System: RH 7.2 PHP Version: 4.1.2 New Comment: Apache does not have en --enable-debug option but I compiled it with -g option in gcc and it still did not work. I only get 2 lines of backtrace info :( Previous Comments: [2002-03-11 08:13:46] [EMAIL PROTECTED] Try compiling Apache with --enable-debug too. [2002-03-11 06:51:55] [EMAIL PROTECTED] As before i did: ./configure --without-mysql --with-imap --with-imap-ssl --with-interbase --with-pgsql --with-kerberos --with-gettext --with-xml --with-apache=../apache_1.3.23/ --enable-track-vars --enable-debug > .log Backtrace only outputs the same 2 lines after httpd crashes [2002-03-11 06:33:13] [EMAIL PROTECTED] Recompile php and the module (if not static already) with the configure line '--enable-debug'. [2002-03-11 06:25:10] [EMAIL PROTECTED] No symbol table info available. What else can I do to help? [2002-03-11 06:07:56] [EMAIL PROTECTED] Can you provide more context of the backtrace (e.g. a few more lines from 'bt full') ? 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/15992 -- Edit this bug report at http://bugs.php.net/?id=15992&edit=1
Bug #15996: ereg doesn't match on Alpha but does on i586
From: [EMAIL PROTECTED]
Operating system: Linux
PHP version: 4.1.2
PHP Bug Type: *Regular Expressions
Bug description: ereg doesn't match on Alpha but does on i586
I was trying a set of scripts on my alpha intead of the i586 I used before
(same php version same configure options). I had some problems and
found it had something to do with weird behaviour of ereg. It doesn't
match
in some cases where it should (and does on i586), the matches array is
left empty.
Some examples:
$p="blah link website bluh";
ereg("(.*)bla(.*)lin(.*)uh",$p,$regs1); //OK
isset($regs1) and print(implode("",$regs1));
ereg("(.*)bla(.*)lin(.*)web(.*)uh",$p,$regs2); //NOT OK
isset($regs2) and print(implode("",$regs2));
ereg("bla(.*)lin(.*)web(.*)uh",$p,$regs3); //NOT OK
isset($regs3) and print(implode("",$regs3));
ereg("bla(.*)lin(.*)uh",$p,$regs4); //OK
isset($regs4) and print(implode("",$regs4));
So only examples 1 and 4 have output. I can't find a real patern in it..
I hope you can
Tim
XXX
Compile options (I got from debian):
'../configure' '--prefix=/usr' '--with-apxs=/usr/bin/apxs'
'--with-regex=system' '--with-config-file-path=/etc/php4/apache'
'--disable-rpath' '--disable-debug' '--enable-memory-limit'
'--enable-calendar' '--enable-sysvsem' '--enable-sysvshm'
'--enable-track-vars' '--enable-trans-sid' '--enable-bcmath' '--with-bz2'
'--enable-ctype' '--with-db2' '--with-iconv' '--with-ndbm'
'--enable-exif' '--enable-filepro' '--enable-ftp' '--with-gettext'
'--enable-mbstring' '--with-pcre-regex=/usr' '--enable-shmop'
'--enable-sockets' '--enable-wddx' '--with-xml=/usr'
'--with-expat-dir=/usr' '--enable-yp' '--with-zlib' '--without-pgsql'
'--disable-static' '--with-layout=GNU' '--with-curl=shared,/usr'
'--with-dom=shared,/usr' '--with-zlib-dir=/usr'
'--with-gd=shared,/usr' '--with-jpeg-dir=shared,/usr'
'--with-xpm-dir=shared,/usr/X11R6' '--with-png-dir=shared,/usr'
'--with-freetype-dir=shared,/usr' '--with-imap=shared,/usr'
'--with-ldap=shared,/usr' '--with-mcal=shared,/usr'
'--with-mhash=shared,/usr' '--with-mm' '--with-mysql=shared,/usr'
'--with-recode=shared,/usr' '--enable-xslt'
'--with-xslt-sablot=shared,/usr' '--with-snmp=shared'
'--enable-ucd-snmp-hack' '--with-sybase-ct=shared,/usr'
'--with-ttf=shared,/usr' '--with-t1lib=shared,/usr'
--
Edit bug report at http://bugs.php.net/?id=15996&edit=1
--
Fixed in CVS:http://bugs.php.net/fix.php?id=15996&r=fixedcvs
Fixed in release:http://bugs.php.net/fix.php?id=15996&r=alreadyfixed
Need backtrace: http://bugs.php.net/fix.php?id=15996&r=needtrace
Try newer version: http://bugs.php.net/fix.php?id=15996&r=oldversion
Not developer issue: http://bugs.php.net/fix.php?id=15996&r=support
Expected behavior: http://bugs.php.net/fix.php?id=15996&r=notwrong
Not enough info: http://bugs.php.net/fix.php?id=15996&r=notenoughinfo
Submitted twice: http://bugs.php.net/fix.php?id=15996&r=submittedtwice
Bug #14906 Updated: The function mysql_select_db set the db for other link ids than specified.
ID: 14906
Updated by: [EMAIL PROTECTED]
Reported By: [EMAIL PROTECTED]
-Status: Open
+Status: Closed
Bug Type: MySQL related
Operating System: RedHat 7.1
PHP Version: 4.1.0
New Comment:
This is a known limitation and a workaround exists in current CVS and
upcomming 4.2.0 version which has a new, additional/optional parameter
to mysql_connect() [NOT! pconnect!] which forces the creation of a
truly new link and not re-use an existing one.
Previous Comments:
[2002-03-11 07:24:13] [EMAIL PROTECTED]
On my Slackware 3.6 box (not that it matters, since everything has been
built from source [php 4.0.6, 4.1.1 and 4.1.2, mysql 3.22.30]), I get
essentially the same results. I don't remember if the resource IDs
were the same, but I rewrote a few of my database libraries because of
this.
Basically, I had to write my database wrappers to never select a
database and always user mysql_db_query() because if someone using the
library connected with the same host/user/pass and selected a database,
the most current one would be used by both/all connections.
Please don't take mysql_db_query() away until this is sorted out. (and
maybe not even then) :)
[2002-01-07 07:27:54] [EMAIL PROTECTED]
PHP 4.1.0 and MySQL 3.23.41-log
The function mysql_select_db set the db for other link
identifiers than specified.
Doc:
bool mysql_select_db (string database_name, resource
[link_identifier])
mysql_select_db() sets the current active database on the server that's
associated with the specified link identifier. If no link identifier is
specified, the last opened link is assumed. If no link is open, the
function will try to establish a link as if mysql_connect() was called
without arguments, and use it.
The table my_table is in db1 but the active database
seems to be test on link #8.
Here the result:
mysql_pconnect() id1=Resource id #8
mysql_select_db(db1,Resource id #8)
mysql_pconnect() id2=Resource id #9
mysql_select_db(test,Resource id #9)
mysql_query(select * from my_table,Resource id #8)
failed: Table 'test.my_table' doesn't exist
Here the source:
$id1=mysql_pconnect($host,$user,$pass);
if($id1==false){
die("mysql_pconnect() failed: ".mysql_error());
}
echo "mysql_pconnect() id1=$id1";
$b=mysql_select_db($db1,$id1);
if($b==false){
die("mysql_select_db($db1,$id1)
failed:".mysql_error());
}
echo "mysql_select_db($db1,$id1)";
$id2=mysql_pconnect($host,$user,$pass);
if($id2==false){
echo "mysql_pconnect() failed: ".mysql_error();
}
echo "mysql_pconnect() id2=$id2";
$b=mysql_select_db($db2,$id2);
if($b==false){
die("mysql_select_db($db2,$id2)
failed:".mysql_error());
}
echo "mysql_select_db($db2,$id2)";
$sql='select * from my_table';
$result=mysql_query($sql,$id1);
if($result==false){
die("mysql_query($sql,$id1)
failed:".mysql_error());
}
--
Edit this bug report at http://bugs.php.net/?id=14906&edit=1
Bug #15992 Updated: Segmentation fault (11)
ID: 15992 Updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] -Status: Open +Status: Feedback Bug Type: InterBase related Operating System: RH 7.2 PHP Version: 4.1.2 New Comment: Try compiling Apache with --enable-debug too. Previous Comments: [2002-03-11 06:51:55] [EMAIL PROTECTED] As before i did: ./configure --without-mysql --with-imap --with-imap-ssl --with-interbase --with-pgsql --with-kerberos --with-gettext --with-xml --with-apache=../apache_1.3.23/ --enable-track-vars --enable-debug > .log Backtrace only outputs the same 2 lines after httpd crashes [2002-03-11 06:33:13] [EMAIL PROTECTED] Recompile php and the module (if not static already) with the configure line '--enable-debug'. [2002-03-11 06:25:10] [EMAIL PROTECTED] No symbol table info available. What else can I do to help? [2002-03-11 06:07:56] [EMAIL PROTECTED] Can you provide more context of the backtrace (e.g. a few more lines from 'bt full') ? [2002-03-11 05:07:08] [EMAIL PROTECTED] ibase_close function causes Segmentation fault (11) in Apache 1.3.23 web server. Program received signal SIGSEGV, Segmentation fault. 0x40430c7c in memcpy () from /lib/i686/libc.so.6 (gdb) bt #0 0x40430c7c in memcpy () from /lib/i686/libc.so.6 #1 0x in __strtol_internal (nptr=0x0, endptr=0x0, base=165, group=128) If I comment out the ibase_close() from my PHP scripst all works well. -- Edit this bug report at http://bugs.php.net/?id=15992&edit=1
Bug #15993 Updated: Download problem
ID: 15993
Updated by: [EMAIL PROTECTED]
Reported By: [EMAIL PROTECTED]
-Status: Open
+Status: Closed
Bug Type: *General Issues
Operating System: Windows
PHP Version: 4.1.2
New Comment:
Works fine for me.
This is likely to be a problem with your browser or your internet
connection.
Previous Comments:
[2002-03-11 05:59:21] [EMAIL PROTECTED]
Hi,
I tried to download the php patch from 4.06 to 4.1.1. The problem is
that the download does not stop. The file gets bigger and bigger.
I am downloading the file in an windows environment, but for the linux
distribution. I push right mouse button and chose "save link location"
("Ziel speichern unter" <- german).
Benjamin Elixmann
--
Edit this bug report at http://bugs.php.net/?id=15993&edit=1
Bug #15994 Updated: PHP should support Status-headerline
ID: 15994
Updated by: [EMAIL PROTECTED]
Reported By: [EMAIL PROTECTED]
-Status: Open
+Status: Bogus
Bug Type:HTTP related
PHP Version: 4.0.5
New Comment:
You can do header("HTTP/1.1 404"); and PHP will create a nice header
for it.
Previous Comments:
[2002-03-11 07:24:22] [EMAIL PROTECTED]
Apache returns HTTP-status code according to Status:-header line
returned by a cgi-script. PHP should do that too because it's a good
feature to support that behavior to allow script-writers return custom
status-codes.
Status is not a real HTTP header but a HTTP-server could return e.g.
"HTTP/1.0 404" from a cgi-script. But it doesn't work that way for PHP
when running as a module inside Apache. It could.
e.g.
In Apache it's done this way
But this doesn't get done for PHP when running as a module.
(Apache 1.3.9 util-script.c
ap_scan_script_header_err_core(...)
{
...
/*
* If the script returned a specific status, that's what
* we'll use - otherwise we assume 200 OK.
*/
else if (!strcasecmp(w, "Status")) {
r->status = cgi_status = atoi(l);
r->status_line = ap_pstrdup(r->pool, l);
}
...
--
Edit this bug report at http://bugs.php.net/?id=15994&edit=1
Bug #15995 Updated: Syntax error in debugger documentation (debugger-using.html, 10-03-2002)
ID: 15995 Updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] -Status: Open +Status: Closed Bug Type:Documentation problem PHP Version: 4.1.1 New Comment: This bug has been fixed in CVS. Previous Comments: [2002-03-11 07:55:20] [EMAIL PROTECTED] In the debugger documentation (debugger-using.html) is a syntax error in last sentence: "even if you them turned off with" -> "even if you turned them off with" I have found this error both in the online version as well as in the downloadable version (english, many HTML files, http://www.php.net/distributions/manual/php_manual_en.tar.bz2) Kind regards Markus Wolf -- Edit this bug report at http://bugs.php.net/?id=15995&edit=1
Bug #15995: Syntax error in debugger documentation (debugger-using.html, 10-03-2002)
From: [EMAIL PROTECTED] Operating system: PHP version: 4.1.1 PHP Bug Type: Documentation problem Bug description: Syntax error in debugger documentation (debugger-using.html, 10-03-2002) In the debugger documentation (debugger-using.html) is a syntax error in last sentence: "even if you them turned off with" -> "even if you turned them off with" I have found this error both in the online version as well as in the downloadable version (english, many HTML files, http://www.php.net/distributions/manual/php_manual_en.tar.bz2) Kind regards Markus Wolf -- Edit bug report at http://bugs.php.net/?id=15995&edit=1 -- Fixed in CVS:http://bugs.php.net/fix.php?id=15995&r=fixedcvs Fixed in release:http://bugs.php.net/fix.php?id=15995&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=15995&r=needtrace Try newer version: http://bugs.php.net/fix.php?id=15995&r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=15995&r=support Expected behavior: http://bugs.php.net/fix.php?id=15995&r=notwrong Not enough info: http://bugs.php.net/fix.php?id=15995&r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=15995&r=submittedtwice
Bug #13834 Updated: SID already defined
ID: 13834
Updated by: [EMAIL PROTECTED]
-Reported By: [EMAIL PROTECTED]
+Reported By: [EMAIL PROTECTED]
-Status: Closed
+Status: Open
Bug Type: Session related
Operating System: FreeBSD 4.2
-PHP Version: 4.0.6
+PHP Version: 4.1.2
New Comment:
Reopening and updating reporter & version.
Previous Comments:
[2002-03-10 15:53:45] [EMAIL PROTECTED]
This is still broken in 4.1.2
Using Horde 2.0 & IMP 3.0 wiht an SQL session handler, we get the
following error:
[Sun Mar 10 15:16:29 2002] [error] PHP Warning: Constant sid already
defined in /home/secure/public_html/horde/lib/Prefs.php on line 91
[Sun Mar 10 15:16:29 2002] [error] PHP Fatal error: Failed to
initialize session module in
/home/secure/public_html/horde/lib/Prefs.php on line 91
The code causing the error is the usual destory/start:
if ($registry->getMethod('auth/logout') == $registry->getApp())
{
include_once HORDE_BASE . '/lib/Auth.php';
Auth::clearAuth();
session_destroy();
@session_start();
}
Execution stops immediately after the session_start or better put
inside session_start as no debug msg immediately after the
session_start is ever printed.
[2002-01-09 02:09:30] [EMAIL PROTECTED]
No feedback. Closing.
[2001-12-19 22:53:16] [EMAIL PROTECTED]
Please test with 4.1.0 and latest CVS snapshot.
CVS snapshot source can be found
http://snaps.php.net/
(No windows binary)
If you don't have problem with latest CVS snapshot,
you can close your bug report by yourself.
Please report the result. When you update your bug
report, do not forget updating PHP version also.
Thank you
--
Yasuo
[2001-10-26 01:30:56] [EMAIL PROTECTED]
This is intended as more information for Bug id #11643. I could not
make comments directly as I am not the creator of the bug and I don't
have Dev Edit privilegdes either.
In any case, the redefinition is apparently session_start(). If I do
more than one session_start(), separated by a session_destroy(), then I
get warning:
Warning: Constant sid already defined in
/usr/home/smoore/php-include/Session_class.php on line 80
I am sure it is session_start() because the following makes the warning
go away:
$save = error_reporting( E_ERROR ); // temporarily turn off warnings
session_start();
error_reporting( $save );
Obviously the fix is to undefine SID in session_destroy. However,
there is no undefine in PHP is there?
It must be redefined because the original session has been destroyed
and the new one has a new session_id().
This doesn't bother my code because I don't use SID.
Hope this helps...
--
Edit this bug report at http://bugs.php.net/?id=13834&edit=1
Bug #14370 Updated: PHP_AUTH_PW being improperly set
ID: 14370
Updated by: [EMAIL PROTECTED]
Reported By: [EMAIL PROTECTED]
Status: Open
Bug Type: Apache related
Operating System: FreeBSD
PHP Version: 4.0.6
New Comment:
The following patch solves this bug by not exporting the PHP_AUTH_*
variables if safe_mode is set.
===8<
--- php-4.1.2/main/main.c.orig-securevars Mon Dec 17 22:19:51
2001
+++ php-4.1.2/main/main.c Mon Mar 11 07:34:40 2002
@@ -1031,10 +1031,10 @@
}
/* PHP Authentication support */
- if (SG(request_info).auth_user) {
+ if (!PG(safe_mode) && SG(request_info).auth_user) {
php_register_variable("PHP_AUTH_USER",
SG(request_info).auth_user, array_ptr TSRMLS_CC);
}
- if (SG(request_info).auth_password) {
+ if (!PG(safe_mode) && SG(request_info).auth_password) {
php_register_variable("PHP_AUTH_PW",
SG(request_info).auth_password, array_ptr TSRMLS_CC);
}
}
Previous Comments:
[2002-03-11 07:36:53] [EMAIL PROTECTED]
The following patch solves this bug by not exporting the PHP_AUTH_*
variables when safe_mode is set.
===8<
--- php-4.1.2/main/main.c.orig-securevars Mon Dec 17 22:19:51
2001
+++ php-4.1.2/main/main.c Mon Mar 11 07:34:40 2002
@@ -1031,10 +1031,10 @@
}
/* PHP Authentication support */
- if (SG(request_info).auth_user) {
+ if (!PG(safe_mode) && SG(request_info).auth_user) {
php_register_variable("PHP_AUTH_USER",
SG(request_info).auth_user, array_ptr TSRMLS_CC);
}
- if (SG(request_info).auth_password) {
+ if (!PG(safe_mode) && SG(request_info).auth_password) {
php_register_variable("PHP_AUTH_PW",
SG(request_info).auth_password, array_ptr TSRMLS_CC);
}
}
[2001-12-06 19:34:29] [EMAIL PROTECTED]
PHP_AUTH_PW is being improperly set when external authentication is
active
on Apache.
I have a directory structure that is protected via Apache
authentication, according
to the PHP documentation the PHP_AUTH_PW should not be available when
external authentication is in use. This is necessary for security
concerns when you
cannot trust the php applications. In any case, w/ php the AUTH_PW is
being
set at all times. Please fix, thanks!
--
Edit this bug report at http://bugs.php.net/?id=14370&edit=1
Bug #14370 Updated: PHP_AUTH_PW being improperly set
ID: 14370
Updated by: [EMAIL PROTECTED]
Reported By: [EMAIL PROTECTED]
Status: Open
Bug Type: Apache related
Operating System: FreeBSD
PHP Version: 4.0.6
New Comment:
The following patch solves this bug by not exporting the PHP_AUTH_*
variables when safe_mode is set.
===8<
--- php-4.1.2/main/main.c.orig-securevars Mon Dec 17 22:19:51
2001
+++ php-4.1.2/main/main.c Mon Mar 11 07:34:40 2002
@@ -1031,10 +1031,10 @@
}
/* PHP Authentication support */
- if (SG(request_info).auth_user) {
+ if (!PG(safe_mode) && SG(request_info).auth_user) {
php_register_variable("PHP_AUTH_USER",
SG(request_info).auth_user, array_ptr TSRMLS_CC);
}
- if (SG(request_info).auth_password) {
+ if (!PG(safe_mode) && SG(request_info).auth_password) {
php_register_variable("PHP_AUTH_PW",
SG(request_info).auth_password, array_ptr TSRMLS_CC);
}
}
Previous Comments:
[2001-12-06 19:34:29] [EMAIL PROTECTED]
PHP_AUTH_PW is being improperly set when external authentication is
active
on Apache.
I have a directory structure that is protected via Apache
authentication, according
to the PHP documentation the PHP_AUTH_PW should not be available when
external authentication is in use. This is necessary for security
concerns when you
cannot trust the php applications. In any case, w/ php the AUTH_PW is
being
set at all times. Please fix, thanks!
--
Edit this bug report at http://bugs.php.net/?id=14370&edit=1
Bug #13655 Updated: undefined symbol: stat
ID: 13655 Updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] Status: Open Bug Type: Informix related Operating System: RedHat Linux/Alpha 7.1 PHP Version: 4.0.6 New Comment: Syntax error on line 205 of /usr/local/apache/conf/httpd.conf: Cannot load /usr/local/apache/libexec/libphp4.so into server: /usr/local/informix/lib/esql/libifgen.so: undefined symbol: stat esql -V: INFORMIX-ESQL Version 9.51.UC3 Apache: 1.3.22 PHP: 4.1.1 Linux Mandrake: 8.1 glibc: 2.2.4 Same problem and no fix for that ;-) Gilles. Previous Comments: [2001-10-12 11:28:02] [EMAIL PROTECTED] Syntax error on line 205 of /usr/local/httpd/conf/httpd.conf Cannot load /usr/local/httpd/libexec/libphp4.so into server: /usr/local/informix/lib/esql/libifos.so: undefined symbol: stat esql -V: INFORMIX-ESQL Version 9.40FC2A Apache: 1.3.19 PHP: 4.0.6 RedHat Linux: 7.1 glibc: 2.2.3 We have the same problem with newer Intel Informix Client SDK (the one you can download from www.informix.com) One esql that works on Intel Linux is: INFORMIX-ESQL Version 9.30.UC1 I unfortunately don't have an older Redhat Linux/Alpha Informix Client SDK to try. -- Edit this bug report at http://bugs.php.net/?id=13655&edit=1
Bug #15994: PHP should support Status-headerline
From: [EMAIL PROTECTED]
Operating system:
PHP version: 4.0.5
PHP Bug Type: HTTP related
Bug description: PHP should support Status-headerline
Apache returns HTTP-status code according to Status:-header line returned
by a cgi-script. PHP should do that too because it's a good feature to
support that behavior to allow script-writers return custom
status-codes.
Status is not a real HTTP header but a HTTP-server could return e.g.
"HTTP/1.0 404" from a cgi-script. But it doesn't work that way for PHP
when running as a module inside Apache. It could.
e.g.
In Apache it's done this way
But this doesn't get done for PHP when running as a module.
(Apache 1.3.9 util-script.c
ap_scan_script_header_err_core(...)
{
...
/*
* If the script returned a specific status, that's what
* we'll use - otherwise we assume 200 OK.
*/
else if (!strcasecmp(w, "Status")) {
r->status = cgi_status = atoi(l);
r->status_line = ap_pstrdup(r->pool, l);
}
...
--
Edit bug report at http://bugs.php.net/?id=15994&edit=1
--
Fixed in CVS:http://bugs.php.net/fix.php?id=15994&r=fixedcvs
Fixed in release:http://bugs.php.net/fix.php?id=15994&r=alreadyfixed
Need backtrace: http://bugs.php.net/fix.php?id=15994&r=needtrace
Try newer version: http://bugs.php.net/fix.php?id=15994&r=oldversion
Not developer issue: http://bugs.php.net/fix.php?id=15994&r=support
Expected behavior: http://bugs.php.net/fix.php?id=15994&r=notwrong
Not enough info: http://bugs.php.net/fix.php?id=15994&r=notenoughinfo
Submitted twice: http://bugs.php.net/fix.php?id=15994&r=submittedtwice
Bug #14906 Updated: The function mysql_select_db set the db for other link ids than specified.
ID: 14906
Updated by: [EMAIL PROTECTED]
Reported By: [EMAIL PROTECTED]
Status: Open
Bug Type: MySQL related
Operating System: RedHat 7.1
PHP Version: 4.1.0
New Comment:
On my Slackware 3.6 box (not that it matters, since everything has been
built from source [php 4.0.6, 4.1.1 and 4.1.2, mysql 3.22.30]), I get
essentially the same results. I don't remember if the resource IDs
were the same, but I rewrote a few of my database libraries because of
this.
Basically, I had to write my database wrappers to never select a
database and always user mysql_db_query() because if someone using the
library connected with the same host/user/pass and selected a database,
the most current one would be used by both/all connections.
Please don't take mysql_db_query() away until this is sorted out. (and
maybe not even then) :)
Previous Comments:
[2002-01-07 07:27:54] [EMAIL PROTECTED]
PHP 4.1.0 and MySQL 3.23.41-log
The function mysql_select_db set the db for other link
identifiers than specified.
Doc:
bool mysql_select_db (string database_name, resource
[link_identifier])
mysql_select_db() sets the current active database on the server that's
associated with the specified link identifier. If no link identifier is
specified, the last opened link is assumed. If no link is open, the
function will try to establish a link as if mysql_connect() was called
without arguments, and use it.
The table my_table is in db1 but the active database
seems to be test on link #8.
Here the result:
mysql_pconnect() id1=Resource id #8
mysql_select_db(db1,Resource id #8)
mysql_pconnect() id2=Resource id #9
mysql_select_db(test,Resource id #9)
mysql_query(select * from my_table,Resource id #8)
failed: Table 'test.my_table' doesn't exist
Here the source:
$id1=mysql_pconnect($host,$user,$pass);
if($id1==false){
die("mysql_pconnect() failed: ".mysql_error());
}
echo "mysql_pconnect() id1=$id1";
$b=mysql_select_db($db1,$id1);
if($b==false){
die("mysql_select_db($db1,$id1)
failed:".mysql_error());
}
echo "mysql_select_db($db1,$id1)";
$id2=mysql_pconnect($host,$user,$pass);
if($id2==false){
echo "mysql_pconnect() failed: ".mysql_error();
}
echo "mysql_pconnect() id2=$id2";
$b=mysql_select_db($db2,$id2);
if($b==false){
die("mysql_select_db($db2,$id2)
failed:".mysql_error());
}
echo "mysql_select_db($db2,$id2)";
$sql='select * from my_table';
$result=mysql_query($sql,$id1);
if($result==false){
die("mysql_query($sql,$id1)
failed:".mysql_error());
}
--
Edit this bug report at http://bugs.php.net/?id=14906&edit=1
Bug #15658 Updated: session.save_path directive has no influence on session files save_path
ID: 15658 Updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] Status: Feedback Bug Type: *Configuration Issues Operating System: win2k PHP Version: 4.1.1 New Comment: I use the ISAPI version of PHP (IIS5) and Yes, I restarted that many times to checkt the (mis)behaviour of this directive. Previous Comments: [2002-02-22 12:16:38] [EMAIL PROTECTED] Did you restart Apache? [2002-02-21 09:37:38] [EMAIL PROTECTED] I try to get PHP to save it's session files in the /sessions directory (set session.save_path = e:\sessions) on my document drive, but no matter what I do and how I specify the directory (forward and backward slashes) it keeps saving them in the /tmp directory on that same drive (e:\tmp). There is no reference to /tmp in my whole php.ini file! >From my point of view it looks like the session.save_path directive recognition in the php.ini file is broken. -- Edit this bug report at http://bugs.php.net/?id=15658&edit=1
Bug #15992 Updated: Segmentation fault (11)
ID: 15992 Updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] -Status: Feedback +Status: Open Bug Type: InterBase related Operating System: RH 7.2 PHP Version: 4.1.2 New Comment: As before i did: ./configure --without-mysql --with-imap --with-imap-ssl --with-interbase --with-pgsql --with-kerberos --with-gettext --with-xml --with-apache=../apache_1.3.23/ --enable-track-vars --enable-debug > .log Backtrace only outputs the same 2 lines after httpd crashes Previous Comments: [2002-03-11 06:33:13] [EMAIL PROTECTED] Recompile php and the module (if not static already) with the configure line '--enable-debug'. [2002-03-11 06:25:10] [EMAIL PROTECTED] No symbol table info available. What else can I do to help? [2002-03-11 06:07:56] [EMAIL PROTECTED] Can you provide more context of the backtrace (e.g. a few more lines from 'bt full') ? [2002-03-11 05:07:08] [EMAIL PROTECTED] ibase_close function causes Segmentation fault (11) in Apache 1.3.23 web server. Program received signal SIGSEGV, Segmentation fault. 0x40430c7c in memcpy () from /lib/i686/libc.so.6 (gdb) bt #0 0x40430c7c in memcpy () from /lib/i686/libc.so.6 #1 0x in __strtol_internal (nptr=0x0, endptr=0x0, base=165, group=128) If I comment out the ibase_close() from my PHP scripst all works well. -- Edit this bug report at http://bugs.php.net/?id=15992&edit=1
Bug #15992 Updated: Segmentation fault (11)
ID: 15992 Updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] -Status: Open +Status: Feedback Bug Type: InterBase related Operating System: RH 7.2 PHP Version: 4.1.2 New Comment: Recompile php and the module (if not static already) with the configure line '--enable-debug'. Previous Comments: [2002-03-11 06:25:10] [EMAIL PROTECTED] No symbol table info available. What else can I do to help? [2002-03-11 06:07:56] [EMAIL PROTECTED] Can you provide more context of the backtrace (e.g. a few more lines from 'bt full') ? [2002-03-11 05:07:08] [EMAIL PROTECTED] ibase_close function causes Segmentation fault (11) in Apache 1.3.23 web server. Program received signal SIGSEGV, Segmentation fault. 0x40430c7c in memcpy () from /lib/i686/libc.so.6 (gdb) bt #0 0x40430c7c in memcpy () from /lib/i686/libc.so.6 #1 0x in __strtol_internal (nptr=0x0, endptr=0x0, base=165, group=128) If I comment out the ibase_close() from my PHP scripst all works well. -- Edit this bug report at http://bugs.php.net/?id=15992&edit=1
Bug #15992 Updated: Segmentation fault (11)
ID: 15992 Updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] -Status: Feedback +Status: Open Bug Type: InterBase related Operating System: RH 7.2 PHP Version: 4.1.2 New Comment: No symbol table info available. What else can I do to help? Previous Comments: [2002-03-11 06:07:56] [EMAIL PROTECTED] Can you provide more context of the backtrace (e.g. a few more lines from 'bt full') ? [2002-03-11 05:07:08] [EMAIL PROTECTED] ibase_close function causes Segmentation fault (11) in Apache 1.3.23 web server. Program received signal SIGSEGV, Segmentation fault. 0x40430c7c in memcpy () from /lib/i686/libc.so.6 (gdb) bt #0 0x40430c7c in memcpy () from /lib/i686/libc.so.6 #1 0x in __strtol_internal (nptr=0x0, endptr=0x0, base=165, group=128) If I comment out the ibase_close() from my PHP scripst all works well. -- Edit this bug report at http://bugs.php.net/?id=15992&edit=1
Bug #15955 Updated: header("Location: ...") doesn't work
ID: 15955
Updated by: [EMAIL PROTECTED]
-Summary: header("Location: ...") doesn't work
Reported By: [EMAIL PROTECTED]
-Status: Open
+Status: Closed
Bug Type: HTTP related
Operating System: Win 98 SE
PHP Version: 4.1.2
New Comment:
you won :) i'll try this :)
Previous Comments:
[2002-03-11 06:07:43] [EMAIL PROTECTED]
Even worse, the protocol and full hostname are required too by the
RFCs.
Derick
[2002-03-11 06:03:35] [EMAIL PROTECTED]
arg php.net was just an exapmle :)
i'm calling header("Location: artikel.php?".$QUERY_STRING);
;)
[2002-03-11 05:59:36] [EMAIL PROTECTED]
well, for a start: "http://www.php.net"; is *not* a valid
URL, "http://www.php.net/"; is
the trailing slash behind the Hostname is required by
the RFCs
[2002-03-08 07:59:14] [EMAIL PROTECTED]
what's wrong with following file:
http://www.php.net";);
?>
When it works on other servers, but not on 98SE with 4.1.2
with 98SE and 4.1.1 it's also working
[2002-03-08 07:52:47] [EMAIL PROTECTED]
Without complete, short script that fails I'm pretty sure
you're doing something wrong.
--Jani
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/15955
--
Edit this bug report at http://bugs.php.net/?id=15955&edit=1
Bug #15992 Updated: Segmentation fault (11)
ID: 15992 Updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] -Status: Open +Status: Feedback Bug Type: InterBase related Operating System: RH 7.2 PHP Version: 4.1.2 New Comment: Can you provide more context of the backtrace (e.g. a few more lines from 'bt full') ? Previous Comments: [2002-03-11 05:07:08] [EMAIL PROTECTED] ibase_close function causes Segmentation fault (11) in Apache 1.3.23 web server. Program received signal SIGSEGV, Segmentation fault. 0x40430c7c in memcpy () from /lib/i686/libc.so.6 (gdb) bt #0 0x40430c7c in memcpy () from /lib/i686/libc.so.6 #1 0x in __strtol_internal (nptr=0x0, endptr=0x0, base=165, group=128) If I comment out the ibase_close() from my PHP scripst all works well. -- Edit this bug report at http://bugs.php.net/?id=15992&edit=1
Bug #15955 Updated: header("Location: ...") doesn't work
ID: 15955
Updated by: [EMAIL PROTECTED]
-Summary: header("Location: ...") doesn't work
Reported By: [EMAIL PROTECTED]
Status: Open
Bug Type: HTTP related
Operating System: Win 98 SE
PHP Version: 4.1.2
New Comment:
Even worse, the protocol and full hostname are required too by the
RFCs.
Derick
Previous Comments:
[2002-03-11 06:03:35] [EMAIL PROTECTED]
arg php.net was just an exapmle :)
i'm calling header("Location: artikel.php?".$QUERY_STRING);
;)
[2002-03-11 05:59:36] [EMAIL PROTECTED]
well, for a start: "http://www.php.net"; is *not* a valid
URL, "http://www.php.net/"; is
the trailing slash behind the Hostname is required by
the RFCs
[2002-03-08 07:59:14] [EMAIL PROTECTED]
what's wrong with following file:
http://www.php.net";);
?>
When it works on other servers, but not on 98SE with 4.1.2
with 98SE and 4.1.1 it's also working
[2002-03-08 07:52:47] [EMAIL PROTECTED]
Without complete, short script that fails I'm pretty sure
you're doing something wrong.
--Jani
[2002-03-08 07:38:51] [EMAIL PROTECTED]
lol?
i'm not a noob, that's not a support question it's a bug
i wrote enough projects to decide whats a bug and when i'm to silly to
code something
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/15955
--
Edit this bug report at http://bugs.php.net/?id=15955&edit=1
Bug #15991 Updated: Undefined symbol "mysql_drop_db"
ID: 15991 Updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] Status: Feedback Bug Type: MySQL related Operating System: FreeBSD 4.5 PHP Version: 4.0CVS-2002-03-11 New Comment: mysql-4.0.1-alpha (libmysqlclient.so.11) ./configure --disable-cli --with-exec-dir=/usr/local/php/bin --with-mnogosearch=/usr/local/mnsh --enable-inline-optimization --with-freetype-dir=/usr/local --enable-trans-sid --enable-versioning --enable-ftp --with-xml --with-magic-quotes --enable-track-vars --enable-gd-native-ttf --with-png-dir=/usr/local --with-apxs=/usr/local/apache/bin/apxs --with-gd=/usr/local --with-jpeg-dir=/usr/local --with-gettext=/usr/local --with-bz2=/usr/local --with-zlib=/usr/local --with-mysql=/usr/local/mysql --enable-calendar --enable-safe-mode --enable-sysvsem --enable-sysvshm --with-config-file-path=/usr/local/php/ --with-exec-dir=/usr/local/php/bin --with-mod_charset --enable-bcmath Previous Comments: [2002-03-11 05:34:37] [EMAIL PROTECTED] What is your configure line? What is your version of libmysqlclient (if you're using an other client than the built-in)? [2002-03-11 04:09:34] [EMAIL PROTECTED] Cannot load /usr/local/apache/libexec/libphp4.so into server: /usr/local/apache/ libexec/libphp4.so: Undefined symbol "mysql_drop_db" ./apachectl start: httpd could not be started -- Edit this bug report at http://bugs.php.net/?id=15991&edit=1
Bug #15955 Updated: header("Location: ...") doesn't work
ID: 15955
Updated by: [EMAIL PROTECTED]
-Summary: header("Location: ...") doesn't work
Reported By: [EMAIL PROTECTED]
Status: Open
Bug Type: HTTP related
Operating System: Win 98 SE
PHP Version: 4.1.2
New Comment:
arg php.net was just an exapmle :)
i'm calling header("Location: artikel.php?".$QUERY_STRING);
;)
Previous Comments:
[2002-03-11 05:59:36] [EMAIL PROTECTED]
well, for a start: "http://www.php.net"; is *not* a valid
URL, "http://www.php.net/"; is
the trailing slash behind the Hostname is required by
the RFCs
[2002-03-08 07:59:14] [EMAIL PROTECTED]
what's wrong with following file:
http://www.php.net";);
?>
When it works on other servers, but not on 98SE with 4.1.2
with 98SE and 4.1.1 it's also working
[2002-03-08 07:52:47] [EMAIL PROTECTED]
Without complete, short script that fails I'm pretty sure
you're doing something wrong.
--Jani
[2002-03-08 07:38:51] [EMAIL PROTECTED]
lol?
i'm not a noob, that's not a support question it's a bug
i wrote enough projects to decide whats a bug and when i'm to silly to
code something
[2002-03-08 07:30:54] [EMAIL PROTECTED]
The bug system is not the appropriate forum for asking support
questions. For a list of a range of more appropriate places to ask
for help using PHP, please visit http://www.php.net/support.php
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/15955
--
Edit this bug report at http://bugs.php.net/?id=15955&edit=1
Bug #15955 Updated: header("Location: ...") doesn't work
ID: 15955
Updated by: [EMAIL PROTECTED]
-Summary: header("Location: ...") doesn't work
Reported By: [EMAIL PROTECTED]
Status: Open
Bug Type: HTTP related
Operating System: Win 98 SE
PHP Version: 4.1.2
New Comment:
well, for a start: "http://www.php.net"; is *not* a valid
URL, "http://www.php.net/"; is
the trailing slash behind the Hostname is required by
the RFCs
Previous Comments:
[2002-03-08 07:59:14] [EMAIL PROTECTED]
what's wrong with following file:
http://www.php.net";);
?>
When it works on other servers, but not on 98SE with 4.1.2
with 98SE and 4.1.1 it's also working
[2002-03-08 07:52:47] [EMAIL PROTECTED]
Without complete, short script that fails I'm pretty sure
you're doing something wrong.
--Jani
[2002-03-08 07:38:51] [EMAIL PROTECTED]
lol?
i'm not a noob, that's not a support question it's a bug
i wrote enough projects to decide whats a bug and when i'm to silly to
code something
[2002-03-08 07:30:54] [EMAIL PROTECTED]
The bug system is not the appropriate forum for asking support
questions. For a list of a range of more appropriate places to ask
for help using PHP, please visit http://www.php.net/support.php
[2002-03-08 07:27:22] [EMAIL PROTECTED]
so,
i don't get any error message or anything else
only a blank site, with nothing
also the log files don't have anything
it's really like he's ignoring the header function with 4.1.2 on win 98
se
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/15955
--
Edit this bug report at http://bugs.php.net/?id=15955&edit=1
Bug #15993: Download problem
From: [EMAIL PROTECTED]
Operating system: Windows
PHP version: 4.1.2
PHP Bug Type: *General Issues
Bug description: Download problem
Hi,
I tried to download the php patch from 4.06 to 4.1.1. The problem is that
the download does not stop. The file gets bigger and bigger.
I am downloading the file in an windows environment, but for the linux
distribution. I push right mouse button and chose "save link location"
("Ziel speichern unter" <- german).
Benjamin Elixmann
--
Edit bug report at http://bugs.php.net/?id=15993&edit=1
--
Fixed in CVS:http://bugs.php.net/fix.php?id=15993&r=fixedcvs
Fixed in release:http://bugs.php.net/fix.php?id=15993&r=alreadyfixed
Need backtrace: http://bugs.php.net/fix.php?id=15993&r=needtrace
Try newer version: http://bugs.php.net/fix.php?id=15993&r=oldversion
Not developer issue: http://bugs.php.net/fix.php?id=15993&r=support
Expected behavior: http://bugs.php.net/fix.php?id=15993&r=notwrong
Not enough info: http://bugs.php.net/fix.php?id=15993&r=notenoughinfo
Submitted twice: http://bugs.php.net/fix.php?id=15993&r=submittedtwice
Bug #15799 Updated: Another segfault on iconv
ID: 15799
Updated by: [EMAIL PROTECTED]
Reported By: [EMAIL PROTECTED]
-Status: Open
+Status: Assigned
Bug Type: ICONV related
Operating System: Linux
PHP Version: 4.0CVS-2002-02-2
-Assigned To:
+Assigned To: mfischer
New Comment:
Yep, saw it. Will fix this later (this day).
Previous Comments:
[2002-03-11 05:18:13] [EMAIL PROTECTED]
I see you already committed the patch to cvs and, yes, php doesn't
segfault anymore, thanks.
But unfortunately the conversion doesn't happen at all. You can try the
same script I posted earlier to reproduce it. Method 1 converts
correctly, method 2 just send the Big5 data asis.
[2002-03-10 18:01:25] [EMAIL PROTECTED]
Fixed in CVS and 4.2.0 branch.
[2002-03-09 15:34:13] [EMAIL PROTECTED]
I've sent a patch to jan (wouldn't make sense to paste here as long
lines get broken) and I'm pretty sure it's the right fix. I bet the
current code never really worked the way it was written.
Anyway I'm for deprecating iconv_(set|get)_encoding. All it does is
changing INI settigns which can be easily read and set with
ini_get("iconv.input_encoding") or ini_set(). However I don't know what
the general consesus in in such situations. The two functions just seem
redundant to me.
[2002-03-09 11:19:45] [EMAIL PROTECTED]
The segfaults still happen even after the recent changes in the iconv
extension and the output buffering code.
Here is a small script to reproduce it. Method 1 (commented out) works
fine, method 2 segfaults.
www.yahoo.com.tw
END;
// Method 1: Works!
/*
$src = 'BIG5';
$dst = 'UTF-8';
$rc = iconv($src, $dst, $text);
header('Content-Type: text/plain; charset=UTF-8');
echo $rc;
*/
// Method 2: Segfaults!
iconv_set_encoding('input_encoding', 'BIG5');
iconv_set_encoding('internal_encoding', 'UTF-8');
iconv_set_encoding('output_encoding', 'UTF-8');
ob_start('ob_iconv_handler');
echo $text;
$rc = ob_get_contents();
ob_end_clean();
header('Content-Type: text/plain; charset=UTF-8');
echo $rc;
?>
Since the line numbers changed since my initial report and I use a
different script (above), here's also an updated bt:
Program received signal SIGSEGV, Segmentation fault.
0x4010621a in chunk_free (ar_ptr=0x7a62e850, p=0x404ea168) at
malloc.c:3049
3049malloc.c: No such file or directory.
(gdb) bt
#0 0x4010621a in chunk_free (ar_ptr=0x7a62e850, p=0x404ea168) at
malloc.c:3049
#1 0x401061bf in free () at malloc.c:2952
#2 0x403744ec in zif_iconv_set_encoding () at iconv.c:267
#3 0x40317077 in execute () at ./zend_execute.c:959
#4 0x40328fb4 in zend_execute_scripts () at zend.c:373
#5 0x4033cea7 in php_execute_script () at main.c:1309
#6 0x40337240 in apache_php_module_main () at sapi_apache.c:100
#7 0x403381d8 in send_php (r=0x81825a0, display_source_mode=0,
filename=0x81841a8 "/usr/local/httpd/htdocs/headhorde/iconv.php")
at mod_php4.c:575
#8 0x40338263 in send_parsed_php (r=0x81825a0) at mod_php4.c:590
#9 0x8055250 in ap_invoke_handler ()
#10 0x80677bc in ap_some_auth_required ()
#11 0x8067833 in ap_process_request ()
#12 0x805fd27 in ap_child_terminate ()
#13 0x805fed5 in ap_child_terminate ()
#14 0x8060016 in ap_child_terminate ()
#15 0x8060628 in ap_child_terminate ()
#16 0x8060e95 in main ()
#17 0x400cca8e in __libc_start_main () at
../sysdeps/generic/libc-start.c:93
[2002-02-28 20:26:43] [EMAIL PROTECTED]
Better yet.
Could you make a script that included base64/uuencoded BIG5 data end
decode it and feed it to iconv?
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/15799
--
Edit this bug report at http://bugs.php.net/?id=15799&edit=1
Bug #15989 Updated: php is segfaulting when trying to read http header of a ftp.domaine.com site
ID: 15989 Updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] -Status: Open +Status: Feedback Bug Type: cURL related Operating System: windows 2000, macosx PHP Version: 4.1.2 New Comment: To properly diagnose this bug, 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". Previous Comments: [2002-03-10 21:06:57] [EMAIL PROTECTED] Here is a simple code for this : When the protocol is not specified, and the host name starts with ftp., there is a conflict segfault. It seems to have a conflict where curl choose automatically ftp protocole for ftp.*.* sites, but the script ask for http header. Then php crashes. This has been found with PHP 4.1.0/4.1.1 for windows, and PHP 4.1.2/ curl 7.9.4 PHP should return an error, but not crash. Note that when specifying the protocol, (eg, "http://ftp.site.com";), it works fine. -- Edit this bug report at http://bugs.php.net/?id=15989&edit=1
Bug #15991 Updated: Undefined symbol "mysql_drop_db"
ID: 15991 Updated by: [EMAIL PROTECTED] -Summary: Undefined symbol "mysql_drop_db" Reported By: [EMAIL PROTECTED] -Status: Open +Status: Feedback Bug Type: MySQL related Operating System: FreeBSD 4.5 PHP Version: 4.0CVS-2002-03-11 New Comment: What is your configure line? What is your version of libmysqlclient (if you're using an other client than the built-in)? Previous Comments: [2002-03-11 04:09:34] [EMAIL PROTECTED] Cannot load /usr/local/apache/libexec/libphp4.so into server: /usr/local/apache/ libexec/libphp4.so: Undefined symbol "mysql_drop_db" ./apachectl start: httpd could not be started -- Edit this bug report at http://bugs.php.net/?id=15991&edit=1
Bug #15799 Updated: Another segfault on iconv
ID: 15799
Updated by: [EMAIL PROTECTED]
Reported By: [EMAIL PROTECTED]
-Status: Closed
+Status: Open
Bug Type: ICONV related
Operating System: Linux
PHP Version: 4.0CVS-2002-02-2
New Comment:
I see you already committed the patch to cvs and, yes, php doesn't
segfault anymore, thanks.
But unfortunately the conversion doesn't happen at all. You can try the
same script I posted earlier to reproduce it. Method 1 converts
correctly, method 2 just send the Big5 data asis.
Previous Comments:
[2002-03-10 18:01:25] [EMAIL PROTECTED]
Fixed in CVS and 4.2.0 branch.
[2002-03-09 15:34:13] [EMAIL PROTECTED]
I've sent a patch to jan (wouldn't make sense to paste here as long
lines get broken) and I'm pretty sure it's the right fix. I bet the
current code never really worked the way it was written.
Anyway I'm for deprecating iconv_(set|get)_encoding. All it does is
changing INI settigns which can be easily read and set with
ini_get("iconv.input_encoding") or ini_set(). However I don't know what
the general consesus in in such situations. The two functions just seem
redundant to me.
[2002-03-09 11:19:45] [EMAIL PROTECTED]
The segfaults still happen even after the recent changes in the iconv
extension and the output buffering code.
Here is a small script to reproduce it. Method 1 (commented out) works
fine, method 2 segfaults.
www.yahoo.com.tw
END;
// Method 1: Works!
/*
$src = 'BIG5';
$dst = 'UTF-8';
$rc = iconv($src, $dst, $text);
header('Content-Type: text/plain; charset=UTF-8');
echo $rc;
*/
// Method 2: Segfaults!
iconv_set_encoding('input_encoding', 'BIG5');
iconv_set_encoding('internal_encoding', 'UTF-8');
iconv_set_encoding('output_encoding', 'UTF-8');
ob_start('ob_iconv_handler');
echo $text;
$rc = ob_get_contents();
ob_end_clean();
header('Content-Type: text/plain; charset=UTF-8');
echo $rc;
?>
Since the line numbers changed since my initial report and I use a
different script (above), here's also an updated bt:
Program received signal SIGSEGV, Segmentation fault.
0x4010621a in chunk_free (ar_ptr=0x7a62e850, p=0x404ea168) at
malloc.c:3049
3049malloc.c: No such file or directory.
(gdb) bt
#0 0x4010621a in chunk_free (ar_ptr=0x7a62e850, p=0x404ea168) at
malloc.c:3049
#1 0x401061bf in free () at malloc.c:2952
#2 0x403744ec in zif_iconv_set_encoding () at iconv.c:267
#3 0x40317077 in execute () at ./zend_execute.c:959
#4 0x40328fb4 in zend_execute_scripts () at zend.c:373
#5 0x4033cea7 in php_execute_script () at main.c:1309
#6 0x40337240 in apache_php_module_main () at sapi_apache.c:100
#7 0x403381d8 in send_php (r=0x81825a0, display_source_mode=0,
filename=0x81841a8 "/usr/local/httpd/htdocs/headhorde/iconv.php")
at mod_php4.c:575
#8 0x40338263 in send_parsed_php (r=0x81825a0) at mod_php4.c:590
#9 0x8055250 in ap_invoke_handler ()
#10 0x80677bc in ap_some_auth_required ()
#11 0x8067833 in ap_process_request ()
#12 0x805fd27 in ap_child_terminate ()
#13 0x805fed5 in ap_child_terminate ()
#14 0x8060016 in ap_child_terminate ()
#15 0x8060628 in ap_child_terminate ()
#16 0x8060e95 in main ()
#17 0x400cca8e in __libc_start_main () at
../sysdeps/generic/libc-start.c:93
[2002-02-28 20:26:43] [EMAIL PROTECTED]
Better yet.
Could you make a script that included base64/uuencoded BIG5 data end
decode it and feed it to iconv?
[2002-02-28 19:32:59] [EMAIL PROTECTED]
BIG5
I guess it's supported by libiconv and your glibc is ok..
If text is small enough, could you pate uuencoded text there?
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/15799
--
Edit this bug report at http://bugs.php.net/?id=15799&edit=1
Bug #15992: Segmentation fault (11)
From: [EMAIL PROTECTED] Operating system: RH 7.2 PHP version: 4.1.2 PHP Bug Type: InterBase related Bug description: Segmentation fault (11) ibase_close function causes Segmentation fault (11) in Apache 1.3.23 web server. Program received signal SIGSEGV, Segmentation fault. 0x40430c7c in memcpy () from /lib/i686/libc.so.6 (gdb) bt #0 0x40430c7c in memcpy () from /lib/i686/libc.so.6 #1 0x in __strtol_internal (nptr=0x0, endptr=0x0, base=165, group=128) If I comment out the ibase_close() from my PHP scripst all works well. -- Edit bug report at http://bugs.php.net/?id=15992&edit=1 -- Fixed in CVS:http://bugs.php.net/fix.php?id=15992&r=fixedcvs Fixed in release:http://bugs.php.net/fix.php?id=15992&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=15992&r=needtrace Try newer version: http://bugs.php.net/fix.php?id=15992&r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=15992&r=support Expected behavior: http://bugs.php.net/fix.php?id=15992&r=notwrong Not enough info: http://bugs.php.net/fix.php?id=15992&r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=15992&r=submittedtwice
Bug #15595 Updated: imap routines hang when "To" header is too large
ID: 15595
Updated by: [EMAIL PROTECTED]
-Summary: imap routines hang when "To" header is too large
Reported By: [EMAIL PROTECTED]
Status: Open
Bug Type: IMAP related
Operating System: Solaris-i86
PHP Version: 4.1.1
New Comment:
Is there anything I can do to help this along? We've been bitten twice
by this in the last few days.
Previous Comments:
[2002-02-18 18:09:33] [EMAIL PROTECTED]
An exact script is difficult. (I've spent a day or two trying to pin it
down to a simple routine, not with any great success).
However, it looks like
$h = @imap_header($imp->stream, imap_msgno($imp->stream, $msgnum));
is hanging with a message that has to header of about 4K (again, this
probably violates rfc822, but it shouldn't hang like it does).
$imp->stream is constructed like this (as you'd expect):
$connstr = '{' . $this->server . ':' . $this->port . '}' .
$this->mailbox;
$this->stream = @imap_open($connstr, $this->user, $this->pass);
Thanks.
[2002-02-18 08:29:31] [EMAIL PROTECTED]
Can you provide a simple sample script?
[2002-02-18 04:23:34] [EMAIL PROTECTED]
The starting point for this was that our webmail (customised IMP)would
crash if the "To" header was too large. Probably the header violates
rfc822, but php should be able to cope, or at least fail gracefully and
not hang.
We are running php built with the imap4.5 uwash c-client, with ldap,
with mysql. Apache is built with mods rewrite, mime_magic, the lastest
fastcgi, the latest modssl. The fastcgi connection is used for most
pages rendered from our site.
Playing around with truss led us to suspect mime_header_decode was at
fault, ie:
php_if_imap_mime_header_decode+0x6d3: movl (%ebx),%edx
Now, in getting a gdb backtrace, things got very wierd. Below is the
output - but it occurs not only when we try to read the email with the
oversized to header, but when I try to do something mundane like parse
the whole mailbox.
So maybe there are two problems, needless to say - I hope the truss
line is useful, because I wouldn't rely on the gdb backtrace.
Thanks.
Program received signal SIGPIPE, Broken pipe.
0xdfee1f3b in _writev ()
(gdb) bt
#0 0xdfee1f3b in _writev ()
#1 0x80b2254 in ssl_io_unregister ()
#2 0x81ba5f4 in ap_hook_call ()
#3 0x81b9d41 in ap_hook_call ()
#4 0x8196641 in ap_bfilbuf ()
#5 0x8196a6c in ap_bfilbuf ()
#6 0x8196b38 in ap_bwrite ()
#7 0x816537e in php_mergesort ()
#8 0x8166ec5 in php_mergesort ()
#9 0x816749d in php_mergesort ()
#10 0x8197ddb in ap_invoke_handler ()
#11 0x81ac451 in ap_some_auth_required ()
#12 0x81ac4b0 in ap_process_request ()
#13 0x81a3ad1 in ap_child_terminate ()
#14 0x81a3c80 in ap_child_terminate ()
#15 0x81a3ddb in ap_child_terminate ()
#16 0x81a43d8 in ap_child_terminate ()
#17 0x81a4b9b in main ()
#18 0x809b947 in _start ()
--
Edit this bug report at http://bugs.php.net/?id=15595&edit=1
Bug #15991: Undefined symbol "mysql_drop_db"
From: [EMAIL PROTECTED] Operating system: FreeBSD 4.5 PHP version: 4.0CVS-2002-03-11 PHP Bug Type: MySQL related Bug description: Undefined symbol "mysql_drop_db" Cannot load /usr/local/apache/libexec/libphp4.so into server: /usr/local/apache/ libexec/libphp4.so: Undefined symbol "mysql_drop_db" ./apachectl start: httpd could not be started -- Edit bug report at http://bugs.php.net/?id=15991&edit=1 -- Fixed in CVS:http://bugs.php.net/fix.php?id=15991&r=fixedcvs Fixed in release:http://bugs.php.net/fix.php?id=15991&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=15991&r=needtrace Try newer version: http://bugs.php.net/fix.php?id=15991&r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=15991&r=support Expected behavior: http://bugs.php.net/fix.php?id=15991&r=notwrong Not enough info: http://bugs.php.net/fix.php?id=15991&r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=15991&r=submittedtwice
Bug #15980 Updated: can't install php4
ID: 15980
Updated by: [EMAIL PROTECTED]
-Summary: can't install php4
Reported By: [EMAIL PROTECTED]
Status: Analyzed
Bug Type: Documentation problem
Operating System: Linux mandrake 7.2
PHP Version: 4.1.2
New Comment:
dear sir/madam,
i have installed flex and bison again. however the same problems still
occurred. (my procedure is : download the flex-2.5.4a.tar.gz and
bison-1.33.tar.gz ) then copy to /usr/local/ and go to their directory
and "./configure" and "make" and "make install".
Finally, i go to /usr/local/php-4.1.2/
and cd /usr/local/php-4.1.2
./configure --with-apxs=/usr/local/apache/bin/apxs \
--with-mysql \
--enable-track-vars
:(
but the same problem is still here
thanks
Rgds,
arthur
Previous Comments:
[2002-03-10 22:42:20] [EMAIL PROTECTED]
You need to install flex.. ask further support questions
on the mailing lists. http://www.php.net/support.php
(Reclassified as documentation problem, FAQ's build section should have
entry for this :)
[2002-03-10 21:11:09] [EMAIL PROTECTED]
Dear sir/madam,
my OS is Linux Mandrake 7.2 and i install apache as my web server and
mysql as my database. (Perl is also pre loaded)
However, i tried to install PHP by use php*.tar.gz or *.rpm are both
failed. i don't know why. Isn't the computer missed some gcc (compilers
such as C compiler or others). Please give me a hand . thanks.
when i tried to install by using un-tar *.tar.gz. the error is as
below:
firstly, i saved the un-tar directory in /tmp/php-4.1.2/**
it is a root user too.
The error as below:
**
[root@i-arthur php-4.1.2]# ./configure
loading cache ./config.cache
checking for a BSD compatible install... /usr/bin/install -c
checking whether build environment is sane... yes
checking whether make sets ${MAKE}... yes
checking for working aclocal... missing
checking for working autoconf... missing
checking for working automake... missing
checking for working autoheader... missing
checking for working makeinfo... missing
checking whether to enable maintainer-specific portions of Makefiles...
no
checking host system type... i686-pc-linux-gnu
checking for gawk... gawk
checking for bison... bison -y
checking bison version... 1.28 (ok)
checking for gcc... gcc
checking whether the C compiler (gcc ) works... yes
checking whether the C compiler (gcc ) is a cross-compiler... no
checking whether we are using GNU C... yes
checking whether gcc accepts -g... yes
checking how to run the C preprocessor... gcc -E
checking for AIX... no
checking for gcc option to accept ANSI C... none needed
checking for ranlib... ranlib
checking whether gcc and cc understand -c and -o together... yes
checking whether ln -s works... yes
checking for flex... lex
checking for yywrap in -ll... no
checking lex output file root... ./configure: lex: command not found
configure: error: cannot find output from lex; giving up
**
What can i do?
thanks
Rgds,
arthur
[EMAIL PROTECTED]
[2002-03-10 21:09:34] [EMAIL PROTECTED]
Dear sir/madam,
my OS is Linux Mandrake 7.2 and i install apache as my web server and
mysql as my database. (Perl is also pre loaded)
However, i tried to install PHP by use php*.tar.gz or *.rpm are both
failed. i don't know why. Isn't the computer missed some gcc (compilers
such as C compiler or others). Please give me a hand . thanks.
when i tried to install by using un-tar *.tar.gz. the error is as
below:
firstly, i saved the un-tar directory in /tmp/php-4.1.2/**
it is a root user too.
The error as below:
**
[root@i-arthur php-4.1.2]# ./configure
loading cache ./config.cache
checking for a BSD compatible install... /usr/bin/install -c
checking whether build environment is sane... yes
checking whether make sets ${MAKE}... yes
checking for working aclocal... missing
checking for working autoconf... missing
checking for working automake... missing
checking for working autoheader... missing
checking for working makeinfo... missing
checking whether to enable maintainer-specific portions of Makefiles...
no
checking host system type... i686-pc-linux-gnu
checking for gawk... gawk
checking for bison... bison -y
checking bison version... 1.28 (ok)
checking for gcc... gcc
checking whether the C compiler (gcc ) works... yes
checking whether the C compiler (gcc ) is a cross-compiler... no
checking whether we are using GNU C... yes
checking whether gcc accepts -g... yes
checking how to run the C preprocessor... gcc -E
checking for AIX... no
checking for gcc option to accept ANSI C... none needed
checking for ranlib... ranlib
check
Bug #15990: Communication error between php ISAPI module and MySQL
From: [EMAIL PROTECTED] Operating system: MS Windows 2000 PHP version: 4.1.1 PHP Bug Type: MySQL related Bug description: Communication error between php ISAPI module and MySQL Communication error between php ISAPI module and MySQL OS: MS Windows 2000 Server SP2, SRP1 and up to date fixes WWW Server: IIS 5.0 PHP: 4.1.1 used as ISAPI dll (php4isapi.dll) - downloaded binary from "http://www.php.net/do_download.php?download_file=php-4.1.1-Win32.zip"; MySQL: 3.23.39-nt installed on the same machine MySQL Error message in mysql.err like this one: "Aborted connection 3957 to db: 'phpLinks3' user: 'rcc' host: `localhost' (Unknown error) - see http://www.mysql.com/doc/C/o/Communication_errors.html"; Application error message: "Too many connections", ... The error has occurred several hours after starting/restarting IIS. After reinstalling previous version of php (4.0.6), everything is OK (www and ftp server with about 10 000 hits per day). Best regards Peter Santavy -- Edit bug report at http://bugs.php.net/?id=15990&edit=1 -- Fixed in CVS:http://bugs.php.net/fix.php?id=15990&r=fixedcvs Fixed in release:http://bugs.php.net/fix.php?id=15990&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=15990&r=needtrace Try newer version: http://bugs.php.net/fix.php?id=15990&r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=15990&r=support Expected behavior: http://bugs.php.net/fix.php?id=15990&r=notwrong Not enough info: http://bugs.php.net/fix.php?id=15990&r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=15990&r=submittedtwice
