#20986 [Com]: PHP causes Apache to leak semaphores
ID: 20986 Comment by: mee at huyou dot com Reported By: louis at sixnet dot net Status: No Feedback Bug Type: Apache related Operating System: RedHat Linux 7.1 8.0 PHP Version: 4.2.2 New Comment: ~ from china Previous Comments: [2003-01-07 01:00:10] php-bugs at lists dot php dot net No feedback was provided for this bug for over 2 weeks, so it is being suspended automatically. If you are able to provide the information that was originally requested, please do so and change the status of the bug back to Open. [2002-12-22 01:10:25] [EMAIL PROTECTED] Please try using this CVS snapshot: http://snaps.php.net/php4-latest.tar.gz For Windows: http://snaps.php.net/win32/php4-win32-latest.zip [2002-12-13 04:13:22] louis at sixnet dot net This bug has been discussed over at RedHat's Bugzilla. See http://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=70846 A quick synopsis of how I get it to misbehave: Create the following simple PHP script and access it through a web browser: ?php $crash = array( 0 = 2, 'test' = 2, 1 = 'hello', 'say' = 'hello', 2 = 42, 'life' = 42, 3 = 'this should help \'crash\' the machine', 'hoho' = 'this should help \'crash\' the machine'); print_r($crash); for( $i=0; $icount($crash); $i++ ) $crash[$i] = stripslashes($crash[$i]); print_r($crash); ? It should die with an error similar to this: Fatal error: Allowed memory size of 8388608 bytes exhausted (tried to allocate 35 bytes) in /home//crash.php on line 14 Reload this page a good 5-10 times. If you run 'ipcs -s' and then restart apache and run 'ipcs -s' again you will find that the number of semaphore arrays has increased and the first few semid's are unchanged (not having been freed when apache shutdown?). If you rinse and repeat the above with a crude shell script like: while [ true ]; do wget -O - http://localhost/crash.php wget -O - http://localhost/crash.php wget -O - http://localhost/crash.php wget -O - http://localhost/crash.php wget -O - http://localhost/crash.php wget -O - http://localhost/crash.php wget -O - http://localhost/crash.php wget -O - http://localhost/crash.php wget -O - http://localhost/crash.php wget -O - http://localhost/crash.php ipcs -s|grep apache|wc /etc/rc.d/init.d/httpd restart sleep 1 ipcs -s|grep apache|wc done then you'll find the semaphore array numbers increasing slowly and apache taking longer and longer to do each restart until eventually (once all 128 semaphore arrays are used) it refuses to start at all with the message reported earlier in this bug (70846): Starting httpd: Ouch! ap_mm_create(1048576, /var/run/httpd.mm.5619) failed Error: MM: mm:core: failed to acquire semaphore (No space left on device): OS: Invalid argument [FAILED] Just restarting apache in a loop without loading crash.php on a freshly booted system does not cause the number of semaphores to spiral - it stays constant at 5. This is verifyable on multiple RH7.1 and a RH8.0 machine, all fully updated through RHN (except for kernels). RedHat have literally just released an updated mm package which stops the use of kernel semaphores so that the leaks should not cause Apache problems so quickly (ie more than 128 are now allowed), but none-the-less there RedHat agree there is still a PHP problem. Louis -- Edit this bug report at http://bugs.php.net/?id=20986edit=1
#24141 [Fbk-Opn]: Massive configure script failures when LDAP is linked against kerberos.
ID: 24141
User updated by: robbat2 at gentoo dot org
Reported By: robbat2 at gentoo dot org
-Status: Feedback
+Status: Open
Bug Type: Compile Failure
Operating System: Gentoo Linux
PHP Version: 4.3.2
New Comment:
Hi Derick, a response.
As for the part of not finding the libkrb4.so.2, it turned out that the
user unmerged it without heed to that was linked against it.
However I still that that the configure script should have failed MUCH
earlier to make this failure easier to catch and not result in totally
erroroneus error messages.
Previous Comments:
[2003-06-12 03:01:25] [EMAIL PROTECTED]
Where is libkrb4.so.2 on your system, and is it in the paths
described in /etc/ld.so.conf ? And did you run ldconfig after
installing that ldap?
[2003-06-12 01:49:07] robbat2 at gentoo dot org
Description:
On a system that has OpenLDAP installed, and dynamically linked against
kerberos, the configure script starts massively failing after adding in
-lldap.
When that starts, it gives incorrect errors until it hits some check
that causes the configure script to bail out.
This results in a VERY incorrect error message being given by the
configure script.
This is similar to bug item #4133, but only a workaround was provided
for that bug, and not a proper fix.
I think in this case, putting the kerberos checks together with the
ldap stuff might solve the problem, but I'm not a configure guru.
Expected result:
Two things:
Firstly, there needs to be some form of checks against the libraries
that are added to the LIBS list so that the system catches ALL of the
extra libraries they are linked against.
Secondly, the configure script SHOULD fail sooner after errors, and
give more intelligable answers.
It should have failed right after the initial error that linking
against LDAP gave.
Actual result:
--
You can see the entire config.log file and more details at our
bugzilla: http://bugs.gentoo.org/show_bug.cgi?id=22635
snippet from config.log when it first fails:
CUT
configure:41615: gcc -o conftest -O2 -mcpu=i686 -pipe -L/usr/lib
conftest.c -lldap -llber -lcrypt -lpam -lxsltbreakpoint -lxml2 -lxslt
-lz -lndbm -lgdbm -lcurl -lcrack -lbz2 -lz -lssl -lcrypto -lresolv -lm
-ldl -lnsl -lcurl -lz -lssl -lcrypto -ldl -lz -lxml2 -lz -lm 15
/usr/lib/gcc-lib/i686-pc-linux-gnu/3.2.2/../../../../i686-pc-linux-gnu/bin/ld:
warning: libkrb4.so.2, needed by /usr/lib/libldap.so, not found (try
using -rpath or -rpath-link)
configure:41587: checking for ldap_start_tls_s
configure:41615: gcc -o conftest -O2 -mcpu=i686 -pipe -L/usr/lib
conftest.c -lldap -llber -lcrypt -lpam -lxsltbreakpoint -lxml2 -lxslt
-lz -lndbm -lgdbm -lcurl -lcrack -lbz2 -lz -lssl -lcrypto -lresolv -lm
-ldl -lnsl -lcurl -lz -lssl -lcrypto -ldl -lz -lxml2 -lz -lm 15
/usr/lib/gcc-lib/i686-pc-linux-gnu/3.2.2/../../../../i686-pc-linux-gnu/bin/ld:
warning: libkrb4.so.2, needed by /usr/lib/libldap.so, not found (try
using -rpath or -rpath-link)
configure:41645: checking whether to enable multibyte string support
CUT
Here is where it finally fails and gives up:
CUT
configure:75358: checking for Sablotron version
configure:75383: gcc -o conftest -O2 -mcpu=i686 -pipe -I/usr/include
-L/usr/lib conftest.c -lcrypt -lpspell -lpq -lpdf -lz -ltiff -lpng
-ljpeg -lmysqlclient -lmhash -lmcrypt -lltdl -lldap -llber -lcrypt
-lpam -lxsltbreakpoint -lxml2 -lxslt -lz -lndbm -lgdbm -lcurl -lcrack
-lbz2 -lz -lssl -lcrypto -lresolv -lm -ldl -lnsl -lcurl -lz -lssl
-lcrypto -ldl -lz -lxml2 -lz -lm -lodbc -lnetsnmp -lcrypto -lm -lcrypt
15
/usr/lib/gcc-lib/i686-pc-linux-gnu/3.2.2/../../../../i686-pc-linux-gnu/bin/ld:
warning: libkrb4.so.2, needed by /usr/lib/libldap.so, not found (try
using -rpath or -rpath-link)
configure: failed program was:
#line 75365 configure
#include confdefs.h
#include stdlib.h
#include sablot.h
int main ()
{
double version;
version = atof(SAB_VERSION);
if (version = 0.96) {
exit(0);
}
exit(255);
}
CUT
The error that the above failure throws. Totally incorrect about the
problem of course.
CUT
checking for Sablotron version... configure: error: Sablotron version
0.96 or
greater required.
CUT
--
Edit this bug report at http://bugs.php.net/?id=24141edit=1
#24167 [NEW]: FastCGI server processes dying when script not found
From: mweilguni at sime dot com
Operating system: Redhat Linux 7.2
PHP version: 4.3.2
PHP Bug Type: CGI related
Bug description: FastCGI server processes dying when script not found
Description:
We use PHP 4.3.2 + FastCGI + Apache/mod_fcgi. The PHP fastcgi server is
started in our setup with 8 preforked php-servers,
so after a restart the process tree will look like:
\_ /usr/bin/php-fcgi-4.3.2
| \_ /usr/bin/php-fcgi-4.3.2
| \_ /usr/bin/php-fcgi-4.3.2
| \_ /usr/bin/php-fcgi-4.3.2
| \_ /usr/bin/php-fcgi-4.3.2
| \_ /usr/bin/php-fcgi-4.3.2
| \_ /usr/bin/php-fcgi-4.3.2
| \_ /usr/bin/php-fcgi-4.3.2
| \_ /usr/bin/php-fcgi-4.3.2
so far it's ok. when I request for a non-existant script, I get the error
No input file specified.. That's ok too. But after that, one server
process died:
\_ /usr/bin/php-fcgi-4.3.2
| \_ /usr/bin/php-fcgi-4.3.2
| \_ /usr/bin/php-fcgi-4.3.2
| \_ /usr/bin/php-fcgi-4.3.2
| \_ /usr/bin/php-fcgi-4.3.2
| \_ /usr/bin/php-fcgi-4.3.2
| \_ /usr/bin/php-fcgi-4.3.2
| \_ /usr/bin/php-fcgi-4.3.2
After requesting a non-existant script 8 times all servers are gone, only
the master server process remains:
\_ /usr/bin/php-fcgi-4.3.2
I checked the file sapi/cgi/cgi_main.c and it seems the error is in line
1473:
if (retval == FAILURE file_handle.handle.fp == NULL) {
SG(sapi_headers).http_response_code = 404;
PUTS(No input file specified.\n);
php_request_shutdown((void *) 0);
php_module_shutdown(TSRMLS_C);
return FAILURE;
}
IMO this should be:
if (retval == FAILURE file_handle.handle.fp == NULL) {
SG(sapi_headers).http_response_code = 404;
PUTS(No input file specified.\n);
#if PHP_FASTCGI
continue;
#endif
php_request_shutdown((void *) 0);
php_module_shutdown(TSRMLS_C);
return FAILURE;
}
It seems to work fine, but I'm not really sure if this is right.
--
Edit bug report at http://bugs.php.net/?id=24167edit=1
--
Try a CVS snapshot: http://bugs.php.net/fix.php?id=24167r=trysnapshot
Fixed in CVS: http://bugs.php.net/fix.php?id=24167r=fixedcvs
Fixed in release: http://bugs.php.net/fix.php?id=24167r=alreadyfixed
Need backtrace: http://bugs.php.net/fix.php?id=24167r=needtrace
Try newer version: http://bugs.php.net/fix.php?id=24167r=oldversion
Not developer issue:http://bugs.php.net/fix.php?id=24167r=support
Expected behavior: http://bugs.php.net/fix.php?id=24167r=notwrong
Not enough info:http://bugs.php.net/fix.php?id=24167r=notenoughinfo
Submitted twice:http://bugs.php.net/fix.php?id=24167r=submittedtwice
register_globals: http://bugs.php.net/fix.php?id=24167r=globals
PHP 3 support discontinued: http://bugs.php.net/fix.php?id=24167r=php3
Daylight Savings: http://bugs.php.net/fix.php?id=24167r=dst
IIS Stability: http://bugs.php.net/fix.php?id=24167r=isapi
Install GNU Sed:http://bugs.php.net/fix.php?id=24167r=gnused
#24168 [NEW]: XSL functions 'forget' current node position after absolute path argument
From: christian dot hang at web dot de Operating system: Linux (Debian woody) PHP version: 4.3.2 PHP Bug Type: DOM XML related Bug description: XSL functions 'forget' current node position after absolute path argument Description: After an upgrade (from 4.3.0 to 4.3.2), some of the XSL transformation (handled by domxml) where not working correctly anymore. It seems, that XSL functions (like concat) forget the current node, that they should use to evualate relative XPath-Expression in their arguments, when an absolute Path is given in a prior argument. The example code demonstrates that behavior (compare description of Expected result and Actual result). A quick workaround is the addition of the current()-function in the relative path expressions, as that will fix the problem. But as far as I know, that is not required by the standard. If one switches the two arguments (concat(@nr, //testnode/@test)), everything works fine, the current() is not necessary and @nr is evaluated correctly. As the order of the arguments has an effect on the path evaluation (which it should not), I figure that there is problem. The versions of the libraries used: DOM/XML API Version 20020815 libxml Version 20419 HTML Support enabled XPath Support enabled XPointer Support enabled DOM/XSLT enabled libxslt Version 1.0.20 libxslt compiled against libxml Version 2.4.24 DOM/EXSLT enabled libexslt Version 1.0.20 I have to admit that I cannot compare the library versions used here with the ones I used for 4.3.0 version where everything worked okay (system crashed - long and ugly story), so it might very well be a problem of the libraries instead of the domxml extenstion. Reproduce code: --- $xml = ?xml version=\1.0\ ?roottestnode test=\somevalue\node nr=\1\/node nr=\2\/node nr=\3\//testnode/roo\ t; $xml_doc = domxml_open_mem($xml); $xsl_text=?xml version=\1.0\ ? xsl:stylesheet xmlns:xsl=\http://www.w3.org/1999/XSL/Transform\; version=\1.0\ xsl:output method=\xml\/ xsl:template match=\root\ new_root xsl:for-each select=\testnode/node\ xsl:value-of select=\concat(//testnode/@test, @nr)\/ - /xsl:for-each /new_root /xsl:template /xsl:stylesheet; $xsl = domxml_open_mem($xsl_text); $xsl_doc = domxml_xslt_stylesheet_doc($xsl); $res = $xsl_doc-process($xml_doc); Expected result: A dump of the $res result tree should produce the following ?xml version=1.0? new_rootsomevalue1 - somevalue2 - somevalue3 - /new_root and it does, if the concat expression in the example script is changed to concat(//testnode/@test, current()/@nr) Actual result: -- A dump of the $res result tree does produce the following ?xml version=1.0? new_rootsomevalue - somevalue - somevalue - /new_root The nr-attribute value is not concatenated to the value of the test-attribute in testnode. -- Edit bug report at http://bugs.php.net/?id=24168edit=1 -- Try a CVS snapshot: http://bugs.php.net/fix.php?id=24168r=trysnapshot Fixed in CVS: http://bugs.php.net/fix.php?id=24168r=fixedcvs Fixed in release: http://bugs.php.net/fix.php?id=24168r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=24168r=needtrace Try newer version: http://bugs.php.net/fix.php?id=24168r=oldversion Not developer issue:http://bugs.php.net/fix.php?id=24168r=support Expected behavior: http://bugs.php.net/fix.php?id=24168r=notwrong Not enough info:http://bugs.php.net/fix.php?id=24168r=notenoughinfo Submitted twice:http://bugs.php.net/fix.php?id=24168r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=24168r=globals PHP 3 support discontinued: http://bugs.php.net/fix.php?id=24168r=php3 Daylight Savings: http://bugs.php.net/fix.php?id=24168r=dst IIS Stability: http://bugs.php.net/fix.php?id=24168r=isapi Install GNU Sed:http://bugs.php.net/fix.php?id=24168r=gnused
#24169 [NEW]: session cookie being incorrectly sent
From: steveh at brendata dot co dot uk Operating system: NT4 SP6a PHP version: 4.3.2 PHP Bug Type: Session related Bug description: session cookie being incorrectly sent Description: For session handling a cookie should be set as follows: session name=session id This was previously working, but since upgrading to 4.3.2 we now see cookies set as follows: session id=session id As a result sessions are not carried over and a new session is started for every access (i.e. no cookie called PHPSESSID or whatever is in the php.ini) Here's the relevant chunk of phpinfo output that demonstrates this. _SERVER[HTTP_COOKIE] CookieProductID=94; a9c7fa405401e831e6ada0ee31f67ea3=a9c7fa405401e831e6ada0ee31f67ea3; caec00776094cd5017fa35e41162333b=caec00776094cd5017fa35e41162333b; 139632a02257356caa27c86256afcb70=139632a02257356caa27c86256afcb70; 0ba5beadf45c35245e67c1f67ffc70dc=0ba5beadf45c35245e67c1f67ffc70dc; b7f2e2e4a196a620f318f16034a8192b=b7f2e2e4a196a620f318f16034a8192b; 6ca2b668932e46c85528d399fad50541=6ca2b668932e46c85528d399fad50541; 913a5a99fa54ccd33b610b3f882d132d=913a5a99fa54ccd33b610b3f882d132d; a7c7085d672b5e885476dabdc096ca9f=a7c7085d672b5e885476dabdc096ca9f; 04a257bf48fef943fb1d4ed508970140=04a257bf48fef943fb1d4ed508970140; d269823ce913782241613e3791935d11=d269823ce913782241613e3791935d11; edc78b150437138fb1d14915a97dee87=edc78b150437138fb1d14915a97dee87; 50212bca7b517a57521305d72a6c43c9=50212bca7b517a57521305d72a6c43c9; 68c37f0103351348dd1e705847e2f6d3=68c37f0103351348dd1e705847e2f6d3; 78d96155c83ee77e3fc3b69731b428a4=78d96155c83ee77e3fc3b69731b428a4; e7b52247b003b85c04d942721879206a=e7b52247b003b85c04d942721879206a; f3d20ebc7068137eaa7b3461eab64d62=f3d20ebc7068137eaa7b3461eab64d62; c3940ed02170d481105849b74b6d3cb8=c3940ed02170d481105849b74b6d3cb8; e8109d59aca1442f4cd7fa5358410c30=e8109d59aca1442f4cd7fa5358410c30; 2a0f643e85d2b21003958bb47c2a2d4d=2a0f643e85d2b21003958bb47c2a2d4d Reproduce code: --- ?php session_start(); $_SESSION[FRED]=1; echo session_id(); phpinfo(); ? Expected result: The same session id for each open, and PHPSESSID seen as a cookie in the headers. Actual result: -- Different session id's each time, and a growing list of session id=session id cookies. -- Edit bug report at http://bugs.php.net/?id=24169edit=1 -- Try a CVS snapshot: http://bugs.php.net/fix.php?id=24169r=trysnapshot Fixed in CVS: http://bugs.php.net/fix.php?id=24169r=fixedcvs Fixed in release: http://bugs.php.net/fix.php?id=24169r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=24169r=needtrace Try newer version: http://bugs.php.net/fix.php?id=24169r=oldversion Not developer issue:http://bugs.php.net/fix.php?id=24169r=support Expected behavior: http://bugs.php.net/fix.php?id=24169r=notwrong Not enough info:http://bugs.php.net/fix.php?id=24169r=notenoughinfo Submitted twice:http://bugs.php.net/fix.php?id=24169r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=24169r=globals PHP 3 support discontinued: http://bugs.php.net/fix.php?id=24169r=php3 Daylight Savings: http://bugs.php.net/fix.php?id=24169r=dst IIS Stability: http://bugs.php.net/fix.php?id=24169r=isapi Install GNU Sed:http://bugs.php.net/fix.php?id=24169r=gnused
#24156 [Opn-Bgs]: T undefined during compile of php_imap.c
ID: 24156 Updated by: [EMAIL PROTECTED] Reported By: barryn at baptisthealth dot net -Status: Open +Status: Bogus Bug Type: IMAP related Operating System: Solaris 8 PHP Version: 4.3.2 New Comment: If that constant is not defined, it's really something broken in your c-client headers, not by any chance in PHP. Previous Comments: [2003-06-12 13:47:46] barryn at baptisthealth dot net I have no more time to assist with this. Here is the information you requested. You fix this problem (which probably only occurs with certain versions of the imap headers, maybe only on Solaris) by adding the code I included, which will do nothing if T is already defined. Or not... It's up the powers that be that maintain this package. Whatever. Here's the error text: /bin/sh /usr/share/src/php-4.3.2/libtool --silent --preserve-dup-deps --mode=compile /usr/share/src/php-4.3.2/meta_ccld -Iext/imap/ -I/usr/share/src/php-4.3.2/ext/imap/ -DPHP_ATOM_INC -I/usr/share/src/php-4.3.2/include -I/usr/share/src/php-4.3.2/main -I/usr/share/src/php-4.3.2 -I/opt/netscape/plugins/include -I/usr/share/src/php-4.3.2/Zend -I/opt/sfw/include -I/opt/app/oracle/product/8.1.6/rdbms/public -I/opt/app/oracle/product/8.1.6/rdbms/demo -I/opt/app/oracle/product/8.1.6/network/public -I/usr/share/src/php-4.3.2/ext/xml/expat -D_POSIX_PTHREAD_SEMANTICS -D_POSIX_PTHREAD_SEMANTICS -D_REENTRANT -I/usr/share/src/php-4.3.2/TSRM -DTHREAD=1 -O2 -I/opt/app/oracle/product/8.1.6/rdbms/demo -I/opt/app/oracle/product/8.1.6/rdbms/public -I/opt/app/oracle/product/8.1.6/network/public -pthreads -DZTS -prefer-pic -c /usr/share/src/php-4.3.2/ext/imap/php_imap.c -o ext/imap/php_imap.lo /usr/share/src/php-4.3.2/ext/imap/php_imap.c: In function `zif_imap_mail_copy': /usr/share/src/php-4.3.2/ext/imap/php_imap.c:1117: `T' undeclared (first use in this function) /usr/share/src/php-4.3.2/ext/imap/php_imap.c:1117: (Each undeclared identifier is reported only once /usr/share/src/php-4.3.2/ext/imap/php_imap.c:1117: for each function it appears in.) /usr/share/src/php-4.3.2/ext/imap/php_imap.c: In function `zif_imap_mail_move': /usr/share/src/php-4.3.2/ext/imap/php_imap.c:1145: `T' undeclared (first use in this function) /usr/share/src/php-4.3.2/ext/imap/php_imap.c: In function `zif_imap_createmailbox': /usr/share/src/php-4.3.2/ext/imap/php_imap.c:1168: `T' undeclared (first use in this function) /usr/share/src/php-4.3.2/ext/imap/php_imap.c: In function `zif_imap_renamemailbox': /usr/share/src/php-4.3.2/ext/imap/php_imap.c:1192: `T' undeclared (first use in this function) /usr/share/src/php-4.3.2/ext/imap/php_imap.c: In function `zif_imap_deletemailbox': /usr/share/src/php-4.3.2/ext/imap/php_imap.c:1215: `T' undeclared (first use in this function) /usr/share/src/php-4.3.2/ext/imap/php_imap.c: In function `zif_imap_subscribe': /usr/share/src/php-4.3.2/ext/imap/php_imap.c:1648: `T' undeclared (first use in this function) /usr/share/src/php-4.3.2/ext/imap/php_imap.c: In function `zif_imap_unsubscribe': /usr/share/src/php-4.3.2/ext/imap/php_imap.c:1671: `T' undeclared (first use in this function) *** Error code 1 make: Fatal error: Command failed for target `ext/imap/php_imap.lo' [2003-06-12 13:28:35] [EMAIL PROTECTED] I need the full *original* error, so remove your hack and recompile again. It works fine here. [2003-06-12 13:26:00] barryn at baptisthealth dot net My source no longer generates this error. Please read the full bug description. OBVIOUSLY the error was something to effect of: `T' undeclared (first use in this function) (Each undeclared identifier is reported only once for each function it appears in.) The line number in the source code was 1117 [2003-06-12 13:15:13] [EMAIL PROTECTED] Please add the full error message here. [2003-06-12 13:03:17] barryn at baptisthealth dot net Description: Compiling with these switches: ./configure --prefix=/opt/php --with-nsapi=/opt/netscape --with-oci8 --enable-dbase --enable-filepro --enable-ftp --enable-sysvsem --enable-sysvshm --with-zlib --with-jpeg-dir=/opt/sfw --with-png-dir=/opt/sfw --with-gdbm --with-gd --with-imap --with-mysql --enable-sigchild --enable-libgcc --with-cpdflib --with-flatfile on Solaris 8 resulted in T being undefined when compiling php_imap.c Imap version info: * Program: Interactive Mail Access Protocol 4rev1 (IMAP4R1) routines * * Author: Mark Crispin * Networks and Distributed Computing * Computing Communications * University of Washington * Administration Building, AG-44 *
#24043 [Bgs-Csd]: include()/require() not working properly with absolute URL
ID: 24043 User updated by: delmatto at genotec dot ch Reported By: delmatto at genotec dot ch -Status: Bogus +Status: Closed Bug Type: Scripting Engine problem Operating System: Debian GNU/Linux 3.0 / stable -PHP Version: 4.3.2 +PHP Version: 4.3.3-dev New Comment: As of PHP 4.3.3-dev snapshot June 13, 2003 07:30 GMT the problem as described above seems to be gone. Previous Comments: [2003-06-09 12:00:37] delmatto at genotec dot ch Well, actually not the answer I expected ;-) Since I really *need* to fix this, I'd appreciate some thoughts on how to find the source of this problem. If you say, it ain't a bug in PHP, then it's propably a local configuration issue (php.ini/apache.conf/etc) or a compiling issue (compiler version/libc/dev headers). what do you think about that? any ideas? [2003-06-09 08:15:58] [EMAIL PROTECTED] Both scripts work just fine. No bug. [2003-06-07 05:03:32] delmatto at genotec dot ch I am Sorry, I understood you wantet a working link to see the scripts in action... This is the code of the two test files I use: ---begin test.php--- ?PHP include(http://gic-web-lin-01.genotec.ch/php/gd/index.php;); ? ---end--- ---begin test2.php--- ?PHP include(http://support.genotec.ch/main.asp;); ? ---end--- [2003-06-07 04:52:43] [EMAIL PROTECTED] I asked for a SOURCE of a script that I can run myself. [2003-06-07 02:54:51] delmatto at genotec dot ch use the following for a server running php 4.3.1 (original config) http://212.80.185.102/test.php (- http://212.80.185.102/php/gd/index.php) http://212.80.185.102/test2.php (- http://support.genotec.ch/main.asp) here the error happens, no matter wether I include from the same server or from an external one as in the later case. now these for the server running 4.3.3-dev snapshot http://212.80.185.101/test.php (- http://212.80.185.101/php/gd/index.php) http://212.80.185.101/test2.php (- http://support.genotec.ch/main.asp) here comes a very strange behaviour as it sometimes works without this 'headers' and sometimes the page even stays blank, then I find the following in the error log: [Sat Jun 7 09:34:29 2003] [error] PHP Warning: main(http://gic-web-lin-01.genotec.ch/php/gd/index.php): failed to open stream: HTTP request failed! [EMAIL PROTECTED]@P_P #9227;[EMAIL PROTECTED]@T #9227;#9532; /#9524;#9618;#9148;/#9252;#9228;#9228;/#9252;#9500;#9229;#9146;#9228;#9149;/#9229;#9226;°#9618;#9508;#9484;#9500;/#9500;#9226;#9149;#9500;.#9147;#9252;#9147; #9146;#9532; #9484;#9227;#9532;#9226; 4 to reproduce just try to reload the page a few times. I'm not sure wether this header problem is gone now, though the error shown in the log was only introduced when using the new snapshot. It seems like it would only happen when including from the same server, not from an external one, as I couldn't reproduce it on the second url. PHP4 ist running as mod_php in Apache. There is no mod_php3. CGI is not specifically configured in apache, however I didn't use the '--disable-cgi' switch when building PHP, if anyone happens to rename a .php file to .cgi and adds a #!/usr/bin/php to the top of the file, it would run over cgi/suexec. Normal .php/php3/phtml files run through mod_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/24043 -- Edit this bug report at http://bugs.php.net/?id=24043edit=1
#24170 [NEW]: Configure fails because floorf doesn't exists
From: l_faillie at yahoo dot com
Operating system: HP-UX
PHP version: 4.3.2
PHP Bug Type: *Configuration Issues
Bug description: Configure fails because floorf doesn't exists
Description:
configure fails w/ following messages :
checking for floorf... no
configure: error: libjpeg.(a|so) not found.
I've checked error log and the faulty test is :
configure: failed program was:
#line 28040 configure
#include confdefs.h
/* System header to define __stub macros and hopefully few prototypes,
which can conflict with char floorf(); below. */
#include assert.h
/* Override any gcc2 internal prototype to avoid an error. */
/* We use char because int might match the return type of a gcc2
builtin and then its argument prototype would still apply. */
char floorf();
int main() {
/* The GNU C library defines this for functions which it implements
to always fail with ENOSYS. Some functions are actually named
something starting with __ and the normal name is an alias. */
#if defined (__stub_floorf) || defined (__stub___floorf)
choke me
#else
floorf();
#endif
; return 0; }
I made some checks and it seems floorf() doesn't exists at all on my HP-UX
boxes (10.20 and 11.00).
I think it's the same problem for bug #23322, #21924 and #21973
Bye
Laurent
--
Edit bug report at http://bugs.php.net/?id=24170edit=1
--
Try a CVS snapshot: http://bugs.php.net/fix.php?id=24170r=trysnapshot
Fixed in CVS: http://bugs.php.net/fix.php?id=24170r=fixedcvs
Fixed in release: http://bugs.php.net/fix.php?id=24170r=alreadyfixed
Need backtrace: http://bugs.php.net/fix.php?id=24170r=needtrace
Try newer version: http://bugs.php.net/fix.php?id=24170r=oldversion
Not developer issue:http://bugs.php.net/fix.php?id=24170r=support
Expected behavior: http://bugs.php.net/fix.php?id=24170r=notwrong
Not enough info:http://bugs.php.net/fix.php?id=24170r=notenoughinfo
Submitted twice:http://bugs.php.net/fix.php?id=24170r=submittedtwice
register_globals: http://bugs.php.net/fix.php?id=24170r=globals
PHP 3 support discontinued: http://bugs.php.net/fix.php?id=24170r=php3
Daylight Savings: http://bugs.php.net/fix.php?id=24170r=dst
IIS Stability: http://bugs.php.net/fix.php?id=24170r=isapi
Install GNU Sed:http://bugs.php.net/fix.php?id=24170r=gnused
#24146 [Opn]: Installer crash
ID: 24146 User updated by: gk at online dot dp dot ua Reported By: gk at online dot dp dot ua Status: Open Bug Type: Compile Failure Operating System: Red Hat Linux 7.3 PHP Version: 4.3.2 New Comment: I don't know why, but 'make install' works! Only what I did - reboot. First time I didn't have set SYBASE env, but I add it to /etc/profile and logout/login. Set |grep SYBASE returns SYBASE, but make install crash. After reboot it works... Previous Comments: [2003-06-12 10:20:16] gk at online dot dp dot ua Yes - LANG=en_US.iso885915, SYBASE=/opt/sybase-11.9.2 [2003-06-12 08:33:48] [EMAIL PROTECTED] Do you have SYBASE abd LANG environment variables set when running 'make install' ?? [2003-06-12 07:42:28] gk at online dot dp dot ua Starting program: /backup/INST/1/php-4.3.2/sapi/cli/php -n -dsafe_mode=0 pear/install-pear.php pear/package-*.xml Program received signal SIGSEGV, Segmentation fault. 0x4212dfd0 in main_arena () from /lib/i686/libc.so.6 (gdb) bt #0 0x4212dfd0 in main_arena () from /lib/i686/libc.so.6 #1 0x4205535f in buffered_vfprintf () from /lib/i686/libc.so.6 #2 0x42050437 in vfprintf () from /lib/i686/libc.so.6 #3 0x4205a297 in fprintf () from /lib/i686/libc.so.6 #4 0x40098ffe in com_perr () from /opt/sybase-11.9.2/lib/libcomn.so #5 0x4008ae1d in com_intl_verify_ctxloc () from /opt/sybase-11.9.2/lib/libcomn.so #6 0x4012c4ad in cs_ctx_alloc () from /opt/sybase-11.9.2/lib/libcs.so #7 0x080d52ba in php_sybase_init_globals (sybase_globals=0x81758c0) at /backup/INST/1/php-4.3.2/ext/sybase_ct/php_sybase_ct.c:312 #8 0x080d5496 in zm_startup_sybase (type=1, module_number=3) at /backup/INST/1/php-4.3.2/ext/sybase_ct/php_sybase_ct.c:372 #9 0x08122ebf in zend_startup_module (module=0x816c9e0) at /backup/INST/1/php-4.3.2/Zend/zend_API.c:1005 #10 0x080f901f in php_startup_extensions (ptr=0x81733d0, count=10) at /backup/INST/1/php-4.3.2/main/main.c:1033 #11 0x0813bc49 in php_startup_internal_extensions () at main/internal_functions_cli.c:69 #12 0x080f9469 in php_module_startup (sf=0x8173340, additional_modules=0x0, num_additional_modules=0) at /backup/INST/1/php-4.3.2/main/main.c:1200 #13 0x0813af09 in main (argc=7, argv=0xbfffe984) at /backup/INST/1/php-4.3.2/sapi/cli/php_cli.c:520 #14 0x42017589 in __libc_start_main () from /lib/i686/libc.so.6 [2003-06-12 07:30:48] [EMAIL PROTECTED] Thank you for this bug report. To properly diagnose the problem, we need a backtrace to see what is happening behind the scenes. To find out how to generate a backtrace, please read http://bugs.php.net/bugs-generating-backtrace.php Once you have generated a backtrace, please submit it to this bug report and change the status back to Open. Thank you for helping us make PHP better. Get the backtrace like this: # gdb sapi/cli/php (gdb) run -n -dsafe_mode=0 pear/install-pear.php pear/package-*.xml wait for crash.. (gdb) bt [2003-06-12 06:57:05] gk at online dot dp dot ua Description: After make install: ... Installing shared extensions: /usr/local/lib/php/extensions/no-debug-non-zts-20020429/ Installing PEAR environment: /usr/local/lib/php/ make[1]: *** [install-pear-installer] Segmentation fault make: *** [install-pear] Error 2 ./configure \ --with-apxs=/usr/local/apache/bin/apxs \ --with-sybase-ct=/opt/sybase-11.9.2 \ --enable-track-vars -- Edit this bug report at http://bugs.php.net/?id=24146edit=1
#24141 [Opn-Bgs]: Massive configure script failures when LDAP is linked against kerberos.
ID: 24141
Updated by: [EMAIL PROTECTED]
Reported By: robbat2 at gentoo dot org
-Status: Open
+Status: Bogus
Bug Type: Compile Failure
Operating System: Gentoo Linux
PHP Version: 4.3.2
New Comment:
As this was not PHP bug - bogus.
In future, there is going to be a sanity test in ldap configure part,
so this will get caught there already.
Previous Comments:
[2003-06-13 01:52:06] robbat2 at gentoo dot org
Hi Derick, a response.
As for the part of not finding the libkrb4.so.2, it turned out that the
user unmerged it without heed to that was linked against it.
However I still that that the configure script should have failed MUCH
earlier to make this failure easier to catch and not result in totally
erroroneus error messages.
[2003-06-12 03:01:25] [EMAIL PROTECTED]
Where is libkrb4.so.2 on your system, and is it in the paths
described in /etc/ld.so.conf ? And did you run ldconfig after
installing that ldap?
[2003-06-12 01:49:07] robbat2 at gentoo dot org
Description:
On a system that has OpenLDAP installed, and dynamically linked against
kerberos, the configure script starts massively failing after adding in
-lldap.
When that starts, it gives incorrect errors until it hits some check
that causes the configure script to bail out.
This results in a VERY incorrect error message being given by the
configure script.
This is similar to bug item #4133, but only a workaround was provided
for that bug, and not a proper fix.
I think in this case, putting the kerberos checks together with the
ldap stuff might solve the problem, but I'm not a configure guru.
Expected result:
Two things:
Firstly, there needs to be some form of checks against the libraries
that are added to the LIBS list so that the system catches ALL of the
extra libraries they are linked against.
Secondly, the configure script SHOULD fail sooner after errors, and
give more intelligable answers.
It should have failed right after the initial error that linking
against LDAP gave.
Actual result:
--
You can see the entire config.log file and more details at our
bugzilla: http://bugs.gentoo.org/show_bug.cgi?id=22635
snippet from config.log when it first fails:
CUT
configure:41615: gcc -o conftest -O2 -mcpu=i686 -pipe -L/usr/lib
conftest.c -lldap -llber -lcrypt -lpam -lxsltbreakpoint -lxml2 -lxslt
-lz -lndbm -lgdbm -lcurl -lcrack -lbz2 -lz -lssl -lcrypto -lresolv -lm
-ldl -lnsl -lcurl -lz -lssl -lcrypto -ldl -lz -lxml2 -lz -lm 15
/usr/lib/gcc-lib/i686-pc-linux-gnu/3.2.2/../../../../i686-pc-linux-gnu/bin/ld:
warning: libkrb4.so.2, needed by /usr/lib/libldap.so, not found (try
using -rpath or -rpath-link)
configure:41587: checking for ldap_start_tls_s
configure:41615: gcc -o conftest -O2 -mcpu=i686 -pipe -L/usr/lib
conftest.c -lldap -llber -lcrypt -lpam -lxsltbreakpoint -lxml2 -lxslt
-lz -lndbm -lgdbm -lcurl -lcrack -lbz2 -lz -lssl -lcrypto -lresolv -lm
-ldl -lnsl -lcurl -lz -lssl -lcrypto -ldl -lz -lxml2 -lz -lm 15
/usr/lib/gcc-lib/i686-pc-linux-gnu/3.2.2/../../../../i686-pc-linux-gnu/bin/ld:
warning: libkrb4.so.2, needed by /usr/lib/libldap.so, not found (try
using -rpath or -rpath-link)
configure:41645: checking whether to enable multibyte string support
CUT
Here is where it finally fails and gives up:
CUT
configure:75358: checking for Sablotron version
configure:75383: gcc -o conftest -O2 -mcpu=i686 -pipe -I/usr/include
-L/usr/lib conftest.c -lcrypt -lpspell -lpq -lpdf -lz -ltiff -lpng
-ljpeg -lmysqlclient -lmhash -lmcrypt -lltdl -lldap -llber -lcrypt
-lpam -lxsltbreakpoint -lxml2 -lxslt -lz -lndbm -lgdbm -lcurl -lcrack
-lbz2 -lz -lssl -lcrypto -lresolv -lm -ldl -lnsl -lcurl -lz -lssl
-lcrypto -ldl -lz -lxml2 -lz -lm -lodbc -lnetsnmp -lcrypto -lm -lcrypt
15
/usr/lib/gcc-lib/i686-pc-linux-gnu/3.2.2/../../../../i686-pc-linux-gnu/bin/ld:
warning: libkrb4.so.2, needed by /usr/lib/libldap.so, not found (try
using -rpath or -rpath-link)
configure: failed program was:
#line 75365 configure
#include confdefs.h
#include stdlib.h
#include sablot.h
int main ()
{
double version;
version = atof(SAB_VERSION);
if (version = 0.96) {
exit(0);
}
exit(255);
}
CUT
The error that the above failure throws. Totally incorrect about the
problem of course.
CUT
checking for Sablotron version... configure: error: Sablotron version
0.96 or
greater required.
CUT
--
Edit this bug report at http://bugs.php.net/?id=24141edit=1
#24170 [Opn]: Configure fails because floorf doesn't exists
ID: 24170
User updated by: l_faillie at yahoo dot com
Reported By: l_faillie at yahoo dot com
Status: Open
Bug Type: *Configuration Issues
Operating System: HP-UX
PHP Version: 4.3.2
New Comment:
I made some check : this function is only used in ext/gd/libgd/gd.c and
every thing is made to works even if floorf miss.
So, for me, it's a configure script bug : it fails whereas it has only
said 'floorf = no'.
Previous Comments:
[2003-06-13 05:30:43] l_faillie at yahoo dot com
Description:
configure fails w/ following messages :
checking for floorf... no
configure: error: libjpeg.(a|so) not found.
I've checked error log and the faulty test is :
configure: failed program was:
#line 28040 configure
#include confdefs.h
/* System header to define __stub macros and hopefully few prototypes,
which can conflict with char floorf(); below. */
#include assert.h
/* Override any gcc2 internal prototype to avoid an error. */
/* We use char because int might match the return type of a gcc2
builtin and then its argument prototype would still apply. */
char floorf();
int main() {
/* The GNU C library defines this for functions which it implements
to always fail with ENOSYS. Some functions are actually named
something starting with __ and the normal name is an alias. */
#if defined (__stub_floorf) || defined (__stub___floorf)
choke me
#else
floorf();
#endif
; return 0; }
I made some checks and it seems floorf() doesn't exists at all on my
HP-UX boxes (10.20 and 11.00).
I think it's the same problem for bug #23322, #21924 and #21973
Bye
Laurent
--
Edit this bug report at http://bugs.php.net/?id=24170edit=1
#24171 [NEW]: is_dir() always returns false on non-relative base directories
From: php at webfreezer dot com
Operating system: Windows XP
PHP version: 4.3.2
PHP Bug Type: Directory function related
Bug description: is_dir() always returns false on non-relative base directories
Description:
Hi,
this bug has been described before however everyone seemed to make a
mistake in the report.
Create this directory/file structure in the root of drive C:
- testDir
-- Directory01
-- Directory02
-- Directory03
-- file01.txt
-- file02.txt
-- file03.txt
Then start the script below.
The BUG occurs when using a non-relative directory, i.e. an ABSOULTE
path.
The documentation states Returns TRUE if the filename exists and is a
directory. If filename is a relative filename, it will be checked relative
to the current working directory.
It seems that a check is only performed in the current directory. If you
uncomment the chdir line everything works fine!
Please fix this reproducible bug!
(Apache 1.3.27, PHP 4.3.2)
Reproduce code:
---
$baseDir=c:/testDir;
function parseDir($baseDir)
{
[EMAIL PROTECTED]($baseDir);
if($handle)
{
while ($file = readdir ($handle))
{
if (is_dir($file))
{
echo $file. is a directory!br;
} else {
echo $file. is NOT a directory!br;
}
}
@closedir($handle);
}
}
//chdir(c:/testDir);
parseDir(c:/testDir);
Expected result:
. is a directory!
.. is a directory!
Directory01 is a directory!
Directory02 is a directory!
Directory03 is a directory!
file01.txt is NOT a directory!
file02.txt is NOT a directory!
file03.txt is NOT a directory!
Actual result:
--
. is a directory!
.. is a directory!
Directory01 is NOT a directory!
Directory02 is NOT a directory!
Directory03 is NOT a directory!
file01.txt is NOT a directory!
file02.txt is NOT a directory!
file03.txt is NOT a directory!
--
Edit bug report at http://bugs.php.net/?id=24171edit=1
--
Try a CVS snapshot: http://bugs.php.net/fix.php?id=24171r=trysnapshot
Fixed in CVS: http://bugs.php.net/fix.php?id=24171r=fixedcvs
Fixed in release: http://bugs.php.net/fix.php?id=24171r=alreadyfixed
Need backtrace: http://bugs.php.net/fix.php?id=24171r=needtrace
Try newer version: http://bugs.php.net/fix.php?id=24171r=oldversion
Not developer issue:http://bugs.php.net/fix.php?id=24171r=support
Expected behavior: http://bugs.php.net/fix.php?id=24171r=notwrong
Not enough info:http://bugs.php.net/fix.php?id=24171r=notenoughinfo
Submitted twice:http://bugs.php.net/fix.php?id=24171r=submittedtwice
register_globals: http://bugs.php.net/fix.php?id=24171r=globals
PHP 3 support discontinued: http://bugs.php.net/fix.php?id=24171r=php3
Daylight Savings: http://bugs.php.net/fix.php?id=24171r=dst
IIS Stability: http://bugs.php.net/fix.php?id=24171r=isapi
Install GNU Sed:http://bugs.php.net/fix.php?id=24171r=gnused
#24171 [Opn-Fbk]: is_dir() always returns false on non-relative base directories
ID: 24171
Updated by: [EMAIL PROTECTED]
Reported By: php at webfreezer dot com
-Status: Open
+Status: Feedback
Bug Type: Directory function related
Operating System: Windows XP
PHP Version: 4.3.2
New Comment:
while ($file = readdir ($handle)) {
if (is_dir($file))
This looks bogus... shouldn't you be testing:
is_dir($baseDir . DIRECTORY_SEPARATOR . $file)
instead?
Previous Comments:
[2003-06-13 07:14:06] php at webfreezer dot com
Description:
Hi,
this bug has been described before however everyone seemed to make a
mistake in the report.
Create this directory/file structure in the root of drive C:
- testDir
-- Directory01
-- Directory02
-- Directory03
-- file01.txt
-- file02.txt
-- file03.txt
Then start the script below.
The BUG occurs when using a non-relative directory, i.e. an ABSOULTE
path.
The documentation states Returns TRUE if the filename exists and is a
directory. If filename is a relative filename, it will be checked
relative to the current working directory.
It seems that a check is only performed in the current directory. If
you uncomment the chdir line everything works fine!
Please fix this reproducible bug!
(Apache 1.3.27, PHP 4.3.2)
Reproduce code:
---
$baseDir=c:/testDir;
function parseDir($baseDir)
{
[EMAIL PROTECTED]($baseDir);
if($handle)
{
while ($file = readdir ($handle))
{
if (is_dir($file))
{
echo $file. is a directory!br;
} else {
echo $file. is NOT a directory!br;
}
}
@closedir($handle);
}
}
//chdir(c:/testDir);
parseDir(c:/testDir);
Expected result:
. is a directory!
.. is a directory!
Directory01 is a directory!
Directory02 is a directory!
Directory03 is a directory!
file01.txt is NOT a directory!
file02.txt is NOT a directory!
file03.txt is NOT a directory!
Actual result:
--
. is a directory!
.. is a directory!
Directory01 is NOT a directory!
Directory02 is NOT a directory!
Directory03 is NOT a directory!
file01.txt is NOT a directory!
file02.txt is NOT a directory!
file03.txt is NOT a directory!
--
Edit this bug report at http://bugs.php.net/?id=24171edit=1
#24170 [Opn-Bgs]: Configure fails because floorf doesn't exists
ID: 24170
Updated by: [EMAIL PROTECTED]
Reported By: l_faillie at yahoo dot com
-Status: Open
+Status: Bogus
Bug Type: *Configuration Issues
Operating System: HP-UX
PHP Version: 4.3.2
New Comment:
Check for the LAST lines of the config.log, the real
reason why the configure fails is really mentioned there.
Missing floorf() does NOT make the test fail.
You didn't tell what your configure line was, so I assume it's wrong.
Not PHP bug - bogus.
Previous Comments:
[2003-06-13 06:54:22] l_faillie at yahoo dot com
I made some check : this function is only used in ext/gd/libgd/gd.c and
every thing is made to works even if floorf miss.
So, for me, it's a configure script bug : it fails whereas it has only
said 'floorf = no'.
[2003-06-13 05:30:43] l_faillie at yahoo dot com
Description:
configure fails w/ following messages :
checking for floorf... no
configure: error: libjpeg.(a|so) not found.
I've checked error log and the faulty test is :
configure: failed program was:
#line 28040 configure
#include confdefs.h
/* System header to define __stub macros and hopefully few prototypes,
which can conflict with char floorf(); below. */
#include assert.h
/* Override any gcc2 internal prototype to avoid an error. */
/* We use char because int might match the return type of a gcc2
builtin and then its argument prototype would still apply. */
char floorf();
int main() {
/* The GNU C library defines this for functions which it implements
to always fail with ENOSYS. Some functions are actually named
something starting with __ and the normal name is an alias. */
#if defined (__stub_floorf) || defined (__stub___floorf)
choke me
#else
floorf();
#endif
; return 0; }
I made some checks and it seems floorf() doesn't exists at all on my
HP-UX boxes (10.20 and 11.00).
I think it's the same problem for bug #23322, #21924 and #21973
Bye
Laurent
--
Edit this bug report at http://bugs.php.net/?id=24170edit=1
#24170 [Bgs]: Configure fails because floorf doesn't exists
ID: 24170
Updated by: [EMAIL PROTECTED]
Reported By: l_faillie at yahoo dot com
Status: Bogus
Bug Type: *Configuration Issues
Operating System: HP-UX
PHP Version: 4.3.2
New Comment:
Forget the config.log, the test failure is because libjpeg.so
or libjpeg.a was not found under the given path (?), /usr/lib or
/usr/local/lib
Previous Comments:
[2003-06-13 07:19:28] [EMAIL PROTECTED]
Check for the LAST lines of the config.log, the real
reason why the configure fails is really mentioned there.
Missing floorf() does NOT make the test fail.
You didn't tell what your configure line was, so I assume it's wrong.
Not PHP bug - bogus.
[2003-06-13 06:54:22] l_faillie at yahoo dot com
I made some check : this function is only used in ext/gd/libgd/gd.c and
every thing is made to works even if floorf miss.
So, for me, it's a configure script bug : it fails whereas it has only
said 'floorf = no'.
[2003-06-13 05:30:43] l_faillie at yahoo dot com
Description:
configure fails w/ following messages :
checking for floorf... no
configure: error: libjpeg.(a|so) not found.
I've checked error log and the faulty test is :
configure: failed program was:
#line 28040 configure
#include confdefs.h
/* System header to define __stub macros and hopefully few prototypes,
which can conflict with char floorf(); below. */
#include assert.h
/* Override any gcc2 internal prototype to avoid an error. */
/* We use char because int might match the return type of a gcc2
builtin and then its argument prototype would still apply. */
char floorf();
int main() {
/* The GNU C library defines this for functions which it implements
to always fail with ENOSYS. Some functions are actually named
something starting with __ and the normal name is an alias. */
#if defined (__stub_floorf) || defined (__stub___floorf)
choke me
#else
floorf();
#endif
; return 0; }
I made some checks and it seems floorf() doesn't exists at all on my
HP-UX boxes (10.20 and 11.00).
I think it's the same problem for bug #23322, #21924 and #21973
Bye
Laurent
--
Edit this bug report at http://bugs.php.net/?id=24170edit=1
#24171 [Fbk-Bgs]: is_dir() always returns false on non-relative base directories
ID: 24171
Updated by: [EMAIL PROTECTED]
Reported By: php at webfreezer dot com
-Status: Feedback
+Status: Bogus
Bug Type: Directory function related
Operating System: Windows XP
PHP Version: 4.3.2
New Comment:
It's just broken script. Not a bug.
Previous Comments:
[2003-06-13 07:17:53] [EMAIL PROTECTED]
while ($file = readdir ($handle)) {
if (is_dir($file))
This looks bogus... shouldn't you be testing:
is_dir($baseDir . DIRECTORY_SEPARATOR . $file)
instead?
[2003-06-13 07:14:06] php at webfreezer dot com
Description:
Hi,
this bug has been described before however everyone seemed to make a
mistake in the report.
Create this directory/file structure in the root of drive C:
- testDir
-- Directory01
-- Directory02
-- Directory03
-- file01.txt
-- file02.txt
-- file03.txt
Then start the script below.
The BUG occurs when using a non-relative directory, i.e. an ABSOULTE
path.
The documentation states Returns TRUE if the filename exists and is a
directory. If filename is a relative filename, it will be checked
relative to the current working directory.
It seems that a check is only performed in the current directory. If
you uncomment the chdir line everything works fine!
Please fix this reproducible bug!
(Apache 1.3.27, PHP 4.3.2)
Reproduce code:
---
$baseDir=c:/testDir;
function parseDir($baseDir)
{
[EMAIL PROTECTED]($baseDir);
if($handle)
{
while ($file = readdir ($handle))
{
if (is_dir($file))
{
echo $file. is a directory!br;
} else {
echo $file. is NOT a directory!br;
}
}
@closedir($handle);
}
}
//chdir(c:/testDir);
parseDir(c:/testDir);
Expected result:
. is a directory!
.. is a directory!
Directory01 is a directory!
Directory02 is a directory!
Directory03 is a directory!
file01.txt is NOT a directory!
file02.txt is NOT a directory!
file03.txt is NOT a directory!
Actual result:
--
. is a directory!
.. is a directory!
Directory01 is NOT a directory!
Directory02 is NOT a directory!
Directory03 is NOT a directory!
file01.txt is NOT a directory!
file02.txt is NOT a directory!
file03.txt is NOT a directory!
--
Edit this bug report at http://bugs.php.net/?id=24171edit=1
#24170 [Bgs]: Configure fails because floorf doesn't exists
ID: 24170
User updated by: l_faillie at yahoo dot com
Reported By: l_faillie at yahoo dot com
Status: Bogus
Bug Type: *Configuration Issues
Operating System: HP-UX
PHP Version: 4.3.2
New Comment:
Oups ... forget it : I made a STUPID mistake :-(
Sorry.
Previous Comments:
[2003-06-13 07:21:33] [EMAIL PROTECTED]
Forget the config.log, the test failure is because libjpeg.so
or libjpeg.a was not found under the given path (?), /usr/lib or
/usr/local/lib
[2003-06-13 07:19:28] [EMAIL PROTECTED]
Check for the LAST lines of the config.log, the real
reason why the configure fails is really mentioned there.
Missing floorf() does NOT make the test fail.
You didn't tell what your configure line was, so I assume it's wrong.
Not PHP bug - bogus.
[2003-06-13 06:54:22] l_faillie at yahoo dot com
I made some check : this function is only used in ext/gd/libgd/gd.c and
every thing is made to works even if floorf miss.
So, for me, it's a configure script bug : it fails whereas it has only
said 'floorf = no'.
[2003-06-13 05:30:43] l_faillie at yahoo dot com
Description:
configure fails w/ following messages :
checking for floorf... no
configure: error: libjpeg.(a|so) not found.
I've checked error log and the faulty test is :
configure: failed program was:
#line 28040 configure
#include confdefs.h
/* System header to define __stub macros and hopefully few prototypes,
which can conflict with char floorf(); below. */
#include assert.h
/* Override any gcc2 internal prototype to avoid an error. */
/* We use char because int might match the return type of a gcc2
builtin and then its argument prototype would still apply. */
char floorf();
int main() {
/* The GNU C library defines this for functions which it implements
to always fail with ENOSYS. Some functions are actually named
something starting with __ and the normal name is an alias. */
#if defined (__stub_floorf) || defined (__stub___floorf)
choke me
#else
floorf();
#endif
; return 0; }
I made some checks and it seems floorf() doesn't exists at all on my
HP-UX boxes (10.20 and 11.00).
I think it's the same problem for bug #23322, #21924 and #21973
Bye
Laurent
--
Edit this bug report at http://bugs.php.net/?id=24170edit=1
#24169 [Opn-Fbk]: session cookie being incorrectly sent
ID: 24169 Updated by: [EMAIL PROTECTED] Reported By: steveh at brendata dot co dot uk -Status: Open +Status: Feedback Bug Type: Session related Operating System: NT4 SP6a PHP Version: 4.3.2 New Comment: And what might be the relevant php.ini options..? (the ones with session. prefix) Previous Comments: [2003-06-13 03:51:15] steveh at brendata dot co dot uk Description: For session handling a cookie should be set as follows: session name=session id This was previously working, but since upgrading to 4.3.2 we now see cookies set as follows: session id=session id As a result sessions are not carried over and a new session is started for every access (i.e. no cookie called PHPSESSID or whatever is in the php.ini) Here's the relevant chunk of phpinfo output that demonstrates this. _SERVER[HTTP_COOKIE] CookieProductID=94; a9c7fa405401e831e6ada0ee31f67ea3=a9c7fa405401e831e6ada0ee31f67ea3; caec00776094cd5017fa35e41162333b=caec00776094cd5017fa35e41162333b; 139632a02257356caa27c86256afcb70=139632a02257356caa27c86256afcb70; 0ba5beadf45c35245e67c1f67ffc70dc=0ba5beadf45c35245e67c1f67ffc70dc; b7f2e2e4a196a620f318f16034a8192b=b7f2e2e4a196a620f318f16034a8192b; 6ca2b668932e46c85528d399fad50541=6ca2b668932e46c85528d399fad50541; 913a5a99fa54ccd33b610b3f882d132d=913a5a99fa54ccd33b610b3f882d132d; a7c7085d672b5e885476dabdc096ca9f=a7c7085d672b5e885476dabdc096ca9f; 04a257bf48fef943fb1d4ed508970140=04a257bf48fef943fb1d4ed508970140; d269823ce913782241613e3791935d11=d269823ce913782241613e3791935d11; edc78b150437138fb1d14915a97dee87=edc78b150437138fb1d14915a97dee87; 50212bca7b517a57521305d72a6c43c9=50212bca7b517a57521305d72a6c43c9; 68c37f0103351348dd1e705847e2f6d3=68c37f0103351348dd1e705847e2f6d3; 78d96155c83ee77e3fc3b69731b428a4=78d96155c83ee77e3fc3b69731b428a4; e7b52247b003b85c04d942721879206a=e7b52247b003b85c04d942721879206a; f3d20ebc7068137eaa7b3461eab64d62=f3d20ebc7068137eaa7b3461eab64d62; c3940ed02170d481105849b74b6d3cb8=c3940ed02170d481105849b74b6d3cb8; e8109d59aca1442f4cd7fa5358410c30=e8109d59aca1442f4cd7fa5358410c30; 2a0f643e85d2b21003958bb47c2a2d4d=2a0f643e85d2b21003958bb47c2a2d4d Reproduce code: --- ?php session_start(); $_SESSION[FRED]=1; echo session_id(); phpinfo(); ? Expected result: The same session id for each open, and PHPSESSID seen as a cookie in the headers. Actual result: -- Different session id's each time, and a growing list of session id=session id cookies. -- Edit this bug report at http://bugs.php.net/?id=24169edit=1
#24169 [Fbk-Opn]: session cookie being incorrectly sent
ID: 24169 User updated by: steveh at brendata dot co dot uk Reported By: steveh at brendata dot co dot uk -Status: Feedback +Status: Open Bug Type: Session related Operating System: NT4 SP6a PHP Version: 4.3.2 New Comment: Here they are. Files do get created in the php\sessiondata directory, this worked fine with 4.3.1 (and the same php.ini file), it has stopped since upgrading to 4.3.2. Directive Local Value Master Value session.auto_start Off Off session.bug_compat_42 Off Off session.bug_compat_warn Off Off session.cache_expire 180 180 session.cache_limiter nocache nocache session.cookie_domain no value no value session.cookie_lifetime 0 0 session.cookie_path / / session.cookie_secure Off Off session.entropy_file no value no value session.entropy_length 0 0 session.gc_divisor 100 100 session.gc_maxlifetime 1440 1440 session.gc_probability 1 1 session.name PHPSESSID PHPSESSID session.referer_check no value no value session.save_handler files files session.save_path C:\PHP\sessiondata C:\PHP\sessiondata session.serialize_handler php php session.use_cookies On On session.use_only_cookies Off Off session.use_trans_sid Off Off Previous Comments: [2003-06-13 07:28:05] [EMAIL PROTECTED] And what might be the relevant php.ini options..? (the ones with session. prefix) [2003-06-13 03:51:15] steveh at brendata dot co dot uk Description: For session handling a cookie should be set as follows: session name=session id This was previously working, but since upgrading to 4.3.2 we now see cookies set as follows: session id=session id As a result sessions are not carried over and a new session is started for every access (i.e. no cookie called PHPSESSID or whatever is in the php.ini) Here's the relevant chunk of phpinfo output that demonstrates this. _SERVER[HTTP_COOKIE] CookieProductID=94; a9c7fa405401e831e6ada0ee31f67ea3=a9c7fa405401e831e6ada0ee31f67ea3; caec00776094cd5017fa35e41162333b=caec00776094cd5017fa35e41162333b; 139632a02257356caa27c86256afcb70=139632a02257356caa27c86256afcb70; 0ba5beadf45c35245e67c1f67ffc70dc=0ba5beadf45c35245e67c1f67ffc70dc; b7f2e2e4a196a620f318f16034a8192b=b7f2e2e4a196a620f318f16034a8192b; 6ca2b668932e46c85528d399fad50541=6ca2b668932e46c85528d399fad50541; 913a5a99fa54ccd33b610b3f882d132d=913a5a99fa54ccd33b610b3f882d132d; a7c7085d672b5e885476dabdc096ca9f=a7c7085d672b5e885476dabdc096ca9f; 04a257bf48fef943fb1d4ed508970140=04a257bf48fef943fb1d4ed508970140; d269823ce913782241613e3791935d11=d269823ce913782241613e3791935d11; edc78b150437138fb1d14915a97dee87=edc78b150437138fb1d14915a97dee87; 50212bca7b517a57521305d72a6c43c9=50212bca7b517a57521305d72a6c43c9; 68c37f0103351348dd1e705847e2f6d3=68c37f0103351348dd1e705847e2f6d3; 78d96155c83ee77e3fc3b69731b428a4=78d96155c83ee77e3fc3b69731b428a4; e7b52247b003b85c04d942721879206a=e7b52247b003b85c04d942721879206a; f3d20ebc7068137eaa7b3461eab64d62=f3d20ebc7068137eaa7b3461eab64d62; c3940ed02170d481105849b74b6d3cb8=c3940ed02170d481105849b74b6d3cb8; e8109d59aca1442f4cd7fa5358410c30=e8109d59aca1442f4cd7fa5358410c30; 2a0f643e85d2b21003958bb47c2a2d4d=2a0f643e85d2b21003958bb47c2a2d4d Reproduce code: --- ?php session_start(); $_SESSION[FRED]=1; echo session_id(); phpinfo(); ? Expected result: The same session id for each open, and PHPSESSID seen as a cookie in the headers. Actual result: -- Different session id's each time, and a growing list of session id=session id cookies. -- Edit this bug report at http://bugs.php.net/?id=24169edit=1
#24168 [Opn-Fbk]: XSL functions 'forget' current node position after absolute path argument
ID: 24168 Updated by: [EMAIL PROTECTED] Reported By: christian dot hang at web dot de -Status: Open +Status: Feedback Bug Type: DOM XML related Operating System: Linux (Debian woody) PHP Version: 4.3.2 New Comment: Did you happen to change the libxslt/libxml versions the same time..? You're not using the latest of them. Previous Comments: [2003-06-13 03:39:38] christian dot hang at web dot de Description: After an upgrade (from 4.3.0 to 4.3.2), some of the XSL transformation (handled by domxml) where not working correctly anymore. It seems, that XSL functions (like concat) forget the current node, that they should use to evualate relative XPath-Expression in their arguments, when an absolute Path is given in a prior argument. The example code demonstrates that behavior (compare description of Expected result and Actual result). A quick workaround is the addition of the current()-function in the relative path expressions, as that will fix the problem. But as far as I know, that is not required by the standard. If one switches the two arguments (concat(@nr, //testnode/@test)), everything works fine, the current() is not necessary and @nr is evaluated correctly. As the order of the arguments has an effect on the path evaluation (which it should not), I figure that there is problem. The versions of the libraries used: DOM/XML API Version 20020815 libxml Version 20419 HTML Support enabled XPath Support enabled XPointer Support enabled DOM/XSLT enabled libxslt Version 1.0.20 libxslt compiled against libxml Version 2.4.24 DOM/EXSLT enabled libexslt Version 1.0.20 I have to admit that I cannot compare the library versions used here with the ones I used for 4.3.0 version where everything worked okay (system crashed - long and ugly story), so it might very well be a problem of the libraries instead of the domxml extenstion. Reproduce code: --- $xml = ?xml version=\1.0\ ?roottestnode test=\somevalue\node nr=\1\/node nr=\2\/node nr=\3\//testnode/roo\ t; $xml_doc = domxml_open_mem($xml); $xsl_text=?xml version=\1.0\ ? xsl:stylesheet xmlns:xsl=\http://www.w3.org/1999/XSL/Transform\; version=\1.0\ xsl:output method=\xml\/ xsl:template match=\root\ new_root xsl:for-each select=\testnode/node\ xsl:value-of select=\concat(//testnode/@test, @nr)\/ - /xsl:for-each /new_root /xsl:template /xsl:stylesheet; $xsl = domxml_open_mem($xsl_text); $xsl_doc = domxml_xslt_stylesheet_doc($xsl); $res = $xsl_doc-process($xml_doc); Expected result: A dump of the $res result tree should produce the following ?xml version=1.0? new_rootsomevalue1 - somevalue2 - somevalue3 - /new_root and it does, if the concat expression in the example script is changed to concat(//testnode/@test, current()/@nr) Actual result: -- A dump of the $res result tree does produce the following ?xml version=1.0? new_rootsomevalue - somevalue - somevalue - /new_root The nr-attribute value is not concatenated to the value of the test-attribute in testnode. -- Edit this bug report at http://bugs.php.net/?id=24168edit=1
#24169 [Opn-Fbk]: session cookie being incorrectly sent
ID: 24169 Updated by: [EMAIL PROTECTED] Reported By: steveh at brendata dot co dot uk -Status: Open +Status: Feedback Bug Type: Session related Operating System: NT4 SP6a PHP Version: 4.3.2 New Comment: What webserver are you using? And which SAPI module? Does this happen with any browser? Previous Comments: [2003-06-13 07:35:44] steveh at brendata dot co dot uk Here they are. Files do get created in the php\sessiondata directory, this worked fine with 4.3.1 (and the same php.ini file), it has stopped since upgrading to 4.3.2. Directive Local Value Master Value session.auto_start Off Off session.bug_compat_42 Off Off session.bug_compat_warn Off Off session.cache_expire 180 180 session.cache_limiter nocache nocache session.cookie_domain no value no value session.cookie_lifetime 0 0 session.cookie_path / / session.cookie_secure Off Off session.entropy_file no value no value session.entropy_length 0 0 session.gc_divisor 100 100 session.gc_maxlifetime 1440 1440 session.gc_probability 1 1 session.name PHPSESSID PHPSESSID session.referer_check no value no value session.save_handler files files session.save_path C:\PHP\sessiondata C:\PHP\sessiondata session.serialize_handler php php session.use_cookies On On session.use_only_cookies Off Off session.use_trans_sid Off Off [2003-06-13 07:28:05] [EMAIL PROTECTED] And what might be the relevant php.ini options..? (the ones with session. prefix) [2003-06-13 03:51:15] steveh at brendata dot co dot uk Description: For session handling a cookie should be set as follows: session name=session id This was previously working, but since upgrading to 4.3.2 we now see cookies set as follows: session id=session id As a result sessions are not carried over and a new session is started for every access (i.e. no cookie called PHPSESSID or whatever is in the php.ini) Here's the relevant chunk of phpinfo output that demonstrates this. _SERVER[HTTP_COOKIE] CookieProductID=94; a9c7fa405401e831e6ada0ee31f67ea3=a9c7fa405401e831e6ada0ee31f67ea3; caec00776094cd5017fa35e41162333b=caec00776094cd5017fa35e41162333b; 139632a02257356caa27c86256afcb70=139632a02257356caa27c86256afcb70; 0ba5beadf45c35245e67c1f67ffc70dc=0ba5beadf45c35245e67c1f67ffc70dc; b7f2e2e4a196a620f318f16034a8192b=b7f2e2e4a196a620f318f16034a8192b; 6ca2b668932e46c85528d399fad50541=6ca2b668932e46c85528d399fad50541; 913a5a99fa54ccd33b610b3f882d132d=913a5a99fa54ccd33b610b3f882d132d; a7c7085d672b5e885476dabdc096ca9f=a7c7085d672b5e885476dabdc096ca9f; 04a257bf48fef943fb1d4ed508970140=04a257bf48fef943fb1d4ed508970140; d269823ce913782241613e3791935d11=d269823ce913782241613e3791935d11; edc78b150437138fb1d14915a97dee87=edc78b150437138fb1d14915a97dee87; 50212bca7b517a57521305d72a6c43c9=50212bca7b517a57521305d72a6c43c9; 68c37f0103351348dd1e705847e2f6d3=68c37f0103351348dd1e705847e2f6d3; 78d96155c83ee77e3fc3b69731b428a4=78d96155c83ee77e3fc3b69731b428a4; e7b52247b003b85c04d942721879206a=e7b52247b003b85c04d942721879206a; f3d20ebc7068137eaa7b3461eab64d62=f3d20ebc7068137eaa7b3461eab64d62; c3940ed02170d481105849b74b6d3cb8=c3940ed02170d481105849b74b6d3cb8; e8109d59aca1442f4cd7fa5358410c30=e8109d59aca1442f4cd7fa5358410c30; 2a0f643e85d2b21003958bb47c2a2d4d=2a0f643e85d2b21003958bb47c2a2d4d Reproduce code: --- ?php session_start(); $_SESSION[FRED]=1; echo session_id(); phpinfo(); ? Expected result: The same session id for each open, and PHPSESSID seen as a cookie in the headers. Actual result: -- Different session id's each time, and a growing list of session id=session id cookies. -- Edit this bug report at http://bugs.php.net/?id=24169edit=1
#24169 [Fbk-Opn]: session cookie being incorrectly sent
ID: 24169 User updated by: steveh at brendata dot co dot uk Reported By: steveh at brendata dot co dot uk -Status: Feedback +Status: Open Bug Type: Session related Operating System: NT4 SP6a PHP Version: 4.3.2 New Comment: This is with IIS4 and it's an issue in all versions of Internet explorer we have at hand, including 6.0.2800 (XP SP2) using php4isapi.dll ( Previous Comments: [2003-06-13 07:45:01] [EMAIL PROTECTED] What webserver are you using? And which SAPI module? Does this happen with any browser? [2003-06-13 07:35:44] steveh at brendata dot co dot uk Here they are. Files do get created in the php\sessiondata directory, this worked fine with 4.3.1 (and the same php.ini file), it has stopped since upgrading to 4.3.2. Directive Local Value Master Value session.auto_start Off Off session.bug_compat_42 Off Off session.bug_compat_warn Off Off session.cache_expire 180 180 session.cache_limiter nocache nocache session.cookie_domain no value no value session.cookie_lifetime 0 0 session.cookie_path / / session.cookie_secure Off Off session.entropy_file no value no value session.entropy_length 0 0 session.gc_divisor 100 100 session.gc_maxlifetime 1440 1440 session.gc_probability 1 1 session.name PHPSESSID PHPSESSID session.referer_check no value no value session.save_handler files files session.save_path C:\PHP\sessiondata C:\PHP\sessiondata session.serialize_handler php php session.use_cookies On On session.use_only_cookies Off Off session.use_trans_sid Off Off [2003-06-13 07:28:05] [EMAIL PROTECTED] And what might be the relevant php.ini options..? (the ones with session. prefix) [2003-06-13 03:51:15] steveh at brendata dot co dot uk Description: For session handling a cookie should be set as follows: session name=session id This was previously working, but since upgrading to 4.3.2 we now see cookies set as follows: session id=session id As a result sessions are not carried over and a new session is started for every access (i.e. no cookie called PHPSESSID or whatever is in the php.ini) Here's the relevant chunk of phpinfo output that demonstrates this. _SERVER[HTTP_COOKIE] CookieProductID=94; a9c7fa405401e831e6ada0ee31f67ea3=a9c7fa405401e831e6ada0ee31f67ea3; caec00776094cd5017fa35e41162333b=caec00776094cd5017fa35e41162333b; 139632a02257356caa27c86256afcb70=139632a02257356caa27c86256afcb70; 0ba5beadf45c35245e67c1f67ffc70dc=0ba5beadf45c35245e67c1f67ffc70dc; b7f2e2e4a196a620f318f16034a8192b=b7f2e2e4a196a620f318f16034a8192b; 6ca2b668932e46c85528d399fad50541=6ca2b668932e46c85528d399fad50541; 913a5a99fa54ccd33b610b3f882d132d=913a5a99fa54ccd33b610b3f882d132d; a7c7085d672b5e885476dabdc096ca9f=a7c7085d672b5e885476dabdc096ca9f; 04a257bf48fef943fb1d4ed508970140=04a257bf48fef943fb1d4ed508970140; d269823ce913782241613e3791935d11=d269823ce913782241613e3791935d11; edc78b150437138fb1d14915a97dee87=edc78b150437138fb1d14915a97dee87; 50212bca7b517a57521305d72a6c43c9=50212bca7b517a57521305d72a6c43c9; 68c37f0103351348dd1e705847e2f6d3=68c37f0103351348dd1e705847e2f6d3; 78d96155c83ee77e3fc3b69731b428a4=78d96155c83ee77e3fc3b69731b428a4; e7b52247b003b85c04d942721879206a=e7b52247b003b85c04d942721879206a; f3d20ebc7068137eaa7b3461eab64d62=f3d20ebc7068137eaa7b3461eab64d62; c3940ed02170d481105849b74b6d3cb8=c3940ed02170d481105849b74b6d3cb8; e8109d59aca1442f4cd7fa5358410c30=e8109d59aca1442f4cd7fa5358410c30; 2a0f643e85d2b21003958bb47c2a2d4d=2a0f643e85d2b21003958bb47c2a2d4d Reproduce code: --- ?php session_start(); $_SESSION[FRED]=1; echo session_id(); phpinfo(); ? Expected result: The same session id for each open, and PHPSESSID seen as a cookie in the headers. Actual result: -- Different session id's each time, and a growing list of session id=session id cookies. -- Edit this bug report at http://bugs.php.net/?id=24169edit=1
#24161 [Asn]: imap_open will not timeout
ID: 24161
Updated by: [EMAIL PROTECTED]
Reported By: thomas at xenocast dot com
Status: Assigned
Bug Type: IMAP related
Operating System: Windows 2000
PHP Version: 4.3.2
Assigned To: iliaa
New Comment:
For Ilia:
Maybe we should try introducing 'imap_parameters()' function.
(wrapper for mail_parameters()). And allow people set those low-level
parameters in the script.
Previous Comments:
[2003-06-13 07:47:56] [EMAIL PROTECTED]
Then assign it for real, Ilia. :)
[2003-06-12 17:50:36] [EMAIL PROTECTED]
assigning to self.
[2003-06-12 16:39:55] [EMAIL PROTECTED]
About 500 ppl, but I doubt they saw it before you changed it.
[2003-06-12 16:35:30] thomas at xenocast dot com
Damn, umn.. I had trouble with the submission form and
some funky thing with my browser. I didn't change the
values of the user/pass and domain in my script. Now
how many people got it?! Well, I changed my password.
please don't hack me.
[2003-06-12 16:30:44] thomas at xenocast dot com
Description:
This is a difficult situation to reproduce. I will try
to give you the history. We are running iMail 7.x and
the back-end is through an SQL server. there is a bug
in iMail that if the SQL Server for any reason is
'lost' then POP3 will just hang and not attempt to
reconnect. The only way around it is to restart the
service. This doesn't happen often on our system and
it's quite random, but when it happens nobody can get
their e-mail. The solution I came up with is a script
(referenced below) to check on if I can login to POP3.
If I cannot, restart the service.
The problem arises when this situation happens with
iMail, the imap_open command simply hangs there. It is
waiting for a response from the server after giving the
username and/or password. and nothing comes. It hangs
just like the e-mail clients do, howevver imap_open
FAILS to timeout. At last count the longest the script
hung there without going anywhere was 30 minutes. and I
do not even have set a script time-out so in the least
the script should have failed itself due to running too
long. the function is just sitting there waiting for a
response from the server.
Perhaps there's another way to do this or perhaps there
is a bug in imap_open that doesn't provide for the
thing to timeout or something, wdyt?
Reproduce code:
---
$mbox = imap_open({mail.neweve.com:110/pop3/notls}INBOX, thomas,
theduke);
if (!$mbox) {
system(net stop pop3d32);
system(net start pop3d32);
}
Expected result:
Expected is that imap_open would fail with a timeout or
something and $mbox would be false so my system would
restart.
Actual result:
--
Actual result is that imap_open sits there and does
nothing it never stops the script just hangs
indefinitely. When adding echo statements as debug
code I see it never passes that line.
--
Edit this bug report at http://bugs.php.net/?id=24161edit=1
#19778 [Com]: Provide a way to remove http headers - like f.x. header(Pragma:)
ID: 19778 Comment by: Xuefer at 21cn dot com Reported By: php at savignano dot de Status: Open Bug Type: Feature/Change Request Operating System: any PHP Version: 4.2.1 New Comment: by the way php document never said: headers get sent as soon they are encountered and it seems different for each sapi module it's better for php to buffer all response headers until give it to sapi and use: header_flush(); to flush headers, but keep header_sent() false, which meaning header is not ended yet header_flush is only used to ping client to see if connection lost, before output any content. u may say, i can buffer it in script using array, but this is not able to manage php's internal headers Previous Comments: [2003-06-13 08:06:41] Xuefer at 21cn dot com in php manual: The optional replace parameter indicates whether the header should replace a previous similar header, or add a second header of the same type. By default it will replace, but if you pass in FALSE as the second argument you can force multiple headers of the same type so it can replace header, is should be able to unset header header() is to low level better to implement these functions: header_set($name, $value [, response_code]) // replace or set new one header_add($name, $value) // append new one header_unset($name, [, $count]) // remove all, or N these functions will work, until header_sent(), after which will get warnning. it's just like operating on an array/table (but allow dup key) [2002-11-11 15:02:22] php at savignano dot de If you can imodify/i headers using the header() function, they can't be sent already, can they? At least with some types of headers, this works. So I assume that headers are buffered at least until the document output has begun. [2002-11-10 18:41:54] [EMAIL PROTECTED] Blind shot - this is impossible because headers get sent as soon I they are encountered and thus you can override them by sending one more yet cannot remove what you have already sent. I might be wrong, though. If I'm not then lots close this one. [2002-10-06 08:29:27] php at savignano dot de Sometimes it would be very handy to be able to remove a http header that has already been set (for example, by the session module). Even though header() allows me to replace a header, there is no way to completely remove it. Proposal: header(Pragma:) could be used to remove a Pragma header - i.e. a header given with no parms would remove the header. Better: New function like remove_header() -- Edit this bug report at http://bugs.php.net/?id=19778edit=1
#24173 [NEW]: ability and get dup headers
From: Xuefer at 21cn dot com Operating system: all PHP version: 4.3.2 PHP Bug Type: Feature/Change Request Bug description: ability and get dup headers Description: current apache_response_headers() is not able to return multi headers, e.g.: 2 Set-Cookie, only 1 returned, because it return array, which store only unique key so i suggest that, add apache_response_headers(true) to return array like this: array( 0= Content-Type: .., 1= Set-Cookie: ..., 2= Set-Cookie: ..., 3= Set-Cookie: ..., ); -- Edit bug report at http://bugs.php.net/?id=24173edit=1 -- Try a CVS snapshot: http://bugs.php.net/fix.php?id=24173r=trysnapshot Fixed in CVS: http://bugs.php.net/fix.php?id=24173r=fixedcvs Fixed in release: http://bugs.php.net/fix.php?id=24173r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=24173r=needtrace Try newer version: http://bugs.php.net/fix.php?id=24173r=oldversion Not developer issue:http://bugs.php.net/fix.php?id=24173r=support Expected behavior: http://bugs.php.net/fix.php?id=24173r=notwrong Not enough info:http://bugs.php.net/fix.php?id=24173r=notenoughinfo Submitted twice:http://bugs.php.net/fix.php?id=24173r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=24173r=globals PHP 3 support discontinued: http://bugs.php.net/fix.php?id=24173r=php3 Daylight Savings: http://bugs.php.net/fix.php?id=24173r=dst IIS Stability: http://bugs.php.net/fix.php?id=24173r=isapi Install GNU Sed:http://bugs.php.net/fix.php?id=24173r=gnused
#24146 [Opn-Bgs]: Installer crash
ID: 24146 Updated by: [EMAIL PROTECTED] Reported By: gk at online dot dp dot ua -Status: Open +Status: Bogus Bug Type: Compile Failure Operating System: Red Hat Linux 7.3 PHP Version: 4.3.2 New Comment: Not PHP bug. (the crash happens inside the sybase libs, not much we can do about that) Previous Comments: [2003-06-13 05:48:03] gk at online dot dp dot ua I don't know why, but 'make install' works! Only what I did - reboot. First time I didn't have set SYBASE env, but I add it to /etc/profile and logout/login. Set |grep SYBASE returns SYBASE, but make install crash. After reboot it works... [2003-06-12 10:20:16] gk at online dot dp dot ua Yes - LANG=en_US.iso885915, SYBASE=/opt/sybase-11.9.2 [2003-06-12 08:33:48] [EMAIL PROTECTED] Do you have SYBASE abd LANG environment variables set when running 'make install' ?? [2003-06-12 07:42:28] gk at online dot dp dot ua Starting program: /backup/INST/1/php-4.3.2/sapi/cli/php -n -dsafe_mode=0 pear/install-pear.php pear/package-*.xml Program received signal SIGSEGV, Segmentation fault. 0x4212dfd0 in main_arena () from /lib/i686/libc.so.6 (gdb) bt #0 0x4212dfd0 in main_arena () from /lib/i686/libc.so.6 #1 0x4205535f in buffered_vfprintf () from /lib/i686/libc.so.6 #2 0x42050437 in vfprintf () from /lib/i686/libc.so.6 #3 0x4205a297 in fprintf () from /lib/i686/libc.so.6 #4 0x40098ffe in com_perr () from /opt/sybase-11.9.2/lib/libcomn.so #5 0x4008ae1d in com_intl_verify_ctxloc () from /opt/sybase-11.9.2/lib/libcomn.so #6 0x4012c4ad in cs_ctx_alloc () from /opt/sybase-11.9.2/lib/libcs.so #7 0x080d52ba in php_sybase_init_globals (sybase_globals=0x81758c0) at /backup/INST/1/php-4.3.2/ext/sybase_ct/php_sybase_ct.c:312 #8 0x080d5496 in zm_startup_sybase (type=1, module_number=3) at /backup/INST/1/php-4.3.2/ext/sybase_ct/php_sybase_ct.c:372 #9 0x08122ebf in zend_startup_module (module=0x816c9e0) at /backup/INST/1/php-4.3.2/Zend/zend_API.c:1005 #10 0x080f901f in php_startup_extensions (ptr=0x81733d0, count=10) at /backup/INST/1/php-4.3.2/main/main.c:1033 #11 0x0813bc49 in php_startup_internal_extensions () at main/internal_functions_cli.c:69 #12 0x080f9469 in php_module_startup (sf=0x8173340, additional_modules=0x0, num_additional_modules=0) at /backup/INST/1/php-4.3.2/main/main.c:1200 #13 0x0813af09 in main (argc=7, argv=0xbfffe984) at /backup/INST/1/php-4.3.2/sapi/cli/php_cli.c:520 #14 0x42017589 in __libc_start_main () from /lib/i686/libc.so.6 [2003-06-12 07:30:48] [EMAIL PROTECTED] Thank you for this bug report. To properly diagnose the problem, we need a backtrace to see what is happening behind the scenes. To find out how to generate a backtrace, please read http://bugs.php.net/bugs-generating-backtrace.php Once you have generated a backtrace, please submit it to this bug report and change the status back to Open. Thank you for helping us make PHP better. Get the backtrace like this: # gdb sapi/cli/php (gdb) run -n -dsafe_mode=0 pear/install-pear.php pear/package-*.xml wait for crash.. (gdb) bt 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/24146 -- Edit this bug report at http://bugs.php.net/?id=24146edit=1
#24160 [Opn-Bgs]: 4.3.2 Windows Problem BUG CGI CALL
ID: 24160 Updated by: [EMAIL PROTECTED] Reported By: albersag at terra dot es -Status: Open +Status: Bogus Bug Type: *Configuration Issues Operating System: WIN XP PHP Version: 4.3.2 New Comment: Yes, it's configuration issue. But not a bug in PHP. Ask support questions on the appropriate mailing lists, thank you. Previous Comments: [2003-06-12 15:42:41] albersag at terra dot es Description: I have installed php 4.3.2 as a cgi for abyss web server. http://www.aprelium.com . And i get a not imput file specified when calling a index.php file for example , but 4.3.1 works correctly without changing anything. I think is a bug of this version Reproduce code: --- No input file specified. on screen Expected result: When 4.3.1 it works and... i get phpinfo() correctly -- Edit this bug report at http://bugs.php.net/?id=24160edit=1
#24084 [Opn-Csd]: Patch: allow PHP to bind to an LDAP server using SASL
ID: 24084 Updated by: [EMAIL PROTECTED] Reported By: peter_c60 at hotmail dot com -Status: Open +Status: Closed Bug Type: LDAP related Operating System: Linux PHP Version: 4.3.2 New Comment: Should be fixed now. (Your config.m4 patch was not very good, the ldap libs can be static too, so ldd wouldn't work very well. :) Previous Comments: [2003-06-09 18:42:04] peter_c60 at hotmail dot com I have managed to compile and test the new patch and it works AFAICT. [2003-06-09 13:22:04] peter_c60 at hotmail dot com It looks like the patch checked into CVS is wrong, at least from an autoconf point of view. The problem is that the function ldap_sasl_interactive_bind_s is always defined whether SASL was enabled at time of compilation or not. Also the sasl.h header is required because the interactive function requires some of its defines. I've made some new patches that check that the LDAP library was linked against libsasl(2) (using ldd, I'm not sure if this is the correct method on all platforms) and also checks for the headers. I haven't tested it myself because I keep on getting a libtool error at time of compile (but that's a story for another bug report) but it seems to work correctly up to the configure stage. Anyway here are the patches (to be applied to the current CVS version): http://www.geocities.com/ldappatch/config2.txt (apply to config.m4) http://www.geocities.com/ldappatch/ldap2.txt (apply to ldap.c) http://www.geocities.com/ldappatch/php_ldap2.txt (apply to php_ldap.h) [2003-06-08 18:44:26] [EMAIL PROTECTED] Patch committed to CVS. (in php5/) [2003-06-08 16:19:32] [EMAIL PROTECTED] The problem with this patch is that it never checks if SASL support is enabled in your LDAP library. I think you will need to check for this with config.m4 and add some ifdef's to the code accordingly, unless *every* LDAP library comes with SASL support of course. [2003-06-08 16:15:51] peter_c60 at hotmail dot com OK then: http://www.geocities.com/ldappatch/ldap.txt http://www.geocities.com/ldappatch/php_ldap.txt 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/24084 -- Edit this bug report at http://bugs.php.net/?id=24084edit=1
#24174 [NEW]: Seg. fault when calling imagecreatefromstring
From: legion at altlinux dot org
Operating system: ALTLinux
PHP version: 4.3.2
PHP Bug Type: GD related
Bug description: Seg. fault when calling imagecreatefromstring
Description:
Script segfaults when calling function imagecreatefromstring() with
built-in font.
PHP version: 4.3.2 (cvs snapshot 20030609)
GD version: 2.0.4
Reproduce code:
---
$tmpfilename = tempnam (/tmp, FOO);
$im = imagecreate(200, 100);
$black = imagecolorallocate ($im, 0, 0, 0);
$orange = imagecolorallocate($im, 220, 210, 60);
imagefill($im, 0, 0, $black);
$string = '::: Oops! :::';
imagestring($im, 3, 0, 10, $string, $orange);
imagejpeg($im, $tmpfilename);
imagedestroy($im);
$fp = fopen($tmpfilename, 'r');
while (!feof ($fp)) { $content .= fgets($fp, 4096); }
fclose($fp);
$img = imagecreatefromstring($content);
// following function will be work
// $img = imagecreatefromjpeg($tmpfilename);
header (Content-type: image/jpeg);
imagejpeg($img);
imagedestroy($img);
unlink($tmpfilename);
Expected result:
Must be generate jpeg image.
Actual result:
--
Segmentation fault
--
Edit bug report at http://bugs.php.net/?id=24174edit=1
--
Try a CVS snapshot: http://bugs.php.net/fix.php?id=24174r=trysnapshot
Fixed in CVS: http://bugs.php.net/fix.php?id=24174r=fixedcvs
Fixed in release: http://bugs.php.net/fix.php?id=24174r=alreadyfixed
Need backtrace: http://bugs.php.net/fix.php?id=24174r=needtrace
Try newer version: http://bugs.php.net/fix.php?id=24174r=oldversion
Not developer issue:http://bugs.php.net/fix.php?id=24174r=support
Expected behavior: http://bugs.php.net/fix.php?id=24174r=notwrong
Not enough info:http://bugs.php.net/fix.php?id=24174r=notenoughinfo
Submitted twice:http://bugs.php.net/fix.php?id=24174r=submittedtwice
register_globals: http://bugs.php.net/fix.php?id=24174r=globals
PHP 3 support discontinued: http://bugs.php.net/fix.php?id=24174r=php3
Daylight Savings: http://bugs.php.net/fix.php?id=24174r=dst
IIS Stability: http://bugs.php.net/fix.php?id=24174r=isapi
Install GNU Sed:http://bugs.php.net/fix.php?id=24174r=gnused
#24161 [Asn]: imap_open will not timeout
ID: 24161 Updated by: [EMAIL PROTECTED] Reported By: thomas at xenocast dot com Status: Assigned Bug Type: IMAP related Operating System: Windows 2000 PHP Version: 4.3.2 Assigned To: iliaa New Comment: With a noteable exception of timeout values most parameters that can be set via mail_parameters() require your to specify a pointer to a C function. So implementing it is far from easy. Previous Comments: [2003-06-13 08:30:57] [EMAIL PROTECTED] Wrapping mail_parameters was something on the list of TODO. I had spoken with Chuck a long time ago about this, but there were some issues in implementing. Unfortunately I can't remember what just be aware it's not as easy as it first seems. [2003-06-13 08:05:30] [EMAIL PROTECTED] For Ilia: Maybe we should try introducing 'imap_parameters()' function. (wrapper for mail_parameters()). And allow people set those low-level parameters in the script. [2003-06-13 07:47:56] [EMAIL PROTECTED] Then assign it for real, Ilia. :) [2003-06-12 17:50:36] [EMAIL PROTECTED] assigning to self. [2003-06-12 16:39:55] [EMAIL PROTECTED] About 500 ppl, but I doubt they saw it before you changed it. The remainder of the comments for this report are too long. To view the rest of the comments, please view the bug report online at http://bugs.php.net/24161 -- Edit this bug report at http://bugs.php.net/?id=24161edit=1
#24174 [Opn-Fbk]: Seg. fault when calling imagecreatefromstring
ID: 24174
Updated by: [EMAIL PROTECTED]
Reported By: legion at altlinux dot org
-Status: Open
+Status: Feedback
Bug Type: GD related
Operating System: ALTLinux
PHP Version: 4.3.2
New Comment:
And what was the configure line you used to configure PHP?
(note: This does NOT crash for me)
Previous Comments:
[2003-06-13 08:33:40] legion at altlinux dot org
Description:
Script segfaults when calling function imagecreatefromstring() with
built-in font.
PHP version: 4.3.2 (cvs snapshot 20030609)
GD version: 2.0.4
Reproduce code:
---
$tmpfilename = tempnam (/tmp, FOO);
$im = imagecreate(200, 100);
$black = imagecolorallocate ($im, 0, 0, 0);
$orange = imagecolorallocate($im, 220, 210, 60);
imagefill($im, 0, 0, $black);
$string = '::: Oops! :::';
imagestring($im, 3, 0, 10, $string, $orange);
imagejpeg($im, $tmpfilename);
imagedestroy($im);
$fp = fopen($tmpfilename, 'r');
while (!feof ($fp)) { $content .= fgets($fp, 4096); }
fclose($fp);
$img = imagecreatefromstring($content);
// following function will be work
// $img = imagecreatefromjpeg($tmpfilename);
header (Content-type: image/jpeg);
imagejpeg($img);
imagedestroy($img);
unlink($tmpfilename);
Expected result:
Must be generate jpeg image.
Actual result:
--
Segmentation fault
--
Edit this bug report at http://bugs.php.net/?id=24174edit=1
#24175 [NEW]: String overflow? Segmentation faults
From: justinlong at strategicnetwork dot org
Operating system: KRUD/RedHat
PHP version: 4.3.2
PHP Bug Type: Reproducible crash
Bug description: String overflow? Segmentation faults
Description:
Have a 50,000 record Postgres database of articles that this code is
attempting to process. CGI PHP program takes the HTML file and massages it
into a non-HTML subset. Occasional segmentation faults after long runs,
and sometimes the following error in the middle of a run:
ll [Fri Jun 13 09:34:23 2003] Script: './article-preprocess.php'
---
/usr/local/src/php-4.3.2/ext/standard/string.c(3521) : Block 0x084C9780
status:
Beginning: OK (allocated on
/usr/local/src/php-4.3.2/ext/standard/string.c:3330, 1024 bytes)
End: Overflown (magic=0x2A8FCC33 instead of 0x2A8FCC84)
1 byte(s) overflown
---
51613 Friday, June 6: Back in Court
/usr/local/src/php-4.3.2/ext/standard/string.c(3330) : Freeing 0x084C97A4
(1024 bytes), script=./article-preprocess.php
Configure line:
./configure --with-pgsql=/usr2/local/pgsql
--with-curl=/usr/bin,/usr/shared --with-config-file=/etc --enable-stem
--enable-debug
Reproduce code:
---
$article = trim(stripslashes($rec-article));
if (strlen($article)512) {
$article = str_replace(TD, td,$article);
$article = str_replace(/TD, /td,$article);
$article = eregi_replace([[:cntrl:]], ,$article);
// get rid of
control characters
$article = eregi_replace(P[^]+,\n\n\n,$article);
$article = eregi_replace(BR[^]+,\n\n,$article);
$article = html_entity_decode($article);
// get rid of HTML
entities
$article = eregi_replace([^;]+;, ,$article);
// get rid of
control characters
if (!empty($article)) {
$article = strtr($article,
¥µÀÁÂÃÄÅÆÇÈÉÊËÌÍÎÏÐÑÒÓÔÕÖØÙÚÛÜÝßàáâãäåæçèéêëìíîïðñòóôõöøùúûüýÿ,
SOZsozYYuAAACDNOOYsaaaconooyy);
}
if (!empty($article)) {
$article = strip_tags($article,'td');
$article = td.$article;
$textlines = split(td,$article);
foreach ($textlines as $nextstory) {
if (strpos($nextstory,)0) { $nextstory =
substr($nextstory,strpos($nextstory,)+1); }
$checklines = split(\n,$nextstory);
if (count($checklines)0) {
$totallength=1;
$totallines=1;
$totalsingletones=1;
for ($y=0;$ycount($checklines);$y++) {
if (strlen($checklines[$y])0)
{
$totallines++;
$totallength =
$totallength + strlen($checklines[$y]);
if ($checklines[$y] ==
) { $totalsingletones++; }
}
}
if ($totallength/$totallines15
$totalsingletons/$totallines.5
strlen($nextstory)512) { $nextstory = $story .=
trim(strip_tags($nextstory)). \n\n; }
}
}
}
}
Expected result:
Should come out on the other end with a large chunk of text from an HTML
page representing the article in question. Usually has a run of 90+
entries before the error cited above occurs, and if it runs for 200+
entries before a segmentation fault occurs.
Actual result:
--
Backtrace:
NU 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...
warning: core file may not match specified executable file.
Core was generated by `/usr/local/bin/php -q ./article-preprocess.php'.
Program terminated with signal 11, Segmentation fault.
#0 0x40259490 in ?? ()
(gdb) bt
#0 0x40259490 in ?? ()
#1 0x402593f4 in ?? ()
#2
#24175 [Opn-Fbk]: String overflow? Segmentation faults
ID: 24175
Updated by: [EMAIL PROTECTED]
Reported By: justinlong at strategicnetwork dot org
-Status: Open
+Status: Feedback
Bug Type: Reproducible crash
Operating System: KRUD/RedHat
PHP Version: 4.3.2
New Comment:
Please provide a short but _complete_ stand-alone script.
Previous Comments:
[2003-06-13 08:55:57] justinlong at strategicnetwork dot org
Description:
Have a 50,000 record Postgres database of articles that this code is
attempting to process. CGI PHP program takes the HTML file and massages
it into a non-HTML subset. Occasional segmentation faults after long
runs, and sometimes the following error in the middle of a run:
ll [Fri Jun 13 09:34:23 2003] Script: './article-preprocess.php'
---
/usr/local/src/php-4.3.2/ext/standard/string.c(3521) : Block 0x084C9780
status:
Beginning: OK (allocated on
/usr/local/src/php-4.3.2/ext/standard/string.c:3330, 1024 bytes)
End: Overflown (magic=0x2A8FCC33 instead of 0x2A8FCC84)
1 byte(s) overflown
---
51613 Friday, June 6: Back in Court
/usr/local/src/php-4.3.2/ext/standard/string.c(3330) : Freeing
0x084C97A4 (1024 bytes), script=./article-preprocess.php
Configure line:
./configure --with-pgsql=/usr2/local/pgsql
--with-curl=/usr/bin,/usr/shared --with-config-file=/etc --enable-stem
--enable-debug
Reproduce code:
---
$article = trim(stripslashes($rec-article));
if (strlen($article)512) {
$article = str_replace(TD, td,$article);
$article = str_replace(/TD, /td,$article);
$article = eregi_replace([[:cntrl:]], ,$article);
// get rid of
control characters
$article = eregi_replace(P[^]+,\n\n\n,$article);
$article = eregi_replace(BR[^]+,\n\n,$article);
$article = html_entity_decode($article);
// get rid of HTML
entities
$article = eregi_replace([^;]+;, ,$article);
// get rid of
control characters
if (!empty($article)) {
$article = strtr($article,
¥µÀÁÂÃÄÅÆÇÈÉÊËÌÍÎÏÐÑÒÓÔÕÖØÙÚÛÜÝßàáâãäåæçèéêëìíîïðñòóôõöøùúûüýÿ,
SOZsozYYuAAACDNOOYsaaaconooyy);
}
if (!empty($article)) {
$article = strip_tags($article,'td');
$article = td.$article;
$textlines = split(td,$article);
foreach ($textlines as $nextstory) {
if (strpos($nextstory,)0) { $nextstory =
substr($nextstory,strpos($nextstory,)+1); }
$checklines = split(\n,$nextstory);
if (count($checklines)0) {
$totallength=1;
$totallines=1;
$totalsingletones=1;
for ($y=0;$ycount($checklines);$y++) {
if (strlen($checklines[$y])0)
{
$totallines++;
$totallength =
$totallength + strlen($checklines[$y]);
if ($checklines[$y] ==
) { $totalsingletones++; }
}
}
if ($totallength/$totallines15
$totalsingletons/$totallines.5 strlen($nextstory)512) { $nextstory
= $story .= trim(strip_tags($nextstory)). \n\n; }
}
}
}
}
Expected result:
Should come out on the other end with a large chunk of text from an
HTML page representing the article in question. Usually has a run of
90+ entries before the error cited above occurs, and if it runs for
200+ entries before a segmentation fault occurs.
Actual result:
--
Backtrace:
NU 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
#24175 [Fbk-Opn]: String overflow? Segmentation faults
ID: 24175
User updated by: justinlong at strategicnetwork dot org
Reported By: justinlong at strategicnetwork dot org
-Status: Feedback
+Status: Open
Bug Type: Reproducible crash
Operating System: KRUD/RedHat
PHP Version: 4.3.2
New Comment:
#!/usr/local/bin/php -q
?
/*
This program will take the text in article and identify the story to
be indexed, placing it in the story field
*/
$todaySystem= mktime();
$todayJulian= getdate($todaySystem);
$thismorning=
mktime(0,0,0,$todayJulian[mon],$todayJulian[mday],$todayJulian[year]);
$thisweek = mktime()-(24*60*60*intval($todayJulian['wday']));
$lastyear = mktime(0,0,0,1,1,$todayJulian[year]-1);
$thisyear = mktime(0,0,0,1,1,$todayJulian[year]);
$thismonth = mktime(0,0,0,$todayJulian[mon],1,$todayJulian[year]);
$lastmonth = mktime(0,0,0,$todayJulian[mon]-1,1,$todayJulian[year]);
$db = pg_connect (dbname=nsm user=nobody) or die(The Network for
Strategic Missions is presently down for software upgrades. Please try
again a little later.);
$rs = pg_exec($db,UPDATE story_progress SET preprocessing=NULL);
$rs = pg_exec($db,SELECT preprocessing FROM story_progress);
$rec = pg_fetch_object($rs,0);
if ($rec-preprocessing 0) {
die();
} else {
$rs = pg_exec($db,UPDATE story_progress SET
preprocessing=.$todaySystem);
}
set_time_limit(0);
$rs = pg_exec($db,SELECT count(storyid) from story_headline WHERE
article IS NOT NULL and story_preprocessed IS NULL);
$rec = pg_fetch_object($rs,0);
echo $rec-count,' records unprocessed',\n;
//$rs = pg_exec($db,SELECT storyid,headline,article from
story_headline WHERE storyid=80493 limit 1000);
$rs = pg_exec($db,SELECT storyid,headline,article from story_headline
WHERE article IS NOT NULL and story_preprocessed IS NULL order by
storyid desc limit 100);
if ($rs pg_numrows($rs)0) {
for ($x=0;$xpg_numrows($rs);$x++) {
$article = ;
$textlines = ;
$story = ;
$rec = pg_fetch_object($rs,$x);
// echo $rec-storyid,' ',$rec-headline, ;
$article = trim(stripslashes($rec-article));
if (strlen($article)512) {
$article = str_replace(TD, td,$article);
$article = str_replace(/TD, /td,$article);
$article = eregi_replace([[:cntrl:]], ,$article);
// get rid of
control characters
$article = eregi_replace(P[^]+,\n\n\n,$article);
$article = eregi_replace(BR[^]+,\n\n,$article);
$article = html_entity_decode($article);
// get rid of HTML
entities
$article = eregi_replace([^;]+;, ,$article);
// get rid of
control characters
if (!empty($article)) {
$article = strtr($article,
¥µÀÁÂÃÄÅÆÇÈÉÊËÌÍÎÏÐÑÒÓÔÕÖØÙÚÛÜÝßàáâãäåæçèéêëìíîïðñòóôõöøùúûüýÿ,
SOZsozYYuAAACDNOOYsaaaconooyy);
}
if (!empty($article)) {
$article = strip_tags($article,'td');
$article = td.$article;
$textlines = split(td,$article);
foreach ($textlines as $nextstory) {
if (strpos($nextstory,)0) { $nextstory =
substr($nextstory,strpos($nextstory,)+1); }
$checklines = split(\n,$nextstory);
if (count($checklines)0) {
$totallength=1;
$totallines=1;
$totalsingletones=1;
for ($y=0;$ycount($checklines);$y++) {
if (strlen($checklines[$y])0)
{
$totallines++;
$totallength =
$totallength + strlen($checklines[$y]);
if ($checklines[$y] ==
) { $totalsingletones++; }
}
}
if ($totallength/$totallines15
$totalsingletons/$totallines.5 strlen($nextstory)512) { $nextstory
= $story .= trim(strip_tags($nextstory)). \n\n; }
}
}
}
}
if (strlen($story)512) { echo $rec-headline,\n; }
pg_exec($db,UPDATE story_headline
#24169 [Opn-Fbk]: session cookie being incorrectly sent
ID: 24169 Updated by: [EMAIL PROTECTED] Reported By: steveh at brendata dot co dot uk -Status: Open +Status: Feedback Bug Type: Session related Operating System: NT4 SP6a PHP Version: 4.3.2 New Comment: remove that phpinfo() from your test script and use telnet to connect to the webserver and request the script (e.g. GET /test.php HTTP/1.0). Then paste the output here. Previous Comments: [2003-06-13 07:52:31] steveh at brendata dot co dot uk This is with IIS4 and it's an issue in all versions of Internet explorer we have at hand, including 6.0.2800 (XP SP2) using php4isapi.dll ( [2003-06-13 07:45:01] [EMAIL PROTECTED] What webserver are you using? And which SAPI module? Does this happen with any browser? [2003-06-13 07:35:44] steveh at brendata dot co dot uk Here they are. Files do get created in the php\sessiondata directory, this worked fine with 4.3.1 (and the same php.ini file), it has stopped since upgrading to 4.3.2. Directive Local Value Master Value session.auto_start Off Off session.bug_compat_42 Off Off session.bug_compat_warn Off Off session.cache_expire 180 180 session.cache_limiter nocache nocache session.cookie_domain no value no value session.cookie_lifetime 0 0 session.cookie_path / / session.cookie_secure Off Off session.entropy_file no value no value session.entropy_length 0 0 session.gc_divisor 100 100 session.gc_maxlifetime 1440 1440 session.gc_probability 1 1 session.name PHPSESSID PHPSESSID session.referer_check no value no value session.save_handler files files session.save_path C:\PHP\sessiondata C:\PHP\sessiondata session.serialize_handler php php session.use_cookies On On session.use_only_cookies Off Off session.use_trans_sid Off Off [2003-06-13 07:28:05] [EMAIL PROTECTED] And what might be the relevant php.ini options..? (the ones with session. prefix) [2003-06-13 03:51:15] steveh at brendata dot co dot uk Description: For session handling a cookie should be set as follows: session name=session id This was previously working, but since upgrading to 4.3.2 we now see cookies set as follows: session id=session id As a result sessions are not carried over and a new session is started for every access (i.e. no cookie called PHPSESSID or whatever is in the php.ini) Here's the relevant chunk of phpinfo output that demonstrates this. _SERVER[HTTP_COOKIE] CookieProductID=94; a9c7fa405401e831e6ada0ee31f67ea3=a9c7fa405401e831e6ada0ee31f67ea3; caec00776094cd5017fa35e41162333b=caec00776094cd5017fa35e41162333b; 139632a02257356caa27c86256afcb70=139632a02257356caa27c86256afcb70; 0ba5beadf45c35245e67c1f67ffc70dc=0ba5beadf45c35245e67c1f67ffc70dc; b7f2e2e4a196a620f318f16034a8192b=b7f2e2e4a196a620f318f16034a8192b; 6ca2b668932e46c85528d399fad50541=6ca2b668932e46c85528d399fad50541; 913a5a99fa54ccd33b610b3f882d132d=913a5a99fa54ccd33b610b3f882d132d; a7c7085d672b5e885476dabdc096ca9f=a7c7085d672b5e885476dabdc096ca9f; 04a257bf48fef943fb1d4ed508970140=04a257bf48fef943fb1d4ed508970140; d269823ce913782241613e3791935d11=d269823ce913782241613e3791935d11; edc78b150437138fb1d14915a97dee87=edc78b150437138fb1d14915a97dee87; 50212bca7b517a57521305d72a6c43c9=50212bca7b517a57521305d72a6c43c9; 68c37f0103351348dd1e705847e2f6d3=68c37f0103351348dd1e705847e2f6d3; 78d96155c83ee77e3fc3b69731b428a4=78d96155c83ee77e3fc3b69731b428a4; e7b52247b003b85c04d942721879206a=e7b52247b003b85c04d942721879206a; f3d20ebc7068137eaa7b3461eab64d62=f3d20ebc7068137eaa7b3461eab64d62; c3940ed02170d481105849b74b6d3cb8=c3940ed02170d481105849b74b6d3cb8; e8109d59aca1442f4cd7fa5358410c30=e8109d59aca1442f4cd7fa5358410c30; 2a0f643e85d2b21003958bb47c2a2d4d=2a0f643e85d2b21003958bb47c2a2d4d Reproduce code: --- ?php session_start(); $_SESSION[FRED]=1; echo session_id(); phpinfo(); ? Expected result: The same session id for each open, and PHPSESSID seen as a cookie in the headers. Actual result: -- Different session id's each time, and a growing list of session id=session id cookies. -- Edit this bug report at http://bugs.php.net/?id=24169edit=1
#24145 [Bgs-Csd]: Problem using POST request
ID: 24145 User updated by: przemek at hexacom dot biz Reported By: przemek at hexacom dot biz -Status: Bogus +Status: Closed Bug Type: HTTP related Operating System: Linux Mandrake 9.0 PHP Version: 4.3.1 New Comment: In PHP 4.3.2 everything works fine. Previous Comments: [2003-06-12 07:08:29] [EMAIL PROTECTED] Also see #18648 [2003-06-12 05:32:12] [EMAIL PROTECTED] Thank you for taking the time to report a problem with PHP. Unfortunately you are not using a current version of PHP -- the problem might already be fixed. Please download a new PHP version from http://www.php.net/downloads.php If you are able to reproduce the bug with one of the latest versions of PHP, please change the PHP version on this bug report to the version you tested and change the status back to Open. Again, thank you for your continued support of PHP. As far as I remember this is fixed already. [2003-06-12 05:30:55] przemek at hexacom dot biz Description: Situation is very simple, in html file im creating a form. In this form is only one field i.e. named alias, the field has value abc, form method is POST and action script.php. There is a submit button too. When the script.php gets a request it contacentates three values: variable value, variable name and again variable value. It's look like this: abcalias=abc The tip is to add one more i.e. hidden field, but i think it is something wrong. Regards. PS.Sorry for may english. Reproduce code: --- index.htm form action=script.php method=POST Somethinginput type=text name=alias input type=submit value=GO /form - script.php ? echo $_POST[alias]; ? Expected result: abc Actual result: -- abcalias=abc -- Edit this bug report at http://bugs.php.net/?id=24145edit=1
#24161 [Asn-Csd]: imap_open will not timeout
ID: 24161 Updated by: [EMAIL PROTECTED] Reported By: thomas at xenocast dot com -Status: Assigned +Status: Closed Bug Type: IMAP related Operating System: Windows 2000 PHP Version: 4.3.2 Assigned To: iliaa New Comment: This bug has been fixed in CVS. In case this was a PHP problem, snapshots of the sources are packaged every three hours; this change will be in the next snapshot. You can grab the snapshot at http://snaps.php.net/. In case this was a documentation problem, the fix will show up soon at http://www.php.net/manual/. In case this was a PHP.net website problem, the change will show up on the PHP.net site and on the mirror sites in short time. Thank you for the report, and for helping us make PHP better. Previous Comments: [2003-06-13 08:35:01] [EMAIL PROTECTED] With a noteable exception of timeout values most parameters that can be set via mail_parameters() require your to specify a pointer to a C function. So implementing it is far from easy. [2003-06-13 08:30:57] [EMAIL PROTECTED] Wrapping mail_parameters was something on the list of TODO. I had spoken with Chuck a long time ago about this, but there were some issues in implementing. Unfortunately I can't remember what just be aware it's not as easy as it first seems. [2003-06-13 08:05:30] [EMAIL PROTECTED] For Ilia: Maybe we should try introducing 'imap_parameters()' function. (wrapper for mail_parameters()). And allow people set those low-level parameters in the script. [2003-06-13 07:47:56] [EMAIL PROTECTED] Then assign it for real, Ilia. :) [2003-06-12 17:50:36] [EMAIL PROTECTED] assigning to self. 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/24161 -- Edit this bug report at http://bugs.php.net/?id=24161edit=1
#24070 [Bgs-Opn]: Use post instead of get for header(Location:)
ID: 24070
User updated by: john dot winstanley at angelsolutions dot co dot uk
Reported By: john dot winstanley at angelsolutions dot co dot uk
-Status: Bogus
+Status: Open
Bug Type: Feature/Change Request
Operating System: Any
PHP Version: 4.3.2
New Comment:
Thanks for directing me to the curl extension it will be really
helpfull but The advantage of PHP over all other scripting languages is
its ease of use.
This is the code needed to do a simple post request using curl.
$ch = curl_init();
curl_setopt($ch, CURLOPT_URL,hello.php);
curl_setopt($ch, CURLOPT_POST, 1);
curl_setopt($ch, CURLOPT_POSTFIELDS,
postvar1=value1postvar2=value2postvar3=value3);
curl_exec ($ch);
curl_close ($ch);
Too long too difficult to understand all the steps for the average
user. We can make it easier as below but
I'd like a function in the php core like this
postrequest($url,$parameters);
function postrequest($url,$parameters) {
$ch = curl_init();
curl_setopt($ch, CURLOPT_URL,$url)
curl_setopt($ch, CURLOPT_POST, 1);
curl_setopt($ch, CURLOPT_POSTFIELDS, $parameters);
curl_exec ($ch);
curl_close ($ch);
}
This would encourage PHP developers to use Java MVC like archutechture
where a request can be processed on one page and then forwarded to
another with a requestDispatcher or post request. Communication
between different pages is currently one of PHPs big weaknesses where
it loses out to servlets. Make curl part of the core and use simplfied
functions to make it really easy to use!!
Previous Comments:
[2003-06-06 18:34:09] [EMAIL PROTECTED]
There is the curl extension already which you should
use for that.
[2003-06-06 16:59:49] john dot winstanley at angelsolutions dot co dot
uk
I'd like to be able to process a client request on one page and then
pass that request along with information to another page using POST.
At the moment all I can do is forward the request by using GET and the
header(Location: someurl?attribute=4); function.
Thanks Guys
--
Edit this bug report at http://bugs.php.net/?id=24070edit=1
#24169 [Fbk-Opn]: session cookie being incorrectly sent
ID: 24169 User updated by: steveh at brendata dot co dot uk Reported By: steveh at brendata dot co dot uk -Status: Feedback +Status: Open Bug Type: Session related Operating System: NT4 SP6a PHP Version: 4.3.2 New Comment: Unfortunately, the server on which this resides requires authentication, can you quickly paste the format for basic authentication username/password? Previous Comments: [2003-06-13 09:14:28] [EMAIL PROTECTED] remove that phpinfo() from your test script and use telnet to connect to the webserver and request the script (e.g. GET /test.php HTTP/1.0). Then paste the output here. [2003-06-13 07:52:31] steveh at brendata dot co dot uk This is with IIS4 and it's an issue in all versions of Internet explorer we have at hand, including 6.0.2800 (XP SP2) using php4isapi.dll ( [2003-06-13 07:45:01] [EMAIL PROTECTED] What webserver are you using? And which SAPI module? Does this happen with any browser? [2003-06-13 07:35:44] steveh at brendata dot co dot uk Here they are. Files do get created in the php\sessiondata directory, this worked fine with 4.3.1 (and the same php.ini file), it has stopped since upgrading to 4.3.2. Directive Local Value Master Value session.auto_start Off Off session.bug_compat_42 Off Off session.bug_compat_warn Off Off session.cache_expire 180 180 session.cache_limiter nocache nocache session.cookie_domain no value no value session.cookie_lifetime 0 0 session.cookie_path / / session.cookie_secure Off Off session.entropy_file no value no value session.entropy_length 0 0 session.gc_divisor 100 100 session.gc_maxlifetime 1440 1440 session.gc_probability 1 1 session.name PHPSESSID PHPSESSID session.referer_check no value no value session.save_handler files files session.save_path C:\PHP\sessiondata C:\PHP\sessiondata session.serialize_handler php php session.use_cookies On On session.use_only_cookies Off Off session.use_trans_sid Off Off [2003-06-13 07:28:05] [EMAIL PROTECTED] And what might be the relevant php.ini options..? (the ones with session. prefix) 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/24169 -- Edit this bug report at http://bugs.php.net/?id=24169edit=1
#24160 [Bgs]: 4.3.2 Windows Problem BUG CGI CALL
ID: 24160 User updated by: albersag at terra dot es Reported By: albersag at terra dot es Status: Bogus Bug Type: *Configuration Issues Operating System: WIN XP PHP Version: 4.3.2 New Comment: Ok. I supposed it to be a bug, cause 4.3.1 works me fine without changing anything. Thanx for your interest Previous Comments: [2003-06-13 08:19:06] [EMAIL PROTECTED] Yes, it's configuration issue. But not a bug in PHP. Ask support questions on the appropriate mailing lists, thank you. [2003-06-12 15:42:41] albersag at terra dot es Description: I have installed php 4.3.2 as a cgi for abyss web server. http://www.aprelium.com . And i get a not imput file specified when calling a index.php file for example , but 4.3.1 works correctly without changing anything. I think is a bug of this version Reproduce code: --- No input file specified. on screen Expected result: When 4.3.1 it works and... i get phpinfo() correctly -- Edit this bug report at http://bugs.php.net/?id=24160edit=1
#24161 [Csd]: imap_open will not timeout
ID: 24161 User updated by: thomas at xenocast dot com Reported By: thomas at xenocast dot com Status: Closed Bug Type: IMAP related Operating System: Windows 2000 PHP Version: 4.3.2 Assigned To: iliaa New Comment: Is there a windows snap? Do you recommend I do that or just wait for the next release? Previous Comments: [2003-06-13 09:43:30] [EMAIL PROTECTED] This bug has been fixed in CVS. In case this was a PHP problem, snapshots of the sources are packaged every three hours; this change will be in the next snapshot. You can grab the snapshot at http://snaps.php.net/. In case this was a documentation problem, the fix will show up soon at http://www.php.net/manual/. In case this was a PHP.net website problem, the change will show up on the PHP.net site and on the mirror sites in short time. Thank you for the report, and for helping us make PHP better. [2003-06-13 08:35:01] [EMAIL PROTECTED] With a noteable exception of timeout values most parameters that can be set via mail_parameters() require your to specify a pointer to a C function. So implementing it is far from easy. [2003-06-13 08:30:57] [EMAIL PROTECTED] Wrapping mail_parameters was something on the list of TODO. I had spoken with Chuck a long time ago about this, but there were some issues in implementing. Unfortunately I can't remember what just be aware it's not as easy as it first seems. [2003-06-13 08:05:30] [EMAIL PROTECTED] For Ilia: Maybe we should try introducing 'imap_parameters()' function. (wrapper for mail_parameters()). And allow people set those low-level parameters in the script. [2003-06-13 07:47:56] [EMAIL PROTECTED] Then assign it for real, Ilia. :) 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/24161 -- Edit this bug report at http://bugs.php.net/?id=24161edit=1
#24161 [Csd]: imap_open will not timeout
ID: 24161 Updated by: [EMAIL PROTECTED] Reported By: thomas at xenocast dot com Status: Closed Bug Type: IMAP related Operating System: Windows 2000 PHP Version: 4.3.2 Assigned To: iliaa New Comment: Windows snap with this patch should become avaliable in a few hours. Previous Comments: [2003-06-13 09:57:49] thomas at xenocast dot com Is there a windows snap? Do you recommend I do that or just wait for the next release? [2003-06-13 09:43:30] [EMAIL PROTECTED] This bug has been fixed in CVS. In case this was a PHP problem, snapshots of the sources are packaged every three hours; this change will be in the next snapshot. You can grab the snapshot at http://snaps.php.net/. In case this was a documentation problem, the fix will show up soon at http://www.php.net/manual/. In case this was a PHP.net website problem, the change will show up on the PHP.net site and on the mirror sites in short time. Thank you for the report, and for helping us make PHP better. [2003-06-13 08:35:01] [EMAIL PROTECTED] With a noteable exception of timeout values most parameters that can be set via mail_parameters() require your to specify a pointer to a C function. So implementing it is far from easy. [2003-06-13 08:30:57] [EMAIL PROTECTED] Wrapping mail_parameters was something on the list of TODO. I had spoken with Chuck a long time ago about this, but there were some issues in implementing. Unfortunately I can't remember what just be aware it's not as easy as it first seems. [2003-06-13 08:05:30] [EMAIL PROTECTED] For Ilia: Maybe we should try introducing 'imap_parameters()' function. (wrapper for mail_parameters()). And allow people set those low-level parameters in the 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/24161 -- Edit this bug report at http://bugs.php.net/?id=24161edit=1
#24161 [Csd]: imap_open will not timeout
ID: 24161 Updated by: [EMAIL PROTECTED] Reported By: thomas at xenocast dot com Status: Closed Bug Type: IMAP related Operating System: Windows 2000 PHP Version: 4.3.2 Assigned To: iliaa New Comment: Just go the the URL (snaps.php.net) and you will see when the last one was built. Take one built after the current time :) Previous Comments: [2003-06-13 09:59:48] [EMAIL PROTECTED] Windows snap with this patch should become avaliable in a few hours. [2003-06-13 09:57:49] thomas at xenocast dot com Is there a windows snap? Do you recommend I do that or just wait for the next release? [2003-06-13 09:43:30] [EMAIL PROTECTED] This bug has been fixed in CVS. In case this was a PHP problem, snapshots of the sources are packaged every three hours; this change will be in the next snapshot. You can grab the snapshot at http://snaps.php.net/. In case this was a documentation problem, the fix will show up soon at http://www.php.net/manual/. In case this was a PHP.net website problem, the change will show up on the PHP.net site and on the mirror sites in short time. Thank you for the report, and for helping us make PHP better. [2003-06-13 08:35:01] [EMAIL PROTECTED] With a noteable exception of timeout values most parameters that can be set via mail_parameters() require your to specify a pointer to a C function. So implementing it is far from easy. [2003-06-13 08:30:57] [EMAIL PROTECTED] Wrapping mail_parameters was something on the list of TODO. I had spoken with Chuck a long time ago about this, but there were some issues in implementing. Unfortunately I can't remember what just be aware it's not as easy as it first seems. 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/24161 -- Edit this bug report at http://bugs.php.net/?id=24161edit=1
#24169 [Opn-Fbk]: session cookie being incorrectly sent
ID: 24169 Updated by: [EMAIL PROTECTED] Reported By: steveh at brendata dot co dot uk -Status: Open +Status: Feedback Bug Type: Session related Operating System: NT4 SP6a PHP Version: 4.3.2 New Comment: Uh..maybe it's easier if you use lynx: # lynx -dump -head http://localhost/test.php Previous Comments: [2003-06-13 09:49:22] steveh at brendata dot co dot uk Unfortunately, the server on which this resides requires authentication, can you quickly paste the format for basic authentication username/password? [2003-06-13 09:14:28] [EMAIL PROTECTED] remove that phpinfo() from your test script and use telnet to connect to the webserver and request the script (e.g. GET /test.php HTTP/1.0). Then paste the output here. [2003-06-13 07:52:31] steveh at brendata dot co dot uk This is with IIS4 and it's an issue in all versions of Internet explorer we have at hand, including 6.0.2800 (XP SP2) using php4isapi.dll ( [2003-06-13 07:45:01] [EMAIL PROTECTED] What webserver are you using? And which SAPI module? Does this happen with any browser? [2003-06-13 07:35:44] steveh at brendata dot co dot uk Here they are. Files do get created in the php\sessiondata directory, this worked fine with 4.3.1 (and the same php.ini file), it has stopped since upgrading to 4.3.2. Directive Local Value Master Value session.auto_start Off Off session.bug_compat_42 Off Off session.bug_compat_warn Off Off session.cache_expire 180 180 session.cache_limiter nocache nocache session.cookie_domain no value no value session.cookie_lifetime 0 0 session.cookie_path / / session.cookie_secure Off Off session.entropy_file no value no value session.entropy_length 0 0 session.gc_divisor 100 100 session.gc_maxlifetime 1440 1440 session.gc_probability 1 1 session.name PHPSESSID PHPSESSID session.referer_check no value no value session.save_handler files files session.save_path C:\PHP\sessiondata C:\PHP\sessiondata session.serialize_handler php php session.use_cookies On On session.use_only_cookies Off Off session.use_trans_sid Off Off 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/24169 -- Edit this bug report at http://bugs.php.net/?id=24169edit=1
#24169 [Fbk]: session cookie being incorrectly sent
ID: 24169 Updated by: [EMAIL PROTECTED] Reported By: steveh at brendata dot co dot uk Status: Feedback Bug Type: Session related Operating System: NT4 SP6a PHP Version: 4.3.2 New Comment: forgot the auth parameter: -auth=id:pw Previous Comments: [2003-06-13 10:04:58] [EMAIL PROTECTED] Uh..maybe it's easier if you use lynx: # lynx -dump -head http://localhost/test.php [2003-06-13 09:49:22] steveh at brendata dot co dot uk Unfortunately, the server on which this resides requires authentication, can you quickly paste the format for basic authentication username/password? [2003-06-13 09:14:28] [EMAIL PROTECTED] remove that phpinfo() from your test script and use telnet to connect to the webserver and request the script (e.g. GET /test.php HTTP/1.0). Then paste the output here. [2003-06-13 07:52:31] steveh at brendata dot co dot uk This is with IIS4 and it's an issue in all versions of Internet explorer we have at hand, including 6.0.2800 (XP SP2) using php4isapi.dll ( [2003-06-13 07:45:01] [EMAIL PROTECTED] What webserver are you using? And which SAPI module? Does this happen with any browser? 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/24169 -- Edit this bug report at http://bugs.php.net/?id=24169edit=1
#24169 [Fbk-Opn]: session cookie being incorrectly sent
ID: 24169 User updated by: steveh at brendata dot co dot uk Reported By: steveh at brendata dot co dot uk -Status: Feedback +Status: Open Bug Type: Session related Operating System: NT4 SP6a PHP Version: 4.3.2 New Comment: That looks fine, I also tried on the larger app that is really causing the problems and that looks fine as well? HTTP/1.1 200 OK Server: Microsoft-IIS/4.0 Date: Fri, 13 Jun 2003 15:10:57 GMT Content-type: text/html X-Powered-By: PHP/4.3.2 Set-Cookie: PHPSESSID=d1ed576c229f8c72edf65eee70a1bd9f; path=/ Expires: Thu, 19 Nov 1981 08:52:00 GMT Cache-Control: no-store, no-cache, must-revalidate, post-check=0, pre-check=0 Pragma: no-cache Previous Comments: [2003-06-13 10:05:57] [EMAIL PROTECTED] forgot the auth parameter: -auth=id:pw [2003-06-13 10:04:58] [EMAIL PROTECTED] Uh..maybe it's easier if you use lynx: # lynx -dump -head http://localhost/test.php [2003-06-13 09:49:22] steveh at brendata dot co dot uk Unfortunately, the server on which this resides requires authentication, can you quickly paste the format for basic authentication username/password? [2003-06-13 09:14:28] [EMAIL PROTECTED] remove that phpinfo() from your test script and use telnet to connect to the webserver and request the script (e.g. GET /test.php HTTP/1.0). Then paste the output here. [2003-06-13 07:52:31] steveh at brendata dot co dot uk This is with IIS4 and it's an issue in all versions of Internet explorer we have at hand, including 6.0.2800 (XP SP2) using php4isapi.dll ( The remainder of the comments for this report are too long. To view the rest of the comments, please view the bug report online at http://bugs.php.net/24169 -- Edit this bug report at http://bugs.php.net/?id=24169edit=1
#24169 [Opn]: session cookie being incorrectly sent
ID: 24169 User updated by: steveh at brendata dot co dot uk Reported By: steveh at brendata dot co dot uk Status: Open Bug Type: Session related Operating System: NT4 SP6a PHP Version: 4.3.2 New Comment: I'm just going to tcpdump the traffic going between the IIS and the Client PC to see whether that shows more. Previous Comments: [2003-06-13 10:12:11] steveh at brendata dot co dot uk That looks fine, I also tried on the larger app that is really causing the problems and that looks fine as well? HTTP/1.1 200 OK Server: Microsoft-IIS/4.0 Date: Fri, 13 Jun 2003 15:10:57 GMT Content-type: text/html X-Powered-By: PHP/4.3.2 Set-Cookie: PHPSESSID=d1ed576c229f8c72edf65eee70a1bd9f; path=/ Expires: Thu, 19 Nov 1981 08:52:00 GMT Cache-Control: no-store, no-cache, must-revalidate, post-check=0, pre-check=0 Pragma: no-cache [2003-06-13 10:05:57] [EMAIL PROTECTED] forgot the auth parameter: -auth=id:pw [2003-06-13 10:04:58] [EMAIL PROTECTED] Uh..maybe it's easier if you use lynx: # lynx -dump -head http://localhost/test.php [2003-06-13 09:49:22] steveh at brendata dot co dot uk Unfortunately, the server on which this resides requires authentication, can you quickly paste the format for basic authentication username/password? [2003-06-13 09:14:28] [EMAIL PROTECTED] remove that phpinfo() from your test script and use telnet to connect to the webserver and request the script (e.g. GET /test.php HTTP/1.0). Then paste the output here. 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/24169 -- Edit this bug report at http://bugs.php.net/?id=24169edit=1
#24169 [Opn]: session cookie being incorrectly sent
ID: 24169 User updated by: steveh at brendata dot co dot uk Reported By: steveh at brendata dot co dot uk Status: Open Bug Type: Session related Operating System: NT4 SP6a PHP Version: 4.3.2 New Comment: Now I'm totally foxed, it's working again, but IIS has not been restarted, neither has the browser on my PC and notjing has changed in the INI file. I'll get the vardump of $_COOKIE again. There is now just that single cookie set PHPSESSID. Previous Comments: [2003-06-13 10:12:55] steveh at brendata dot co dot uk I'm just going to tcpdump the traffic going between the IIS and the Client PC to see whether that shows more. [2003-06-13 10:12:11] steveh at brendata dot co dot uk That looks fine, I also tried on the larger app that is really causing the problems and that looks fine as well? HTTP/1.1 200 OK Server: Microsoft-IIS/4.0 Date: Fri, 13 Jun 2003 15:10:57 GMT Content-type: text/html X-Powered-By: PHP/4.3.2 Set-Cookie: PHPSESSID=d1ed576c229f8c72edf65eee70a1bd9f; path=/ Expires: Thu, 19 Nov 1981 08:52:00 GMT Cache-Control: no-store, no-cache, must-revalidate, post-check=0, pre-check=0 Pragma: no-cache [2003-06-13 10:05:57] [EMAIL PROTECTED] forgot the auth parameter: -auth=id:pw [2003-06-13 10:04:58] [EMAIL PROTECTED] Uh..maybe it's easier if you use lynx: # lynx -dump -head http://localhost/test.php [2003-06-13 09:49:22] steveh at brendata dot co dot uk Unfortunately, the server on which this resides requires authentication, can you quickly paste the format for basic authentication username/password? 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/24169 -- Edit this bug report at http://bugs.php.net/?id=24169edit=1
#24168 [Fbk-Bgs]: Fatal error: Call to undefined function: get_attribute_node()
ID: 24168 Updated by: [EMAIL PROTECTED] -Summary: XSL functions 'forget' current node position after absolute path argument Reported By: christian dot hang at web dot de -Status: Feedback +Status: Bogus Bug Type: DOM XML related -Operating System: Linux (Debian woody) +Operating System: Solaris 5.7 -PHP Version: 4.3.2 +PHP Version: 4.2.3 New Comment: Hi this is not a php bug. PHP itself does not handle anything in XSLT-Processing, it's all libxslt's work. Please upgrade to the latest libxslt libraries and if there's still a problem, report it to the libxslt mailing list (to be found at http://xmlsoft.org) Previous Comments: [2003-06-13 07:36:56] [EMAIL PROTECTED] Did you happen to change the libxslt/libxml versions the same time..? You're not using the latest of them. [2003-06-13 03:39:38] christian dot hang at web dot de Description: After an upgrade (from 4.3.0 to 4.3.2), some of the XSL transformation (handled by domxml) where not working correctly anymore. It seems, that XSL functions (like concat) forget the current node, that they should use to evualate relative XPath-Expression in their arguments, when an absolute Path is given in a prior argument. The example code demonstrates that behavior (compare description of Expected result and Actual result). A quick workaround is the addition of the current()-function in the relative path expressions, as that will fix the problem. But as far as I know, that is not required by the standard. If one switches the two arguments (concat(@nr, //testnode/@test)), everything works fine, the current() is not necessary and @nr is evaluated correctly. As the order of the arguments has an effect on the path evaluation (which it should not), I figure that there is problem. The versions of the libraries used: DOM/XML API Version 20020815 libxml Version 20419 HTML Support enabled XPath Support enabled XPointer Support enabled DOM/XSLT enabled libxslt Version 1.0.20 libxslt compiled against libxml Version 2.4.24 DOM/EXSLT enabled libexslt Version 1.0.20 I have to admit that I cannot compare the library versions used here with the ones I used for 4.3.0 version where everything worked okay (system crashed - long and ugly story), so it might very well be a problem of the libraries instead of the domxml extenstion. Reproduce code: --- $xml = ?xml version=\1.0\ ?roottestnode test=\somevalue\node nr=\1\/node nr=\2\/node nr=\3\//testnode/roo\ t; $xml_doc = domxml_open_mem($xml); $xsl_text=?xml version=\1.0\ ? xsl:stylesheet xmlns:xsl=\http://www.w3.org/1999/XSL/Transform\; version=\1.0\ xsl:output method=\xml\/ xsl:template match=\root\ new_root xsl:for-each select=\testnode/node\ xsl:value-of select=\concat(//testnode/@test, @nr)\/ - /xsl:for-each /new_root /xsl:template /xsl:stylesheet; $xsl = domxml_open_mem($xsl_text); $xsl_doc = domxml_xslt_stylesheet_doc($xsl); $res = $xsl_doc-process($xml_doc); Expected result: A dump of the $res result tree should produce the following ?xml version=1.0? new_rootsomevalue1 - somevalue2 - somevalue3 - /new_root and it does, if the concat expression in the example script is changed to concat(//testnode/@test, current()/@nr) Actual result: -- A dump of the $res result tree does produce the following ?xml version=1.0? new_rootsomevalue - somevalue - somevalue - /new_root The nr-attribute value is not concatenated to the value of the test-attribute in testnode. -- Edit this bug report at http://bugs.php.net/?id=24168edit=1
#24007 [Asn-WFx]: register_globals + request arrays = missing register_global variables
ID: 24007
Updated by: [EMAIL PROTECTED]
Reported By: gateschris at yahoo dot com
-Status: Assigned
+Status: Wont fix
Bug Type: Scripting Engine problem
Operating System: Linux version 2.2.19
PHP Version: 4.3.2
Assigned To: iliaa
New Comment:
You should either use the recommended _REQUEST super global or not
create values with the same names in both POST GET if you need to use
register_globals.
Previous Comments:
[2003-06-04 10:32:57] [EMAIL PROTECTED]
The fix only fixed the _REQUEST, which is what you should be using. The
register_global variables still have the same issue. I will look into
this issue to see if it can be easily fixed, but I suspect there is a
greater chance this will be marked won't fix.
[2003-06-04 05:59:48] gateschris at yahoo dot com
Hi Philip,
Yes, sorry i did not find that report before, but bug report #23454
relates to a 4.3.2RC3-dev not 4.3.2 release version, and the bug
report is closed, and [EMAIL PROTECTED] mentions that they have
patched the cvs on the 13 May (before the release version), so
perhaps something is still wrong here, it seems like a serious
bug in a release version to me.
I will wait for the next point release (incase the patch was passed
over this current release).
Cheers,
[2003-06-04 00:39:31] [EMAIL PROTECTED]
Verified and related to bug #23454 Note that $_REQUEST works perfectly
here...
?php
if (@$_POST['action'] == 'submit') {
print pre;
print_r(array('get' = $_GET,
'post'= $_POST,
'request' = $_REQUEST,
'foo' = $foo));
} else {
?
form method=POST action=?php echo $_SERVER['PHP_SELF']
??foo[a][a]=a
brinput type=text name=foo[] value=b
brinput type=text name=foo[a][b] value=c
brinput type=submit name=submit value=submit
input type=hidden name=action value=submit
/form
?php
}
?
Outputs:
Array
(
[get] = Array
(
[foo] = Array
(
[a] = Array
(
[a] = a
)
)
)
[post] = Array
(
[foo] = Array
(
[0] = b
[a] = Array
(
[b] = c
)
)
[submit] = submit
[action] = submit
)
[request] = Array
(
[foo] = Array
(
[a] = Array
(
[a] = a
[b] = c
)
[0] = b
)
[submit] = submit
[action] = submit
)
[foo] = Array
(
[0] = b
[a] = Array
(
[b] = c
)
)
)
[2003-06-04 00:04:38] gateschris at yahoo dot com
when performing a post in a form, if the url contains a variable of the
form name[key]=value, and php has register_globals enabled, the
name/key is not registered.
example form:
form enctype=multipart/form-data method=post
action=test.php?name[key][key2]=value
input name=name[key][key3] value=value type=hidden
/form
example php:
?
print_r($name);
?
with register_globals on, this script will only remember the
name[key][key3] and not the name[key][key2], please note that i have
not tested this script, its just a summary of what i have found in a
much larger script, and ive already reverted back to an older version
of php and im to lazy to try it on another machine.
--
Edit this bug report at http://bugs.php.net/?id=24007edit=1
#24169 [Opn]: session cookie being incorrectly sent
ID: 24169 User updated by: steveh at brendata dot co dot uk Reported By: steveh at brendata dot co dot uk Status: Open Bug Type: Session related Operating System: NT4 SP6a PHP Version: 4.3.2 New Comment: This now seems to fall into the same description a sthe other session bugs, failing randomly, I thought we'd caught the definitive problem here, dont' understand how the cookies became corrrupted though? I wish I'd traced the session when it was wrong, as new cookies were appearing during my tests (id=id rather than PHPSESSID=id. Previous Comments: [2003-06-13 10:16:13] steveh at brendata dot co dot uk Now I'm totally foxed, it's working again, but IIS has not been restarted, neither has the browser on my PC and notjing has changed in the INI file. I'll get the vardump of $_COOKIE again. There is now just that single cookie set PHPSESSID. [2003-06-13 10:12:55] steveh at brendata dot co dot uk I'm just going to tcpdump the traffic going between the IIS and the Client PC to see whether that shows more. [2003-06-13 10:12:11] steveh at brendata dot co dot uk That looks fine, I also tried on the larger app that is really causing the problems and that looks fine as well? HTTP/1.1 200 OK Server: Microsoft-IIS/4.0 Date: Fri, 13 Jun 2003 15:10:57 GMT Content-type: text/html X-Powered-By: PHP/4.3.2 Set-Cookie: PHPSESSID=d1ed576c229f8c72edf65eee70a1bd9f; path=/ Expires: Thu, 19 Nov 1981 08:52:00 GMT Cache-Control: no-store, no-cache, must-revalidate, post-check=0, pre-check=0 Pragma: no-cache [2003-06-13 10:05:57] [EMAIL PROTECTED] forgot the auth parameter: -auth=id:pw [2003-06-13 10:04:58] [EMAIL PROTECTED] Uh..maybe it's easier if you use lynx: # lynx -dump -head http://localhost/test.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/24169 -- Edit this bug report at http://bugs.php.net/?id=24169edit=1
#24007 [WFx-Opn]: register_globals + request arrays = missing register_global variables
ID: 24007
Updated by: [EMAIL PROTECTED]
Reported By: gateschris at yahoo dot com
-Status: Wont fix
+Status: Open
Bug Type: Scripting Engine problem
Operating System: Linux version 2.2.19
PHP Version: 4.3.2
Assigned To: iliaa
New Comment:
I'm not ready to give up on this one. This used to work and really
should be fixed.
Previous Comments:
[2003-06-13 10:19:21] [EMAIL PROTECTED]
You should either use the recommended _REQUEST super global or not
create values with the same names in both POST GET if you need to use
register_globals.
[2003-06-04 10:32:57] [EMAIL PROTECTED]
The fix only fixed the _REQUEST, which is what you should be using. The
register_global variables still have the same issue. I will look into
this issue to see if it can be easily fixed, but I suspect there is a
greater chance this will be marked won't fix.
[2003-06-04 05:59:48] gateschris at yahoo dot com
Hi Philip,
Yes, sorry i did not find that report before, but bug report #23454
relates to a 4.3.2RC3-dev not 4.3.2 release version, and the bug
report is closed, and [EMAIL PROTECTED] mentions that they have
patched the cvs on the 13 May (before the release version), so
perhaps something is still wrong here, it seems like a serious
bug in a release version to me.
I will wait for the next point release (incase the patch was passed
over this current release).
Cheers,
[2003-06-04 00:39:31] [EMAIL PROTECTED]
Verified and related to bug #23454 Note that $_REQUEST works perfectly
here...
?php
if (@$_POST['action'] == 'submit') {
print pre;
print_r(array('get' = $_GET,
'post'= $_POST,
'request' = $_REQUEST,
'foo' = $foo));
} else {
?
form method=POST action=?php echo $_SERVER['PHP_SELF']
??foo[a][a]=a
brinput type=text name=foo[] value=b
brinput type=text name=foo[a][b] value=c
brinput type=submit name=submit value=submit
input type=hidden name=action value=submit
/form
?php
}
?
Outputs:
Array
(
[get] = Array
(
[foo] = Array
(
[a] = Array
(
[a] = a
)
)
)
[post] = Array
(
[foo] = Array
(
[0] = b
[a] = Array
(
[b] = c
)
)
[submit] = submit
[action] = submit
)
[request] = Array
(
[foo] = Array
(
[a] = Array
(
[a] = a
[b] = c
)
[0] = b
)
[submit] = submit
[action] = submit
)
[foo] = Array
(
[0] = b
[a] = Array
(
[b] = c
)
)
)
[2003-06-04 00:04:38] gateschris at yahoo dot com
when performing a post in a form, if the url contains a variable of the
form name[key]=value, and php has register_globals enabled, the
name/key is not registered.
example form:
form enctype=multipart/form-data method=post
action=test.php?name[key][key2]=value
input name=name[key][key3] value=value type=hidden
/form
example php:
?
print_r($name);
?
with register_globals on, this script will only remember the
name[key][key3] and not the name[key][key2], please note that i have
not tested this script, its just a summary of what i have found in a
much larger script, and ive already reverted back to an older version
of php and im to lazy to try it on another machine.
--
Edit this bug report at http://bugs.php.net/?id=24007edit=1
#24177 [NEW]: header() call doesn't replace 404 status code
From: [EMAIL PROTECTED] Operating system: Linux PHP version: 4.3.2 PHP Bug Type: Apache2 related Bug description: header() call doesn't replace 404 status code Description: Using Apache 2.0.46 and PHP 4.3.2 compiled with --with-apxs2 When a PHP page is used as an ErrorDocument page, calling any variation of header() to replace the status code doesn't work. The client always receive 404. For example, try downloading from se.php.net: http://se.php.net/get/php-4.3.2.tar.gz/from/this/mirror You'll se that a Location header has been added (by the call to header() in /include/do-download.inc) but the status returned is still 404, not 302 as expected. -- Edit bug report at http://bugs.php.net/?id=24177edit=1 -- Try a CVS snapshot: http://bugs.php.net/fix.php?id=24177r=trysnapshot Fixed in CVS: http://bugs.php.net/fix.php?id=24177r=fixedcvs Fixed in release: http://bugs.php.net/fix.php?id=24177r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=24177r=needtrace Try newer version: http://bugs.php.net/fix.php?id=24177r=oldversion Not developer issue:http://bugs.php.net/fix.php?id=24177r=support Expected behavior: http://bugs.php.net/fix.php?id=24177r=notwrong Not enough info:http://bugs.php.net/fix.php?id=24177r=notenoughinfo Submitted twice:http://bugs.php.net/fix.php?id=24177r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=24177r=globals PHP 3 support discontinued: http://bugs.php.net/fix.php?id=24177r=php3 Daylight Savings: http://bugs.php.net/fix.php?id=24177r=dst IIS Stability: http://bugs.php.net/fix.php?id=24177r=isapi Install GNU Sed:http://bugs.php.net/fix.php?id=24177r=gnused
#24178 [NEW]: Post an array
From: fernando at reweb dot com dot br Operating system: Free BSD 4.8 PHP version: 4.3.2 PHP Bug Type: Arrays related Bug description: Post an array Description: When I post an array and try do recover it I can´t do it. The result values doesn´t fetch the posted values. Reproduce code: --- ##form.php## form action=\send.php\ input type=\checkbox\ name=\opt[]\ value=\aaa\ input type=\checkbox\ name=\opt[]\ value=\bbb\ input type=\checkbox\ name=\opt[]\ value=\ccc\ input type=\checkbox\ name=\opt[]\ value=\ddd\ input type=\checkbox\ name=\opt[]\ value=\eee\ input type=\submit\ value=\Send\ ##send.php## $vars = $_POST; $opcoes = $vars['opt']; echo $opcoes[0]###$opcoes[1]###$opcoes[2]###$opcoes[3]###$opcoes[4]; ## The result should be aaa###bbb###ccc###ddd###eee, but it prints A###r###r###a###y (the word Array) Expected result: aaa###bbb###ccc###ddd###eee Actual result: -- A###r###r###a###y -- Edit bug report at http://bugs.php.net/?id=24178edit=1 -- Try a CVS snapshot: http://bugs.php.net/fix.php?id=24178r=trysnapshot Fixed in CVS: http://bugs.php.net/fix.php?id=24178r=fixedcvs Fixed in release: http://bugs.php.net/fix.php?id=24178r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=24178r=needtrace Try newer version: http://bugs.php.net/fix.php?id=24178r=oldversion Not developer issue:http://bugs.php.net/fix.php?id=24178r=support Expected behavior: http://bugs.php.net/fix.php?id=24178r=notwrong Not enough info:http://bugs.php.net/fix.php?id=24178r=notenoughinfo Submitted twice:http://bugs.php.net/fix.php?id=24178r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=24178r=globals PHP 3 support discontinued: http://bugs.php.net/fix.php?id=24178r=php3 Daylight Savings: http://bugs.php.net/fix.php?id=24178r=dst IIS Stability: http://bugs.php.net/fix.php?id=24178r=isapi Install GNU Sed:http://bugs.php.net/fix.php?id=24178r=gnused
#24179 [NEW]: Test
From: as at as dot com Operating system: win2k PHP version: 4.3.1 PHP Bug Type: Feature/Change Request Bug description: Test Description: test Reproduce code: --- test Expected result: test Actual result: -- test -- Edit bug report at http://bugs.php.net/?id=24179edit=1 -- Try a CVS snapshot: http://bugs.php.net/fix.php?id=24179r=trysnapshot Fixed in CVS: http://bugs.php.net/fix.php?id=24179r=fixedcvs Fixed in release: http://bugs.php.net/fix.php?id=24179r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=24179r=needtrace Try newer version: http://bugs.php.net/fix.php?id=24179r=oldversion Not developer issue:http://bugs.php.net/fix.php?id=24179r=support Expected behavior: http://bugs.php.net/fix.php?id=24179r=notwrong Not enough info:http://bugs.php.net/fix.php?id=24179r=notenoughinfo Submitted twice:http://bugs.php.net/fix.php?id=24179r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=24179r=globals PHP 3 support discontinued: http://bugs.php.net/fix.php?id=24179r=php3 Daylight Savings: http://bugs.php.net/fix.php?id=24179r=dst IIS Stability: http://bugs.php.net/fix.php?id=24179r=isapi Install GNU Sed:http://bugs.php.net/fix.php?id=24179r=gnused
#24179 [Opn-Bgs]: Test
ID: 24179 Updated by: [EMAIL PROTECTED] Reported By: as at as dot com -Status: Open +Status: Bogus Bug Type: Feature/Change Request Operating System: win2k PHP Version: 4.3.1 New Comment: test elsewhere.. Previous Comments: [2003-06-13 14:49:47] as at as dot com Description: test Reproduce code: --- test Expected result: test Actual result: -- test -- Edit this bug report at http://bugs.php.net/?id=24179edit=1
#24177 [Opn-Fbk]: header() call doesn't replace 404 status code
ID: 24177 Updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] -Status: Open +Status: Feedback Bug Type: Apache2 related Operating System: Linux PHP Version: 4.3.2 New Comment: # lynx -dump -head http://se.php.net/imap HTTP/1.1 200 OK Date: Fri, 13 Jun 2003 19:17:17 GMT Server: Apache/2.0.46 (Unix) mod_ssl/2.0.46 OpenSSL/0.9.6b PHP/4.3.2 X-Powered-By: PHP/4.3.2 Content-language: en Set-Cookie: COUNTRY=FIN%2C213.243.181.8; expires=Fri, 20-Jun-2003 19:17:17 GMT; path=/; domain=.php.net Status: 200 OK Last-Modified: Fri, 13 Jun 2003 19:09:38 GMT Vary: Cookie Connection: close Content-Type: text/html;charset=ISO-8859-1 That works just fine? Previous Comments: [2003-06-13 13:42:09] [EMAIL PROTECTED] Description: Using Apache 2.0.46 and PHP 4.3.2 compiled with --with-apxs2 When a PHP page is used as an ErrorDocument page, calling any variation of header() to replace the status code doesn't work. The client always receive 404. For example, try downloading from se.php.net: http://se.php.net/get/php-4.3.2.tar.gz/from/this/mirror You'll se that a Location header has been added (by the call to header() in /include/do-download.inc) but the status returned is still 404, not 302 as expected. -- Edit this bug report at http://bugs.php.net/?id=24177edit=1
#24178 [Opn-Bgs]: Post an array
ID: 24178 Updated by: [EMAIL PROTECTED] Reported By: fernando at reweb dot com dot br -Status: Open +Status: Bogus Bug Type: Arrays related Operating System: Free BSD 4.8 PHP Version: 4.3.2 New Comment: Default send method for forms is GET, not POST. Change: form action=send.php to: form action=send.php method=POST and it will work fine. Previous Comments: [2003-06-13 14:49:44] fernando at reweb dot com dot br Description: When I post an array and try do recover it I can´t do it. The result values doesn´t fetch the posted values. Reproduce code: --- ##form.php## form action=\send.php\ input type=\checkbox\ name=\opt[]\ value=\aaa\ input type=\checkbox\ name=\opt[]\ value=\bbb\ input type=\checkbox\ name=\opt[]\ value=\ccc\ input type=\checkbox\ name=\opt[]\ value=\ddd\ input type=\checkbox\ name=\opt[]\ value=\eee\ input type=\submit\ value=\Send\ ##send.php## $vars = $_POST; $opcoes = $vars['opt']; echo $opcoes[0]###$opcoes[1]###$opcoes[2]###$opcoes[3]###$opcoes[4]; ## The result should be aaa###bbb###ccc###ddd###eee, but it prints A###r###r###a###y (the word Array) Expected result: aaa###bbb###ccc###ddd###eee Actual result: -- A###r###r###a###y -- Edit this bug report at http://bugs.php.net/?id=24178edit=1
#24180 [NEW]: foobar
From: [EMAIL PROTECTED] Operating system: foobar PHP version: 4.3.1 PHP Bug Type: *General Issues Bug description: foobar Description: foo bar Reproduce code: --- foo bar Expected result: foo bar Actual result: -- foo bar -- Edit bug report at http://bugs.php.net/?id=24180edit=1 -- Try a CVS snapshot: http://bugs.php.net/fix.php?id=24180r=trysnapshot Fixed in CVS: http://bugs.php.net/fix.php?id=24180r=fixedcvs Fixed in release: http://bugs.php.net/fix.php?id=24180r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=24180r=needtrace Try newer version: http://bugs.php.net/fix.php?id=24180r=oldversion Not developer issue:http://bugs.php.net/fix.php?id=24180r=support Expected behavior: http://bugs.php.net/fix.php?id=24180r=notwrong Not enough info:http://bugs.php.net/fix.php?id=24180r=notenoughinfo Submitted twice:http://bugs.php.net/fix.php?id=24180r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=24180r=globals PHP 3 support discontinued: http://bugs.php.net/fix.php?id=24180r=php3 Daylight Savings: http://bugs.php.net/fix.php?id=24180r=dst IIS Stability: http://bugs.php.net/fix.php?id=24180r=isapi Install GNU Sed:http://bugs.php.net/fix.php?id=24180r=gnused
#24180 [Opn-Bgs]: foobar
ID: 24180 Updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] -Status: Open +Status: Bogus Bug Type: *General Issues Operating System: foobar PHP Version: 4.3.1 New Comment: just test. Previous Comments: [2003-06-13 15:29:54] [EMAIL PROTECTED] Description: foo bar Reproduce code: --- foo bar Expected result: foo bar Actual result: -- foo bar -- Edit this bug report at http://bugs.php.net/?id=24180edit=1
#24169 [Opn-Bgs]: session cookie being incorrectly sent
ID: 24169 Updated by: [EMAIL PROTECTED] Reported By: steveh at brendata dot co dot uk -Status: Open +Status: Bogus Bug Type: Session related Operating System: NT4 SP6a PHP Version: 4.3.2 New Comment: Reopen if it happens again and you can prove it's some bug in PHP and not in your script/browser/IIS/etc.. Previous Comments: [2003-06-13 10:28:40] steveh at brendata dot co dot uk This now seems to fall into the same description a sthe other session bugs, failing randomly, I thought we'd caught the definitive problem here, dont' understand how the cookies became corrrupted though? I wish I'd traced the session when it was wrong, as new cookies were appearing during my tests (id=id rather than PHPSESSID=id. [2003-06-13 10:16:13] steveh at brendata dot co dot uk Now I'm totally foxed, it's working again, but IIS has not been restarted, neither has the browser on my PC and notjing has changed in the INI file. I'll get the vardump of $_COOKIE again. There is now just that single cookie set PHPSESSID. [2003-06-13 10:12:55] steveh at brendata dot co dot uk I'm just going to tcpdump the traffic going between the IIS and the Client PC to see whether that shows more. [2003-06-13 10:12:11] steveh at brendata dot co dot uk That looks fine, I also tried on the larger app that is really causing the problems and that looks fine as well? HTTP/1.1 200 OK Server: Microsoft-IIS/4.0 Date: Fri, 13 Jun 2003 15:10:57 GMT Content-type: text/html X-Powered-By: PHP/4.3.2 Set-Cookie: PHPSESSID=d1ed576c229f8c72edf65eee70a1bd9f; path=/ Expires: Thu, 19 Nov 1981 08:52:00 GMT Cache-Control: no-store, no-cache, must-revalidate, post-check=0, pre-check=0 Pragma: no-cache [2003-06-13 10:05:57] [EMAIL PROTECTED] forgot the auth parameter: -auth=id:pw 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/24169 -- Edit this bug report at http://bugs.php.net/?id=24169edit=1
#24178 [Bgs]: Post an array
ID: 24178 Updated by: [EMAIL PROTECTED] Reported By: fernando at reweb dot com dot br Status: Bogus Bug Type: Arrays related Operating System: Free BSD 4.8 PHP Version: 4.3.2 New Comment: Why do you keep escaping the quotes?? It's not necessary. And in any case, you're just doing something wrong. Please ask further support questions elsewhere, there is no bug here. Previous Comments: [2003-06-13 15:31:59] fernando at reweb dot com dot br My form was in that way: form action=\send.php\ method=\post\ and didn´t work too. [2003-06-13 15:28:51] [EMAIL PROTECTED] Default send method for forms is GET, not POST. Change: form action=send.php to: form action=send.php method=POST and it will work fine. [2003-06-13 14:49:44] fernando at reweb dot com dot br Description: When I post an array and try do recover it I can´t do it. The result values doesn´t fetch the posted values. Reproduce code: --- ##form.php## form action=\send.php\ input type=\checkbox\ name=\opt[]\ value=\aaa\ input type=\checkbox\ name=\opt[]\ value=\bbb\ input type=\checkbox\ name=\opt[]\ value=\ccc\ input type=\checkbox\ name=\opt[]\ value=\ddd\ input type=\checkbox\ name=\opt[]\ value=\eee\ input type=\submit\ value=\Send\ ##send.php## $vars = $_POST; $opcoes = $vars['opt']; echo $opcoes[0]###$opcoes[1]###$opcoes[2]###$opcoes[3]###$opcoes[4]; ## The result should be aaa###bbb###ccc###ddd###eee, but it prints A###r###r###a###y (the word Array) Expected result: aaa###bbb###ccc###ddd###eee Actual result: -- A###r###r###a###y -- Edit this bug report at http://bugs.php.net/?id=24178edit=1
#23764 [Com]: session spans 2 or more IE windows, PHP doesn't let me create a unique session
ID: 23764 Comment by: ky at jelly dot com Reported By: mfoxx at hotmail dot com Status: Bogus Bug Type: Session related Operating System: RH 6.2 PHP Version: 4.3.0 New Comment: the ice caps are melting, nyah nyah nyah the world is drowning, nyah nyah nyah Previous Comments: [2003-05-28 12:36:19] mfoxx at hotmail dot com Just for the record, and for posterity who might read this thread and wonder, the solution was to change both the session name AND the session id BEFORE calling session_start() in the first script loaded into the new window. Thereafter in that new window (popup), before each call to session_start(), you only have to change the session name (otherwise it will default back to the PHPSESSID). This gave me the results I expected, the problem really was that it was not a correctly documented process, and so it appeared to be a bug at first. I have since submitted this to the documentation team to have them consider clarifying their documentation. [2003-05-28 03:44:02] heng at yahoo dot com even you using other language like micro$oft' ASP, you also will get the same result. So no blaming to php, as rasmus said Do a little bit of homework please and give us something to go on. [2003-05-23 11:32:10] [EMAIL PROTECTED] Actually, the fact that you don't buy PHP gives us all the freedom in the world to be rude and unhelpful. Compare the result of all this with you having submitted a bug report to Microsoft. They would have politely ignored you. We rudely solved your problem within 24 hours. Which would you rather have? You are in no position to complain here and I would advise you to stop flaming the hands that feed you. [2003-05-23 11:21:59] mfoxx at hotmail dot com Ya know, if the session_name() was the only problem, and the session_name() is by default globally always PHPSESSID, then why would simply opening up a new internet explorer browser window manually and loading myscriptB.php into it NOT have that behavior? I'll tell you why, cause its a combination of both the session_id and the session_name needing to be different. Clearly, the PHP documentation doesn't spell this out in any detail, and so I will be submitting a request to them to add some description of how to correctly start a new session and abandon any old or inherited one for that window. That's not an easy, intuitive, or simple concept that any old programmer would catch right away --- that two seperately opened windows would have their own unique session_id, and therefore the common PHPSESSID name wouldn't matter, whereas spawning a child window through an a href tag would copy over the default session_id and so the only way to diffrentiate in that case is to change not only the session_id but the default session_name as well. You almighty PHP gods clearly knew that, since you responded to me by saying so of course the last accessed script... Us lowly PHP minions though aren't as well versed in all the ins and outs. Reading less than clear documentation on the subject, as well as posting the same question to several different forums, and having NOONE that understood that quirk, clearly it appeared to me to be unexpected behavior, ie A BUG. I apologize for so severely wasting your time. I wish at first glance someone might have read a little closer my original post (cause my omission was clear and obvious then) and pointed it out, instead of taking the easy way out and just blaming it on my older version of PHP. That was by beef in the the first place, that it didn't appear to be version related, and I was right. It's your bad handling that escalated this discussion beyond a simple support open-and-close case. Your collective self-righteous and condescending attitude doesn't help anyone here. You can't possibly expect that every single USER of PHP would be so well versed in all the insides of PHP, like looking at session files and cookies and doing traces, etc. People of all different levels of knowledge come to the PHP website, and its several different tools, FOR SUPPORT. I guess you assume otherwise since we don't really buy PHP like we would a product from microsoft. That doesn't just let you off the hook, free to be rude and unhelpful to those that are genuinely seeking assistance. The bug reporting tool is clearly focused on documenting unexpected or buggy behavior and trying to find out the solution to it. The trouble is that you feel your job is not support in any sense, and so you assume initially that every post here is BOGUS until we the inexperienced find a way to prove otherwise. Guilty until proven innocent. Very poor public relations
#24133 [Opn-Bgs]: mysql.connect_timeout has no effect
ID: 24133 Updated by: [EMAIL PROTECTED] Reported By: nospam at unclassified dot de -Status: Open +Status: Bogus Bug Type: MySQL related Operating System: Windows 2000 Pro PHP Version: 4.3.2 New Comment: connect_timeout specifies the number of seconds the server is waiting for a connectpacket before he responding a bad handshake. Previous Comments: [2003-06-11 13:58:57] nospam at unclassified dot de I tried to connect to a mysql server that was not accessible. mysql_connect() gave me an error 10060, that's ok. But it did that after abt. 20 seconds, and in conjunction with a fatal error that said my script timed out after 10 seconds. And that's although I set the 'mysql.connect_timeout' setting to 4 seconds. It seems the 'mysql.connect_timeout' setting in my php.ini has no effect on the behaviour of mysql_connect(). I have checked the setting with ini_get() and it was correct. I have found the bug in PHP 4.3.1, an upgrade to 4.3.2 did not help. Can it be that connection timeouts aren't supported under Windows platform? In that case, this should be documented. -- Edit this bug report at http://bugs.php.net/?id=24133edit=1
#24181 [NEW]: mysql_info() causes segfault
From: tmiller at web-1hosting dot net Operating system: Linux-2.4.20 PHP version: 4.3.2 PHP Bug Type: Reproducible crash Bug description: mysql_info() causes segfault Description: When using mysql_info() whithin a class if the link identifier is passed using $this-connection_id php will crash. This happens both with apache module and using CLI. Reproduce code: --- Code may be found at: http://php.web-1hosting.net/bugs/mysql_info_crash.html Expected result: I expect to see the string here: Rows matched: 1 Changed: 0 Warnings: 0 on the screen/webpage. Actual result: -- [EMAIL PROTECTED]:~/Developement/htdocs$ ./mysql.php Segmentation fault (core dumped) [EMAIL PROTECTED]:~/Developement/htdocs$ gdb /usr/bin/php core (gdb) bt #0 0x08152672 in zend_fetch_resource (passed_id=0x4, default_id=-1, resource_type_name=0x4001dc53 MySQL-Link, found_resource_type=0x0, num_resource_types=2) at /home/tmiller/Php/php-4.3.2/Zend/zend_list.c:123 #1 0x40019bf9 in zif_mysql_info () from /usr/lib/php/extensions/mysql.so #2 0x08159c7a in execute (op_array=0x8232be4) at /home/tmiller/Php/php-4.3.2/Zend/zend_execute.c:1606 #3 0x08159a1b in execute (op_array=0x822cfe4) at /home/tmiller/Php/php-4.3.2/Zend/zend_execute.c:1650 #4 0x0814d4fb in zend_execute_scripts (type=8, retval=0x0, file_count=3) at /home/tmiller/Php/php-4.3.2/Zend/zend.c:869 #5 0x0812787f in php_execute_script (primary_file=0xb820) at /home/tmiller/Php/php-4.3.2/main/main.c:1671 #6 0x0815e788 in main (argc=3, argv=0xb8b4) at /home/tmiller/Php/php-4.3.2/sapi/cli/php_cli.c:806 #7 0x4033bbb4 in __libc_start_main () from /lib/libc.so.6 -- Edit bug report at http://bugs.php.net/?id=24181edit=1 -- Try a CVS snapshot: http://bugs.php.net/fix.php?id=24181r=trysnapshot Fixed in CVS: http://bugs.php.net/fix.php?id=24181r=fixedcvs Fixed in release: http://bugs.php.net/fix.php?id=24181r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=24181r=needtrace Try newer version: http://bugs.php.net/fix.php?id=24181r=oldversion Not developer issue:http://bugs.php.net/fix.php?id=24181r=support Expected behavior: http://bugs.php.net/fix.php?id=24181r=notwrong Not enough info:http://bugs.php.net/fix.php?id=24181r=notenoughinfo Submitted twice:http://bugs.php.net/fix.php?id=24181r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=24181r=globals PHP 3 support discontinued: http://bugs.php.net/fix.php?id=24181r=php3 Daylight Savings: http://bugs.php.net/fix.php?id=24181r=dst IIS Stability: http://bugs.php.net/fix.php?id=24181r=isapi Install GNU Sed:http://bugs.php.net/fix.php?id=24181r=gnused
#24132 [Opn-Bgs]: insert an array with keyed values into a mysql table
ID: 24132
Updated by: [EMAIL PROTECTED]
Reported By: wayne-php at waynef dot com
-Status: Open
+Status: Bogus
Bug Type: Feature/Change Request
Operating System: freebsd
PHP Version: 4.3.2
New Comment:
This is too special and won't work with lot of MySQL specific column
types/syntax.
MySQL-Syntax:
insert into foo (a) values (GeomFromText('point(10 10)'));
insert into foo (a,b) values (1, a+1);
How will you realize these queries with your function? Quoting all
values doesn't work.
Also you would need a lot of additional parameters for insert delayed,
priority and duplicate keys.
Previous Comments:
[2003-06-11 13:54:08] wayne-php at waynef dot com
i have created a function i found useful. i am sure there are better
ways to doing this and it doesn't do much error checking but you get
the idea and how this may be a useful feature...
/**
** this function will take in an array with keyed values
** and place the values into the
** same name columns as the key name.
**
** bool mysql_insert_array(array, table_name)
**
** ie...
**
** $array = array(id = $id, md5 = md5($id));
**
** mysql_insert_array($array, users);
**/
function mysql_insert_array($array, $table) {
$keys = array_keys($array);
for ($index = 0; $index count($array); $index++) {
if ($index != 0) {
$columns .= ,;
$values .= ,;
}
/** construct the column names from the array **/
$columns .= $keys[$index];
if (is_int($array[$keys[$index]])) {
$values .= $array[$keys[$index]];
} else {
$values .= ' .
mysql_real_escape_string($array[$keys[$index]]) . ';
}
}
$query = INSERT INTO ` . $table . ` ( . $columns . ) VALUES (
. $values . );
if (($result = mysql_query($query)) == 0)
return(0);
if (mysql_affected_rows() == 1)
return(1);
else
return(0);
}
--
Edit this bug report at http://bugs.php.net/?id=24132edit=1
#24033 [Com]: changed behaviour of fread() ?
ID: 24033
Comment by: bob at bravenet dot com
Reported By: thomas at nimstad dot com
Status: Bogus
Bug Type: Sockets related
Operating System: Win32
PHP Version: 4.3.2
New Comment:
I absolutely disagree with the conclusion on this bug. To outright
change the functionality of fread like this without any notice
whatsoever and especially in a minor revision is totally irresponsible
as a company.
To date fread has always taken a $length parameter and php handled the
buffering. And the docs still say that it will. When making a change
like this, at a minimum, update the docs so we don't waste a couple
days trying to find out that you changed the functionality of fread.
Previous Comments:
[2003-06-06 03:17:06] [EMAIL PROTECTED]
This is your loop:
while (!feof($fp) $length 0) {
$size = min(1024, $length);
$reply .= fread($fp, $size);
$length -= $size;
}
It looks wrong to me, since you are not checking the return value of
fread and are just assuming that it read the chunk you asked for.
This is a better loop:
while ($length 0) {
$size = min(8192, $length);
$data = fread($fp, $size);
if (strlen($data) == 0) {
break; // EOF
}
$reply .= $data;
$length -= strlen($data);
}
It is recommended that you fread() in chunks of 8kb from sockets, as
you will get better performance than using a smaller value. Using a
larger value is wasteful as the streams layer will only allocate in 8KB
chunks; Win32 has a maximum internal packet size of 8KB too.
I'm marking this as bogus since it is the expected behaviour of PHP (I
actually spent a couple of days correcting and testing this for
HTTP/1.1 keep alives).
[2003-06-06 03:06:27] thomas at nimstad dot com
Ok. Since I'm was not the only having the problem I examined it some
more... here we goes again...
Problem #1: When using a chunk size = 8192 bytes it's just to
concatenate the data and continue reading (as examplified in the
documentation). So to what I understand, this is not a bug, rather than
a timing issue that fread() returns the number of bytes available at
the moment? Anyway, in this case problem #2 doesn't occurs!!
Problem #2: The fread() still hangs until timeout if I try to read data
in chunks of = 4096 bytes!!
[2003-06-06 01:46:52] [EMAIL PROTECTED]
From the manual:
When reading from network streams or pipes, such as those returned when
reading remote files or from popen() and proc_open(), reading will stop
after a packet is available. This means that you should collect the
data together in chunks as shown in the example below.
A bug existed in 4.3.0-1 that made it work, so, it's not considered
changed behavior, just a bug. This bug, for example, did not exist in
4.2.3
Regarding Thomas problem #2, not sure about that, will see what Wez
has to say.
Regarding the last proposed example by PJ, just use
file_get_contents().
[2003-06-05 14:56:49] PJ at Elitegamer dot com
I too am experiencing this changed behavior. Previously, my code was as
follows:
$contents = fread ($fp, 2097152);
And that would return up to 2mb from the given socket. In my case, the
socket was a fopen() url.
However, when I upgraded to PHP 4.3.2 it would ONLY return 2481 bytes
no matter what. As a quick fix I had to move the fread() inside of a
while loop, in order to fix this issue. Like this:
$contents = ;
while (($data = fread ($fp, 2097152)) !== )
{
$contents .= $data;
}
The only change on my system and the files being read was my upgrading
to PHP 4.3.2. This definitely appears to be changed behavior of
fread().
-PJ
[2003-06-05 02:56:25] thomas at nimstad dot com
I don't think it's a documentation problem of fread().
The posted code worked fine in 4.3.1 but failed when upgrading to 4.3.2
(Win32 version).
Problem 1: fread($fp, 4096) returns max 1024 bytes.
Problem 2: fread($fp, 1024) hangs until timeout if buffer only contains
1023 bytes.
/Thomas
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/24033
--
Edit this bug report at http://bugs.php.net/?id=24033edit=1
#24033 [Bgs]: changed behaviour of fread() ?
ID: 24033
Updated by: [EMAIL PROTECTED]
Reported By: thomas at nimstad dot com
Status: Bogus
Bug Type: Sockets related
Operating System: Win32
PHP Version: 4.3.2
New Comment:
bob at bravenet dot com:
That is just one of the reasons why we reinstated the pre 4.3.x
behaviour.
Please check your history before complaining.
Previous Comments:
[2003-06-13 17:29:07] bob at bravenet dot com
I absolutely disagree with the conclusion on this bug. To outright
change the functionality of fread like this without any notice
whatsoever and especially in a minor revision is totally irresponsible
as a company.
To date fread has always taken a $length parameter and php handled the
buffering. And the docs still say that it will. When making a change
like this, at a minimum, update the docs so we don't waste a couple
days trying to find out that you changed the functionality of fread.
[2003-06-06 03:17:06] [EMAIL PROTECTED]
This is your loop:
while (!feof($fp) $length 0) {
$size = min(1024, $length);
$reply .= fread($fp, $size);
$length -= $size;
}
It looks wrong to me, since you are not checking the return value of
fread and are just assuming that it read the chunk you asked for.
This is a better loop:
while ($length 0) {
$size = min(8192, $length);
$data = fread($fp, $size);
if (strlen($data) == 0) {
break; // EOF
}
$reply .= $data;
$length -= strlen($data);
}
It is recommended that you fread() in chunks of 8kb from sockets, as
you will get better performance than using a smaller value. Using a
larger value is wasteful as the streams layer will only allocate in 8KB
chunks; Win32 has a maximum internal packet size of 8KB too.
I'm marking this as bogus since it is the expected behaviour of PHP (I
actually spent a couple of days correcting and testing this for
HTTP/1.1 keep alives).
[2003-06-06 03:06:27] thomas at nimstad dot com
Ok. Since I'm was not the only having the problem I examined it some
more... here we goes again...
Problem #1: When using a chunk size = 8192 bytes it's just to
concatenate the data and continue reading (as examplified in the
documentation). So to what I understand, this is not a bug, rather than
a timing issue that fread() returns the number of bytes available at
the moment? Anyway, in this case problem #2 doesn't occurs!!
Problem #2: The fread() still hangs until timeout if I try to read data
in chunks of = 4096 bytes!!
[2003-06-06 01:46:52] [EMAIL PROTECTED]
From the manual:
When reading from network streams or pipes, such as those returned when
reading remote files or from popen() and proc_open(), reading will stop
after a packet is available. This means that you should collect the
data together in chunks as shown in the example below.
A bug existed in 4.3.0-1 that made it work, so, it's not considered
changed behavior, just a bug. This bug, for example, did not exist in
4.2.3
Regarding Thomas problem #2, not sure about that, will see what Wez
has to say.
Regarding the last proposed example by PJ, just use
file_get_contents().
[2003-06-05 14:56:49] PJ at Elitegamer dot com
I too am experiencing this changed behavior. Previously, my code was as
follows:
$contents = fread ($fp, 2097152);
And that would return up to 2mb from the given socket. In my case, the
socket was a fopen() url.
However, when I upgraded to PHP 4.3.2 it would ONLY return 2481 bytes
no matter what. As a quick fix I had to move the fread() inside of a
while loop, in order to fix this issue. Like this:
$contents = ;
while (($data = fread ($fp, 2097152)) !== )
{
$contents .= $data;
}
The only change on my system and the files being read was my upgrading
to PHP 4.3.2. This definitely appears to be changed behavior of
fread().
-PJ
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/24033
--
Edit this bug report at http://bugs.php.net/?id=24033edit=1
#24182 [NEW]: va_arg macro error in Zend/zend.c
From: china at thewrittenword dot com
Operating system: Tru64 UNIX 4.0D
PHP version: 4.3.2
PHP Bug Type: Compile Failure
Bug description: va_arg macro error in Zend/zend.c
Description:
Tru64 UNIX 4.0D doesn't have vsnprintf(). So, the following code in
Zend/zend.c is built:
strncpy(z_error_message-value.str.val, va_arg(format,
char *), ZEND_ERROR_BUFFER_SIZE);
Unfortunately, va_arg() in varargs.h on Tru64 UNIX expects the first
argument (format in this case) to be of type struct va_list. Hence the
error:
cc: Error: /opt/build/php-4.3.2/Zend/zend.c, line 763: In this
statement, (format) has a pointer type, but occurs in
a context that requires a union or struct. (needstruct)
strncpy(z_error_message-value.str.val, va_arg(format,
char *), ZEND_ERROR_BUFFER_SIZE);
^
gmake: *** [Zend/zend.lo] Error 1
In va_list.h, va_list is defined as:
typedef struct {
char**_a0;
int _offset;
} va_list;
I checked out CVS head and replaced the offending 4.3.2 Zend/zend.c code
with CVS Zend/zend.c and it built ok. Is that the proper solution?
--
Edit bug report at http://bugs.php.net/?id=24182edit=1
--
Try a CVS snapshot: http://bugs.php.net/fix.php?id=24182r=trysnapshot
Fixed in CVS: http://bugs.php.net/fix.php?id=24182r=fixedcvs
Fixed in release: http://bugs.php.net/fix.php?id=24182r=alreadyfixed
Need backtrace: http://bugs.php.net/fix.php?id=24182r=needtrace
Try newer version: http://bugs.php.net/fix.php?id=24182r=oldversion
Not developer issue:http://bugs.php.net/fix.php?id=24182r=support
Expected behavior: http://bugs.php.net/fix.php?id=24182r=notwrong
Not enough info:http://bugs.php.net/fix.php?id=24182r=notenoughinfo
Submitted twice:http://bugs.php.net/fix.php?id=24182r=submittedtwice
register_globals: http://bugs.php.net/fix.php?id=24182r=globals
PHP 3 support discontinued: http://bugs.php.net/fix.php?id=24182r=php3
Daylight Savings: http://bugs.php.net/fix.php?id=24182r=dst
IIS Stability: http://bugs.php.net/fix.php?id=24182r=isapi
Install GNU Sed:http://bugs.php.net/fix.php?id=24182r=gnused
#23599 [Opn]: Crash when using COM object property/method
ID: 23599 User updated by: zstomp at yandex dot ru Reported By: zstomp at yandex dot ru Status: Open Bug Type: COM related Operating System: Win2k, Win98 PHP Version: 4.3.2RC3-dev New Comment: Anybody working on it? Previous Comments: [2003-05-20 15:54:06] zstomp at yandex dot ru I emailed it a couple of days ago. Did you receive it? [2003-05-17 10:32:52] [EMAIL PROTECTED] please mail it directly to me together with a short script that demonstrates that misbehaviour. [2003-05-16 09:22:12] zstomp at yandex dot ru Here's the test results: DllGetClassObject is called ok, that was my fault. Object initialization is passed ok too. But, when execution comes to reading from property, PHP crashes before property is read. I can supply you with the ActiveX I have, if you wish. [2003-05-16 08:18:08] zstomp at yandex dot ru Just tested with other object that had same problem before and it works ok. Will try to investigate further. [2003-05-16 08:13:43] zstomp at yandex dot ru I tested it with latest CVS version and got other error. Exception now happens, as Windows reports, in unknown module. I started PHP from debugger and it seems like DllGetClassObject is not called. 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/23599 -- Edit this bug report at http://bugs.php.net/?id=23599edit=1
#20935 [Com]: mssql_query causes segfault
ID: 20935 Comment by: hasshk at hotmail dot com Reported By: jonas at ionax dot se Status: No Feedback Bug Type: MSSQL related Operating System: RedHat Linux 7.2 / Apache 1.3.27 PHP Version: 4.3.0 New Comment: I'm getting an error message 8007007F when i try to view data either by query or by Returning all rows. Need an Advice Please. Previous Comments: [2003-03-11 07:27:24] bds at geekboys dot org With this setup: PHP Version 4.3.0 Red Hat 8.0 (Linux 2.4.18-3) Apache 1.3.27 FreeTDS 0.60 It worked fine with --with-mssql In this setup: PHP Version 4.3.1 Red Hat 8.0 (Linux 2.4.18-14) Apache 1.3.27 FreeTDS 0.61 I had to compile with --with-sybase to get it to work. Exact same installation routine on both systems. [2003-02-07 23:44:28] [EMAIL PROTECTED] No feedback was provided. The bug is being suspended because we assume that you are no longer experiencing the problem. If this is not the case and you are able to provide the information that was requested earlier, please do so and change the status of the bug back to Open. Thank you. [2003-01-27 12:29:54] ernesto at gupos dot com dot ar Well, I finally make it work using the FreeTDS 0.60 with the --with-sybase=/path_to_freetds instead of --with-mssql=/path_to_freetds as metioned on the manual. I'm using the MSSQL function anyway. Greettings. Ernesto [2003-01-27 09:46:09] ernesto at gupos dot com dot ar It doesn't seemd to be a FreeTDS bug. I tested the tarball and CVS version of FreeTDS with sqsh (a command line client that use FreeTDS library, www.sqsh.org) and it worked fine. But, when I do a remote connect with PHP using the same FreeTDS library, it segfault when I do a simple: $res = mssql_query(select * from Test); The connection and selection of the database works fine. That's all that I can say for now. Thanks for all. Ernesto [2003-01-21 11:03:02] [EMAIL PROTECTED] Can you test the same code under Win32 ? This could be a bug in FreeTDS. To my knowledge the latest version of that is 0.60! - Frank 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/20935 -- Edit this bug report at http://bugs.php.net/?id=20935edit=1
