Bug #17181 Updated: ADO crash
ID: 17181
Updated by: [EMAIL PROTECTED]
Reported By: [EMAIL PROTECTED]
Status: Open
Bug Type: COM related
Operating System: Windows 2000 Sp2
PHP Version: 4.2.0
New Comment:
also on PHP4.1.2 this doesen't work anymore, it seems that the upgrade
to MSDAC2.7 caused this crash
Previous Comments:
[2002-05-14 02:41:15] [EMAIL PROTECTED]
Sorry,
but I have not time to debug this, but with PHP4.1.2 this worked,
[2002-05-14 02:21:01] [EMAIL PROTECTED]
Our resources regarding COM and win32 seem to be very low. Are you
create a debug build yourself and start debugging it?
[2002-05-13 10:02:11] [EMAIL PROTECTED]
Hi,
this script lets php crash:
$conn = new COM( "ADODB.Connection" );
$conn->Provider = 'SQLOLEDB';
$conn->Open( "Server=wincubix;Uid=oebb;Pwd=oebb;Database=cubix" );
$conn->Execute('SET DATEFORMAT ymd');
$rs = new COM( "ADODB.Recordset" );
$rs->ActiveConnection = $conn;
$rs->Open("SELECT DISTINCT * FROM news WHERE gueltig_von <=
'2002-05-13'");
changing the script like this will prevent the AV
//$rs->ActiveConnection = $conn;
$rs->Open("SELECT DISTINCT * FROM news WHERE gueltig_von <=
'2002-05-13'", $conn);
I'm using the latest MSDAC (2.7) and the latest snapshot of php
--
Edit this bug report at http://bugs.php.net/?id=17181&edit=1
Bug #17192 Updated: DLL not valid
ID: 17192 Updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] -Status: Open +Status: Feedback Bug Type: GD related Operating System: Windows 2002 PHP Version: 4.2.1 Assigned To: edink New Comment: Could you please try php_gd2.dll that I just uploaded to http://ftp.proventum.net/pub/php/win32/php_gd2.zip Previous Comments: [2002-05-14 02:10:27] [EMAIL PROTECTED] I can confirm that php_gd2.dll seem not to be functional. But problems reported by [EMAIL PROTECTED] are probably due to misconfiguration on his part. Plus php_imap.dll, php_ldap.dll are both included in the zip file. [2002-05-14 00:44:50] [EMAIL PROTECTED] Missing modules -> assigning to Edin [2002-05-13 19:32:45] [EMAIL PROTECTED] I've got the same problems (OS = WinXP) trying to load the curl and sockets modules. Apache reports the PHP API compile date of 20010901(!) but the modules as 20020429. Also, where are the missing modules (imap, ldap, etc)? [2002-05-13 19:15:57] [EMAIL PROTECTED] Today I installed PHP 4.2.1 and did everything I had to do... copy DLLs to Winnt\System32, configure Apache, etc. When I started Apache, I got an error concerning php_gd2.dll : it can't be loaded. I think there is an error of compilation in Win32 binaries of PHP 4.2.1. Thanks -- Edit this bug report at http://bugs.php.net/?id=17192&edit=1
Bug #17198 Updated: Deerfield Website 3.11 can not locate program entry _ecalloc on php4ts.dll
ID: 17198 Updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] Status: Open Bug Type: Other web server Operating System: Win2K PHP Version: 4.2.1 New Comment: Again, load ISAPI moudle in Sambar 5.1 Production, When browsing php script, the screen is always blank, original script can be read using : View -> Page source Previous Comments: [2002-05-14 02:23:42] [EMAIL PROTECTED] I Install PHP4.21 as ISAPI moudle on Deerfield Website 3.11. When the webserver starts at the first time, browse a php script in browser, an alart window will popup, window title is : httpd32.exe - can not locate entry alart message : can not locate program entry _ecalloc on php4ts.dll. Press OK button, the script will go on running. Then every thing seems ok, no error message will appear when other scripts run. The error message will appear when webserver restarts. PS: ZendOptimizer 1.20 seems have no effect on PHP version 4.21 ? -- Edit this bug report at http://bugs.php.net/?id=17198&edit=1
Bug #17200: page not found on form submissions
From: [EMAIL PROTECTED] Operating system: Win 2k PHP version: 4.1.2 PHP Bug Type: OpenSSL related Bug description: page not found on form submissions hello... recently i have had a problem with a SSL connection in my PHP form... after submit i recive a 404 error if i access the page via http:// rather than https:// i do not recive the error... PHP version is 4.1.2 Apache version 1.3.23 OS is Win 2k (IIS not installed) any help would be greatly apriciated... thnx, dave [EMAIL PROTECTED] -- Edit bug report at http://bugs.php.net/?id=17200&edit=1 -- Fixed in CVS:http://bugs.php.net/fix.php?id=17200&r=fixedcvs Fixed in release:http://bugs.php.net/fix.php?id=17200&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=17200&r=needtrace Try newer version: http://bugs.php.net/fix.php?id=17200&r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=17200&r=support Expected behavior: http://bugs.php.net/fix.php?id=17200&r=notwrong Not enough info: http://bugs.php.net/fix.php?id=17200&r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=17200&r=submittedtwice register_globals:http://bugs.php.net/fix.php?id=17200&r=globals
Bug #17199: fail compile apache + php + openldap
From: [EMAIL PROTECTED] Operating system: solaris 8 PHP version: 4.1.2 PHP Bug Type: Compile Failure Bug description: fail compile apache + php + openldap When I complie php(4.1.2) + openldap (2.0.23) ./configure --with-apache=../apache_1.3.22 --enable-track-vars --enable-force-cgi-redirect --with-ldap =/opt/apache/openldap-2.0.23 make make install It is fine. But when I complie apache (1.3.22) ./configure --prefix=/usr/local/apache --activate-module=src/modules/php4/libphp4.a make The following error occured: Undefined first referenced symbol in file ldap_first_referencemodules/php4/libphp4.a(ldap.o) ldap_count_values_len modules/php4/libphp4.a(ldap.o) ldap_memfreemodules/php4/libphp4.a(ldap.o) ldap_get_dn modules/php4/libphp4.a(ldap.o) . . . ldap_next_entry modules/php4/libphp4.a(ldap.o) ldap_get_values modules/php4/libphp4.a(ldap.o) ldap_count_entries modules/php4/libphp4.a(ldap.o) ld: fatal: Symbol referencing errors. No output written to httpsd collect2: ld returned 1 exit status make[2]: *** [target_static] Error 1 make[2]: Leaving directory `/opt/apache/apache_1.3.22/src' make[1]: *** [build-std] Error 2 make[1]: Leaving directory `/opt/apache/apache_1.3.22' make: *** [build] Error 2 Pls help to fix the problem. Thx -- Edit bug report at http://bugs.php.net/?id=17199&edit=1 -- Fixed in CVS:http://bugs.php.net/fix.php?id=17199&r=fixedcvs Fixed in release:http://bugs.php.net/fix.php?id=17199&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=17199&r=needtrace Try newer version: http://bugs.php.net/fix.php?id=17199&r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=17199&r=support Expected behavior: http://bugs.php.net/fix.php?id=17199&r=notwrong Not enough info: http://bugs.php.net/fix.php?id=17199&r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=17199&r=submittedtwice register_globals:http://bugs.php.net/fix.php?id=17199&r=globals
Bug #17181 Updated: ADO crash
ID: 17181
Updated by: [EMAIL PROTECTED]
Reported By: [EMAIL PROTECTED]
Status: Open
Bug Type: COM related
Operating System: Windows 2000 Sp2
PHP Version: 4.2.0
New Comment:
Sorry,
but I have not time to debug this, but with PHP4.1.2 this worked,
Previous Comments:
[2002-05-14 02:21:01] [EMAIL PROTECTED]
Our resources regarding COM and win32 seem to be very low. Are you
create a debug build yourself and start debugging it?
[2002-05-13 10:02:11] [EMAIL PROTECTED]
Hi,
this script lets php crash:
$conn = new COM( "ADODB.Connection" );
$conn->Provider = 'SQLOLEDB';
$conn->Open( "Server=wincubix;Uid=oebb;Pwd=oebb;Database=cubix" );
$conn->Execute('SET DATEFORMAT ymd');
$rs = new COM( "ADODB.Recordset" );
$rs->ActiveConnection = $conn;
$rs->Open("SELECT DISTINCT * FROM news WHERE gueltig_von <=
'2002-05-13'");
changing the script like this will prevent the AV
//$rs->ActiveConnection = $conn;
$rs->Open("SELECT DISTINCT * FROM news WHERE gueltig_von <=
'2002-05-13'", $conn);
I'm using the latest MSDAC (2.7) and the latest snapshot of php
--
Edit this bug report at http://bugs.php.net/?id=17181&edit=1
Bug #16994 Updated: Error log reports seg fault and bus error at what seems to be arbitrary moments
ID: 16994 Updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] -Status: Open +Status: Closed Bug Type: Scripting Engine problem Operating System: FreeBSD 4.5 PHP Version: 4.2.0 New Comment: Thank you for your bug report. This issue has already been fixed in the latest released version of PHP, which you can download at http://www.php.net/downloads.php Previous Comments: [2002-05-14 02:11:23] [EMAIL PROTECTED] Problem solved (at least for me). Either upgrade to PHP 4.2.1 or upgrade your ports collection which now includes a patch for PHP 4.2.0. It was caused by a mkdir() in my script which triggered a FreeBSD-specific bug in PHP. (http://www.freebsd.org/cgi/query-pr.cgi?pr=37825) Greets, Manuel [2002-05-11 07:38:23] [EMAIL PROTECTED] I'm too experiencing an extremely similar problem on two entirely different FreeBSD machines (hardware-wise), both running FreeBSD-4.5-RELEASE-p4. apache dies with signal 11, sometimes signal 10, like this: May 9 13:32:10 freebsd /kernel: pid 1534 (httpd), uid 80: exited on signal 11 May 9 13:32:11 freebsd /kernel: pid 165 (httpd), uid 80: exited on signal 11 May 9 13:32:11 freebsd /kernel: pid 164 (httpd), uid 80: exited on signal 11 May 9 13:32:11 freebsd /kernel: pid 163 (httpd), uid 80: exited on signal 11 May 9 13:32:11 freebsd /kernel: pid 162 (httpd), uid 80: exited on signal 11 May 9 13:32:11 freebsd /kernel: pid 161 (httpd), uid 80: exited on signal 11 May 9 13:32:11 freebsd /kernel: pid 4330 (httpd), uid 80: exited on signal 11 May 9 13:32:13 freebsd /kernel: pid 157 (httpd), uid 0: exited on signal 10 (core dumped) Although I've seen it with different scripts, it was most obvious with a simple HTTP file upload handling script - almost every time I tried a file upload (no matter how big), it crashed. I've tried recompiling PHP without anything but the standard modules (zlib / mysql) - same thing still. I also tried recompiling apache 1.3.24/php 4.2.0 "by hand" without DSO (I usually use the FreeBSD port which uses DSOs) and no optimizations. No luck, same problem. So... I rebuilt both apache and php using the FreeBSD ports system and with just the default options (however with --march=pentiumpro!), but added --enable-debug to the PHP ./configure call. After recompiling/installing I called httpd -X as indicated in the manual, first tried a script which only calls phpinfo() (this one worked, as always), then tried the file upload script and was rewarded with a core dump (this time signal 4??) Here's what I managed to get out of it: --- s1# gdb /usr/local/sbin/httpd /usr/local/httpd.core GNU gdb 4.18 Copyright 1998 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-unknown-freebsd"...(no debugging symbols found)... Core was generated by `httpd'. Program terminated with signal 4, Illegal instruction. Reading symbols from /usr/lib/libcrypt.so.2...(no debugging symbols found)...done. Reading symbols from /usr/lib/libc.so.4...(no debugging symbols found)...done. Reading symbols from /usr/local/libexec/apache/mod_mmap_static.so...(no debugging symbols found)...done. Reading symbols from /usr/local/libexec/apache/mod_vhost_alias.so...(no debugging symbols found)...done. Reading symbols from /usr/local/libexec/apache/mod_env.so...(no debugging symbols found)...done. Reading symbols from /usr/local/libexec/apache/mod_log_config.so...(no debugging symbols found)...done. Reading symbols from /usr/local/libexec/apache/mod_mime_magic.so...(no debugging symbols found)...done. Reading symbols from /usr/local/libexec/apache/mod_mime.so...(no debugging symbols found)...done. Reading symbols from /usr/local/libexec/apache/mod_negotiation.so...(no debugging symbols found)...done. Reading symbols from /usr/local/libexec/apache/mod_status.so...(no debugging symbols found)...done. Reading symbols from /usr/local/libexec/apache/mod_info.so...(no debugging symbols found)...done. Reading symbols from /usr/local/libexec/apache/mod_include.so...(no debugging symbols found)...done. Reading symbols from /usr/local/libexec/apache/mod_autoindex.so...(no debugging symbols found)...done. Reading symbols from /usr/local/libexec/apache/mod_dir.so...(no debugging symbols found)...done. Reading symbols from /usr/local/libexec/apache/mod_cgi.so...(no debugging symbols found)...done. Reading symbols from /usr/local/libexec/apache/mod_asis.so...(no debugging symbols found)...done. Reading symbols from /usr/local/libexec/apache/mod_imap.so...(no
Bug #17197 Updated: Apache Crash when triying to modify a property of a COM Object
ID: 17197
Updated by: [EMAIL PROTECTED]
Reported By: [EMAIL PROTECTED]
-Status: Open
+Status: Closed
Bug Type: Apache related
Operating System: Windows ME
PHP Version: 4.1.2
New Comment:
Thank you for your bug report. This issue has already been fixed
in the latest released version of PHP, which you can download at
http://www.php.net/downloads.php
This should be fixed in the latest 4.2.1 version available for download
from www.php.net
Derick
Previous Comments:
[2002-05-14 01:37:31] [EMAIL PROTECTED]
Utilizo un entorno de desarrollo compuesto por PHP 4.1.3-dev corriendo
como modulo en Apache 1.3.23 en WinME y cuando intento modificar el
valor de algun objeto COM obtengo un crash en el Servidor Apache.
La secuencia de Comandos es similar a la que sigue:
$objecto = new COM("Objeto.subobjeto");
$objeto->propiedad1 = "Valor"; <- Aqui es donde obtengo el crash (si
comento la linea todo funcioa bien)
El Objeto que utilizo es el Control ActiveX del Servidor de Correo de
ArGoSoft
ENGLISH TRANLATED (my english is not too good)
I use a development enviroment formed by PHP 4.1.3-dev as a module of
Apache 1.3.23 in WinMe and when a try to modify the value of any
property in an COM object i get a crash in the apache server.
The Script is similar to following:
$object = new COM("Object.Subobject");
$object->property1 = "Value"; <-Here is when i get the crash (if I
comment this line everything works ok)
The object used is the ActiveX control of Mail Server from ArGoSoft
--
Edit this bug report at http://bugs.php.net/?id=17197&edit=1
Bug #17198: Deerfield Website 3.11 can not locate program entry _ecalloc on php4ts.dll
From: [EMAIL PROTECTED] Operating system: Win2K PHP version: 4.2.1 PHP Bug Type: Other web server Bug description: Deerfield Website 3.11 can not locate program entry _ecalloc on php4ts.dll I Install PHP4.21 as ISAPI moudle on Deerfield Website 3.11. When the webserver starts at the first time, browse a php script in browser, an alart window will popup, window title is : httpd32.exe - can not locate entry alart message : can not locate program entry _ecalloc on php4ts.dll. Press OK button, the script will go on running. Then every thing seems ok, no error message will appear when other scripts run. The error message will appear when webserver restarts. PS: ZendOptimizer 1.20 seems have no effect on PHP version 4.21 ? -- Edit bug report at http://bugs.php.net/?id=17198&edit=1 -- Fixed in CVS:http://bugs.php.net/fix.php?id=17198&r=fixedcvs Fixed in release:http://bugs.php.net/fix.php?id=17198&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=17198&r=needtrace Try newer version: http://bugs.php.net/fix.php?id=17198&r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=17198&r=support Expected behavior: http://bugs.php.net/fix.php?id=17198&r=notwrong Not enough info: http://bugs.php.net/fix.php?id=17198&r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=17198&r=submittedtwice register_globals:http://bugs.php.net/fix.php?id=17198&r=globals
Bug #17181 Updated: ADO crash
ID: 17181
Updated by: [EMAIL PROTECTED]
Reported By: [EMAIL PROTECTED]
Status: Open
Bug Type: COM related
Operating System: Windows 2000 Sp2
PHP Version: 4.2.0
New Comment:
Our resources regarding COM and win32 seem to be very low. Are you
create a debug build yourself and start debugging it?
Previous Comments:
[2002-05-13 10:02:11] [EMAIL PROTECTED]
Hi,
this script lets php crash:
$conn = new COM( "ADODB.Connection" );
$conn->Provider = 'SQLOLEDB';
$conn->Open( "Server=wincubix;Uid=oebb;Pwd=oebb;Database=cubix" );
$conn->Execute('SET DATEFORMAT ymd');
$rs = new COM( "ADODB.Recordset" );
$rs->ActiveConnection = $conn;
$rs->Open("SELECT DISTINCT * FROM news WHERE gueltig_von <=
'2002-05-13'");
changing the script like this will prevent the AV
//$rs->ActiveConnection = $conn;
$rs->Open("SELECT DISTINCT * FROM news WHERE gueltig_von <=
'2002-05-13'", $conn);
I'm using the latest MSDAC (2.7) and the latest snapshot of php
--
Edit this bug report at http://bugs.php.net/?id=17181&edit=1
Bug #17191 Updated: PHP Variables undefined
ID: 17191 Updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] -Status: Open +Status: Bogus Bug Type: IIS related Operating System: Win 2000 Server PHP Version: 4.2.1 New Comment: In PHP 4.2.0, the 'register_globals' setting default changed to be off. See http://www.php.net/release_4_2_0.php for more info. We are sorry about the inconvenience, but this change was a necessary part of our efforts to make PHP scripting more secure and portable. Previous Comments: [2002-05-13 18:05:00] [EMAIL PROTECTED] No, I've already changed both "register_globals" and "register_argc_argv" to "On". Now, e.g. $OS is defined. However, Variables passed via URL still remaine undefined. (I am using the same PHP.INI File than on an XP-Installation, where PHP&IIS5 work. Are there any other modifications performed by the OCX which I am still missing ?) [2002-05-13 17:45:04] [EMAIL PROTECTED] That makes sense if you haven't turned the register_globals directive On in php.ini. [2002-05-13 17:36:44] [EMAIL PROTECTED] Because of the known "OCX-Control missing" problem I did a manual configuration on Windows 2000 Server (IIS5). PHP scripts run (e.g. phpinfo()), but own function don't have access to PHP Variables, there seem to be no variable definitions at all. Calling a script via http://localhost/test.php?a=1 does not result in a variable "a" within the script. -- Edit this bug report at http://bugs.php.net/?id=17191&edit=1
Bug #14200 Updated: remote navigation problem
ID: 14200 Updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] Status: Open Bug Type: *General Issues Operating System: Windows XP Pro PHP Version: 4.0.6 New Comment: Hello, I had tryed all of the above, long time ago. Problems are in the Windows XP. Second, Why use Windows XP as an server plattform? The most unrealiable so far. Choose Windows 2000 Pro or Server if you want w32 as your server. There is some information about this issues posted Apache's website telling that Microsoft is working on their problems, but there is not update yet. Most users do not know that XP is cousing this problem, and they start accusing PHP or Apache for thier problems. Some of the problems: - When users browse your PHP pages on the web, - Web Pages are reloading all the time - They are cut in the middle and not completely displayed Acctually, Windows XP is not ment to be used as an Server plattform yet, and no hosts are using it today, beacuse it's an unproven as a server technology. Regards, -Vildan Previous Comments: [2002-03-21 14:39:19] [EMAIL PROTECTED] Same problem. Under 2k works fine but under xp there're some problems : sometimes i see a portion of the code instead of the page and i've to refresh the page 3 or 4 times to make it good. [2002-01-11 17:00:20] [EMAIL PROTECTED] I have exactly the same problem, on a remote computer the long page show many strange chars, and I have to refresh the page few time before it show correctly. And that's when I'm in cgi... With php as a module, i got some 404 errors, and much more errors of loading... My server is running on Apache 1.3.22 (as a nt service), with PHP 4.1.1 under XP Pro whithout any firewall (xp or third party ones). And I've tried to move the php4apache.dll in the system directory, but it don't seem to change anything (em, it should be normal ? :) ) (i've also tried the compatibility mode with the application, don't work too :/) (and sorry for my bad English, i'm Frensh ;) ) [2001-12-19 10:06:54] [EMAIL PROTECTED] Yes, only way is to use PHP as CGI NOT as module because module has many problem! But using CGI I can't use function getallheader() to support resume with download :-(( [2001-12-19 07:07:04] [EMAIL PROTECTED] Any news with 4.1.0? [2001-11-30 14:48:37] [EMAIL PROTECTED] I have verified but i don't have any firewall installed. Other people have same problem. I don't know why this problem happens, I think I've read all possible news about but I don't have found any solution. Have you replicated this problem in lab? I hope in 4.1.0 release 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/14200 -- Edit this bug report at http://bugs.php.net/?id=14200&edit=1
Bug #17190 Updated: Date() gives error for date prior to 1-1-1970
ID: 17190
Updated by: [EMAIL PROTECTED]
Reported By: [EMAIL PROTECTED]
-Status: Open
+Status: Bogus
Bug Type: Date/time related
Operating System: Windows NT 4.0
PHP Version: 4.2.0
New Comment:
Sorry, but the bug system is not the appropriate forum for asking
support questions. Your problem does not imply a bug in PHP itself.
For a list of more appropriate places to ask for help using PHP,
please visit http://www.php.net/support.php
Thank you for your interest in PHP.
This is a problem in Windows, not in PHP.
Derick
Previous Comments:
[2002-05-13 17:31:08] [EMAIL PROTECTED]
When using date() to format date prior to Jan 1, 1970 or after Jan 19,
2038 PHP gives
Warning: unexpected error in date()
script
\\variable's byear,bmonth,bday come from user form
\\script works fine for dates between 1-1-1970 - 1-19-2038
$bdate = $byear . "-" . $bmonth . "-" . $bday ;
$dob = strtotime($bdate);
$_SESSION['view_dob'] = date("d-m-Y",$dob);
--
Edit this bug report at http://bugs.php.net/?id=17190&edit=1
Bug #16994 Updated: Error log reports seg fault and bus error at what seems to be arbitrary moments
ID: 16994 Updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] Status: Open Bug Type: Scripting Engine problem Operating System: FreeBSD 4.5 PHP Version: 4.2.0 New Comment: Problem solved (at least for me). Either upgrade to PHP 4.2.1 or upgrade your ports collection which now includes a patch for PHP 4.2.0. It was caused by a mkdir() in my script which triggered a FreeBSD-specific bug in PHP. (http://www.freebsd.org/cgi/query-pr.cgi?pr=37825) Greets, Manuel Previous Comments: [2002-05-11 07:38:23] [EMAIL PROTECTED] I'm too experiencing an extremely similar problem on two entirely different FreeBSD machines (hardware-wise), both running FreeBSD-4.5-RELEASE-p4. apache dies with signal 11, sometimes signal 10, like this: May 9 13:32:10 freebsd /kernel: pid 1534 (httpd), uid 80: exited on signal 11 May 9 13:32:11 freebsd /kernel: pid 165 (httpd), uid 80: exited on signal 11 May 9 13:32:11 freebsd /kernel: pid 164 (httpd), uid 80: exited on signal 11 May 9 13:32:11 freebsd /kernel: pid 163 (httpd), uid 80: exited on signal 11 May 9 13:32:11 freebsd /kernel: pid 162 (httpd), uid 80: exited on signal 11 May 9 13:32:11 freebsd /kernel: pid 161 (httpd), uid 80: exited on signal 11 May 9 13:32:11 freebsd /kernel: pid 4330 (httpd), uid 80: exited on signal 11 May 9 13:32:13 freebsd /kernel: pid 157 (httpd), uid 0: exited on signal 10 (core dumped) Although I've seen it with different scripts, it was most obvious with a simple HTTP file upload handling script - almost every time I tried a file upload (no matter how big), it crashed. I've tried recompiling PHP without anything but the standard modules (zlib / mysql) - same thing still. I also tried recompiling apache 1.3.24/php 4.2.0 "by hand" without DSO (I usually use the FreeBSD port which uses DSOs) and no optimizations. No luck, same problem. So... I rebuilt both apache and php using the FreeBSD ports system and with just the default options (however with --march=pentiumpro!), but added --enable-debug to the PHP ./configure call. After recompiling/installing I called httpd -X as indicated in the manual, first tried a script which only calls phpinfo() (this one worked, as always), then tried the file upload script and was rewarded with a core dump (this time signal 4??) Here's what I managed to get out of it: --- s1# gdb /usr/local/sbin/httpd /usr/local/httpd.core GNU gdb 4.18 Copyright 1998 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-unknown-freebsd"...(no debugging symbols found)... Core was generated by `httpd'. Program terminated with signal 4, Illegal instruction. Reading symbols from /usr/lib/libcrypt.so.2...(no debugging symbols found)...done. Reading symbols from /usr/lib/libc.so.4...(no debugging symbols found)...done. Reading symbols from /usr/local/libexec/apache/mod_mmap_static.so...(no debugging symbols found)...done. Reading symbols from /usr/local/libexec/apache/mod_vhost_alias.so...(no debugging symbols found)...done. Reading symbols from /usr/local/libexec/apache/mod_env.so...(no debugging symbols found)...done. Reading symbols from /usr/local/libexec/apache/mod_log_config.so...(no debugging symbols found)...done. Reading symbols from /usr/local/libexec/apache/mod_mime_magic.so...(no debugging symbols found)...done. Reading symbols from /usr/local/libexec/apache/mod_mime.so...(no debugging symbols found)...done. Reading symbols from /usr/local/libexec/apache/mod_negotiation.so...(no debugging symbols found)...done. Reading symbols from /usr/local/libexec/apache/mod_status.so...(no debugging symbols found)...done. Reading symbols from /usr/local/libexec/apache/mod_info.so...(no debugging symbols found)...done. Reading symbols from /usr/local/libexec/apache/mod_include.so...(no debugging symbols found)...done. Reading symbols from /usr/local/libexec/apache/mod_autoindex.so...(no debugging symbols found)...done. Reading symbols from /usr/local/libexec/apache/mod_dir.so...(no debugging symbols found)...done. Reading symbols from /usr/local/libexec/apache/mod_cgi.so...(no debugging symbols found)...done. Reading symbols from /usr/local/libexec/apache/mod_asis.so...(no debugging symbols found)...done. Reading symbols from /usr/local/libexec/apache/mod_imap.so...(no debugging symbols found)...done. Reading symbols from /usr/local/libexec/apache/mod_actions.so...(no debugging symbols found)...done. Reading symbols from /usr/local/libexec/apache/mod_speling.so...(no debugging symbols found)...done. Reading symbols from /usr/local/libexec/apache/mod_userdir.so...(no d
Bug #17192 Updated: DLL not valid
ID: 17192 Updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] Status: Open Bug Type: GD related Operating System: Windows 2002 PHP Version: 4.2.1 Assigned To: edink New Comment: I can confirm that php_gd2.dll seem not to be functional. But problems reported by [EMAIL PROTECTED] are probably due to misconfiguration on his part. Plus php_imap.dll, php_ldap.dll are both included in the zip file. Previous Comments: [2002-05-14 00:44:50] [EMAIL PROTECTED] Missing modules -> assigning to Edin [2002-05-13 19:32:45] [EMAIL PROTECTED] I've got the same problems (OS = WinXP) trying to load the curl and sockets modules. Apache reports the PHP API compile date of 20010901(!) but the modules as 20020429. Also, where are the missing modules (imap, ldap, etc)? [2002-05-13 19:15:57] [EMAIL PROTECTED] Today I installed PHP 4.2.1 and did everything I had to do... copy DLLs to Winnt\System32, configure Apache, etc. When I started Apache, I got an error concerning php_gd2.dll : it can't be loaded. I think there is an error of compilation in Win32 binaries of PHP 4.2.1. Thanks -- Edit this bug report at http://bugs.php.net/?id=17192&edit=1
Bug #16337 Updated: include() does not decode % correctly
ID: 16337 Updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] Status: Open Bug Type: HTTP related Operating System: Unix based PHP Version: 4.1.0 New Comment: We are still having issues with this. If you require any additional explanation, or examples, I can give them. Some indication of whether this is being worked on or not would be nice... Previous Comments: [2002-05-14 00:46:32] [EMAIL PROTECTED] Feedback was given, but status not changed. Reopening. [2002-05-14 00:00:04] [EMAIL PROTECTED] No feedback was provided for this bug for over a month, so it is being suspended automatically. If you are able to provide the information that was originally requested, please do so and change the status of the bug back to "Open". [2002-04-15 14:04:07] [EMAIL PROTECTED] Ok, so I think maybe I shouldn't have brought up the HTTP spec. The *only* reason I did that, was that HTTP has one small limitation on username:password pairs. As far as I could find, in all of new and old RFCs (including 2617) was that ':' is disallowed from the username. I have read of no limitations on what the password can contain. Based on the above, I am going to make the conjecture that if the 'http://USERNAME:PASSWORD@;...' syntax in PHP can't handle certain 'special' characters, then it is broken. The way I was trying to use this feature was like the following: I was trying to include some headers and footers from my *local* webserver into my PHP script when it is displayed. Why am I using an URL for this?? Well, because the script that dynamically generates those headers and footers is written in a different language. It is a temporary fix for me while I port code. In any case, the authentication realm that my PHP script lives in, is the same realm as the headers and footers. So, when a user hits the PHP script, the username and password variables are stuck together into a URL like: "http://$username:$[EMAIL PROTECTED]/header.cgi"; Then I use an include() call to grab the header. Make sense so far? The problem is, PHP bombs when the user's password contains any special characters. More specifically, if it contains characters that are normally considered special in URL terms. Just suppose for a minute, that my password contains an '@'. How is PHP to parse this? Should it assume that the first or last @ found is the delimiter? What if the username was equal to 'www.example.org/evilscript.cgi?var='? Then we have a Cross-Site Scripting Vulnerability on our hands. So, my reasoning for the urlencoding was that if the user was responsible, they would urlencode the username and password individually, thus making the URL actually parseable in any situation. The only way this would work though, is if PHP unencoded those tokens after parsing them out of the URL. Currently it does not. Once again, this escaping problem is between the caller and the include() function, not between the PHP internals and HTTP. [2002-04-13 19:11:18] [EMAIL PROTECTED] RFC 2068 is obsoleted by RFC 2616, so your assumption that RFC 2068 is still adhered to is incorrect. The username:password string is base-64 encoded for Basic Authentication, which I'm going to assume you're using, since you didn't mention what type of authentication the server demands for access to http://www.example.org/. It is not URL encoded. Now, as for your bug report, why in the world would the include function *decode* the username:password string? The content coming back from the server doesn't specify the username and password to be used; that's what *you* sent. See RFC 2617 for more information about both Basic and Digest Authentication over HTTP. http://ietf.org/rfc/rfc2617.txt will point you there. I think a better understanding of this might help you solve your problem on your own. However, if this does not help, it should at least allow you to better explain what the problem is, because your reports have too many holes for me to understand what problem you are having, whether a bug in PHP or not. [2002-04-10 20:01:07] [EMAIL PROTECTED] in case anyone wondered, the HTTP spec I am refering to, is at: http://www.cis.ohio-state.edu/cgi-bin/rfc/rfc2068.html (Section 11.1) Since RFC 2616 doesn't specify user-pass strings, I assume this older RFC still applies. 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/16337 -- Edit this
Bug #17197: Apache Crash when triying to modify a property of a COM Object
From: [EMAIL PROTECTED]
Operating system: Windows ME
PHP version: 4.1.2
PHP Bug Type: Apache related
Bug description: Apache Crash when triying to modify a property of a COM Object
Utilizo un entorno de desarrollo compuesto por PHP 4.1.3-dev corriendo como
modulo en Apache 1.3.23 en WinME y cuando intento modificar el valor de
algun objeto COM obtengo un crash en el Servidor Apache.
La secuencia de Comandos es similar a la que sigue:
$objecto = new COM("Objeto.subobjeto");
$objeto->propiedad1 = "Valor"; <- Aqui es donde obtengo el crash (si
comento la linea todo funcioa bien)
El Objeto que utilizo es el Control ActiveX del Servidor de Correo de
ArGoSoft
ENGLISH TRANLATED (my english is not too good)
I use a development enviroment formed by PHP 4.1.3-dev as a module of
Apache 1.3.23 in WinMe and when a try to modify the value of any property
in an COM object i get a crash in the apache server.
The Script is similar to following:
$object = new COM("Object.Subobject");
$object->property1 = "Value"; <-Here is when i get the crash (if I comment
this line everything works ok)
The object used is the ActiveX control of Mail Server from ArGoSoft
--
Edit bug report at http://bugs.php.net/?id=17197&edit=1
--
Fixed in CVS:http://bugs.php.net/fix.php?id=17197&r=fixedcvs
Fixed in release:http://bugs.php.net/fix.php?id=17197&r=alreadyfixed
Need backtrace: http://bugs.php.net/fix.php?id=17197&r=needtrace
Try newer version: http://bugs.php.net/fix.php?id=17197&r=oldversion
Not developer issue: http://bugs.php.net/fix.php?id=17197&r=support
Expected behavior: http://bugs.php.net/fix.php?id=17197&r=notwrong
Not enough info: http://bugs.php.net/fix.php?id=17197&r=notenoughinfo
Submitted twice: http://bugs.php.net/fix.php?id=17197&r=submittedtwice
register_globals:http://bugs.php.net/fix.php?id=17197&r=globals
Bug #17193 Updated: calling getenv after register_shutdown causes apache to crash
ID: 17193 Updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] -Status: Open +Status: Feedback Bug Type: Scripting Engine problem Operating System: RH Linux 7.2/Apach 1.3.22 PHP Version: 4.1.2 New Comment: Thank you for this bug report. To properly diagnose the problem, we need a backtrace to see what is happening behind the scenes. To find out how to generate a backtrace, please read http://bugs.php.net/bugs-generating-backtrace.php Once you have generated a backtrace, please submit it to this bug report and change the status back to "Open". Thank you for helping us make PHP better. You can find ho wto make a backtrace on the location mentioned above. Derick Previous Comments: [2002-05-13 19:25:57] [EMAIL PROTECTED] If you call register_shutdown_function, and then in the registered function make a call to getenv, Apache segfaults. Here's a sample script: Please note. This only happens when running as an apache module. CLI works fine, and I'd assume that CGI does too. I'll post a back trace if some kind soul will explain how to do it under RH linux using the messed up !apachectl method that they use to start apache. -- Edit this bug report at http://bugs.php.net/?id=17193&edit=1
Bug #17196 Updated: ZendOptimizer dll not loading
ID: 17196 Updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] -Status: Open +Status: Bogus Bug Type: IIS related Operating System: Windows 2000 PHP Version: 4.2.1 New Comment: This is not a bug in PHP, you need a newer ZendOptimizer.dll which Zend will most likely provide in the next couple of days. Derick Previous Comments: [2002-05-13 23:14:09] [EMAIL PROTECTED] Running PHP with IIS 5.0, successfully ran 4.2.0 with the ZendOptimizer, upgraded to 4.2.1 using the zip package and restarted the server. Error message appears saying that the ZendOptimizer.dll file cannot be loaded. Have commented out the Zend options in the php.ini file. Everything else is working well. Modules running: gd, mysql, imap, xml, wddx, pcre, odbc, ftp. Server API: CGI No changes made to basic system installed by zip package. -- Edit this bug report at http://bugs.php.net/?id=17196&edit=1
Bug #16337 Updated: include() does not decode % correctly
ID: 16337 Updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] -Status: No Feedback +Status: Open Bug Type: HTTP related Operating System: Unix based PHP Version: 4.1.0 New Comment: Feedback was given, but status not changed. Reopening. Previous Comments: [2002-05-14 00:00:04] [EMAIL PROTECTED] No feedback was provided for this bug for over a month, so it is being suspended automatically. If you are able to provide the information that was originally requested, please do so and change the status of the bug back to "Open". [2002-04-15 14:04:07] [EMAIL PROTECTED] Ok, so I think maybe I shouldn't have brought up the HTTP spec. The *only* reason I did that, was that HTTP has one small limitation on username:password pairs. As far as I could find, in all of new and old RFCs (including 2617) was that ':' is disallowed from the username. I have read of no limitations on what the password can contain. Based on the above, I am going to make the conjecture that if the 'http://USERNAME:PASSWORD@;...' syntax in PHP can't handle certain 'special' characters, then it is broken. The way I was trying to use this feature was like the following: I was trying to include some headers and footers from my *local* webserver into my PHP script when it is displayed. Why am I using an URL for this?? Well, because the script that dynamically generates those headers and footers is written in a different language. It is a temporary fix for me while I port code. In any case, the authentication realm that my PHP script lives in, is the same realm as the headers and footers. So, when a user hits the PHP script, the username and password variables are stuck together into a URL like: "http://$username:$[EMAIL PROTECTED]/header.cgi"; Then I use an include() call to grab the header. Make sense so far? The problem is, PHP bombs when the user's password contains any special characters. More specifically, if it contains characters that are normally considered special in URL terms. Just suppose for a minute, that my password contains an '@'. How is PHP to parse this? Should it assume that the first or last @ found is the delimiter? What if the username was equal to 'www.example.org/evilscript.cgi?var='? Then we have a Cross-Site Scripting Vulnerability on our hands. So, my reasoning for the urlencoding was that if the user was responsible, they would urlencode the username and password individually, thus making the URL actually parseable in any situation. The only way this would work though, is if PHP unencoded those tokens after parsing them out of the URL. Currently it does not. Once again, this escaping problem is between the caller and the include() function, not between the PHP internals and HTTP. [2002-04-13 19:11:18] [EMAIL PROTECTED] RFC 2068 is obsoleted by RFC 2616, so your assumption that RFC 2068 is still adhered to is incorrect. The username:password string is base-64 encoded for Basic Authentication, which I'm going to assume you're using, since you didn't mention what type of authentication the server demands for access to http://www.example.org/. It is not URL encoded. Now, as for your bug report, why in the world would the include function *decode* the username:password string? The content coming back from the server doesn't specify the username and password to be used; that's what *you* sent. See RFC 2617 for more information about both Basic and Digest Authentication over HTTP. http://ietf.org/rfc/rfc2617.txt will point you there. I think a better understanding of this might help you solve your problem on your own. However, if this does not help, it should at least allow you to better explain what the problem is, because your reports have too many holes for me to understand what problem you are having, whether a bug in PHP or not. [2002-04-10 20:01:07] [EMAIL PROTECTED] in case anyone wondered, the HTTP spec I am refering to, is at: http://www.cis.ohio-state.edu/cgi-bin/rfc/rfc2068.html (Section 11.1) Since RFC 2616 doesn't specify user-pass strings, I assume this older RFC still applies. [2002-04-10 19:57:48] [EMAIL PROTECTED] Correction: PHP's fopen url wrapper doesn't appear to unencode ANY encodings at all. Since the HTTP spec only excludes ':' from the username (and nothing at all from the password), this bug makes many username:password pairs unusable. The remainder of the comments for this report are too long. To view the rest of the comments,
Bug #17192 Updated: DLL not valid
ID: 17192 Updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] Status: Open Bug Type: GD related Operating System: Windows 2002 PHP Version: 4.2.1 -Assigned To: +Assigned To: edink New Comment: Missing modules -> assigning to Edin Previous Comments: [2002-05-13 19:32:45] [EMAIL PROTECTED] I've got the same problems (OS = WinXP) trying to load the curl and sockets modules. Apache reports the PHP API compile date of 20010901(!) but the modules as 20020429. Also, where are the missing modules (imap, ldap, etc)? [2002-05-13 19:15:57] [EMAIL PROTECTED] Today I installed PHP 4.2.1 and did everything I had to do... copy DLLs to Winnt\System32, configure Apache, etc. When I started Apache, I got an error concerning php_gd2.dll : it can't be loaded. I think there is an error of compilation in Win32 binaries of PHP 4.2.1. Thanks -- Edit this bug report at http://bugs.php.net/?id=17192&edit=1
Bug #17106 Updated: Session variable disappears
ID: 17106 Updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] Status: Open Bug Type: Session related Operating System: Win98, Win2000 Pro PHP Version: 4.1.2 New Comment: Can you supply a small script reproducing this problem also how frequent it happens? every page view or random or every 10 page views? _ brad Previous Comments: [2002-05-14 00:24:26] [EMAIL PROTECTED] For f#cks sake, we STILL have this damn problem under 4.2.1 as well. This is really starting to p#ss me off - we generate a HUGE amount of traffic, one of the top ten movie related sites in this country, and this session problem is causing viewers to constantly reload pages so that their bloody cookie logs them in - thus our bandwidth is shooting through the bloody roof (read $ down the toilet)... [2002-05-13 20:32:50] [EMAIL PROTECTED] The last version for which this script works on all my tested platforms (Win98-Win2000, Apache1.3.22, Netscape 4.75) is 4.0.6. Using the php4xx-installer.exe for MS Windows. Also note that 4.0.6 does NOT register PHP in the MS Win registry, whereas versions >= 4.1.0 DO register it. Could the registry be causing problems with session variables? Just a question from an un-initiated user. Lee [2002-05-13 19:28:07] [EMAIL PROTECTED] 14 May 2002 PHP 4.2.1, all other settings as before Same behavior as 4.2.0 - on "submit" the login prompt immediately re-appears. So has NOT been fixed. The last version for which this script works is 4.1.0 Lee [2002-05-09 01:34:57] [EMAIL PROTECTED] I found the following on Zend's site: FIX: 4.2.0 session SID broken Sascha Schumann has posted a fix for problems with the session SID under 4.2.0. If you need it immediately, the fix can be found at http://apache.org/~sascha/php-420-session-fix, or will be available in 4.2.1 along with the other fixes since 4.2.0. Sounds like it may resolve the issue we're having??? [2002-05-08 22:18:00] [EMAIL PROTECTED] Sequence of tests: originally running php4.1.0 Un-installed that, installed php4.2.0 - found bug. Un-installed php4.2.0, installed php4.1.2 - still bug. Same behavior if Apache/php and Netscape on same machine (using 127.0.0.1 or localhost) or on different machines with different users. 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/17106 -- Edit this bug report at http://bugs.php.net/?id=17106&edit=1
Bug #17106 Updated: Session variable disappears
ID: 17106 Updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] Status: Open Bug Type: Session related Operating System: Win98, Win2000 Pro PHP Version: 4.1.2 New Comment: For f#cks sake, we STILL have this damn problem under 4.2.1 as well. This is really starting to p#ss me off - we generate a HUGE amount of traffic, one of the top ten movie related sites in this country, and this session problem is causing viewers to constantly reload pages so that their bloody cookie logs them in - thus our bandwidth is shooting through the bloody roof (read $ down the toilet)... Previous Comments: [2002-05-13 20:32:50] [EMAIL PROTECTED] The last version for which this script works on all my tested platforms (Win98-Win2000, Apache1.3.22, Netscape 4.75) is 4.0.6. Using the php4xx-installer.exe for MS Windows. Also note that 4.0.6 does NOT register PHP in the MS Win registry, whereas versions >= 4.1.0 DO register it. Could the registry be causing problems with session variables? Just a question from an un-initiated user. Lee [2002-05-13 19:28:07] [EMAIL PROTECTED] 14 May 2002 PHP 4.2.1, all other settings as before Same behavior as 4.2.0 - on "submit" the login prompt immediately re-appears. So has NOT been fixed. The last version for which this script works is 4.1.0 Lee [2002-05-09 01:34:57] [EMAIL PROTECTED] I found the following on Zend's site: FIX: 4.2.0 session SID broken Sascha Schumann has posted a fix for problems with the session SID under 4.2.0. If you need it immediately, the fix can be found at http://apache.org/~sascha/php-420-session-fix, or will be available in 4.2.1 along with the other fixes since 4.2.0. Sounds like it may resolve the issue we're having??? [2002-05-08 22:18:00] [EMAIL PROTECTED] Sequence of tests: originally running php4.1.0 Un-installed that, installed php4.2.0 - found bug. Un-installed php4.2.0, installed php4.1.2 - still bug. Same behavior if Apache/php and Netscape on same machine (using 127.0.0.1 or localhost) or on different machines with different users. [2002-05-08 20:23:43] [EMAIL PROTECTED] When it fails under PHP 4.1.2, does it fail for ALL users or just SOME users? We've been having sheer hell since upgrading to PHP 4.2 with exactly this - SOME people are having severe intermittent problems with reading cookies (ie sometimes they'll login okay, other times they keep being asked to login), others (such as myself) have no problem what-so-ever. 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/17106 -- Edit this bug report at http://bugs.php.net/?id=17106&edit=1
Bug #14278 Updated: % and / bug with INTEGERs!
ID: 14278 Updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] -Status: Feedback +Status: No Feedback Bug Type: OCI8 related Operating System: Linux 2.2.19 PHP Version: 4.0.6 New Comment: No feedback was provided for this bug for over a month, so it is being suspended automatically. If you are able to provide the information that was originally requested, please do so and change the status of the bug back to "Open". Previous Comments: [2002-04-13 09:02:35] [EMAIL PROTECTED] oops - closed to fast. please send me a short _SELF_ contains script that shows the problem (including the oci-calls) [2002-04-13 09:00:59] [EMAIL PROTECTED] all scalar values returned from PHP-OCI8 are strings. [2002-04-09 18:12:39] [EMAIL PROTECTED] recategorizing as an oci8 issue. [2002-01-09 09:17:14] [EMAIL PROTECTED] After some more investigation on this bug I noticed following: I have an OCI insert statement executed with a 'RETURNING INTO' clause. The value which is returned is a oracle DB entry of type NUMBER. I expected to have the returned value in PHP to be a number as well. BUT it is a string! Some more output I produced in my script is: The result (when the error occures): 106851 (type: string[6] - 1068514) As you can see the value of the $num variable changes while automatic type casting from string to int is executed. The reason for the NEW (bigger) value is possibly a not null terminated string value returned by the OCI interface. My suggestion: While typecasting from string to int an extra check should be done (e.g. detect if there is a null terminated string and if not: terminate it). Thanks for your patch! [2001-12-20 12:48:09] [EMAIL PROTECTED] No feedback. Closing. 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/14278 -- Edit this bug report at http://bugs.php.net/?id=14278&edit=1
Bug #10275 Updated: can´t connect to oracle with NLS_LANG="BRAZILIAN PORTUGUESE_BRAZIL.WE8ISO8859P1
ID: 10275 Updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] -Status: Feedback +Status: No Feedback Bug Type: OCI8 related Operating System: Conectiva Linux 6 (a Red Hat bas PHP Version: 4.0.4pl1 New Comment: No feedback was provided for this bug for over a month, so it is being suspended automatically. If you are able to provide the information that was originally requested, please do so and change the status of the bug back to "Open". Previous Comments: [2002-04-13 08:24:04] [EMAIL PROTECTED] works for me. does sqlplus work with this NLS_LANG setting? [2001-04-10 18:50:56] [EMAIL PROTECTED] When I try to connect to oracle 8.1.6 or 8.1.7 configured with NLS_LANG="BRAZILIAN PORTUGUESE_BRAZIL.WE8ISO8859P1" I get the message "Warning: OCISessionBegin: Error while trying to retrieve text for error ORA-03106 in /usr/local/apache/htdocs/teste3.php on line 3" I can connect to another oracle server with default installation and the same versions of apache, linux, php and oracle. I put the variables NLS_LANG and ORACLE_HOME into apache initialization script but it didn´t work. I configured php wiht these options: --with-apache=/usr/src/apache_1.3.19/ --with-mysql --with-oci8=$ORACLE_HOME --enable-track-vars --enable-sigchild Thanks and sorry my poor english. -- Edit this bug report at http://bugs.php.net/?id=10275&edit=1
Bug #16346 Updated: MSIE Cookies problem
ID: 16346
Updated by: [EMAIL PROTECTED]
Reported By: [EMAIL PROTECTED]
-Status: Feedback
+Status: No Feedback
Bug Type: HTTP related
Operating System: Linux 7.2
PHP Version: 4.1.1
New Comment:
No feedback was provided for this bug for over a month, so it is
being suspended automatically. If you are able to provide the
information that was originally requested, please do so and change
the status of the bug back to "Open".
Previous Comments:
[2002-04-13 18:56:49] [EMAIL PROTECTED]
Please explain what the bug is. Your submission makes no sense, and we
are often too busy to spend time trying to interpret every bug report.
Please be more clear.
[2002-03-29 11:05:07] [EMAIL PROTECTED]
I use string
setcookie('some_c_name','user', $var);
PHP 4.4.1
$var| exp date
IE 5.5
9600 -> Jan 01 2070 02:40:00
3600 -> Jan 01 2070 01:00:00
1-> Jan 01 2070 00:00:01
time()+(60 * 60 * 24 * 30) -> Cant see this cook
NC
9600 -> Jan 01 02:00:01 1970
3600 -> Jan 01 02:00:01 1970
1-> Jan 01 02:00:01 1970
time()+(60 * 60 * 24 * 30) -> Apr 28 17:42:00 2002
I am used the test (http://www.chipchapin.com/WebTools/cookietest.php)
PHP 4.1.1
Method 1: OK
Method 2: Fail
Method 3: Fail
Method 4: OK
Method 5: Fail
Method 6: OK
Method 7: Fail
Method 8: OK
Method 9: OK
Method 10: Fail
Method 11: Fail
Method 12: Fail
Method 13: Fail
PHP 4.0.6
Method 1: OK
Method 2: OK
Method 3: OK
Method 4: OK
Method 5: OK
Method 6: OK
Method 7: OK
Method 8: OK
Method 9: OK
Method 10: OK
Method 11: OK
Method 12: Fail
Method 13: OK
--
Edit this bug report at http://bugs.php.net/?id=16346&edit=1
Bug #16585 Updated: Use of $_SESSION to set variable doesn't save variable
ID: 16585
Updated by: [EMAIL PROTECTED]
Reported By: [EMAIL PROTECTED]
-Status: Feedback
+Status: No Feedback
Bug Type: Session related
Operating System: Windows XP
PHP Version: 4.1.2
New Comment:
No feedback was provided for this bug for over a month, so it is
being suspended automatically. If you are able to provide the
information that was originally requested, please do so and change
the status of the bug back to "Open".
Previous Comments:
[2002-04-13 14:11:08] [EMAIL PROTECTED]
It's propably the same issue as everyone else is having.
Please try the PHP 4.2.0RC3 from http://www.php.net/~derick/
as others have reported that it works fine for them.
And don't forget to replace the php4ts.dll in your system
with the one in the 4.2.0RC3 package.
[2002-04-13 06:50:03] [EMAIL PROTECTED]
Following the 'Session handling' documentation and expriencing problems
with a production script, I wrote the following test script:
test.php:
\r\n";
if( !isset( $_SESSION['Test'] ) )
{
$_SESSION['Test'] = "bla bla bla";
echo "Defined : ".$_SESSION['Test']."\r\n";
}
else
{
echo "Existing : ".$_SESSION['Test']."\r\n";
}
//session_write_close();
?>
which I expect to set the 'Test' session variable on the first call to
the page and then return the 'Test' session variable on subsequent
calls to the script.
This works FINE with PHP 4.1.1 but DOES NOT WORK with PHP 4.1.2 (though
the session ID is the same). I had to revert to the old
'session_register()' function for the script to work in PHP 4.1.2,
$HTTP_SESSION_VARS not working either.
Any clue ?
Ce.D
--
Edit this bug report at http://bugs.php.net/?id=16585&edit=1
Bug #16337 Updated: include() does not decode % correctly
ID: 16337
Updated by: [EMAIL PROTECTED]
Reported By: [EMAIL PROTECTED]
-Status: Feedback
+Status: No Feedback
Bug Type: HTTP related
Operating System: Unix based
PHP Version: 4.1.0
New Comment:
No feedback was provided for this bug for over a month, so it is
being suspended automatically. If you are able to provide the
information that was originally requested, please do so and change
the status of the bug back to "Open".
Previous Comments:
[2002-04-15 14:04:07] [EMAIL PROTECTED]
Ok, so I think maybe I shouldn't have brought up the HTTP spec. The
*only* reason I did that, was that HTTP has one small limitation on
username:password pairs. As far as I could find, in all of new and old
RFCs (including 2617) was that ':' is disallowed from the username. I
have read of no limitations on what the password can contain.
Based on the above, I am going to make the conjecture that if the
'http://USERNAME:PASSWORD@;...' syntax in PHP can't handle certain
'special' characters, then it is broken.
The way I was trying to use this feature was like the following:
I was trying to include some headers and footers from my *local*
webserver into my PHP script when it is displayed. Why am I using an
URL for this?? Well, because the script that dynamically generates
those headers and footers is written in a different language. It is a
temporary fix for me while I port code. In any case, the
authentication realm that my PHP script lives in, is the same realm as
the headers and footers. So, when a user hits the PHP script, the
username and password variables are stuck together into a URL like:
"http://$username:$[EMAIL PROTECTED]/header.cgi";
Then I use an include() call to grab the header. Make sense so far?
The problem is, PHP bombs when the user's password contains any special
characters. More specifically, if it contains characters that are
normally considered special in URL terms.
Just suppose for a minute, that my password contains an '@'. How is
PHP to parse this? Should it assume that the first or last @ found is
the delimiter? What if the username was equal to
'www.example.org/evilscript.cgi?var='? Then we have a Cross-Site
Scripting Vulnerability on our hands.
So, my reasoning for the urlencoding was that if the user was
responsible, they would urlencode the username and password
individually, thus making the URL actually parseable in any situation.
The only way this would work though, is if PHP unencoded those tokens
after parsing them out of the URL. Currently it does not. Once again,
this escaping problem is between the caller and the include() function,
not between the PHP internals and HTTP.
[2002-04-13 19:11:18] [EMAIL PROTECTED]
RFC 2068 is obsoleted by RFC 2616, so your assumption that RFC 2068 is
still adhered to is incorrect.
The username:password string is base-64 encoded for Basic
Authentication, which I'm going to assume you're using, since you
didn't mention what type of authentication the server demands for
access to http://www.example.org/. It is not URL encoded.
Now, as for your bug report, why in the world would the include
function *decode* the username:password string? The content coming back
from the server doesn't specify the username and password to be used;
that's what *you* sent.
See RFC 2617 for more information about both Basic and Digest
Authentication over HTTP. http://ietf.org/rfc/rfc2617.txt will point
you there.
I think a better understanding of this might help you solve your
problem on your own. However, if this does not help, it should at least
allow you to better explain what the problem is, because your reports
have too many holes for me to understand what problem you are having,
whether a bug in PHP or not.
[2002-04-10 20:01:07] [EMAIL PROTECTED]
in case anyone wondered, the HTTP spec I am refering to, is at:
http://www.cis.ohio-state.edu/cgi-bin/rfc/rfc2068.html
(Section 11.1)
Since RFC 2616 doesn't specify user-pass strings, I assume this older
RFC still applies.
[2002-04-10 19:57:48] [EMAIL PROTECTED]
Correction:
PHP's fopen url wrapper doesn't appear to unencode ANY encodings at
all. Since the HTTP spec only excludes ':' from the username (and
nothing at all from the password), this bug makes many
username:password pairs unusable.
[2002-03-28 18:12:28] [EMAIL PROTECTED]
When include() is called with the following syntax:
include("http://username:[EMAIL PROTECTED]/";);
It is the duty of the include call to tokenize the username and
password, and to urldecode each of them. Why? B
Bug #17196: ZendOptimizer dll not loading
From: [EMAIL PROTECTED] Operating system: Windows 2000 PHP version: 4.2.1 PHP Bug Type: IIS related Bug description: ZendOptimizer dll not loading Running PHP with IIS 5.0, successfully ran 4.2.0 with the ZendOptimizer, upgraded to 4.2.1 using the zip package and restarted the server. Error message appears saying that the ZendOptimizer.dll file cannot be loaded. Have commented out the Zend options in the php.ini file. Everything else is working well. Modules running: gd, mysql, imap, xml, wddx, pcre, odbc, ftp. Server API: CGI No changes made to basic system installed by zip package. -- Edit bug report at http://bugs.php.net/?id=17196&edit=1 -- Fixed in CVS:http://bugs.php.net/fix.php?id=17196&r=fixedcvs Fixed in release:http://bugs.php.net/fix.php?id=17196&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=17196&r=needtrace Try newer version: http://bugs.php.net/fix.php?id=17196&r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=17196&r=support Expected behavior: http://bugs.php.net/fix.php?id=17196&r=notwrong Not enough info: http://bugs.php.net/fix.php?id=17196&r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=17196&r=submittedtwice register_globals:http://bugs.php.net/fix.php?id=17196&r=globals
Bug #17195: unhandle exception processiong ISAPI
From: [EMAIL PROTECTED] Operating system: win2000 PHP version: 4.2.0 PHP Bug Type: IIS related Bug description: unhandle exception processiong ISAPI Hi derek Sorry for open a new bug report again, because I cannot change the status of the previous bug report from bogus to open. sorry for the inconvenience. This is my first time to report bug and sorry of my stupid way to present my problem before. I would like to describe my problem again. I have simpplified my php script as follow: Proactive Channel Monitor I want to connect to a server socket and the php will be refresh in 10 sec. Now, my server socket is down. So my expect result is: fsockopen() return false->the error no is print out->the page refresh after 10 sec to reconnect. And the actual result is that it work under my expectation,but after the page refresh for about 20 times. PHP is crash and from the "Event viewer" of win2000. I found that: Source:WAM Event ID:204 Type:error Description: The HTTP server encountered an unhandled exception while processing the ISAPI Application ' php4ts!zend_strndup + 0x2B + 0xA05E5983 '. After that, I have to restart the IIS to make PHP work again Is there any other method for me to collect more information for helping debug?? Thx!! -- Edit bug report at http://bugs.php.net/?id=17195&edit=1 -- Fixed in CVS:http://bugs.php.net/fix.php?id=17195&r=fixedcvs Fixed in release:http://bugs.php.net/fix.php?id=17195&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=17195&r=needtrace Try newer version: http://bugs.php.net/fix.php?id=17195&r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=17195&r=support Expected behavior: http://bugs.php.net/fix.php?id=17195&r=notwrong Not enough info: http://bugs.php.net/fix.php?id=17195&r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=17195&r=submittedtwice register_globals:http://bugs.php.net/fix.php?id=17195&r=globals
Bug #17106 Updated: Session variable disappears
ID: 17106
Updated by: [EMAIL PROTECTED]
Reported By: [EMAIL PROTECTED]
Status: Open
Bug Type: Session related
Operating System: Win98, Win2000 Pro
PHP Version: 4.1.2
New Comment:
The last version for which this script works on all my tested platforms
(Win98-Win2000, Apache1.3.22, Netscape 4.75) is 4.0.6. Using the
php4xx-installer.exe for MS Windows.
Also note that 4.0.6 does NOT register PHP in the MS Win registry,
whereas versions >= 4.1.0 DO register it. Could the registry be causing
problems with session variables? Just a question from an un-initiated
user.
Lee
Previous Comments:
[2002-05-13 19:28:07] [EMAIL PROTECTED]
14 May 2002
PHP 4.2.1, all other settings as before
Same behavior as 4.2.0 - on "submit" the login prompt immediately
re-appears. So has NOT been fixed.
The last version for which this script works is 4.1.0
Lee
[2002-05-09 01:34:57] [EMAIL PROTECTED]
I found the following on Zend's site:
FIX: 4.2.0 session SID broken
Sascha Schumann has posted a fix for problems with the session SID
under 4.2.0. If you need it immediately, the fix can be found at
http://apache.org/~sascha/php-420-session-fix, or will be available in
4.2.1 along with the other fixes since 4.2.0.
Sounds like it may resolve the issue we're having???
[2002-05-08 22:18:00] [EMAIL PROTECTED]
Sequence of tests:
originally running php4.1.0
Un-installed that, installed php4.2.0 - found bug.
Un-installed php4.2.0, installed php4.1.2 - still bug.
Same behavior if Apache/php and Netscape on same machine (using
127.0.0.1 or localhost) or on different machines with different users.
[2002-05-08 20:23:43] [EMAIL PROTECTED]
When it fails under PHP 4.1.2, does it fail for ALL users or just SOME
users? We've been having sheer hell since upgrading to PHP 4.2 with
exactly this - SOME people are having severe intermittent problems with
reading cookies (ie sometimes they'll login okay, other times they keep
being asked to login), others (such as myself) have no problem
what-so-ever.
[2002-05-08 19:00:35] [EMAIL PROTECTED]
Following is a login script which sets a session variable $userSN.
First time it is run, it prompts for username and password, then sets
the $userSN and displays "Welcome...". Second time it is run within a
session, it checks isset($userSN) and displays "You are already logged
in"
Performance:
Win98, Apache1.3.22, Netscape 4.75, php4.1.0 - first time - prompts as
expected and displays "Welcome..", second time - displays "already
logged in" as expected
Win98, Apache1.3.22, Netscape 4.75, php4.1.2 - first time - prompts as
expected and displays "Welcome..", second time - prompts for name and
password again, so $userSN has NOT been set or has disappeared. (Note:
same behavior with Win2000 Pro, Apache1.3.22, Netscape 4.75, php4.1.0)
Win98, Apache1.3.22, Netscape 4.75, php4.2.0 - first time - prompts as
expected, but on "submit" returns immediately to the prompt again.
PHP session parameters in php.ini are the default options.
Previous bug report 15867 - was claimed to have been fixed.
You have already logged in for this
session.\n");
printf("To logout click here.");
printf("");
exit;
}
//Check Password IF $userSN is NOT SET AND either clicked Submit or are
off-line
if ($submit || ($OnLine == false)) {
$conn = odbc_connect( DB_PROVIDER_NAME, DB_PROVIDER_USERNAME,
DB_PROVIDER_PASSWORD, DB_PROVIDER_CURSORTYPE);
// OFFLINE VERSION uses $DefaultPassword or $DefaultUserSN
if ($OnLine == false) {
$query= "SELECT ProviderSN, ProviderName, UserName, Password,
RefereeS
Bug #17194 Updated: bouncing email address ->confirm@php.net
ID: 17194 Updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] -Status: Open +Status: Bogus Bug Type: *General Issues Operating System: win2000 PHP Version: 4.2.0 New Comment: please forward the bounce (including the message that got bounced) to [EMAIL PROTECTED] Previous Comments: [2002-05-13 19:43:44] [EMAIL PROTECTED] Hi. This is the qmail-send program at php.net. I'm afraid I wasn't able to deliver your message to the following addresses. This is a permanent error; I've given up. Sorry it didn't work out. <[EMAIL PROTECTED]>: confirmation hash does not match sender email. -- Edit this bug report at http://bugs.php.net/?id=17194&edit=1
Bug #17194: bouncing email address ->confirm@php.net
From: [EMAIL PROTECTED] Operating system: win2000 PHP version: 4.2.0 PHP Bug Type: *General Issues Bug description: bouncing email address ->[EMAIL PROTECTED] Hi. This is the qmail-send program at php.net. I'm afraid I wasn't able to deliver your message to the following addresses. This is a permanent error; I've given up. Sorry it didn't work out. <[EMAIL PROTECTED]>: confirmation hash does not match sender email. -- Edit bug report at http://bugs.php.net/?id=17194&edit=1 -- Fixed in CVS:http://bugs.php.net/fix.php?id=17194&r=fixedcvs Fixed in release:http://bugs.php.net/fix.php?id=17194&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=17194&r=needtrace Try newer version: http://bugs.php.net/fix.php?id=17194&r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=17194&r=support Expected behavior: http://bugs.php.net/fix.php?id=17194&r=notwrong Not enough info: http://bugs.php.net/fix.php?id=17194&r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=17194&r=submittedtwice register_globals:http://bugs.php.net/fix.php?id=17194&r=globals
Bug #17192 Updated: DLL not valid
ID: 17192 Updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] Status: Open Bug Type: GD related Operating System: Windows 2002 PHP Version: 4.2.1 New Comment: I've got the same problems (OS = WinXP) trying to load the curl and sockets modules. Apache reports the PHP API compile date of 20010901(!) but the modules as 20020429. Also, where are the missing modules (imap, ldap, etc)? Previous Comments: [2002-05-13 19:15:57] [EMAIL PROTECTED] Today I installed PHP 4.2.1 and did everything I had to do... copy DLLs to Winnt\System32, configure Apache, etc. When I started Apache, I got an error concerning php_gd2.dll : it can't be loaded. I think there is an error of compilation in Win32 binaries of PHP 4.2.1. Thanks -- Edit this bug report at http://bugs.php.net/?id=17192&edit=1
Bug #17106 Updated: Session variable disappears
ID: 17106
Updated by: [EMAIL PROTECTED]
Reported By: [EMAIL PROTECTED]
Status: Open
Bug Type: Session related
Operating System: Win98, Win2000 Pro
PHP Version: 4.1.2
New Comment:
14 May 2002
PHP 4.2.1, all other settings as before
Same behavior as 4.2.0 - on "submit" the login prompt immediately
re-appears. So has NOT been fixed.
The last version for which this script works is 4.1.0
Lee
Previous Comments:
[2002-05-09 01:34:57] [EMAIL PROTECTED]
I found the following on Zend's site:
FIX: 4.2.0 session SID broken
Sascha Schumann has posted a fix for problems with the session SID
under 4.2.0. If you need it immediately, the fix can be found at
http://apache.org/~sascha/php-420-session-fix, or will be available in
4.2.1 along with the other fixes since 4.2.0.
Sounds like it may resolve the issue we're having???
[2002-05-08 22:18:00] [EMAIL PROTECTED]
Sequence of tests:
originally running php4.1.0
Un-installed that, installed php4.2.0 - found bug.
Un-installed php4.2.0, installed php4.1.2 - still bug.
Same behavior if Apache/php and Netscape on same machine (using
127.0.0.1 or localhost) or on different machines with different users.
[2002-05-08 20:23:43] [EMAIL PROTECTED]
When it fails under PHP 4.1.2, does it fail for ALL users or just SOME
users? We've been having sheer hell since upgrading to PHP 4.2 with
exactly this - SOME people are having severe intermittent problems with
reading cookies (ie sometimes they'll login okay, other times they keep
being asked to login), others (such as myself) have no problem
what-so-ever.
[2002-05-08 19:00:35] [EMAIL PROTECTED]
Following is a login script which sets a session variable $userSN.
First time it is run, it prompts for username and password, then sets
the $userSN and displays "Welcome...". Second time it is run within a
session, it checks isset($userSN) and displays "You are already logged
in"
Performance:
Win98, Apache1.3.22, Netscape 4.75, php4.1.0 - first time - prompts as
expected and displays "Welcome..", second time - displays "already
logged in" as expected
Win98, Apache1.3.22, Netscape 4.75, php4.1.2 - first time - prompts as
expected and displays "Welcome..", second time - prompts for name and
password again, so $userSN has NOT been set or has disappeared. (Note:
same behavior with Win2000 Pro, Apache1.3.22, Netscape 4.75, php4.1.0)
Win98, Apache1.3.22, Netscape 4.75, php4.2.0 - first time - prompts as
expected, but on "submit" returns immediately to the prompt again.
PHP session parameters in php.ini are the default options.
Previous bug report 15867 - was claimed to have been fixed.
You have already logged in for this
session.\n");
printf("To logout click here.");
printf("");
exit;
}
//Check Password IF $userSN is NOT SET AND either clicked Submit or are
off-line
if ($submit || ($OnLine == false)) {
$conn = odbc_connect( DB_PROVIDER_NAME, DB_PROVIDER_USERNAME,
DB_PROVIDER_PASSWORD, DB_PROVIDER_CURSORTYPE);
// OFFLINE VERSION uses $DefaultPassword or $DefaultUserSN
if ($OnLine == false) {
$query= "SELECT ProviderSN, ProviderName, UserName, Password,
RefereeStat
FROM Provider
WHERE ProviderSN = $DefaultUserSN;";
} //End of OnLine = False
else {
$form_password = md5($form_password);
$query= "SELECT ProviderSN, ProviderName, UserName, Password,
RefereeStat
FROM Provider
WHERE UserName = '" .
cleanString($form_username) . "'
Bug #17193: calling getenv after register_shutdown causes apache to crash
From: [EMAIL PROTECTED] Operating system: RH Linux 7.2/Apach 1.3.22 PHP version: 4.1.2 PHP Bug Type: Scripting Engine problem Bug description: calling getenv after register_shutdown causes apache to crash If you call register_shutdown_function, and then in the registered function make a call to getenv, Apache segfaults. Here's a sample script: Please note. This only happens when running as an apache module. CLI works fine, and I'd assume that CGI does too. I'll post a back trace if some kind soul will explain how to do it under RH linux using the messed up !apachectl method that they use to start apache. -- Edit bug report at http://bugs.php.net/?id=17193&edit=1 -- Fixed in CVS:http://bugs.php.net/fix.php?id=17193&r=fixedcvs Fixed in release:http://bugs.php.net/fix.php?id=17193&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=17193&r=needtrace Try newer version: http://bugs.php.net/fix.php?id=17193&r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=17193&r=support Expected behavior: http://bugs.php.net/fix.php?id=17193&r=notwrong Not enough info: http://bugs.php.net/fix.php?id=17193&r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=17193&r=submittedtwice register_globals:http://bugs.php.net/fix.php?id=17193&r=globals
Bug #17192: DLL not valid
From: [EMAIL PROTECTED] Operating system: Windows 2002 PHP version: 4.2.1 PHP Bug Type: GD related Bug description: DLL not valid Today I installed PHP 4.2.1 and did everything I had to do... copy DLLs to Winnt\System32, configure Apache, etc. When I started Apache, I got an error concerning php_gd2.dll : it can't be loaded. I think there is an error of compilation in Win32 binaries of PHP 4.2.1. Thanks -- Edit bug report at http://bugs.php.net/?id=17192&edit=1 -- Fixed in CVS:http://bugs.php.net/fix.php?id=17192&r=fixedcvs Fixed in release:http://bugs.php.net/fix.php?id=17192&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=17192&r=needtrace Try newer version: http://bugs.php.net/fix.php?id=17192&r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=17192&r=support Expected behavior: http://bugs.php.net/fix.php?id=17192&r=notwrong Not enough info: http://bugs.php.net/fix.php?id=17192&r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=17192&r=submittedtwice register_globals:http://bugs.php.net/fix.php?id=17192&r=globals
Bug #17144 Updated: No Session ID and losing Session Var's between pages
ID: 17144 Updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] Status: Open Bug Type: Session related Operating System: FreeBSD 4.5 PHP Version: 4.2.0 New Comment: also trying to echo session_id(); with no success. Still not working in 4.2.1 released May 13th Also i can't Edit my submission Previous Comments: [2002-05-10 14:57:44] [EMAIL PROTECTED] Config line: ./configure '--prefix=/usr/opt/php' '--with-apxs=/usr/opt/apache/sbin/apxs' '--with-mysql=/usr/opt/mysql' '--with-pgsql=/usr/opt/pgsql' '--with-mm' '--with-ldap' '--enable-trans-sid' '--enable-magic-quotes' '--enable-shared' '--enable-mhash' '--enable-ftp' '--with-gettext' '--enable-mailparse' '--enable-libgcc' '--enable-calendar' '--with-openssl' Other details: Register Globals = OFF Enable Trans SID = ON Set Session Cookies = 1 Session Auto Start = 1 I have a login form that asks for a used name and password. Once the user has been authenticated they are assigned a set of $_SESSION Variables: code $_SESSION['login'] = $_POST['login']; $_SESSION['password'] = $_POST['password']; $_SESSION['logged'] = $_POST['logged']; $_SESSION['action'] = $action; $_SESSION['rank_id'] = $rank_id; end code When the users click on a link in the menu system all these variables are lost (ie echos come up blank). If i add the session_start(); at the top of the page then the variables are passed without a problem. If at any time i try to echo out the Session ID (which for me is SFDICsession) i get a blank value using the following code: code end code - thoughts? Thanks in advance! -- Edit this bug report at http://bugs.php.net/?id=17144&edit=1
Bug #13133 Updated: Get longbinary data from ACCESS
ID: 13133 Updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] -Status: Open +Status: Bogus Bug Type: ODBC related Operating System: W98 ME PHP Version: 4.0.4pl1 New Comment: Thank you for taking the time to report a problem with PHP. Unfortunately your version of PHP is too old -- 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. Previous Comments: [2001-09-04 11:08:25] [EMAIL PROTECTED] LongBinary data from ACCESS. I receive 2 bytes for every byte of data, one is &h00. Dimensione: ".$Dimensione.""; $NomeFile = $SceltaOggetto.".jpg"; unlink($NomeFile); // scancello if (file_exists($NomeFile) == FALSE): odbc_longreadlen ($resImg,$Dimensione); $graf = odbc_result($resImg,1); echo "Lungore ".strlen($graf); $fp = fopen ($NomeFile, "wb"); fwrite($fp,$graf,$Dimensione); echo "ECHO".$graf; fclose($fp); endif; endif; ?> -- Edit this bug report at http://bugs.php.net/?id=13133&edit=1
Bug #14238 Updated: odbc_fetch_into using an array in an object
ID: 14238
Updated by: [EMAIL PROTECTED]
Reported By: [EMAIL PROTECTED]
-Status: Open
+Status: Bogus
Bug Type: ODBC related
Operating System: NT 4.0 Workstation - SP6
PHP Version: 4.0.6
New Comment:
Thank you for taking the time to report a problem with PHP.
Unfortunately your version of PHP is too old -- 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.
Previous Comments:
[2001-11-26 12:25:10] [EMAIL PROTECTED]
While working on a class to encapsulate ODBC functionality, I
discovered a problem in calling odbc_fetch_into with an array that
exists inside a class. I was creating an array in the class to hold the
results of the current row, and allowing the user of the class to
reference the fields from there. It looked a little like this:
class DB {
var $record = array();
var $queryid;
...
function fetch_row() {
return(odbc_fetch_into($this->queryid, $this->record)
}
...
}
When I tried to display the results from $record with something like
echo $myDB->record[0];, all that is displayed is "Array[0]" (w/o
quotes).
After some tinkering, I modified the "fetch_row()" function in my class
to accept an array parameter:
function fetch_row($myarray) {
return(odbc_fetch_into($this->queryid, $myarray)
}
This corrected the problem, although I have to give up my
encapsulation. Now echo $myarray[0]; displays the appropriate data.
So it appears that there is a conflict with encapsulated arrays and
odbc_fetch_into. I believe that there was a similiar problem with the
MS SQL extension a while back (mid version 3 around 3.0.12 or so).
I'm accessing an MS Access 97 database through Microsoft's ODBC driver.
A fully functional example follows.
Greg Sohl
Cedar Rapids, IA
Here is a fully functional example of what works and what doesn't work.
Its as short as I could get it and keep it understandable.
IDNameEmail
$my_array[0]$my_array[1]$my_array[2]";
odbc_fetch_row($queryid, 0);// Reset to the begininning
/* This technique does not work - Calling odbc_fetch_into with an array
in a class */
$my_results = new Results();
while(odbc_fetch_into($queryid, $my_results->record))
echo
"$my_results->record[0]$my_results->record[1]$my_results->record[2]";
?>
--
Edit this bug report at http://bugs.php.net/?id=14238&edit=1
Bug #16827 Updated: DB2 access fails under PHP4.2.0
ID: 16827 Updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] -Status: Open +Status: Bogus Bug Type: ODBC related Operating System: Linux, Debian 2.2 PHP Version: 4.2.0 New Comment: Thank you for taking the time to report a problem with PHP. Unfortunately your version of PHP is too old -- 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. Previous Comments: [2002-04-25 13:57:58] [EMAIL PROTECTED] I have noticed that all the DB2 (v7.1) accessing code (via the unified ODBC functions) fails to be able to gather results under PHP4.2.0. PHP is not crashing, and script execution continues past the points of failure, and no error messages are displayed or logged. It appears that there is just no data coming back from the odbc_do() function, although the return code of odbc_fetch_into() is greather than zero. PHP configure line: --with-apache=../apache --enable-trans-sid --with-zlib --with-mysql=/usr/local/ --with-ibm-db2=/usr/IBMdb2/V7.1/ --with-ldap --with-mcrypt --with-imap --with-gd=/usr/ --with-png-dir=/usr/ --with-jpeg-dir=/usr/ Yes, I know there's a lot of stuff compiled in, but I need and use it all :) I have done a clean build every time for my setup, and the results are the same with PHP 4.2.0. PHP 4.1.2 does NOT exhibit this problem, using the same compile time options as above - and running on the exact same pages on the same machine, even a recompile with PHP4.1.2 yields a fully working system. Thanks, Derek -- Edit this bug report at http://bugs.php.net/?id=16827&edit=1
Bug #17180 Updated: Operator Precedence
ID: 17180 Updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] Status: Analyzed Bug Type:Scripting Engine problem PHP Version: 4.2.0 New Comment: This behaviour is capable to confuse the developer and if this is "features" it must be documented in manual. Previous Comments: [2002-05-13 18:20:14] [EMAIL PROTECTED] Well, but it's stupid to do something like that. It makes no sense to assign anything to NOT(a variable), so PHP takes care of that by changing the precedence a little in this case. [2002-05-13 17:56:54] [EMAIL PROTECTED] Yes, I want ASSIGN value to $a and check assigned value. But parser must say: "parser error", becouse it can not assign value to constant. Please reopen. [2002-05-13 17:48:54] [EMAIL PROTECTED] "if (!$a = foo(FALSE))" --> you're assigning the output of foo(FALSE) to $a "if (!$a == foo(FALSE))" --> you're comparing !$a and foo(FALSE) [2002-05-13 09:36:32] [EMAIL PROTECTED] Why & How this code will work? Output: if (!$a = foo(FALSE))) is true bool(false) http://www.php.net/manual/en/language.operators.php "Operator Precedence" `!` has more precedence than `=` And after `!` we must have boolean constant in left side: FALSE = foo() Explain to me pls that I do not understand P.S. in C & Perl (!$a = foo()) is not valid expression -- Edit this bug report at http://bugs.php.net/?id=17180&edit=1
Bug #17141 Updated: Self-References not supported
ID: 17141
Updated by: [EMAIL PROTECTED]
Reported By: [EMAIL PROTECTED]
-Status: Open
+Status: Feedback
Bug Type: ODBC related
Operating System: AIX 4.3.3
PHP Version: 4.1.2
New Comment:
Can you please provide a sample schema to reproduce this locally and
test this out further?
Previous Comments:
[2002-05-10 09:14:03] [EMAIL PROTECTED]
I was trying to view a self-referenced Table (parent_id is the id of
another member); with OBDC towards DB2 (on AIX 4.3.3) PHP does not set
the array right; I dont get the parents name but the childs name
twice.
Code
$conn=odbc_connect("db", "user", "pass");
$stmt="select a.bm_id, a.bm_bezeichnung, b.bm_bezeichnung as
parent_bm_bezeichnung from schema.table a, schema.table b where
b.bm_id=a.bes_bm_id";
$res=odbc_exec($conn,$stmt);
print odbc_result_all($res);
ODBC Result
===
BM_ID BM_BEZEICHNUNG PARENT_BM_BEZEICHNUNG
5 Tonband Tonband
6 Handy Handy
2
(the 2 is new, seems to be the "2 records selected" rest)
DB2 Result
==
BM_ID BM_BEZEICHNUNG PARENT_BM_BEZEICHNUNG
-- -
5 Tonband Telefonisch
6 HandyTelefonisch
2 record(s) selected.
--
Edit this bug report at http://bugs.php.net/?id=17141&edit=1
Bug #16756 Updated: type 'text' fields not retrieved, warning given
ID: 16756 Updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] -Status: Open +Status: Closed Bug Type: ODBC related Operating System: Win2000-SP2 + IIS5 PHP Version: 4.2.0 New Comment: Type TEXT is not a valid ODBC type with ODBC v2.0 systems (which PHP is). There is work currently underway to enable support for the recent ODBC release (which includes ODBC v3.7 and TEXT support), but at this time it's not generally available. None the less some of the errors you are seeing have been fixed in 4.2.1 (I believe). Please try that for the other errors you were seeing, and see if that fixes them. Sorry about that, but I made a bad change and no one tested it. Forgot to mark this closed Previous Comments: [2002-05-13 18:26:41] [EMAIL PROTECTED] Type TEXT is not a valid ODBC type with ODBC v2.0 systems (which PHP is). There is work currently underway to enable support for the recent ODBC release (which includes ODBC v3.7 and TEXT support), but at this time it's not generally available. None the less some of the errors you are seeing have been fixed in 4.2.1 (I believe). Please try that for the other errors you were seeing, and see if that fixes them. Sorry about that, but I made a bad change and no one tested it. [2002-04-23 11:14:57] [EMAIL PROTECTED] When selecting data from a table with ODBC on a SQL2000 database (latest MDAC + SQL Server drivers version 200.80.528.00 + PHP4.20) a warning is given. Warning: SQL error: [Microsoft][ODBC SQL Server Driver]Invalid Descriptor Index, SQL state S1002 in SQLGetData This warning does not appear when using PHP version up to 4.1.0. PHP is configured as a CGI program (ISAPI does not seem to work either!!) The warning appears when using odbc_result(), using both field names and column numbers, example: $conID=odbc_pconnect($dsn,$usr,$pwd); $res=odbc_do($conID,"SELECT Fieldname FROM Table") $var=odbc_result($conID,"Fieldname"); //either this $var=odbc_result($conID,1); //or this is used Further, the data is not retrieved from that field onwards and the data transfer from the server dies. The type of data is the SQL Server type 'text', length is 16. The script has not been modified in any way. We have taken into account the parameter for odbc_longreadlen() As far as we understand it, the error seems to indicate that the requested field cannot be found, even though other applications (MS-Access, SQL-Server) and PHP 4.1.0. don't seem to have this problem. -- Edit this bug report at http://bugs.php.net/?id=16756&edit=1
Bug #16756 Updated: type 'text' fields not retrieved, warning given
ID: 16756 Updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] Status: Open Bug Type: ODBC related Operating System: Win2000-SP2 + IIS5 PHP Version: 4.2.0 New Comment: Type TEXT is not a valid ODBC type with ODBC v2.0 systems (which PHP is). There is work currently underway to enable support for the recent ODBC release (which includes ODBC v3.7 and TEXT support), but at this time it's not generally available. None the less some of the errors you are seeing have been fixed in 4.2.1 (I believe). Please try that for the other errors you were seeing, and see if that fixes them. Sorry about that, but I made a bad change and no one tested it. Previous Comments: [2002-04-23 11:14:57] [EMAIL PROTECTED] When selecting data from a table with ODBC on a SQL2000 database (latest MDAC + SQL Server drivers version 200.80.528.00 + PHP4.20) a warning is given. Warning: SQL error: [Microsoft][ODBC SQL Server Driver]Invalid Descriptor Index, SQL state S1002 in SQLGetData This warning does not appear when using PHP version up to 4.1.0. PHP is configured as a CGI program (ISAPI does not seem to work either!!) The warning appears when using odbc_result(), using both field names and column numbers, example: $conID=odbc_pconnect($dsn,$usr,$pwd); $res=odbc_do($conID,"SELECT Fieldname FROM Table") $var=odbc_result($conID,"Fieldname"); //either this $var=odbc_result($conID,1); //or this is used Further, the data is not retrieved from that field onwards and the data transfer from the server dies. The type of data is the SQL Server type 'text', length is 16. The script has not been modified in any way. We have taken into account the parameter for odbc_longreadlen() As far as we understand it, the error seems to indicate that the requested field cannot be found, even though other applications (MS-Access, SQL-Server) and PHP 4.1.0. don't seem to have this problem. -- Edit this bug report at http://bugs.php.net/?id=16756&edit=1
Bug #15306 Updated: odbc_fetch_row does not always return all rows
ID: 15306 Updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] -Status: Open +Status: Closed Bug Type: ODBC related Operating System: MacOSX 10.1.2 PHP Version: 4.1.1 New Comment: running your sample script below I don't see the problem. Although the big differences are I'm on 10.1.4, and PHP 4.3-dev. Please try the 4.2.1 release and see if this continues for you. Previous Comments: [2002-01-30 20:06:35] [EMAIL PROTECTED] odbc_fetch_row( $cur) called repeatedly without passing the row argument should retrieve all the rows in a rowset sequentially. Instead, in my setup, if the query, to which $cur relates, is a SELECT * FROM ... ORDER BY..., a number or rows will be dropped (it seems rows for which some column is not unique in the rowset). My setup is: MacOSX 10.1.2 (what a pain to compile php4.1.1 on it!) DB: OpenLink Virtuoso Lite 2.5 iodbc + Openlink Virtuoso Driver 02.50.2139 php built using: ./configure --prefix=/usr --sysconfdir=/etc -- localstatedir=/var --mandir=/usr/share/man --with-zlib -- with-xml --with-iodbc=/usr/local/odbcsdk --with-apxs < / dev/null (note that I had to use the libtool generated under 4.0.6 in order to compile 4.1.1) and this is the sample script (it includes the workaround, that is to always pass the $row argument to odbc_fetch_row) "; } //disconnect from database odbc_close( $conn); ?> -- Edit this bug report at http://bugs.php.net/?id=15306&edit=1
Bug #17180 Updated: Operator Precedence
ID: 17180 Updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] -Status: Bogus +Status: Analyzed Bug Type:Scripting Engine problem PHP Version: 4.2.0 New Comment: Well, but it's stupid to do something like that. It makes no sense to assign anything to NOT(a variable), so PHP takes care of that by changing the precedence a little in this case. Previous Comments: [2002-05-13 17:56:54] [EMAIL PROTECTED] Yes, I want ASSIGN value to $a and check assigned value. But parser must say: "parser error", becouse it can not assign value to constant. Please reopen. [2002-05-13 17:48:54] [EMAIL PROTECTED] "if (!$a = foo(FALSE))" --> you're assigning the output of foo(FALSE) to $a "if (!$a == foo(FALSE))" --> you're comparing !$a and foo(FALSE) [2002-05-13 09:36:32] [EMAIL PROTECTED] Why & How this code will work? Output: if (!$a = foo(FALSE))) is true bool(false) http://www.php.net/manual/en/language.operators.php "Operator Precedence" `!` has more precedence than `=` And after `!` we must have boolean constant in left side: FALSE = foo() Explain to me pls that I do not understand P.S. in C & Perl (!$a = foo()) is not valid expression -- Edit this bug report at http://bugs.php.net/?id=17180&edit=1
Bug #13809 Updated: Openlink 3.2 and 4.0 odbc_do and single quotes
ID: 13809
Updated by: [EMAIL PROTECTED]
Reported By: [EMAIL PROTECTED]
-Status: Open
+Status: Analyzed
Bug Type: ODBC related
Operating System: SCO Openserver 5.0.5 & RH Lnux 7
PHP Version: 4.0.6
New Comment:
did some examination on this, and I believe it lies in the OpenLink
software... as I see the same problem here, but not on my Windows
emulation. Andrew any chance you can take a look into this further?
Previous Comments:
[2001-10-24 05:19:44] [EMAIL PROTECTED]
Came across this issue when doing my data conversions. If the fields
have single quotes in them, odbc_do fails.
I have tested this against the Openlink 3.2 and 4.1 SDK's and found
that using odbc_prepare works fine.
Basic Script
SQL: $sql";
$results = odbc_do($conn,$sql);
if ($results) {
while (odbc_fetch_into($results,$row)) {
echo $row[0]." ".$row[1]." ".$row[2]."\n";
}
}
$sql="SELECT ID,Category,description FROM card_type WHERE description
LIKE '%PEP%'";
echo "SQL: $sql";
$results = odbc_do($conn,$sql);
if ($results) {
while (odbc_fetch_into($results,$row)) {
echo $row[0]." ".$row[1]." ".$row[2]."\n";
}
}
$sql='SELECT ID,Category,description FROM card_type WHERE description
LIKE "%PEP%"';
echo "SQL: $sql";
$results = odbc_do($conn,$sql);
if ($results) {
while (odbc_fetch_into($results,$row)) {
echo $row[0]." ".$row[1]." ".$row[2]."\n";
}
}
$sql='SELECT ID,Category,description FROM card_type WHERE
description="PEPPERELL\'S"';
echo "SQL: $sql";
$results = odbc_do($conn,$sql);
if ($results) {
while (odbc_fetch_into($results,$row)) {
echo $row[0]." ".$row[1]." ".$row[2]."\n";
}
}
$sql="SELECT ID,Category,description FROM card_type WHERE
description=\"PEPPERELL'S\"";
echo "SQL: $sql";
$results = odbc_do($conn,$sql);
if ($results) {
while (odbc_fetch_into($results,$row)) {
echo $row[0]." ".$row[1]." ".$row[2]."\n";
}
}
/*
Output
--
SQL: SELECT ID,Category,description FROM card_type WHERE
description='IMPEYS'
355 Other Item IMPEYS
SQL: SELECT ID,Category,description FROM card_type WHERE description
LIKE '%PEP%'
177 Other Item PEPPERELL'S
SQL: SELECT ID,Category,description FROM card_type WHERE description
LIKE "%PEP%"
Warning: SQL error: [OpenLink][ODBC][Driver]Syntax error or access, SQL
state 37000 in SQLExecDirect in /usr/local/.WWW/WEBS/_odbc/test.php3 on
line 42
SQL: SELECT ID,Category,description FROM card_type WHERE
description="PEPPERELL'S"
Warning: SQL error: [OpenLink][ODBC][Driver]Syntax error or access, SQL
state 37000 in SQLExecDirect in /usr/local/.WWW/WEBS/_odbc/test.php3 on
line 50
SQL: SELECT ID,Category,description FROM card_type WHERE
description="PEPPERELL'S"
Warning: SQL error: [OpenLink][ODBC][Driver]Syntax error or access, SQL
state 37000 in SQLExecDirect in /usr/local/.WWW/WEBS/_odbc/test.php3 on
line 58
*/
?>
--
Edit this bug report at http://bugs.php.net/?id=13809&edit=1
Bug #17191 Updated: PHP Variables undefined
ID: 17191 Updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] Status: Open Bug Type: IIS related Operating System: Win 2000 Server PHP Version: 4.2.1 New Comment: No, I've already changed both "register_globals" and "register_argc_argv" to "On". Now, e.g. $OS is defined. However, Variables passed via URL still remaine undefined. (I am using the same PHP.INI File than on an XP-Installation, where PHP&IIS5 work. Are there any other modifications performed by the OCX which I am still missing ?) Previous Comments: [2002-05-13 17:45:04] [EMAIL PROTECTED] That makes sense if you haven't turned the register_globals directive On in php.ini. [2002-05-13 17:36:44] [EMAIL PROTECTED] Because of the known "OCX-Control missing" problem I did a manual configuration on Windows 2000 Server (IIS5). PHP scripts run (e.g. phpinfo()), but own function don't have access to PHP Variables, there seem to be no variable definitions at all. Calling a script via http://localhost/test.php?a=1 does not result in a variable "a" within the script. -- Edit this bug report at http://bugs.php.net/?id=17191&edit=1
Bug #17180 Updated: Operator Precedence
ID: 17180 Updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] Status: Bogus Bug Type:Scripting Engine problem PHP Version: 4.2.0 New Comment: Yes, I want ASSIGN value to $a and check assigned value. But parser must say: "parser error", becouse it can not assign value to constant. Please reopen. Previous Comments: [2002-05-13 17:48:54] [EMAIL PROTECTED] "if (!$a = foo(FALSE))" --> you're assigning the output of foo(FALSE) to $a "if (!$a == foo(FALSE))" --> you're comparing !$a and foo(FALSE) [2002-05-13 09:36:32] [EMAIL PROTECTED] Why & How this code will work? Output: if (!$a = foo(FALSE))) is true bool(false) http://www.php.net/manual/en/language.operators.php "Operator Precedence" `!` has more precedence than `=` And after `!` we must have boolean constant in left side: FALSE = foo() Explain to me pls that I do not understand P.S. in C & Perl (!$a = foo()) is not valid expression -- Edit this bug report at http://bugs.php.net/?id=17180&edit=1
Bug #17180 Updated: Operator Precedence
ID: 17180 Updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] -Status: Open +Status: Bogus Bug Type:Scripting Engine problem PHP Version: 4.2.0 Previous Comments: [2002-05-13 17:48:54] [EMAIL PROTECTED] "if (!$a = foo(FALSE))" --> you're assigning the output of foo(FALSE) to $a "if (!$a == foo(FALSE))" --> you're comparing !$a and foo(FALSE) [2002-05-13 09:36:32] [EMAIL PROTECTED] Why & How this code will work? Output: if (!$a = foo(FALSE))) is true bool(false) http://www.php.net/manual/en/language.operators.php "Operator Precedence" `!` has more precedence than `=` And after `!` we must have boolean constant in left side: FALSE = foo() Explain to me pls that I do not understand P.S. in C & Perl (!$a = foo()) is not valid expression -- Edit this bug report at http://bugs.php.net/?id=17180&edit=1
Bug #17180 Updated: Operator Precedence
ID: 17180 Updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] Status: Open Bug Type:Scripting Engine problem PHP Version: 4.2.0 New Comment: "if (!$a = foo(FALSE))" --> you're assigning the output of foo(FALSE) to $a "if (!$a == foo(FALSE))" --> you're comparing !$a and foo(FALSE) Previous Comments: [2002-05-13 09:36:32] [EMAIL PROTECTED] Why & How this code will work? Output: if (!$a = foo(FALSE))) is true bool(false) http://www.php.net/manual/en/language.operators.php "Operator Precedence" `!` has more precedence than `=` And after `!` we must have boolean constant in left side: FALSE = foo() Explain to me pls that I do not understand P.S. in C & Perl (!$a = foo()) is not valid expression -- Edit this bug report at http://bugs.php.net/?id=17180&edit=1
Bug #17191 Updated: PHP Variables undefined
ID: 17191 Updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] Status: Open Bug Type: IIS related Operating System: Win 2000 Server PHP Version: 4.2.1 New Comment: That makes sense if you haven't turned the register_globals directive On in php.ini. Previous Comments: [2002-05-13 17:36:44] [EMAIL PROTECTED] Because of the known "OCX-Control missing" problem I did a manual configuration on Windows 2000 Server (IIS5). PHP scripts run (e.g. phpinfo()), but own function don't have access to PHP Variables, there seem to be no variable definitions at all. Calling a script via http://localhost/test.php?a=1 does not result in a variable "a" within the script. -- Edit this bug report at http://bugs.php.net/?id=17191&edit=1
Bug #17191: PHP Variables undefined
From: [EMAIL PROTECTED] Operating system: Win 2000 Server PHP version: 4.2.1 PHP Bug Type: IIS related Bug description: PHP Variables undefined Because of the known "OCX-Control missing" problem I did a manual configuration on Windows 2000 Server (IIS5). PHP scripts run (e.g. phpinfo()), but own function don't have access to PHP Variables, there seem to be no variable definitions at all. Calling a script via http://localhost/test.php?a=1 does not result in a variable "a" within the script. -- Edit bug report at http://bugs.php.net/?id=17191&edit=1 -- Fixed in CVS:http://bugs.php.net/fix.php?id=17191&r=fixedcvs Fixed in release:http://bugs.php.net/fix.php?id=17191&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=17191&r=needtrace Try newer version: http://bugs.php.net/fix.php?id=17191&r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=17191&r=support Expected behavior: http://bugs.php.net/fix.php?id=17191&r=notwrong Not enough info: http://bugs.php.net/fix.php?id=17191&r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=17191&r=submittedtwice register_globals:http://bugs.php.net/fix.php?id=17191&r=globals
Bug #17189 Updated: php executable interpreter error
ID: 17189 Updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] Status: Feedback Bug Type: Scripting Engine problem Operating System: Linux 1.3.14 RH7 PHP Version: 4.2.1 New Comment: Here is the address of the script: http://www.myhomebc.com/index.wphp Also, I am able to generate the html code by using command line (i.e php index.wphp) and it seems alright when I post on web, no error code given. Previous Comments: [2002-05-13 16:49:31] [EMAIL PROTECTED] Can you provide the full script, preferable somewhere for download so we exactly see how your script looks like (the forms in the report system might scramle them). [2002-05-13 16:42:43] [EMAIL PROTECTED] I was compiled php as cgi support and generated a php executable file. However, I am not able to use this file to run my php script on web. It always gives out the following errors no matter how I configure the php. Warning: Unexpected character in input: ' ' (ASCII=30) state=1 in /home/apache/php on line 3802 Warning: Unexpected character in input: '\' (ASCII=92) state=1 in /home/apache/php on line 3802 Warning: Unexpected character in input: '' (ASCII=24) state=1 in /home/apache/php on line 3802 Parse error: parse error, unexpected T_STRING in /home/apache/php on line 3802 I was working on php4.1.2, but it seems not work in 4.2.0 and 4.2.1. The script I used is for file system handling which may do chmod, upload, delete file and such. I havn't try on the scripts that don't need to access the file system as they can be done on the server module. -- Edit this bug report at http://bugs.php.net/?id=17189&edit=1
Bug #17190: Date() gives error for date prior to 1-1-1970
From: [EMAIL PROTECTED]
Operating system: Windows NT 4.0
PHP version: 4.2.0
PHP Bug Type: Date/time related
Bug description: Date() gives error for date prior to 1-1-1970
When using date() to format date prior to Jan 1, 1970 or after Jan 19,
2038 PHP gives
Warning: unexpected error in date()
script
\\variable's byear,bmonth,bday come from user form
\\script works fine for dates between 1-1-1970 - 1-19-2038
$bdate = $byear . "-" . $bmonth . "-" . $bday ;
$dob = strtotime($bdate);
$_SESSION['view_dob'] = date("d-m-Y",$dob);
--
Edit bug report at http://bugs.php.net/?id=17190&edit=1
--
Fixed in CVS:http://bugs.php.net/fix.php?id=17190&r=fixedcvs
Fixed in release:http://bugs.php.net/fix.php?id=17190&r=alreadyfixed
Need backtrace: http://bugs.php.net/fix.php?id=17190&r=needtrace
Try newer version: http://bugs.php.net/fix.php?id=17190&r=oldversion
Not developer issue: http://bugs.php.net/fix.php?id=17190&r=support
Expected behavior: http://bugs.php.net/fix.php?id=17190&r=notwrong
Not enough info: http://bugs.php.net/fix.php?id=17190&r=notenoughinfo
Submitted twice: http://bugs.php.net/fix.php?id=17190&r=submittedtwice
register_globals:http://bugs.php.net/fix.php?id=17190&r=globals
Bug #17189 Updated: php executable interpreter error
ID: 17189 Updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] -Status: Open +Status: Feedback Bug Type: Scripting Engine problem Operating System: Linux 1.3.14 RH7 PHP Version: 4.2.1 New Comment: Can you provide the full script, preferable somewhere for download so we exactly see how your script looks like (the forms in the report system might scramle them). Previous Comments: [2002-05-13 16:42:43] [EMAIL PROTECTED] I was compiled php as cgi support and generated a php executable file. However, I am not able to use this file to run my php script on web. It always gives out the following errors no matter how I configure the php. Warning: Unexpected character in input: ' ' (ASCII=30) state=1 in /home/apache/php on line 3802 Warning: Unexpected character in input: '\' (ASCII=92) state=1 in /home/apache/php on line 3802 Warning: Unexpected character in input: '' (ASCII=24) state=1 in /home/apache/php on line 3802 Parse error: parse error, unexpected T_STRING in /home/apache/php on line 3802 I was working on php4.1.2, but it seems not work in 4.2.0 and 4.2.1. The script I used is for file system handling which may do chmod, upload, delete file and such. I havn't try on the scripts that don't need to access the file system as they can be done on the server module. -- Edit this bug report at http://bugs.php.net/?id=17189&edit=1
Bug #17189: php executable interpreter error
From: [EMAIL PROTECTED] Operating system: Linux 1.3.14 RH7 PHP version: 4.2.1 PHP Bug Type: Scripting Engine problem Bug description: php executable interpreter error I was compiled php as cgi support and generated a php executable file. However, I am not able to use this file to run my php script on web. It always gives out the following errors no matter how I configure the php. Warning: Unexpected character in input: ' ' (ASCII=30) state=1 in /home/apache/php on line 3802 Warning: Unexpected character in input: '\' (ASCII=92) state=1 in /home/apache/php on line 3802 Warning: Unexpected character in input: '' (ASCII=24) state=1 in /home/apache/php on line 3802 Parse error: parse error, unexpected T_STRING in /home/apache/php on line 3802 I was working on php4.1.2, but it seems not work in 4.2.0 and 4.2.1. The script I used is for file system handling which may do chmod, upload, delete file and such. I havn't try on the scripts that don't need to access the file system as they can be done on the server module. -- Edit bug report at http://bugs.php.net/?id=17189&edit=1 -- Fixed in CVS:http://bugs.php.net/fix.php?id=17189&r=fixedcvs Fixed in release:http://bugs.php.net/fix.php?id=17189&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=17189&r=needtrace Try newer version: http://bugs.php.net/fix.php?id=17189&r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=17189&r=support Expected behavior: http://bugs.php.net/fix.php?id=17189&r=notwrong Not enough info: http://bugs.php.net/fix.php?id=17189&r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=17189&r=submittedtwice register_globals:http://bugs.php.net/fix.php?id=17189&r=globals
Bug #12780 Updated: ImageCopyResampled ignores srcX and srcY parameters
ID: 12780 Updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] -Status: Open +Status: Closed Bug Type: GD related Operating System: Windows 2000 PHP Version: 4.0.6 New Comment: Well, the bug is not in PHP, so I am not sure why you are complaining here. We have gotten frustrated as well with the slow pace of development of GD so in 4.3 or later GD will be bundled with PHP. I have fixed this issue in this bundled version of GD. Previous Comments: [2002-05-13 16:06:51] [EMAIL PROTECTED] If you need a quick fix for this issue, just take this tiny patch proposed in the manual: http://phpug.ch/patches/gd.diff could somebody then tell me why such a bug can remain unfixed for such a long time? [2001-10-20 17:36:29] [EMAIL PROTECTED] The following was in the user manual. Could someone please apply this fix for the next release? [EMAIL PROTECTED] 01-Oct-2001 03:42 As reported above, there is a bug in this function which basically means it ignores the srcX and srcY parameters. The fix is really easy, assuming you don't mind recompiling GD. You need to change the lines in gd.c that read: p = gdImageGetTrueColorPixel ( src, (int) sx, (int) sy; to read: p = gdImageGetTrueColorPixel ( src, (int) sx + srcX, (int) sy + srcY; [2001-08-31 06:42:42] [EMAIL PROTECTED] [User input: [EMAIL PROTECTED]] I have experienced an issue identical to bug #12780, on a Linux machine running RedHat 7.1, Apache 1.3.20, PHP 4.0.6, and GD 2.0.1. The original bug was running under Win2000. [2001-08-15 22:31:16] [EMAIL PROTECTED] The Source X and Y parameters are ignored by the function ImageCopyResampled. This may be a bug with the GD 2.0.1 library itself, since an examination of gd.c lines 1960-2085 reveal no significant reference to these parameters. My e-mail to the developers is getting bounced, so I turn to you. I used the setup program for Windows to install PHP 4.0.6 on a fresh Windows 2000 machine, but I believe the problem is platform independant. Here's how to reproduce the bug: 1: Create a 200 x 200 JPEG image named "grid.jpg". Divide it into four colored sqares of equal size, just for the demonstration. 2: Create an HTML page with the following content: 3: Create a PHP page named "imgTest.php" with the following content: The result is that the bottom group of squares will all be from the upper left corner, while the top group of squares will be separate corners. This shows that the functions are not interchangable. -- Edit this bug report at http://bugs.php.net/?id=12780&edit=1
Bug #12780 Updated: ImageCopyResampled ignores srcX and srcY parameters
ID: 12780 Updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] Status: Open Bug Type: GD related Operating System: Windows 2000 PHP Version: 4.0.6 New Comment: If you need a quick fix for this issue, just take this tiny patch proposed in the manual: http://phpug.ch/patches/gd.diff could somebody then tell me why such a bug can remain unfixed for such a long time? Previous Comments: [2001-10-20 17:36:29] [EMAIL PROTECTED] The following was in the user manual. Could someone please apply this fix for the next release? [EMAIL PROTECTED] 01-Oct-2001 03:42 As reported above, there is a bug in this function which basically means it ignores the srcX and srcY parameters. The fix is really easy, assuming you don't mind recompiling GD. You need to change the lines in gd.c that read: p = gdImageGetTrueColorPixel ( src, (int) sx, (int) sy; to read: p = gdImageGetTrueColorPixel ( src, (int) sx + srcX, (int) sy + srcY; [2001-08-31 06:42:42] [EMAIL PROTECTED] [User input: [EMAIL PROTECTED]] I have experienced an issue identical to bug #12780, on a Linux machine running RedHat 7.1, Apache 1.3.20, PHP 4.0.6, and GD 2.0.1. The original bug was running under Win2000. [2001-08-15 22:31:16] [EMAIL PROTECTED] The Source X and Y parameters are ignored by the function ImageCopyResampled. This may be a bug with the GD 2.0.1 library itself, since an examination of gd.c lines 1960-2085 reveal no significant reference to these parameters. My e-mail to the developers is getting bounced, so I turn to you. I used the setup program for Windows to install PHP 4.0.6 on a fresh Windows 2000 machine, but I believe the problem is platform independant. Here's how to reproduce the bug: 1: Create a 200 x 200 JPEG image named "grid.jpg". Divide it into four colored sqares of equal size, just for the demonstration. 2: Create an HTML page with the following content: 3: Create a PHP page named "imgTest.php" with the following content: The result is that the bottom group of squares will all be from the upper left corner, while the top group of squares will be separate corners. This shows that the functions are not interchangable. -- Edit this bug report at http://bugs.php.net/?id=12780&edit=1
Bug #12975 Updated: Unable to load dynamic library 'd:\applications\php\extensions\php_oci8.dll' -
ID: 12975 Updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] Status: Open Bug Type: IIS related Operating System: Windows 2000 Server PHP Version: 4.0.6 New Comment: Hello, I have similar problems on Win2k-server and WinXP when trying to get php_gd working. This dll-loading seems magical stuff. First I got this 'specified procedure'-error only at work. The configuration there: php_gd.dll/PHP4.0.6/IIS/Win2k. But I didn't have any problem at home with configuration: php_gd.dll/PHP4.0.6/Xitami/WinXP. So I tried to get me a new PHP-version, 4.2, to test with at home. And you won't believe it... with a configuration: php_gd.dll/PHP4.2/Xitami/WinXP, now I get the 'specified procedure'-error at home. By the way, I got rid of the 'module-not-found' by typing the right path c:/php/ex... with all foward-slashes. Once I was a happy php_gd-user. Now feel like a Windoze-looser. h e l p Mark Previous Comments: [2002-02-26 18:01:33] [EMAIL PROTECTED] Hello, I also have a similar problem. I am using with php4ispi.dll with IIS5 Win2000 Prof.. I wrote my own extension in a dll. And it can load it, that means, I can run phpinfo() so that it shows my Extension. But I cannot run the functions which are implemented in this extension. And I also cannot run a simple application. [2002-01-16 12:43:06] [EMAIL PROTECTED] IMO it's not only the php_oci8.dll which cannot be loaded. I even (on windows-NT-system) could not load for example the php_dbg.dll, php_pdf.dll extensions with PHP 4.1.1. May be someone can test this for other extensions to find out if this is a general bug on windows-systems. Can someone help? Thanks Klaus Habeck [2001-08-27 09:15:25] [EMAIL PROTECTED] I install PHP 4.0.6 with IIS 5 and it did install find. I did modify my php.ini. I did create a test page and then it says : Unable to load dynamic library 'd:\applications\php\extensions\php_oci8.dll' - The specified module could not be found And it write the same thing on my server I have installed php on : d:\applications\php and the extension are located on d:\applications\php\extensions I have double check the extension_dir What do i have to do to make it works??? Thanks Philippe BABILOTTE What do i have to do -- Edit this bug report at http://bugs.php.net/?id=12975&edit=1
Bug #17107 Updated: exit() always reports exit status=255
ID: 17107 Updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] Status: Assigned Bug Type: Scripting Engine problem Operating System: Linux PHP Version: 4.2.0 Assigned To: derick New Comment: The pcntl_exec worked good...Thank you. Ideally the exit status would work as discussed on the dev mailing list...exit(int) sets status as integer, exit(string) prints string. just tested on PHP 4.3.0-dev (cli) and still no exit status...;) Know where I should start hacking?? /sapi/cli ? Thanks for the pcntl tip! -Dave Previous Comments: [2002-05-13 14:10:48] [EMAIL PROTECTED] Here's another workaround for you if you have --enable-pcntl: $ php -q $ echo $? 123 [2002-05-13 13:47:19] [EMAIL PROTECTED] Experiencing same problem on 4.2.0/Linux. Return from global scope does not seem to work for me though or else I would use it as an alternative. Is this fixed in CVS? -Dave [2002-05-10 02:06:14] [EMAIL PROTECTED] I think I broke this, so I'll fix it too :) Derick [2002-05-08 21:44:49] [EMAIL PROTECTED] $ php -v 4.2.0 $ php -q $ echo $? 255 exit(n) always reports 255 (or -1) as exit status to the OS, regardless of the value it is passed as argument. The correct behavior according to the documentation would be to report n as exit status, or echo n if n is a string. The only workaround I could find is to use return from the global scope. Thank you :) -- Edit this bug report at http://bugs.php.net/?id=17107&edit=1
Bug #14353 Updated: can't set CP_UTF8 codepage
ID: 14353 Updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] Status: Closed Bug Type: COM related Operating System: Windows 2000 PHP Version: 4.2.0 New Comment: the patch that was made for 4.2.1RC is incomplete - the call to WideCharToMultiByte must have 0 as the second parameter is the codepage is CP_UTF8, but this patch sets it to MB_ERR_INVALID_CHARS instead (submitted to qa.php.net) Previous Comments: [2002-04-25 02:38:19] [EMAIL PROTECTED] Fixed in CVS [2002-04-23 11:22:25] [EMAIL PROTECTED] This is still an issue in 4.2.0. [2001-12-06 12:24:31] [EMAIL PROTECTED] i'll review this [2001-12-05 18:18:23] [EMAIL PROTECTED] A call to create a COM object can pass the codepage as the third parameter and CP_UTF8 is a valid option. If you use this, however, the object create fails. The problem is in the php_char_to_OLECHAR and php_OLECHAR_to_char functions in com\conversion.c. MSDN states that a call to WideCharToMultiByte with a codepage of CP_UTF8 must have a second parameter is 0, but these functions don't account for that. How I fixed it (there may be a better way, but it works for me): lines 764 and 760: change "MB_PRECOMPOSED | MB_ERR_INVALID_CHARS" to "codepage == CP_UTF8 ? 0 : MB_PRECOMPOSED | MB_ERR_INVALID_CHARS" lines 784 and 790: change "WC_COMPOSITECHECK" to "codepage == CP_UTF8 ? 0 : WC_COMPOSITECHECK" This fix is not well debugged, but it got me moving forward again. -- Edit this bug report at http://bugs.php.net/?id=14353&edit=1
Bug #17188 Updated: mysql_pconnect sometimes not work
ID: 17188
Updated by: [EMAIL PROTECTED]
Reported By: [EMAIL PROTECTED]
Status: Closed
Bug Type: MySQL related
Operating System: Linux 1.3.14
PHP Version: 4.2.0
New Comment:
It is already released :)
Derick
Previous Comments:
[2002-05-13 14:27:27] [EMAIL PROTECTED]
Known issue. 4.2.1 is fixed which will be released pretty soon. For a
quick fix, rebuild the ./configure script in your php-4.2.0/ directory
with autoconf 2.13 (run ./buildconf) and it should work (reconfigure
and recompile your source then, better do it on a a fresh archive)
[2002-05-13 14:25:19] [EMAIL PROTECTED]
I just upgrade the php from 4.1.2 to 4.2.0 and the only problem I
encounter is using the mysql_pconnect. It seems like sometimes working
and sometimes not. I am connecting to the mySQL database with the
following code:
function connectDB() {
$link = mysql_pconnect("localhost", "abc.com", "12345");
if (!$link)
die("Couldn't connect to MYSQL");
mysql_select_db("product")
or die("Couldn't open product: ".mysql_error());
return $link;
}
Sometimes I get an error of "Warning: Host 'localhost.localdomain' is
not allowed to connect to this MySQL server in
/mnt/home/apache/public_html/data.php on line 3
Couldn't connect to MYSQL"
I don't know why sometimes the host has been altered to
localhost.localdomain, but sometimes it works just perfectly fine. I
have no problem on the previous version (4.1.2). I have a solution for
this now which is setting the host of the user permission to not only
with "localhost" but also with "Any". However I wish this bug can be
fixed in the future time. Thanks.
--
Edit this bug report at http://bugs.php.net/?id=17188&edit=1
Bug #17159 Updated: touch() is broken
ID: 17159
Updated by: [EMAIL PROTECTED]
Reported By: [EMAIL PROTECTED]
Status: Closed
Bug Type: Reproducible crash
Operating System: linux, kernel 2.4.18
PHP Version: 4.2.0
New Comment:
Thanks for heads up, it's documented now and will show up in a few
days.
Previous Comments:
[2002-05-13 14:31:21] [EMAIL PROTECTED]
great! :-)
btw: your response time is really fast!
btw^2: the optional 3rd parameter (int actime) is not mentioned in the
documentation. That should also be fixed...
regards
Stefan Briesenick
[2002-05-13 14:13:24] [EMAIL PROTECTED]
Ok, really fixed in CVS
[2002-05-13 14:03:21] [EMAIL PROTECTED]
ok, I downloaded the latest snapshot. It is *partly* fixed, but now,
there's another BUG!
here the snippet:
PHP_FUNCTION(touch)
{
pval **filename, **filetime, **fileatime;
int ret;
struct stat sb;
FILE *file;
struct utimbuf newtimebuf;
struct utimbuf *newtime = NULL;
int ac = ZEND_NUM_ARGS();
if (ac == 1 && zend_get_parameters_ex(1, &filename) != FAILURE) {
#ifndef HAVE_UTIME_NULL
newtime->modtime = newtime->actime = time(NULL);
#endif
} else if (ac == 2 && zend_get_parameters_ex(2, &filename, &filetime)
!= FAILURE) {
newtime = &newtimebuf;
convert_to_long_ex(filetime);
newtime->actime = time(NULL);
newtime->modtime = newtime->actime = Z_LVAL_PP(filetime);
} else if (ac == 3 && zend_get_parameters_ex(3, &filename, &filetime,
&fileatime) != FAILURE) {
newtime = &newtimebuf;
convert_to_long_ex(fileatime);
convert_to_long_ex(filetime);
newtime->actime = Z_LVAL_PP(fileatime);
newtime->modtime = Z_LVAL_PP(filetime);
} else {
WRONG_PARAM_COUNT;
}
[..]
ok, lets see, what it do:
> struct utimbuf *newtime = NULL;
great! ;-)
with 2 or 3 parameters, the code do this:
> newtime = &newtimebuf;
great! ;-)
but with 1 parameter:
> #ifndef HAVE_UTIME_NULL
> newtime->modtime = newtime->actime = >time(NULL);
> #endif
eh, if HAVE_UTIME_NULL is *not* defined, 'newtime' is stil NULL. hmmm,
I think, it should be initialized with 'newtime = &newtimebuf;',
shouldn't it? NULL->modtime => SEGV ;-)
Greetings from Germany,
Stefan Briesenick
[2002-05-11 16:55:32] [EMAIL PROTECTED]
This bug has been fixed in CVS. You can grab a snapshot of the
CVS version at http://snaps.php.net/. In case this was a documentation
problem, the fix will show up soon at http://www.php.net/manual/.
Thank you for the report, and for helping us make PHP better.
[2002-05-11 16:54:28] [EMAIL PROTECTED]
In PHP 4.2.0 the touch() function seems to be broken!
When you use touch($filename) the mtime is a random value... if you use
touch($filename,time()), anything works fine.
I checked the source and I think, I found the BUG!
[php-4.2.0/ext/standard/filestat.c # PHP_FUNCTION(touch)]
[..]
struct utimbuf newtimebuf;
struct utimbuf *newtime = &newtimebuf;
int ac = ZEND_NUM_ARGS();
if (ac == 1 && zend_get_parameters_ex(1, &filename) != FAILURE)
{
#ifndef HAVE_UTIME_NULL
newtime->modtime = newtime->actime = time(NULL);
#endif
} else if (ac == 2 && zend_get_parameters_ex(2, &filename,
&filetime) != FAILURE) {
[..]
have a look at the part with HAVE_UTIME_NULL. if HAVE_UTIME_NULL is
*not* defined, it will be initialized with time(NULL). But if it is
defined, newtime->modtime and newtime->actime will be
*uninitialized*!!! There's no code to initialize both values with
something like 0 or NULL. The struct newtime is on the stack and has
random content!
HAVE_UTIME_NULL seems to be defined on my system and so touch() sets
random values for modtime and actime.
Greetings from Germany,
Stefan Briesenick
--
Edit this bug report at http://bugs.php.net/?id=17159&edit=1
Bug #17159 Updated: touch() is broken
ID: 17159
Updated by: [EMAIL PROTECTED]
Reported By: [EMAIL PROTECTED]
Status: Closed
Bug Type: Reproducible crash
Operating System: linux, kernel 2.4.18
PHP Version: 4.2.0
New Comment:
great! :-)
btw: your response time is really fast!
btw^2: the optional 3rd parameter (int actime) is not mentioned in the
documentation. That should also be fixed...
regards
Stefan Briesenick
Previous Comments:
[2002-05-13 14:13:24] [EMAIL PROTECTED]
Ok, really fixed in CVS
[2002-05-13 14:03:21] [EMAIL PROTECTED]
ok, I downloaded the latest snapshot. It is *partly* fixed, but now,
there's another BUG!
here the snippet:
PHP_FUNCTION(touch)
{
pval **filename, **filetime, **fileatime;
int ret;
struct stat sb;
FILE *file;
struct utimbuf newtimebuf;
struct utimbuf *newtime = NULL;
int ac = ZEND_NUM_ARGS();
if (ac == 1 && zend_get_parameters_ex(1, &filename) != FAILURE) {
#ifndef HAVE_UTIME_NULL
newtime->modtime = newtime->actime = time(NULL);
#endif
} else if (ac == 2 && zend_get_parameters_ex(2, &filename, &filetime)
!= FAILURE) {
newtime = &newtimebuf;
convert_to_long_ex(filetime);
newtime->actime = time(NULL);
newtime->modtime = newtime->actime = Z_LVAL_PP(filetime);
} else if (ac == 3 && zend_get_parameters_ex(3, &filename, &filetime,
&fileatime) != FAILURE) {
newtime = &newtimebuf;
convert_to_long_ex(fileatime);
convert_to_long_ex(filetime);
newtime->actime = Z_LVAL_PP(fileatime);
newtime->modtime = Z_LVAL_PP(filetime);
} else {
WRONG_PARAM_COUNT;
}
[..]
ok, lets see, what it do:
> struct utimbuf *newtime = NULL;
great! ;-)
with 2 or 3 parameters, the code do this:
> newtime = &newtimebuf;
great! ;-)
but with 1 parameter:
> #ifndef HAVE_UTIME_NULL
> newtime->modtime = newtime->actime = >time(NULL);
> #endif
eh, if HAVE_UTIME_NULL is *not* defined, 'newtime' is stil NULL. hmmm,
I think, it should be initialized with 'newtime = &newtimebuf;',
shouldn't it? NULL->modtime => SEGV ;-)
Greetings from Germany,
Stefan Briesenick
[2002-05-11 16:55:32] [EMAIL PROTECTED]
This bug has been fixed in CVS. You can grab a snapshot of the
CVS version at http://snaps.php.net/. In case this was a documentation
problem, the fix will show up soon at http://www.php.net/manual/.
Thank you for the report, and for helping us make PHP better.
[2002-05-11 16:54:28] [EMAIL PROTECTED]
In PHP 4.2.0 the touch() function seems to be broken!
When you use touch($filename) the mtime is a random value... if you use
touch($filename,time()), anything works fine.
I checked the source and I think, I found the BUG!
[php-4.2.0/ext/standard/filestat.c # PHP_FUNCTION(touch)]
[..]
struct utimbuf newtimebuf;
struct utimbuf *newtime = &newtimebuf;
int ac = ZEND_NUM_ARGS();
if (ac == 1 && zend_get_parameters_ex(1, &filename) != FAILURE)
{
#ifndef HAVE_UTIME_NULL
newtime->modtime = newtime->actime = time(NULL);
#endif
} else if (ac == 2 && zend_get_parameters_ex(2, &filename,
&filetime) != FAILURE) {
[..]
have a look at the part with HAVE_UTIME_NULL. if HAVE_UTIME_NULL is
*not* defined, it will be initialized with time(NULL). But if it is
defined, newtime->modtime and newtime->actime will be
*uninitialized*!!! There's no code to initialize both values with
something like 0 or NULL. The struct newtime is on the stack and has
random content!
HAVE_UTIME_NULL seems to be defined on my system and so touch() sets
random values for modtime and actime.
Greetings from Germany,
Stefan Briesenick
--
Edit this bug report at http://bugs.php.net/?id=17159&edit=1
Bug #17188 Updated: mysql_pconnect sometimes not work
ID: 17188
Updated by: [EMAIL PROTECTED]
Reported By: [EMAIL PROTECTED]
-Status: Open
+Status: Closed
Bug Type: MySQL related
Operating System: Linux 1.3.14
PHP Version: 4.2.0
New Comment:
Known issue. 4.2.1 is fixed which will be released pretty soon. For a
quick fix, rebuild the ./configure script in your php-4.2.0/ directory
with autoconf 2.13 (run ./buildconf) and it should work (reconfigure
and recompile your source then, better do it on a a fresh archive)
Previous Comments:
[2002-05-13 14:25:19] [EMAIL PROTECTED]
I just upgrade the php from 4.1.2 to 4.2.0 and the only problem I
encounter is using the mysql_pconnect. It seems like sometimes working
and sometimes not. I am connecting to the mySQL database with the
following code:
function connectDB() {
$link = mysql_pconnect("localhost", "abc.com", "12345");
if (!$link)
die("Couldn't connect to MYSQL");
mysql_select_db("product")
or die("Couldn't open product: ".mysql_error());
return $link;
}
Sometimes I get an error of "Warning: Host 'localhost.localdomain' is
not allowed to connect to this MySQL server in
/mnt/home/apache/public_html/data.php on line 3
Couldn't connect to MYSQL"
I don't know why sometimes the host has been altered to
localhost.localdomain, but sometimes it works just perfectly fine. I
have no problem on the previous version (4.1.2). I have a solution for
this now which is setting the host of the user permission to not only
with "localhost" but also with "Any". However I wish this bug can be
fixed in the future time. Thanks.
--
Edit this bug report at http://bugs.php.net/?id=17188&edit=1
Bug #17187 Updated: Cannot declare class "User"
ID: 17187 Updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] -Status: Open +Status: Bogus Bug Type: Class/Object related Operating System: Linux php.ebolamonkeys.net 2.2.1 PHP Version: 4.1.2 New Comment: Sorry, but the bug system is not the appropriate forum for asking support questions. Your problem does not imply a bug in PHP itself. For a list of more appropriate places to ask for help using PHP, please visit http://www.php.net/support.php Thank you for your interest in PHP. this is most likely an include issue, try to improve your logic or use include_once or require_once respectively. Previous Comments: [2002-05-13 14:23:59] [EMAIL PROTECTED] When I try to declare class "User" I get: Fatal error: Cannot redeclare class user in on line 4 I didn't find that "user" or "User" is reserved word? -- Edit this bug report at http://bugs.php.net/?id=17187&edit=1
Bug #17188: mysql_pconnect sometimes not work
From: [EMAIL PROTECTED]
Operating system: Linux 1.3.14
PHP version: 4.2.0
PHP Bug Type: MySQL related
Bug description: mysql_pconnect sometimes not work
I just upgrade the php from 4.1.2 to 4.2.0 and the only problem I encounter
is using the mysql_pconnect. It seems like sometimes working and sometimes
not. I am connecting to the mySQL database with the following code:
function connectDB() {
$link = mysql_pconnect("localhost", "abc.com", "12345");
if (!$link)
die("Couldn't connect to MYSQL");
mysql_select_db("product")
or die("Couldn't open product: ".mysql_error());
return $link;
}
Sometimes I get an error of "Warning: Host 'localhost.localdomain' is not
allowed to connect to this MySQL server in
/mnt/home/apache/public_html/data.php on line 3
Couldn't connect to MYSQL"
I don't know why sometimes the host has been altered to
localhost.localdomain, but sometimes it works just perfectly fine. I have
no problem on the previous version (4.1.2). I have a solution for this now
which is setting the host of the user permission to not only with
"localhost" but also with "Any". However I wish this bug can be fixed in
the future time. Thanks.
--
Edit bug report at http://bugs.php.net/?id=17188&edit=1
--
Fixed in CVS:http://bugs.php.net/fix.php?id=17188&r=fixedcvs
Fixed in release:http://bugs.php.net/fix.php?id=17188&r=alreadyfixed
Need backtrace: http://bugs.php.net/fix.php?id=17188&r=needtrace
Try newer version: http://bugs.php.net/fix.php?id=17188&r=oldversion
Not developer issue: http://bugs.php.net/fix.php?id=17188&r=support
Expected behavior: http://bugs.php.net/fix.php?id=17188&r=notwrong
Not enough info: http://bugs.php.net/fix.php?id=17188&r=notenoughinfo
Submitted twice: http://bugs.php.net/fix.php?id=17188&r=submittedtwice
register_globals:http://bugs.php.net/fix.php?id=17188&r=globals
Bug #17187: Cannot declare class "User"
From: [EMAIL PROTECTED] Operating system: Linux php.ebolamonkeys.net 2.2.1 PHP version: 4.1.2 PHP Bug Type: Class/Object related Bug description: Cannot declare class "User" When I try to declare class "User" I get: Fatal error: Cannot redeclare class user in on line 4 I didn't find that "user" or "User" is reserved word? -- Edit bug report at http://bugs.php.net/?id=17187&edit=1 -- Fixed in CVS:http://bugs.php.net/fix.php?id=17187&r=fixedcvs Fixed in release:http://bugs.php.net/fix.php?id=17187&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=17187&r=needtrace Try newer version: http://bugs.php.net/fix.php?id=17187&r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=17187&r=support Expected behavior: http://bugs.php.net/fix.php?id=17187&r=notwrong Not enough info: http://bugs.php.net/fix.php?id=17187&r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=17187&r=submittedtwice register_globals:http://bugs.php.net/fix.php?id=17187&r=globals
Bug #17159 Updated: touch() is broken
ID: 17159
Updated by: [EMAIL PROTECTED]
Reported By: [EMAIL PROTECTED]
Status: Closed
Bug Type: Reproducible crash
Operating System: linux, kernel 2.4.18
PHP Version: 4.2.0
New Comment:
Ok, really fixed in CVS
Previous Comments:
[2002-05-13 14:03:21] [EMAIL PROTECTED]
ok, I downloaded the latest snapshot. It is *partly* fixed, but now,
there's another BUG!
here the snippet:
PHP_FUNCTION(touch)
{
pval **filename, **filetime, **fileatime;
int ret;
struct stat sb;
FILE *file;
struct utimbuf newtimebuf;
struct utimbuf *newtime = NULL;
int ac = ZEND_NUM_ARGS();
if (ac == 1 && zend_get_parameters_ex(1, &filename) != FAILURE) {
#ifndef HAVE_UTIME_NULL
newtime->modtime = newtime->actime = time(NULL);
#endif
} else if (ac == 2 && zend_get_parameters_ex(2, &filename, &filetime)
!= FAILURE) {
newtime = &newtimebuf;
convert_to_long_ex(filetime);
newtime->actime = time(NULL);
newtime->modtime = newtime->actime = Z_LVAL_PP(filetime);
} else if (ac == 3 && zend_get_parameters_ex(3, &filename, &filetime,
&fileatime) != FAILURE) {
newtime = &newtimebuf;
convert_to_long_ex(fileatime);
convert_to_long_ex(filetime);
newtime->actime = Z_LVAL_PP(fileatime);
newtime->modtime = Z_LVAL_PP(filetime);
} else {
WRONG_PARAM_COUNT;
}
[..]
ok, lets see, what it do:
> struct utimbuf *newtime = NULL;
great! ;-)
with 2 or 3 parameters, the code do this:
> newtime = &newtimebuf;
great! ;-)
but with 1 parameter:
> #ifndef HAVE_UTIME_NULL
> newtime->modtime = newtime->actime = >time(NULL);
> #endif
eh, if HAVE_UTIME_NULL is *not* defined, 'newtime' is stil NULL. hmmm,
I think, it should be initialized with 'newtime = &newtimebuf;',
shouldn't it? NULL->modtime => SEGV ;-)
Greetings from Germany,
Stefan Briesenick
[2002-05-11 16:55:32] [EMAIL PROTECTED]
This bug has been fixed in CVS. You can grab a snapshot of the
CVS version at http://snaps.php.net/. In case this was a documentation
problem, the fix will show up soon at http://www.php.net/manual/.
Thank you for the report, and for helping us make PHP better.
[2002-05-11 16:54:28] [EMAIL PROTECTED]
In PHP 4.2.0 the touch() function seems to be broken!
When you use touch($filename) the mtime is a random value... if you use
touch($filename,time()), anything works fine.
I checked the source and I think, I found the BUG!
[php-4.2.0/ext/standard/filestat.c # PHP_FUNCTION(touch)]
[..]
struct utimbuf newtimebuf;
struct utimbuf *newtime = &newtimebuf;
int ac = ZEND_NUM_ARGS();
if (ac == 1 && zend_get_parameters_ex(1, &filename) != FAILURE)
{
#ifndef HAVE_UTIME_NULL
newtime->modtime = newtime->actime = time(NULL);
#endif
} else if (ac == 2 && zend_get_parameters_ex(2, &filename,
&filetime) != FAILURE) {
[..]
have a look at the part with HAVE_UTIME_NULL. if HAVE_UTIME_NULL is
*not* defined, it will be initialized with time(NULL). But if it is
defined, newtime->modtime and newtime->actime will be
*uninitialized*!!! There's no code to initialize both values with
something like 0 or NULL. The struct newtime is on the stack and has
random content!
HAVE_UTIME_NULL seems to be defined on my system and so touch() sets
random values for modtime and actime.
Greetings from Germany,
Stefan Briesenick
--
Edit this bug report at http://bugs.php.net/?id=17159&edit=1
Bug #17107 Updated: exit() always reports exit status=255
ID: 17107 Updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] Status: Assigned Bug Type: Scripting Engine problem Operating System: Linux PHP Version: 4.2.0 Assigned To: derick New Comment: Here's another workaround for you if you have --enable-pcntl: $ php -q $ echo $? 123 Previous Comments: [2002-05-13 13:47:19] [EMAIL PROTECTED] Experiencing same problem on 4.2.0/Linux. Return from global scope does not seem to work for me though or else I would use it as an alternative. Is this fixed in CVS? -Dave [2002-05-10 02:06:14] [EMAIL PROTECTED] I think I broke this, so I'll fix it too :) Derick [2002-05-08 21:44:49] [EMAIL PROTECTED] $ php -v 4.2.0 $ php -q $ echo $? 255 exit(n) always reports 255 (or -1) as exit status to the OS, regardless of the value it is passed as argument. The correct behavior according to the documentation would be to report n as exit status, or echo n if n is a string. The only workaround I could find is to use return from the global scope. Thank you :) -- Edit this bug report at http://bugs.php.net/?id=17107&edit=1
Bug #17159 Updated: touch() is broken
ID: 17159
Updated by: [EMAIL PROTECTED]
Reported By: [EMAIL PROTECTED]
Status: Closed
Bug Type: Reproducible crash
Operating System: linux, kernel 2.4.18
PHP Version: 4.2.0
New Comment:
ok, I downloaded the latest snapshot. It is *partly* fixed, but now,
there's another BUG!
here the snippet:
PHP_FUNCTION(touch)
{
pval **filename, **filetime, **fileatime;
int ret;
struct stat sb;
FILE *file;
struct utimbuf newtimebuf;
struct utimbuf *newtime = NULL;
int ac = ZEND_NUM_ARGS();
if (ac == 1 && zend_get_parameters_ex(1, &filename) != FAILURE) {
#ifndef HAVE_UTIME_NULL
newtime->modtime = newtime->actime = time(NULL);
#endif
} else if (ac == 2 && zend_get_parameters_ex(2, &filename, &filetime)
!= FAILURE) {
newtime = &newtimebuf;
convert_to_long_ex(filetime);
newtime->actime = time(NULL);
newtime->modtime = newtime->actime = Z_LVAL_PP(filetime);
} else if (ac == 3 && zend_get_parameters_ex(3, &filename, &filetime,
&fileatime) != FAILURE) {
newtime = &newtimebuf;
convert_to_long_ex(fileatime);
convert_to_long_ex(filetime);
newtime->actime = Z_LVAL_PP(fileatime);
newtime->modtime = Z_LVAL_PP(filetime);
} else {
WRONG_PARAM_COUNT;
}
[..]
ok, lets see, what it do:
> struct utimbuf *newtime = NULL;
great! ;-)
with 2 or 3 parameters, the code do this:
> newtime = &newtimebuf;
great! ;-)
but with 1 parameter:
> #ifndef HAVE_UTIME_NULL
> newtime->modtime = newtime->actime = >time(NULL);
> #endif
eh, if HAVE_UTIME_NULL is *not* defined, 'newtime' is stil NULL. hmmm,
I think, it should be initialized with 'newtime = &newtimebuf;',
shouldn't it? NULL->modtime => SEGV ;-)
Greetings from Germany,
Stefan Briesenick
Previous Comments:
[2002-05-11 16:55:32] [EMAIL PROTECTED]
This bug has been fixed in CVS. You can grab a snapshot of the
CVS version at http://snaps.php.net/. In case this was a documentation
problem, the fix will show up soon at http://www.php.net/manual/.
Thank you for the report, and for helping us make PHP better.
[2002-05-11 16:54:28] [EMAIL PROTECTED]
In PHP 4.2.0 the touch() function seems to be broken!
When you use touch($filename) the mtime is a random value... if you use
touch($filename,time()), anything works fine.
I checked the source and I think, I found the BUG!
[php-4.2.0/ext/standard/filestat.c # PHP_FUNCTION(touch)]
[..]
struct utimbuf newtimebuf;
struct utimbuf *newtime = &newtimebuf;
int ac = ZEND_NUM_ARGS();
if (ac == 1 && zend_get_parameters_ex(1, &filename) != FAILURE)
{
#ifndef HAVE_UTIME_NULL
newtime->modtime = newtime->actime = time(NULL);
#endif
} else if (ac == 2 && zend_get_parameters_ex(2, &filename,
&filetime) != FAILURE) {
[..]
have a look at the part with HAVE_UTIME_NULL. if HAVE_UTIME_NULL is
*not* defined, it will be initialized with time(NULL). But if it is
defined, newtime->modtime and newtime->actime will be
*uninitialized*!!! There's no code to initialize both values with
something like 0 or NULL. The struct newtime is on the stack and has
random content!
HAVE_UTIME_NULL seems to be defined on my system and so touch() sets
random values for modtime and actime.
Greetings from Germany,
Stefan Briesenick
--
Edit this bug report at http://bugs.php.net/?id=17159&edit=1
Bug #17107 Updated: exit() always reports exit status=255
ID: 17107 Updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] Status: Assigned Bug Type: Scripting Engine problem Operating System: Linux PHP Version: 4.2.0 Assigned To: derick New Comment: Experiencing same problem on 4.2.0/Linux. Return from global scope does not seem to work for me though or else I would use it as an alternative. Is this fixed in CVS? -Dave Previous Comments: [2002-05-10 02:06:14] [EMAIL PROTECTED] I think I broke this, so I'll fix it too :) Derick [2002-05-08 21:44:49] [EMAIL PROTECTED] $ php -v 4.2.0 $ php -q $ echo $? 255 exit(n) always reports 255 (or -1) as exit status to the OS, regardless of the value it is passed as argument. The correct behavior according to the documentation would be to report n as exit status, or echo n if n is a string. The only workaround I could find is to use return from the global scope. Thank you :) -- Edit this bug report at http://bugs.php.net/?id=17107&edit=1
Bug #17186: session works only after reload on apache2, trans-sid didnt work
From: [EMAIL PROTECTED] Operating system: IRIX64 6.5.15m PHP version: 4.2.0 PHP Bug Type: Session related Bug description: session works only after reload on apache2, trans-sid didnt work Testing the 4.2.1RC2 as a 64bit CGI with apache2 shows a strange behavior with a simple session script. Based on a example from the manual the following script only works after the page was reload. session test '; echo 'link'; ?> Nothing was shown during the first visit but client asking about for accepting the cookie, so after a reload page would work as aspectet. If the script sets 'session.use_cookies' to 0 the page wont works any more(no output). Same is happend when the same setup was made in the php.ini. Using the cgi via comandline the following output was given back.. Settings: 'session.use_cookies = 1' [o200]:/usr/local/apache/htdocs/php/sessions $ ../../../cgi-bin/php index.php X-Powered-By: PHP/4.2.1RC2 Set-Cookie: SID=8cdd40e358f292da280d84fbba73b6e3; 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 Content-type: text/html And now with the -q parameter [o200]:/usr/local/apache/htdocs/php/sessions $ ../../../cgi-bin/php -q index.php Warning: Cannot send session cookie - headers already sent in /usr/local/httpd64/htdocs/php/sessions/index.php on line 3 [o200]:/usr/local/apache/htdocs/php/sessions $ and now with Settings: 'session.use_cookies = 0' the output looks similar to the first without the Set-Cookie information. Error_reporting is set to E_ALL and error.log is stil activate but shows nothing. when using the -q parameter no output was shown ?! ../../../cgi-bin/php -q index.php There is a testscript temporaray available under http://194.15.95.23:8080/php/sessions/index.php http://194.15.95.23:8080/php/sessions/index.phps //source http://194.15.95.23:8080/php/sessions/info.php // phpinfo() The same script runs fine with apache 1.3.24 + mod_php and cgi on http://194.15.95.23/php/sessions/index.php [o200]:/usr/local/apache/htdocs/php/sessions $ ../../../cgi-bin/php -m Running PHP 4.2.1RC2 Zend Engine v1.2.0, Copyright (c) 1998-2002 Zend Technologies [PHP Modules] xslt xml wddx tokenizer sysvshm sysvsem standard shmop session posix pcre mysql ftp exif dio dbx dbase ctype calendar bcmath [Zend Modules] file ../../../cgi-bin/php ../../../cgi-bin/php: ELF 64-bit MSB mips-4 -- Edit bug report at http://bugs.php.net/?id=17186&edit=1 -- Fixed in CVS:http://bugs.php.net/fix.php?id=17186&r=fixedcvs Fixed in release:http://bugs.php.net/fix.php?id=17186&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=17186&r=needtrace Try newer version: http://bugs.php.net/fix.php?id=17186&r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=17186&r=support Expected behavior: http://bugs.php.net/fix.php?id=17186&r=notwrong Not enough info: http://bugs.php.net/fix.php?id=17186&r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=17186&r=submittedtwice register_globals:http://bugs.php.net/fix.php?id=17186&r=globals
Bug #17185: Bad error message
From: [EMAIL PROTECTED]
Operating system: FreeBSD 4.5
PHP version: 4.1.2
PHP Bug Type: Filesystem function related
Bug description: Bad error message
When using readfile("http://domain.com/xxx.html";) where xxx.html does not
exist (404), readfile generates the warning...
Warning: readfile("http://www.wheelpro.co.uk/xxx.html";) - Message too long
in /home/roger/wheelpro/htdocs/read.php on line 11
Message too long???
However, regardless of any message I would still expect the 404 output
from the server?
--
Edit bug report at http://bugs.php.net/?id=17185&edit=1
--
Fixed in CVS:http://bugs.php.net/fix.php?id=17185&r=fixedcvs
Fixed in release:http://bugs.php.net/fix.php?id=17185&r=alreadyfixed
Need backtrace: http://bugs.php.net/fix.php?id=17185&r=needtrace
Try newer version: http://bugs.php.net/fix.php?id=17185&r=oldversion
Not developer issue: http://bugs.php.net/fix.php?id=17185&r=support
Expected behavior: http://bugs.php.net/fix.php?id=17185&r=notwrong
Not enough info: http://bugs.php.net/fix.php?id=17185&r=notenoughinfo
Submitted twice: http://bugs.php.net/fix.php?id=17185&r=submittedtwice
register_globals:http://bugs.php.net/fix.php?id=17185&r=globals
Bug #17184: Interbase 5.1.1.682 compilation
From: [EMAIL PROTECTED] Operating system: Linux 2.4.7-10 PHP version: 4.2.0 PHP Bug Type: Compile Failure Bug description: Interbase 5.1.1.682 compilation Get error on make when trying to compile with '--with-interbase=/usr/interbase'. Worked fine with php-4.1.2 I get the following error : gcc -I. -I/usr/local/php/ext/interbase -I/usr/local/php/main -I/usr/local/php -I/usr/local/apache_1.3.22/src/include -I/usr/local/apache_1.3.22/src/os/unix -I/usr/local/php/Zend -I/usr/local/openssl/include -I/include -I/usr/local/include -I/usr/include/imap -I/usr/interbase/include -I/usr/include/mysql -I/usr/local/php/ext/xml/expat -I/usr/local/php/TSRM -g -O2 -c interbase.c && touch interbase.lo interbase.c: In function `_php_ibase_user': interbase.c:2977: `isc_action_svc_add_user' undeclared (first use in this function) interbase.c:2977: (Each undeclared identifier is reported only once interbase.c:2977: for each function it appears in.) interbase.c:2978: `isc_action_svc_modify_user' undeclared (first use in this function) interbase.c:2985: `isc_action_svc_delete_user' undeclared (first use in this function) interbase.c:2980: warning: unreachable code at beginning of switch statement interbase.c:3041: `isc_spb_version' undeclared (first use in this function) interbase.c:3042: `isc_spb_current_version' undeclared (first use in this function) interbase.c:3068: `isc_spb_sec_username' undeclared (first use in this function) interbase.c:3074: `isc_spb_sec_password' undeclared (first use in this function) interbase.c:3081: `isc_spb_sec_firstname' undeclared (first use in this function) interbase.c:3088: `isc_spb_sec_middlename' undeclared (first use in this function) interbase.c:3095: `isc_spb_sec_lastname' undeclared (first use in this function) interbase.c: In function `zif_ibase_add_user': interbase.c:3123: `isc_action_svc_add_user' undeclared (first use in this function) interbase.c: In function `zif_ibase_modify_user': interbase.c:3132: `isc_action_svc_modify_user' undeclared (first use in this function) interbase.c: In function `zif_ibase_delete_user': interbase.c:3140: `isc_action_svc_delete_user' undeclared (first use in this function) make[3]: *** [interbase.lo] Error 1 make[3]: Leaving directory `/usr/local/php-4.2.0/ext/interbase' make[2]: *** [all-recursive] Error 1 make[2]: Leaving directory `/usr/local/php-4.2.0/ext/interbase' make[1]: *** [all-recursive] Error 1 make[1]: Leaving directory `/usr/local/php-4.2.0/ext' make: *** [all-recursive] Error 1 Thx Per Mårtensson -- Edit bug report at http://bugs.php.net/?id=17184&edit=1 -- Fixed in CVS:http://bugs.php.net/fix.php?id=17184&r=fixedcvs Fixed in release:http://bugs.php.net/fix.php?id=17184&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=17184&r=needtrace Try newer version: http://bugs.php.net/fix.php?id=17184&r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=17184&r=support Expected behavior: http://bugs.php.net/fix.php?id=17184&r=notwrong Not enough info: http://bugs.php.net/fix.php?id=17184&r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=17184&r=submittedtwice register_globals:http://bugs.php.net/fix.php?id=17184&r=globals
Bug #17182 Updated: dbx - sybase-ct support no longer cvs only
ID: 17182 Updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] -Status: Open +Status: Closed Bug Type:Documentation problem PHP Version: 4.2.0 New Comment: This bug has been fixed in CVS. You can grab a snapshot of the CVS version at http://snaps.php.net/. In case this was a documentation problem, the fix will show up soon at http://www.php.net/manual/. Thank you for the report, and for helping us make PHP better. Previous Comments: [2002-05-13 11:03:35] [EMAIL PROTECTED] Hi, The docs for dbx incorrectly list that Sybase-CT support is CVS only, while in fact it is available since 4.2.0. This is listed both on the main dbx page and the dbx_connect page. Thanks, Marc. -- Edit this bug report at http://bugs.php.net/?id=17182&edit=1
Bug #17183 Updated: gd or gd2
ID: 17183 Updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] -Status: Open +Status: Closed Bug Type: *Configuration Issues Operating System: Win32 PHP Version: 4.2.0 New Comment: Known bug, they will be included in 4.2.1 which is due release pretty soon. Thanks for the report. Previous Comments: [2002-05-13 11:23:41] [EMAIL PROTECTED] Not really a bug, and maybe I've been smoking too much banana leafs, but my php 4.2.0 windows binaries came with php.ini-* files that contained: ;extension gd.dll while this particular version of php comes with gd2.dll There were some other files (I believe install.txt) that mentioned gd.dll as well. Anyway, grep "gd.dll" * -ir Regards, Karel -- Edit this bug report at http://bugs.php.net/?id=17183&edit=1
Bug #17183: gd or gd2
From: [EMAIL PROTECTED] Operating system: Win32 PHP version: 4.2.0 PHP Bug Type: *Configuration Issues Bug description: gd or gd2 Not really a bug, and maybe I've been smoking too much banana leafs, but my php 4.2.0 windows binaries came with php.ini-* files that contained: ;extension gd.dll while this particular version of php comes with gd2.dll There were some other files (I believe install.txt) that mentioned gd.dll as well. Anyway, grep "gd.dll" * -ir Regards, Karel -- Edit bug report at http://bugs.php.net/?id=17183&edit=1 -- Fixed in CVS:http://bugs.php.net/fix.php?id=17183&r=fixedcvs Fixed in release:http://bugs.php.net/fix.php?id=17183&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=17183&r=needtrace Try newer version: http://bugs.php.net/fix.php?id=17183&r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=17183&r=support Expected behavior: http://bugs.php.net/fix.php?id=17183&r=notwrong Not enough info: http://bugs.php.net/fix.php?id=17183&r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=17183&r=submittedtwice register_globals:http://bugs.php.net/fix.php?id=17183&r=globals
Bug #14218 Updated: using pspell functions cause apache to Abort
ID: 14218
Updated by: [EMAIL PROTECTED]
Reported By: [EMAIL PROTECTED]
Status: Closed
Bug Type: Pspell related
Operating System: FreeBSD 4.4-STABLE
PHP Version: 4.0.6
New Comment:
I'm having this problem with php 4.2.0 on FreeBSD 4.5.
Previous Comments:
[2002-02-22 06:57:52] [EMAIL PROTECTED]
This bug has been fixed in CVS.
I suppose this is fixed in CVS. Please test CVS version and report back
if you still have this problem.
[2001-11-30 17:07:07] [EMAIL PROTECTED]
thanks for offering access to a freebsd box... i do not think that's
going to help a lot though 'cause I won't have time to get to it soon
(overtime job and getting married at the same time, ouch!).
I'll look more into it later, but if someone with more experience with
freebsd can look into it, that would be great. I am no UNIX guru, by
any means. I don't even know why your apache doesn't give you a core.
No, I do not know whether mod_gzip or zend optimizer contribute, I
would imagine, it shouldn't contribute much, but you could try to
eliminate those two possibilities by not using them and see if that
helps.
In short, does anyone feel up to picking this bug up? It seems like
it's something simple yet fundamental. I lack the time and knowledge.
Otherwise I'll get back to it a bit later (probably ver 4.2 or so)
[2001-11-29 19:22:58] [EMAIL PROTECTED]
Answers:
1. Built pspell from scratch again, uninstalled and reinstalled, su'ed
to nobody, executed example-c with success, ran a few lookups. Cut and
paste:
--> su - nobody -c id
uid=65534(nobody) gid=65534(nobody) groups=65534(nobody)
--> su - nobody -c "`pwd`/example-c en"
Using: en---aspell
Type "h" for help.
s recieve
receive
receiver
Recife
relieve
received
receives
[...]
2. I wasn't sure what the pws format looked like, so I threw out the
personal one and just tried pspell_new("en");, with no luck. I put an
echo and exit before the pspell_new, and it works fine. Put an echo
and an exit AFTER the pspell_new call, and it "Abort"s the apache
thread.
[Thu Nov 29 19:10:42 2001] [notice] child pid 79097 exit signal Abort
trap (6)
Could it be that we're running mod_gzip? I wouldn't think so, but we
are using it. We are also using the Zend PHP Optimizer.
I'm happy to install PHP on a FreeBSD box and give you access if you
want to play, though it wouldn't be the box I'm having trouble with,
and I haven't tested the pspell failure on that install.
[2001-11-29 18:30:05] [EMAIL PROTECTED]
hmmm... It does not crash, it does not let you have a backtrace, yet it
doesn't work either. And you seem to have followed most of the
installation instructions and have recent versions of everything. On
top of that I know nothing concerning FreeBSD, and do not have a
FreeBSD machine.
Couple questions:
1. Can you execute and use example-c as nobody (I know you executed it,
period, but probably with more permissions, so this might not work.
2. Is /usr/share/dict/acmovies is a *file* (not a dir) in the .pws
format? I know, it's kinda stupid to askm but just in case...
Besides that, I have no clues right now. Any ideas? anyone?
[2001-11-25 15:00:29] [EMAIL PROTECTED]
Sorry -- That script has an extra close curly brackets that isn't
really there. Please remove that to get desired crashing effect.
Also, http://www.adcritic.com/spellcheck.php is the offending script.
In IE, I get the "The page cannot be displayed." Telnetting gets me
this:
Trying 127.0.0.1...
Connected to localhost.
Escape character is '^]'.
GET /spellcheck.php?q=foo HTTP/1.0
Connection closed by foreign host.
where if I leave the query blank (it doesn't run the offending pspell
function), I get:
Trying 127.0.0.1...
Connected to localhost.
Escape character is '^]'.
GET /spellcheck.php HTTP/1.0
HTTP/1.1 200 OK
Date: Sun, 25 Nov 2001 19:59:49 GMT
Server: Apache/1.3.22 (Unix) mod_gzip/1.3.19.1a PHP/4.0.6
X-Powered-By: PHP/4.0.6
Set-Cookie: ADCRITICPHPSID=188feaf823cbb54ca102332da63464d8;
expires=Sat, 23-Feb-02 19:59:49 GMT; path=/; domain=.adcritic.com
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
Connection: close
Content-Type: text/html
Connection closed by foreign host.
If q is empty, the script isn't executed (if !empty($q)) etc...
The remainder of the comments for this report are too long. To view
the rest of the comments, please view the bug report online a
Bug #17135 Updated: structure->ifdisposition: Pop3:OK IMAP:fail
ID: 17135 Updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] Status: Open Bug Type: IMAP related Operating System: Windows2000 PHP Version: 4.2.0 New Comment: For mor friendly reading: With pop: [1] => stdClass Object ( [type] => 3 [encoding] => 3 [ifsubtype] => 1 [subtype] => X-ZIP-COMPRESSED [ifdescription] => 0 [ifid] => 0 [bytes] => 26780 [ifdisposition] => 1 [disposition] => ATTACHMENT [ifdparameters] => 1 [dparameters] => Array ( [0] => stdClass Object ( [attribute] => FILENAME [value] => GPLFIX.ZIP ) ) [ifparameters] => 1 [parameters] => Array ( [0] => stdClass Object ( [attribute] => NAME [value] => GPLFIX.ZIP ) ) ) With IMAP: [1] => stdClass Object ( [type] => 3 [encoding] => 3 [ifsubtype] => 1 [subtype] => X-ZIP-COMPRESSED [ifdescription] => 0 [ifid] => 0 [bytes] => 26782 [ifdisposition] => 0 [ifdparameters] => 0 [ifparameters] => 1 [parameters] => Array ( [0] => stdClass Object ( [attribute] => name [value] => GPLFIX.ZIP ) ) ) Previous Comments: [2002-05-11 07:17:53] [EMAIL PROTECTED] This is the total output of imap_fetchstructure when using POP: stdClass Object ( [type] => 1 [encoding] => 0 [ifsubtype] => 1 [subtype] => MIXED [ifdescription] => 0 [ifid] => 0 [bytes] => 28390 [ifdisposition] => 0 [ifdparameters] => 0 [ifparameters] => 1 [parameters] => Array ( [0] => stdClass Object ( [attribute] => BOUNDARY [value] => =_NextPart_000_0047_01C1F7F9.C5E19FE0 ) ) [parts] => Array ( [0] => stdClass Object ( [type] => 1 [encoding] => 0 [ifsubtype] => 1 [subtype] => ALTERNATIVE [ifdescription] => 0 [ifid] => 0 [bytes] => 1162 [ifdisposition] => 0 [ifdparameters] => 0 [ifparameters] => 1 [parameters] => Array ( [0] => stdClass Object ( [attribute] => BOUNDARY [value] => =_NextPart_001_0048_01C1F7F9.C5E19FE0 ) ) [parts] => Array ( [0] => stdClass Object ( [type] => 0 [encoding] => 4 [ifsubtype] => 1 [subtype] => PLAIN [ifdescription] => 0 [ifid] => 0 [lines] => 8 [bytes] => 130 [ifdisposition] => 0 [ifdparameters] => 0 [ifparameters] => 1 [parameters] => Array ( [0] => stdClass Object ( [attribute] => CHARSET [value] => iso-8859-1 ) ) ) [1] => stdClass Object ( [type] => 0 [encoding] => 4 [ifsubtype] => 1 [subtype] => HTML [ifdescription] => 0 [ifid] => 0 [lines] => 16 [bytes] => 696 [ifdisposition] => 0 [ifdparameters] => 0 [ifparameters] => 1 [parameters] => Array ( [0] => stdClass Object ( [attribute] => CHARSET [value] => iso-8859-1 ) ) ) ) ) [1] => stdClass Object ( [type] => 3 [encoding] => 3 [ifsubtype] => 1 [subtype] => X-ZIP-COMPRESSED [ifdescription] => 0 [ifid] => 0 [bytes] => 26780 [ifdisposition] => 1 [disposition] => ATTACHMENT [ifdparameters] => 1 [dparameters] => Array ( [0] => stdClass Object ( [attribute] => FILENAME [value] => GPLFIX.ZIP ) ) [ifparameters] => 1 [parameters] => Array ( [0] => stdClass Object ( [attribute] => NAME [value] => GPLFIX.ZIP ) ) ) ) ) and the same mail with IMAP: stdClass Object ( [type] => 1 [encoding] => 0 [ifsubtype] => 1 [subtype] => MIXED [ifdescription] => 0 [ifid] => 0 [ifdisposition] => 0 [ifdparameters] => 0 [ifparameters] => 0 [parameters] => stdClass Object ( ) [parts] => Array ( [0] => stdClass Object ( [type] => 1 [encoding] => 0 [ifsubtype] => 1 [subtype] => ALTERNATIVE [ifdescription] => 0 [ifid] => 0 [ifdisposition] => 0 [ifdparameters] => 0 [ifparameters] => 0 [parameters] => stdClass Object ( ) [parts] => Array ( [0] => stdClass Object ( [type] => 0 [encoding] => 4 [ifsubtype] => 1 [subtype] => PLAIN [ifdescription] => 0 [ifid] => 0 [lines] => 9 [bytes] => 132 [ifdisposition] => 0 [ifdparameters] => 0 [ifparameters] => 1 [parameters] => Array ( [0
Bug #17182: dbx - sybase-ct support no longer cvs only
From: [EMAIL PROTECTED] Operating system: PHP version: 4.2.0 PHP Bug Type: Documentation problem Bug description: dbx - sybase-ct support no longer cvs only Hi, The docs for dbx incorrectly list that Sybase-CT support is CVS only, while in fact it is available since 4.2.0. This is listed both on the main dbx page and the dbx_connect page. Thanks, Marc. -- Edit bug report at http://bugs.php.net/?id=17182&edit=1 -- Fixed in CVS:http://bugs.php.net/fix.php?id=17182&r=fixedcvs Fixed in release:http://bugs.php.net/fix.php?id=17182&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=17182&r=needtrace Try newer version: http://bugs.php.net/fix.php?id=17182&r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=17182&r=support Expected behavior: http://bugs.php.net/fix.php?id=17182&r=notwrong Not enough info: http://bugs.php.net/fix.php?id=17182&r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=17182&r=submittedtwice register_globals:http://bugs.php.net/fix.php?id=17182&r=globals
Bug #16529 Updated: JPEG library reports unrecoverable error
ID: 16529 Updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] Status: Open Bug Type: GD related Operating System: Linux, RedHat 6.2 PHP Version: 4.1.1 New Comment: 4.2.0 with Apache 2.0.36 doesn't seem to exhibit this behaviour Steve. Previous Comments: [2002-04-10 06:39:53] [EMAIL PROTECTED] Since updating from PHP 4.0.6 to 4.1.1 (and 4.1.2) I can no longer use ImageJpeg() properly. Part of the image is drawn but then I get the error; gd-jpeg: JPEG library reports unrecoverable error: Output file write error --- out of disk space? I am not out of disk space, have well over 2G left on both devices. PHP4.0.6 with all the same config options works fine and I have therefore reverted. If a developer would like to see the PHP environment please drop me a line and I'll point you to a URL you can use. rutherford:[~/php-4.0.6] cat php-build.sh #!/bin/sh ./configure --with-apxs \ --with-gd \ --with-mysql=/usr \ --enable-trans-sid \ --with-ttf \ --with-zlib Steve. -- Edit this bug report at http://bugs.php.net/?id=16529&edit=1
Bug #17181: ADO crash
From: [EMAIL PROTECTED]
Operating system: Windows 2000 Sp2
PHP version: 4.2.0
PHP Bug Type: COM related
Bug description: ADO crash
Hi,
this script lets php crash:
$conn = new COM( "ADODB.Connection" );
$conn->Provider = 'SQLOLEDB';
$conn->Open( "Server=wincubix;Uid=oebb;Pwd=oebb;Database=cubix" );
$conn->Execute('SET DATEFORMAT ymd');
$rs = new COM( "ADODB.Recordset" );
$rs->ActiveConnection = $conn;
$rs->Open("SELECT DISTINCT * FROM news WHERE gueltig_von <=
'2002-05-13'");
changing the script like this will prevent the AV
//$rs->ActiveConnection = $conn;
$rs->Open("SELECT DISTINCT * FROM news WHERE gueltig_von <= '2002-05-13'",
$conn);
I'm using the latest MSDAC (2.7) and the latest snapshot of php
--
Edit bug report at http://bugs.php.net/?id=17181&edit=1
--
Fixed in CVS:http://bugs.php.net/fix.php?id=17181&r=fixedcvs
Fixed in release:http://bugs.php.net/fix.php?id=17181&r=alreadyfixed
Need backtrace: http://bugs.php.net/fix.php?id=17181&r=needtrace
Try newer version: http://bugs.php.net/fix.php?id=17181&r=oldversion
Not developer issue: http://bugs.php.net/fix.php?id=17181&r=support
Expected behavior: http://bugs.php.net/fix.php?id=17181&r=notwrong
Not enough info: http://bugs.php.net/fix.php?id=17181&r=notenoughinfo
Submitted twice: http://bugs.php.net/fix.php?id=17181&r=submittedtwice
register_globals:http://bugs.php.net/fix.php?id=17181&r=globals
Bug #17173 Updated: "case" causes AV
ID: 17173
Updated by: [EMAIL PROTECTED]
Reported By: [EMAIL PROTECTED]
Status: Feedback
Bug Type: COM related
Operating System: Windows 2000 SP2
PHP Version: 4.1.2
New Comment:
The AV still exists,
I tried the latest Snapshot from snaps.php.net
Previous Comments:
[2002-05-13 04:38:32] [EMAIL PROTECTED]
There have been a few changes to the COM extension since the 4.1.2
release. Please try a new version or even a snapshot from
http://bugs.php.net/?id=17173&edit=1
[2002-05-13 03:51:06] [EMAIL PROTECTED]
This script let php crash.
The Problem is the case-statement in the convert_field_crash-function,
but with an If-statement this crash doesen't occur.
Provider = 'SQLOLEDB';
$conn->Open( "Server=wincubix;Uid=oebb;Pwd=oebb;Database=cubix" );
@$rs->Open( "SELECT * FROM news ", $conn);
echo '';
while (!$rs->EOF) {
echo '';
for ($i=0; $i < $rs->Fields->Count(); $i++) {
echo '';
echo convert_field_crash($rs->Fields[$i]);
echo '';
}
echo '';
$rs->MoveNext();
}
echo '';
$rs->Close;
$conn->Close;
$rs->Release();
$rs = null;
$conn->Release();
$conn = null;
function convert_field($field) {
if ($field->type == adDBTimeStamp) {
if (empty($field->Value)) return '';
return strftime('%Y-%m-%d %T', $field->value);
} else {
return $field->Value;
}
}
function convert_field_crash($field) {
// case verursacht AV
switch($field->type) {
case adDBTimeStamp:
return strftime('%Y-%m-%d %T', $field->value);
break;
default:
return $field->Value;
}
}
?>
--
Edit this bug report at http://bugs.php.net/?id=17173&edit=1
Bug #17180: Operator Precedence
From: [EMAIL PROTECTED] Operating system: PHP version: 4.2.0 PHP Bug Type: Scripting Engine problem Bug description: Operator Precedence Why & How this code will work? Output: if (!$a = foo(FALSE))) is true bool(false) http://www.php.net/manual/en/language.operators.php "Operator Precedence" `!` has more precedence than `=` And after `!` we must have boolean constant in left side: FALSE = foo() Explain to me pls that I do not understand P.S. in C & Perl (!$a = foo()) is not valid expression -- Edit bug report at http://bugs.php.net/?id=17180&edit=1 -- Fixed in CVS:http://bugs.php.net/fix.php?id=17180&r=fixedcvs Fixed in release:http://bugs.php.net/fix.php?id=17180&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=17180&r=needtrace Try newer version: http://bugs.php.net/fix.php?id=17180&r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=17180&r=support Expected behavior: http://bugs.php.net/fix.php?id=17180&r=notwrong Not enough info: http://bugs.php.net/fix.php?id=17180&r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=17180&r=submittedtwice register_globals:http://bugs.php.net/fix.php?id=17180&r=globals
Bug #17179: evaluation constants
From: [EMAIL PROTECTED] Operating system: Linux PHP version: 4.2.0 PHP Bug Type: Feature/Change Request Bug description: evaluation constants Hello, I have this idea: will substitute What do you mean about this feature? Thanks, Mark Vydra -- Edit bug report at http://bugs.php.net/?id=17179&edit=1 -- Fixed in CVS:http://bugs.php.net/fix.php?id=17179&r=fixedcvs Fixed in release:http://bugs.php.net/fix.php?id=17179&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=17179&r=needtrace Try newer version: http://bugs.php.net/fix.php?id=17179&r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=17179&r=support Expected behavior: http://bugs.php.net/fix.php?id=17179&r=notwrong Not enough info: http://bugs.php.net/fix.php?id=17179&r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=17179&r=submittedtwice register_globals:http://bugs.php.net/fix.php?id=17179&r=globals
Bug #17178: SetCookie: updated specs
From: [EMAIL PROTECTED] Operating system: Any PHP version: 4.1.2 PHP Bug Type: HTTP related Bug description: SetCookie: updated specs PHP seems to implement to original Cookie *proposal* by Netscape. However, there are two newer *Standard* specifications by the IETF. http://www.netscape.com/newsref/std/cookie_spec.html "Persistent Client State -- HTTP Cookies" http://www.ietf.org/rfc/rfc2109.txt "HTTP State Management Mechanism" http://www.ietf.org/rfc/rfc2965.txt "HTTP State Management Mechanism" Since RFC 2109 is already over 5 years old, I would recommend implementing it over the by long deprecated Netscape specification. The major change is that the Expire attribute is replaced with the Max-Age attribute, eliminating the problem of time synchronization between client and server. Of course, you can sent both attributes. I would not implement RFC 2965 yet, since it defines the Set-Cookie2 header, which is possibly not widely supported yet. Also, please read the security considerations. For example, about spoofing: Proper application design can avoid spoofing attacks from related domains. Consider: 1. User agent makes request to victim.cracker.edu, gets back cookie session_id="1234" and sets the default domain victim.cracker.edu. 2. User agent makes request to spoof.cracker.edu, gets back cookie session-id="", with Domain=".cracker.edu". 3. User agent makes request to victim.cracker.edu again, and passes Cookie: $Version="1"; session_id="1234", $Version="1"; session_id=""; $Domain=".cracker.edu" The server at victim.cracker.edu should detect that the second cookie was not one it originated by noticing that the Domain attribute is not for itself and ignore it. -- Edit bug report at http://bugs.php.net/?id=17178&edit=1 -- Fixed in CVS:http://bugs.php.net/fix.php?id=17178&r=fixedcvs Fixed in release:http://bugs.php.net/fix.php?id=17178&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=17178&r=needtrace Try newer version: http://bugs.php.net/fix.php?id=17178&r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=17178&r=support Expected behavior: http://bugs.php.net/fix.php?id=17178&r=notwrong Not enough info: http://bugs.php.net/fix.php?id=17178&r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=17178&r=submittedtwice register_globals:http://bugs.php.net/fix.php?id=17178&r=globals
Bug #17177: periods in path-to-included-file are removed
From: [EMAIL PROTECTED] Operating system: linux PHP version: 4.1.2 PHP Bug Type: Scripting Engine problem Bug description: periods in path-to-included-file are removed For some reason, when i require a file with an absolute path that has multiple periods in it, the periods WILL be removed from the path-to-the-included-file. example: --- $_maindir = "/path/to.an.includedir/files/"; require($_maindir."includefile.inc"); --- the result will be: --- Fatal error: Failed opening required '/path/toanincludedir/files/includefile.inc' (include_path='.:/usr/share/pear') in /path/to.an.includedir/files/index.php on line 3 --- What's the deal here? seems kinda annoying when having an isp with multiple virtual hosts, and wanting to use the complete website address in the path to the files. -- Edit bug report at http://bugs.php.net/?id=17177&edit=1 -- Fixed in CVS:http://bugs.php.net/fix.php?id=17177&r=fixedcvs Fixed in release:http://bugs.php.net/fix.php?id=17177&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=17177&r=needtrace Try newer version: http://bugs.php.net/fix.php?id=17177&r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=17177&r=support Expected behavior: http://bugs.php.net/fix.php?id=17177&r=notwrong Not enough info: http://bugs.php.net/fix.php?id=17177&r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=17177&r=submittedtwice register_globals:http://bugs.php.net/fix.php?id=17177&r=globals
Bug #14298 Updated: PUT method not supported in PHP 4
ID: 14298 Updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] Status: Analyzed Bug Type:HTTP related PHP Version: 4.0.6 Assigned To: zak New Comment: Just wanted to drop a note about a test I've done: I tried a simple perl script getting the PUT file and it worked. Calling the same script through PHP yields "no file" meaning that PHP does something the uploaded file since the perlscript used by itself works and then called through PHP does'nt. Previous Comments: [2002-05-09 07:55:50] [EMAIL PROTECTED] If you find the temporary file variable I would be much obliged if you could drop me a line. BTW I was thinking would'nt it be better to have the PUT values in the superglobal $_FILES ? Or at least in a $HTTP_PUT_FILE var. A possible solution could be something like the following: $HTTP_PUT_FILE['request_uri'] Path of the proposed upload like /mytest/filename.htm $HTTP_PUT_FILE['path_translated'] The full path of the proposed upload like /usr/home/foo/bar/public_html/mytest/filename.htm $HTTP_PUT_FILE['size'] The size, in bytes, of the uploaded file. $HTTP_PUT_FILE['tmp_name'] Temp name something like /tmp/hfdhjfufd8733 My only bad is that I cant program in C otherwise I would have been there doing it already. [2002-05-08 09:44:42] [EMAIL PROTECTED] Current status on this is that I ignored it for a while - I am taking a look at it again. [2002-05-03 12:15:39] [EMAIL PROTECTED] Whats happening on this subject? [2001-12-02 01:32:31] [EMAIL PROTECTED] Thanks for the report - I am checking into it. --zak [2001-11-30 10:33:31] [EMAIL PROTECTED] Document: features.file-upload.put-method.html SAYS: The filename of this temporary file is in the $PHP_PUT_FILENAME variable SAYS: copy( $PHP_UPLOADED_FILE_NAME, $DOCUMENT_ROOT.$REQUEST_URI ); Neither works. What does? -- Edit this bug report at http://bugs.php.net/?id=14298&edit=1
Bug #17176 Updated: Can not get connected to local mysql db
ID: 17176 Updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] -Status: Open +Status: Closed Bug Type: MySQL related Operating System: Linux (debian) PHP Version: 4.2.0 New Comment: Thank you for your bug report. This issue has already been fixed in the latest released version of PHP, which you can download at http://www.php.net/downloads.php Fixed in 4.2.1, which will be released later today. Derick Previous Comments: [2002-05-13 08:03:25] [EMAIL PROTECTED] './configure' '--prefix=/usr/lib/apache' '--with-apxs=/usr/sbin/apxs' '--enable-calendar' '--enable-bcmath' '--with-gd=/usr/' '--with-jpeg-dir=/usr/' '--with-png-dir=/usr/' '--with-ttflib-dir=/usr/' '--with-zlib' '--enable-gd-native-ttf' '--with-ttf=/usr/' '--with-sybase-ct=/opt/sybase-11.9.2' '--with-pear' '--with-dbase' '--with-gettext' Compilation went just fine, but when trying to get connection to mysql local database, the connection failed. When downgraded to 4.1.2 the connection worked just fine. Sybase connection did not seem to work eather.. -- Edit this bug report at http://bugs.php.net/?id=17176&edit=1
Bug #17176: Can not get connected to local mysql db
From: [EMAIL PROTECTED] Operating system: Linux (debian) PHP version: 4.2.0 PHP Bug Type: MySQL related Bug description: Can not get connected to local mysql db './configure' '--prefix=/usr/lib/apache' '--with-apxs=/usr/sbin/apxs' '--enable-calendar' '--enable-bcmath' '--with-gd=/usr/' '--with-jpeg-dir=/usr/' '--with-png-dir=/usr/' '--with-ttflib-dir=/usr/' '--with-zlib' '--enable-gd-native-ttf' '--with-ttf=/usr/' '--with-sybase-ct=/opt/sybase-11.9.2' '--with-pear' '--with-dbase' '--with-gettext' Compilation went just fine, but when trying to get connection to mysql local database, the connection failed. When downgraded to 4.1.2 the connection worked just fine. Sybase connection did not seem to work eather.. -- Edit bug report at http://bugs.php.net/?id=17176&edit=1 -- Fixed in CVS:http://bugs.php.net/fix.php?id=17176&r=fixedcvs Fixed in release:http://bugs.php.net/fix.php?id=17176&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=17176&r=needtrace Try newer version: http://bugs.php.net/fix.php?id=17176&r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=17176&r=support Expected behavior: http://bugs.php.net/fix.php?id=17176&r=notwrong Not enough info: http://bugs.php.net/fix.php?id=17176&r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=17176&r=submittedtwice register_globals:http://bugs.php.net/fix.php?id=17176&r=globals
Bug #17175 Updated: mail() can't work after I upgrade my php from 4.0.4pl1 to 4.2
ID: 17175 Updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] Status: Bogus Bug Type: Mail related Operating System: RedHat 7.1 PHP Version: 4.2.0 New Comment: I've check the config.log and find about some sendmail infomation: configure:7017: checking for sendmail configure:7034: found /usr/sbin/sendmail configure:7034: found /usr/sbin/sendmail ... ac_cv_path_PROG_SENDMAIL=/usr/sbin/sendmail Previous Comments: [2002-05-13 06:32:01] [EMAIL PROTECTED] Btw, can you check your config.log if it found sendmail during ./configure? ./configure was quite buggy with the 4.2.0 release, maybe that's a another side effect we weren't aware yet. [2002-05-13 06:20:49] [EMAIL PROTECTED] Not enough information was provided for us to be able to handle this bug. Please re-read the instructions at http://bugs.php.net/how-to-report.php If you can provide more information, feel free to add it to this bug and change the status back to "Open". Thank you for your interest in PHP. [2002-05-13 06:17:42] [EMAIL PROTECTED] I upgrade my apache from 1.3 to 2.0.36 and php from 4.0.4pl1 to 4.2. Then I found that the mail() can't work and it's can work fine before I upgrade. The configure command of php4.2 is: './configure' '--prefix=/usr/local/php4.2' '--exec-prefix=/usr/local' '--bindir=/usr/local/bin' '--sbindir=/usr/local/sbin' '--libexecdir=/usr/local/libexec' '--datadir=/usr/local/share' '--sysconfdir=/usr/local/etc' '--sharedstatedir=/usr/local/com' '--localstatedir=/usr/local/var' '--libdir=/usr/local/lib' '--includedir=/usr/local/include' '--oldincludedir=/usr/include' '--infodir=/usr/local/info' '--mandir=/usr/local/man' '--enable-ftp' '--enable-gd-native-ttf' '--enable-mbstring' '--enable-mbstr-enc-trans' '--enable-overload' '--enable-sockets' '--enable-aggregate' '--with-mod_charset' '--with-mysql' '--with-apxs2=/usr/local/apache2/bin/apxs' '--with-config-file-path=/etc' '--with-imap=/usr/lib' '--with-imap-ssl=/usr/lib' '--with-kerberos=/usr/kerberos' '--with-pear=/usr/local/php4.2/lib/php' '--with-exec-dir=/usr/local/bin' '--with-bz2=/usr/bin' '--with-java=/opt/jdk1.3.1' '--with-oci8=/u02/app/oracle/product/ora816' '--with-oracle=/u02/app/oracle/product/ora816' How to resolve it? I wish somebody can help me! -- Edit this bug report at http://bugs.php.net/?id=17175&edit=1
Bug #16542 Updated: safe_mode_exec_dir and exec()
ID: 16542
Updated by: [EMAIL PROTECTED]
Reported By: [EMAIL PROTECTED]
-Status: No Feedback
+Status: Open
Bug Type: IIS related
Operating System: windows XP
PHP Version: 4.1.2
New Comment:
Reopening on user request: it doesn't work, even with forward slashes
Previous Comments:
[2002-05-12 00:00:03] [EMAIL PROTECTED]
No feedback was provided for this bug for over a month, so it is
being suspended automatically. If you are able to provide the
information that was originally requested, please do so and change
the status of the bug back to "Open".
[2002-04-11 06:19:28] [EMAIL PROTECTED]
YOu're messing with backslashes and slashes. Try setting the
safe_mode_exec_dir to something like c:/inetpub/cgi-bin
Does it work now?
[2002-04-11 04:17:29] [EMAIL PROTECTED]
ISAPI mode. IIS 5.1
safe_mode_exec_dir = C:\\Inetpub\cgi-bin\
Calls to exec system with {safe mode = On} result in an extra "/"
being
prepended to the executable file's name:
Warning: Unable to fork [C:Inetpub\cgi-bin\\/myprog.exe] in
c:\inetpub\wwwroot\index.php4
(the fork error results from other issues, but notice the /myprog.exe)
[2002-04-11 04:08:15] [EMAIL PROTECTED]
ISAPI mode. IIS 5.1
safe_mode_exec_dir = C:\\Inetpub\cgi-bin\
Calls to exec system with {safe mode = On} result in an extra "/" being
prepended to the executable file's name:
Warning: Unable to fork [C:Inetpub\cgi-bin\\/myprog.exe] in
c:\inetpub\wwwroot\index.php4
--
Edit this bug report at http://bugs.php.net/?id=16542&edit=1
Bug #16841 Updated: imagepng() segfaults
ID: 16841 Updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] Status: Feedback Bug Type: GD related Operating System: Linux PHP Version: 4.2.0 New Comment: I am having a similar problem, if you notice in the backtrace, it references /usr/lib/libpng.so.3 on my system this is soft-linked to libpng.so.5, and if I remove --with-pdflib from my configure line, it seems to link against the correct library and not segfault, but --with-pdflib it reverts to the version 3 library and segfaults when I try to create from PNG in the GD routines Previous Comments: [2002-04-28 21:23:44] [EMAIL PROTECTED] Have you tried compiling pdflib with external pnglib? (--with-pnglib) --Jani [2002-04-26 21:25:26] [EMAIL PROTECTED] Uh, 'configure', 'make', 'make install'. Always worked in the past. [2002-04-26 21:23:10] [EMAIL PROTECTED] And your pdflib configure line? [2002-04-26 21:18:30] [EMAIL PROTECTED] The simplest configuration I can get it to crash with is: configure --with-zlib --with-gd --with-png-dir=/usr --with-jpeg-dir=/usr --pdflib I'm just building the CGI version because it is easier than doing a 'make install' and restarting the Apache etc, but this bug does affect the Apache DSO build as well. The weird thing is that this works fine with PHP 4.1.2, AND the libpng 1.2.1. It seems to look more and more like this bug is pdflib related. [2002-04-26 09:20:11] [EMAIL PROTECTED] I couldn't reproduce this either with pdflib from pdflib.com. Can you paste the full configure line of PHP and of pdflib ? 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/16841 -- Edit this bug report at http://bugs.php.net/?id=16841&edit=1
Bug #17175 Updated: mail() can't work after I upgrade my php from 4.0.4pl1 to 4.2
ID: 17175 Updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] Status: Bogus Bug Type: Mail related Operating System: RedHat 7.1 PHP Version: 4.2.0 New Comment: Btw, can you check your config.log if it found sendmail during ./configure? ./configure was quite buggy with the 4.2.0 release, maybe that's a another side effect we weren't aware yet. Previous Comments: [2002-05-13 06:20:49] [EMAIL PROTECTED] Not enough information was provided for us to be able to handle this bug. Please re-read the instructions at http://bugs.php.net/how-to-report.php If you can provide more information, feel free to add it to this bug and change the status back to "Open". Thank you for your interest in PHP. [2002-05-13 06:17:42] [EMAIL PROTECTED] I upgrade my apache from 1.3 to 2.0.36 and php from 4.0.4pl1 to 4.2. Then I found that the mail() can't work and it's can work fine before I upgrade. The configure command of php4.2 is: './configure' '--prefix=/usr/local/php4.2' '--exec-prefix=/usr/local' '--bindir=/usr/local/bin' '--sbindir=/usr/local/sbin' '--libexecdir=/usr/local/libexec' '--datadir=/usr/local/share' '--sysconfdir=/usr/local/etc' '--sharedstatedir=/usr/local/com' '--localstatedir=/usr/local/var' '--libdir=/usr/local/lib' '--includedir=/usr/local/include' '--oldincludedir=/usr/include' '--infodir=/usr/local/info' '--mandir=/usr/local/man' '--enable-ftp' '--enable-gd-native-ttf' '--enable-mbstring' '--enable-mbstr-enc-trans' '--enable-overload' '--enable-sockets' '--enable-aggregate' '--with-mod_charset' '--with-mysql' '--with-apxs2=/usr/local/apache2/bin/apxs' '--with-config-file-path=/etc' '--with-imap=/usr/lib' '--with-imap-ssl=/usr/lib' '--with-kerberos=/usr/kerberos' '--with-pear=/usr/local/php4.2/lib/php' '--with-exec-dir=/usr/local/bin' '--with-bz2=/usr/bin' '--with-java=/opt/jdk1.3.1' '--with-oci8=/u02/app/oracle/product/ora816' '--with-oracle=/u02/app/oracle/product/ora816' How to resolve it? I wish somebody can help me! -- Edit this bug report at http://bugs.php.net/?id=17175&edit=1
Bug #17175 Updated: mail() can't work after I upgrade my php from 4.0.4pl1 to 4.2
ID: 17175 Updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] -Status: Open +Status: Bogus Bug Type: Mail related Operating System: RedHat 7.1 PHP Version: 4.2.0 New Comment: Not enough information was provided for us to be able to handle this bug. Please re-read the instructions at http://bugs.php.net/how-to-report.php If you can provide more information, feel free to add it to this bug and change the status back to "Open". Thank you for your interest in PHP. Previous Comments: [2002-05-13 06:17:42] [EMAIL PROTECTED] I upgrade my apache from 1.3 to 2.0.36 and php from 4.0.4pl1 to 4.2. Then I found that the mail() can't work and it's can work fine before I upgrade. The configure command of php4.2 is: './configure' '--prefix=/usr/local/php4.2' '--exec-prefix=/usr/local' '--bindir=/usr/local/bin' '--sbindir=/usr/local/sbin' '--libexecdir=/usr/local/libexec' '--datadir=/usr/local/share' '--sysconfdir=/usr/local/etc' '--sharedstatedir=/usr/local/com' '--localstatedir=/usr/local/var' '--libdir=/usr/local/lib' '--includedir=/usr/local/include' '--oldincludedir=/usr/include' '--infodir=/usr/local/info' '--mandir=/usr/local/man' '--enable-ftp' '--enable-gd-native-ttf' '--enable-mbstring' '--enable-mbstr-enc-trans' '--enable-overload' '--enable-sockets' '--enable-aggregate' '--with-mod_charset' '--with-mysql' '--with-apxs2=/usr/local/apache2/bin/apxs' '--with-config-file-path=/etc' '--with-imap=/usr/lib' '--with-imap-ssl=/usr/lib' '--with-kerberos=/usr/kerberos' '--with-pear=/usr/local/php4.2/lib/php' '--with-exec-dir=/usr/local/bin' '--with-bz2=/usr/bin' '--with-java=/opt/jdk1.3.1' '--with-oci8=/u02/app/oracle/product/ora816' '--with-oracle=/u02/app/oracle/product/ora816' How to resolve it? I wish somebody can help me! -- Edit this bug report at http://bugs.php.net/?id=17175&edit=1
Bug #17175: mail() can't work after I upgrade my php from 4.0.4pl1 to 4.2
From: [EMAIL PROTECTED] Operating system: RedHat 7.1 PHP version: 4.2.0 PHP Bug Type: Mail related Bug description: mail() can't work after I upgrade my php from 4.0.4pl1 to 4.2 I upgrade my apache from 1.3 to 2.0.36 and php from 4.0.4pl1 to 4.2. Then I found that the mail() can't work and it's can work fine before I upgrade. The configure command of php4.2 is: './configure' '--prefix=/usr/local/php4.2' '--exec-prefix=/usr/local' '--bindir=/usr/local/bin' '--sbindir=/usr/local/sbin' '--libexecdir=/usr/local/libexec' '--datadir=/usr/local/share' '--sysconfdir=/usr/local/etc' '--sharedstatedir=/usr/local/com' '--localstatedir=/usr/local/var' '--libdir=/usr/local/lib' '--includedir=/usr/local/include' '--oldincludedir=/usr/include' '--infodir=/usr/local/info' '--mandir=/usr/local/man' '--enable-ftp' '--enable-gd-native-ttf' '--enable-mbstring' '--enable-mbstr-enc-trans' '--enable-overload' '--enable-sockets' '--enable-aggregate' '--with-mod_charset' '--with-mysql' '--with-apxs2=/usr/local/apache2/bin/apxs' '--with-config-file-path=/etc' '--with-imap=/usr/lib' '--with-imap-ssl=/usr/lib' '--with-kerberos=/usr/kerberos' '--with-pear=/usr/local/php4.2/lib/php' '--with-exec-dir=/usr/local/bin' '--with-bz2=/usr/bin' '--with-java=/opt/jdk1.3.1' '--with-oci8=/u02/app/oracle/product/ora816' '--with-oracle=/u02/app/oracle/product/ora816' How to resolve it? I wish somebody can help me! -- Edit bug report at http://bugs.php.net/?id=17175&edit=1 -- Fixed in CVS:http://bugs.php.net/fix.php?id=17175&r=fixedcvs Fixed in release:http://bugs.php.net/fix.php?id=17175&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=17175&r=needtrace Try newer version: http://bugs.php.net/fix.php?id=17175&r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=17175&r=support Expected behavior: http://bugs.php.net/fix.php?id=17175&r=notwrong Not enough info: http://bugs.php.net/fix.php?id=17175&r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=17175&r=submittedtwice register_globals:http://bugs.php.net/fix.php?id=17175&r=globals
Bug #17044 Updated: TIME_WAIT status
ID: 17044
Updated by: [EMAIL PROTECTED]
Reported By: [EMAIL PROTECTED]
Status: Open
Bug Type: Sockets related
Operating System: Linux Red Hat 7.0
PHP Version: 4.2.0
New Comment:
i have also tried this in a slightly different setting:
red hat 7.2, kernel-2.4.7 and php 4.1.2.
in this environment, both tcp-connections go right to the TIME_WAIT
status and stay there for 1 minute (which seems to be 2MSL); the tcp
connection owned by httpd is not waiting in ESTABLISHED mode as it does
under kernel 2.2.
this seems to be a kernel-related issue, then? has anyone else
experienced this problem?
Previous Comments:
[2002-05-06 11:48:40] [EMAIL PROTECTED]
this is my setup:
php 4.2.0 with the socket extension, as a dynamically loaded module in
apache 1.3.23. it is running on is a red hat 7.0 box with kernel
2.2.19.
this is was i am trying to do:
i am using the socket functions to connect to a server which is running
a ticketing software using a specifically designed protocol; the
details do not matter here. i'll call my webserver "webserv.com", the
client calling the script "client.com" and the ticketsystem
"tixserv.com".
i think i am doing everything by the book - just a simple one-shot
tcp-client; writing some request to tixserv.com, reading the response
and closing the connection. i am using socket_create(),
socket_connect(), socket_write(), socket_read(), and finally
socket_close(), pretty much the same way as the example 2 ("Simple
TCP/IP client") in the php manual. this seems to work well (no errors
or warnings).
this is my problem:
if i monitor the connection attempts with netstat, i am seeing the
following behaviour:
firstly, connections are established: from webserv.com to client.com
and from webserv.com to tixserv.com:
tcpwebserv.com:1558 tixserv.com:45007SYN_SENT1126/httpd
tcpwebserv.com:www client.com:1894 ESTABLISHED 1126/httpd
then, the connection from webserv.com to tixserv.com is closed (using
socket_close() in the script), so the connection status goes to
TIME_WAIT:
tcpwebserv.com:1558 tixserv.com:45007TIME_WAIT -
tcpwebserv.com:www client.com:1894 ESTABLISHED 1126/httpd
i see that to go to TIME_WAIT status is the correct way to behave for a
socket. but the problem is that httpd somehow seems to wait for the
TIME_WAIT status to go away and keeps the connection open during this
time (ESTABLISHED). this takes a really long time (at least 30 seconds
or more). at some time, the TIME_WAIT of the connection to tixserv.com
finally goes away, and the connection to the client falls into that
state:
tcpwebserv.com:www client.com:1894 TIME_WAIT -
strange - my browser and php seem to ignore this: the script execution,
measured with microtime(), is around 800 miliseconds, of which at least
90% is response time by tixserv.com which is fine. also, my browser
does not need more than a second to display the script results.
nonetheless, the httpd connection on the server stays ESTABLISHED for
at least 30 seconds.
the scary thing about this is that it gets worse if i start to stress
the server. i used jakarta-jmeter to simulate simultaneous requests.
jmeter did not behave the same as my browser: it actually waited until
the httpd connection status was really closed. this totally stressed
webserv.com: i had response times around 600 seconds and more, with
only 5 threads doing 2 requests for the script. the load on webserv.com
was huge during that time, sometimes i even had to stop apache to end
the test.
--
Edit this bug report at http://bugs.php.net/?id=17044&edit=1
