#42230 [NEW]: echo ++$var output differs from $var++
From: [EMAIL PROTECTED] Operating system: debian linux PHP version: 5.2.4RC1 PHP Bug Type: Unknown/Other Function Bug description: echo ++$var output differs from $var++ Description: different result from echoing post or pre incrementation of a variable $count=1; echo $count++;//echo's 1 echo \n; $count=1; echo ++$count;//echo's 2 its hard to see where this would really be an issue yes the value of $count is still the same in both scenarios, just seems inconsistent behaviour and could confuddle some basic debugging ? Reproduce code: --- $count=1; echo $count++; echo \n; $count=1; echo ++$count; Expected result: 2 2 Actual result: -- 1 2 -- Edit bug report at http://bugs.php.net/?id=42230edit=1 -- Try a CVS snapshot (PHP 4.4): http://bugs.php.net/fix.php?id=42230r=trysnapshot44 Try a CVS snapshot (PHP 5.2): http://bugs.php.net/fix.php?id=42230r=trysnapshot52 Try a CVS snapshot (PHP 6.0): http://bugs.php.net/fix.php?id=42230r=trysnapshot60 Fixed in CVS: http://bugs.php.net/fix.php?id=42230r=fixedcvs Fixed in release: http://bugs.php.net/fix.php?id=42230r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=42230r=needtrace Need Reproduce Script:http://bugs.php.net/fix.php?id=42230r=needscript Try newer version:http://bugs.php.net/fix.php?id=42230r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=42230r=support Expected behavior:http://bugs.php.net/fix.php?id=42230r=notwrong Not enough info: http://bugs.php.net/fix.php?id=42230r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=42230r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=42230r=globals PHP 3 support discontinued: http://bugs.php.net/fix.php?id=42230r=php3 Daylight Savings: http://bugs.php.net/fix.php?id=42230r=dst IIS Stability:http://bugs.php.net/fix.php?id=42230r=isapi Install GNU Sed: http://bugs.php.net/fix.php?id=42230r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=42230r=float No Zend Extensions: http://bugs.php.net/fix.php?id=42230r=nozend MySQL Configuration Error:http://bugs.php.net/fix.php?id=42230r=mysqlcfg
#42230 [Opn-Bgs]: echo ++$var output differs from $var++
ID: 42230 Updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] -Status: Open +Status: Bogus Bug Type: Unknown/Other Function Operating System: debian linux PHP Version: 5.2.4RC1 New Comment: Thank you for taking the time to write to us, but this is not a bug. Please double-check the documentation available at http://www.php.net/manual/ and the instructions on how to report a bug at http://bugs.php.net/how-to-report.php . Previous Comments: [2007-08-07 07:40:15] [EMAIL PROTECTED] Description: different result from echoing post or pre incrementation of a variable $count=1; echo $count++;//echo's 1 echo \n; $count=1; echo ++$count;//echo's 2 its hard to see where this would really be an issue yes the value of $count is still the same in both scenarios, just seems inconsistent behaviour and could confuddle some basic debugging ? Reproduce code: --- $count=1; echo $count++; echo \n; $count=1; echo ++$count; Expected result: 2 2 Actual result: -- 1 2 -- Edit this bug report at http://bugs.php.net/?id=42230edit=1
#42231 [NEW]: Unable to Write to/Updata Mysql Database on NTFS System
From: awesoft at myway dot com Operating system: window Xp PHP version: 4.4.7 PHP Bug Type: MySQL related Bug description: Unable to Write to/Updata Mysql Database on NTFS System Description: I am one of PHP/mySQL users from Nigeria. I have been trying to update or write to my mySQL database running on NTFS but i cannot. What can I do. Alternatively, I run it on FAT32 file system and it is OK. Is there any security configuration I need to do on NTFS before the updating can be done??. Please, I will be very grateful if the security settings can be sent to me. Thanks. I am proud to be a PHP/mySQL user!! Reproduce code: --- $sql=Update my_table set sname='awe'; mysql($sql,$myDB); Expected result: Error is not displayed but the table (in the mySQL database running on NTFS) will not be updated. -- Edit bug report at http://bugs.php.net/?id=42231edit=1 -- Try a CVS snapshot (PHP 4.4): http://bugs.php.net/fix.php?id=42231r=trysnapshot44 Try a CVS snapshot (PHP 5.2): http://bugs.php.net/fix.php?id=42231r=trysnapshot52 Try a CVS snapshot (PHP 6.0): http://bugs.php.net/fix.php?id=42231r=trysnapshot60 Fixed in CVS: http://bugs.php.net/fix.php?id=42231r=fixedcvs Fixed in release: http://bugs.php.net/fix.php?id=42231r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=42231r=needtrace Need Reproduce Script:http://bugs.php.net/fix.php?id=42231r=needscript Try newer version:http://bugs.php.net/fix.php?id=42231r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=42231r=support Expected behavior:http://bugs.php.net/fix.php?id=42231r=notwrong Not enough info: http://bugs.php.net/fix.php?id=42231r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=42231r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=42231r=globals PHP 3 support discontinued: http://bugs.php.net/fix.php?id=42231r=php3 Daylight Savings: http://bugs.php.net/fix.php?id=42231r=dst IIS Stability:http://bugs.php.net/fix.php?id=42231r=isapi Install GNU Sed: http://bugs.php.net/fix.php?id=42231r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=42231r=float No Zend Extensions: http://bugs.php.net/fix.php?id=42231r=nozend MySQL Configuration Error:http://bugs.php.net/fix.php?id=42231r=mysqlcfg
#42077 [Com]: Why have the session folder in open_basedir
ID: 42077 Comment by: harry at rhsoft dot net Reported By: spam2 at rhsoft dot net Status: Feedback Bug Type: Session related Operating System: Linux PHP Version: 5CVS-2007-07-23 (snap) Assigned To: stas New Comment: Yes seems to work correct ?php session_start(); echo $a; phpinfo(); ? Notice: Undefined variable: a in /mnt/data/www/www.rhsoft.net/test.php on line 3 PHP Version 5.2.4RC1-dev __ Session was started with a save-path outside open_basedir The Warning-Message was written in the global error_log also outside open_basedir Previous Comments: [2007-08-07 00:25:39] [EMAIL PROTECTED] Please try using this CVS snapshot: http://snaps.php.net/php5.2-latest.tar.gz For Windows (zip): http://snaps.php.net/win32/php5.2-win32-latest.zip For Windows (installer): http://snaps.php.net/win32/php5.2-win32-installer-latest.msi AFAIK, this is now fixed. Please try the snapshot. [2007-08-03 18:13:36] harry at rhsoft dot net Nice - The bug is present and you make a release candidate? Aug 2007, PHP 5.2.4 02 Aug 2007, PHP 5.2.4RC1 Hopefully this is a joke.. If this will go to final i need a address to send a bill for changing 200 Host-Files on some servers! Need to make for each one a session-directory and set it to open_basedir or a stupid global configuration that allows scripts reading of all session-files from other users too. But what should we do with global error_log? Give all Hosts access to the log-folder? NO - Never! [2007-07-28 13:45:07] harry at rhsoft dot net Is there any change? The downloaded snapshot contains following in news.txt Fixed session.save_path and error_log values to be checked against open_basedir and safe_mode (CVE-2007-3378) If this change goes in php 5.2.4 final it will break many setups session.save_path and error_log set by admin in php.ini must not checked against open_basedir If you have 100 virtual hosts with open_basedir for each per Directory and the server is configured for one central errorlog and one central session.save_path all hosts will crash. You must check changig this in .htaccess/ini_set() against open_basedir but not on the global configuration. A script has not to look in the session-dir because in worst case it can read ALL session-files and display the content - so open_basedir has to block this and did it before the change. [2007-07-25 14:31:47] [EMAIL PROTECTED] Re-opening and assign to Stas who has something cooking up for this. [2007-07-23 09:12:07] [EMAIL PROTECTED] See http://cve.mitre.org/cgi-bin/cvename.cgi?name=2007-3378 for why. 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/42077 -- Edit this bug report at http://bugs.php.net/?id=42077edit=1
#42198 [Opn]: SCRIPT_NAME and PHP_SELF truncated when inside a userdir and using PATH_INFO
ID: 42198
User updated by: hans at parse dot nl
Reported By: hans at parse dot nl
Status: Open
Bug Type: CGI related
Operating System: Linux
PHP Version: 5.2.4RC1
New Comment:
A little more explanation fyi: The problem is that DOCUMENT_ROOT is
always set to the configured document root of the default host or the
vhost, even when calling scripts from a userdir. This is not just in
Lighttpd/FastCGI, also f.e. in Apache setups. In my testcase
DOCUMENT_ROOT is '/var/www/htdocs'.
So if i call http://servername/~hans/info.php/foo/bar , We enter this
bit of code in init_request_info() in sapi/cgi/cgi_main.c:
---
/* figure out docroot
SCRIPT_FILENAME minus SCRIPT_NAME
*/
if (env_document_root)
{
int l = strlen(env_document_root);
int path_translated_len = 0;
char *path_translated = NULL;
if (l env_document_root[l - 1] == '/') {
--l;
}
/* we have docroot, so we should have:
* DOCUMENT_ROOT=/docroot
* SCRIPT_FILENAME=/docroot/info.php
*
* SCRIPT_NAME is the portion of the path beyond docroot
*/
env_script_name = pt + l;
---
Since env_document_root is pretty much always set, we enter the if. pt
is '/home/hans/public_html/info.php' at this point (which is correct). l
becomes 15, the strlen of our DOCUMENT_ROOT '/var/www/htdocs'. The
trailing slash check if loop is skipped since our docroot doesn't have
a trailing slash. After this, SCRIPT_NAME is set to pt + l. pt being
'/home/hans/public_html/info.php' and l being 15, this results in a
invalid SCRIPT_NAME (and thus a PHP_SELF) of 'ic_html/info.php'.
My patch adds a userdir check to the 'if (env_document_root)', to
prevent from entering this if() with a DOCUMENT_ROOT that doesn't match
the actual docroot of the userdir. The code that follows after this if()
handles the userdir requests perfectly and results in correct
SCRIPT_NAME and PHP_SELF vars.
Previous Comments:
[2007-08-06 16:11:11] hans at parse dot nl
./configure --enable-cgi --enable-fastcgi --enable-force-cgi-redirect
--prefix=/usr --sysconfdir=/etc --with-config-file-path=/etc/php
--with-openssl --with-bz2 --with-gd --with-mysql --with-mysqli
--with-gettext --with-zlib --enable-mbstring --enable-sockets
--enable-sysvsem --enable-sysvshm --enable-debug=no
Direct link to my patch against php-5.2.3 on lighttpd Trac:
http://trac.lighttpd.net/trac/attachment/ticket/405/cgi_main.diff
[2007-08-06 15:45:15] [EMAIL PROTECTED]
What was the configure line used to configure PHP?
[2007-08-06 08:30:01] hans at parse dot nl
Yes, problem found initially in 5.2.3 but i tested and confirmed with
5.2.4RC1 before submitting this bug report.
Turning off cgi.fix_pathinfo results in a No input file specified.
message (url being http://servername/~hans/info.php/foo/bar).
[2007-08-04 14:14:24] [EMAIL PROTECTED]
Also, what is the result if cgi.fix_pathinfo = 0 ?
[2007-08-04 14:13:36] [EMAIL PROTECTED]
And you are really using 5.2.4RC1?
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/42198
--
Edit this bug report at http://bugs.php.net/?id=42198edit=1
#42232 [NEW]: Crash after exit mai function
From: filipski at mail dot md
Operating system: Windows
PHP version: 5.2.4RC1
PHP Bug Type: Reproducible crash
Bug description: Crash after exit mai function
Description:
A problem with php5activescript.dll
I created a new Win32 Console application in VisualStudio2005.
Everything runs fine until the very end. But after returning from function
main() the program waits some time and crashes.
So, it:
1. It unload slowly
2. It crashes
When doing the same with Python, PerlScript, JScript, VBScript there is no
problem after the function main exits. The program runs fine, invokes the
script dispatch functions, exits ok, quick and with no crashes.
BTW after the program ends, the engine unloads very slowly. Much slower
than other engines I tried Python, PerlScript, JScript, VBScript.
Reproduce code:
---
int main(){...CoInitialize();...{
IActiveScriptSite* pSite = new MyActiveScriptSite();
CComPtrIActiveScript pas;
CComPtrIDispatch pDisp;
HRESULT hr;
CComPtrIActiveScriptParse pasp;
hr = pasp.CoCreateInstance(LPHPScript, 0, CLSCTX_ALL);
hr = pasp-InitNew();
hr = pasp-QueryInterface(pas);
hr = pas-SetScriptSite(pSite);
EXCEPINFO ei;
wchar_t *pwszCode = L some PHP code in UNICODE format...
hr = pasp-ParseScriptText(pwszCode, 0, 0, 0, 0, 0,
SCRIPTTEXT_ISPERSISTENT,
0, ei);
...
}
CoUninitialize();
Expected result:
I expect the engine to unload imediately, quickly and with no crashes.
Actual result:
--
A diallog box with a crash report is shown:
Unhandled exception at 0x011aa455 in eval.exe: 0xC005: Access
violation reading location 0x019eceb8.
This is the call stack, maybe it could be helpful:
php5ts.dll!011aa455()
[Frames below may be incorrect and/or missing, no symbols loaded for
php5ts.dll]
php5ts.dll!011aa1a8()
php5ts.dll!011aa1c4()
php5ts.dll!01199a97()
php5ts.dll!01101f22()
php5ts.dll!011db5e6()
php5activescript.dll!10001fa2()
ntdll.dll!7c91056d()
kernel32.dll!7c80995a()
ntdll.dll!7c91056d()
msvcrt.dll!77c2c2de()
msvcrt.dll!77c2c2e3()
kernel32.dll!7c80996d()
MSCTFIME.IME!755d9c87()
MSCTFIME.IME!755d9fb8()
php5activescript.dll!10006611()
ntdll.dll!7c9011a7()
ntdll.dll!7c923f31()
ntdll.dll!7c96cd11()
ntdll.dll!7c910945()
ntdll.dll!7c91094e()
kernel32.dll!7c81cd76()
ntdll.dll!7c960af8()
ntdll.dll!7c960bf0()
ntdll.dll!7c960bcc()
ntdll.dll!7c91056d()
eval.exe!_free_base(void * pBlock=0x7ffddc00) Line 109 + 0x12 bytes
C
ntdll.dll!7c90f0aa()
kernel32.dll!7c80e62b()
kernel32.dll!7c80e45c()
kernel32.dll!7c81cdee()
eval.exe!__crtExitProcess(int status=0) Line 684 C
eval.exe!doexit(int code=0, int quick=0, int retcaller=0) Line 596 +
0x9 bytes C
eval.exe!exit(int code=0) Line 398 + 0xd bytes C
eval.exe!__tmainCRTStartup() Line 333 C
eval.exe!mainCRTStartup() Line 196 C
kernel32.dll!7c816fd7()
--
Edit bug report at http://bugs.php.net/?id=42232edit=1
--
Try a CVS snapshot (PHP 4.4):
http://bugs.php.net/fix.php?id=42232r=trysnapshot44
Try a CVS snapshot (PHP 5.2):
http://bugs.php.net/fix.php?id=42232r=trysnapshot52
Try a CVS snapshot (PHP 6.0):
http://bugs.php.net/fix.php?id=42232r=trysnapshot60
Fixed in CVS: http://bugs.php.net/fix.php?id=42232r=fixedcvs
Fixed in release:
http://bugs.php.net/fix.php?id=42232r=alreadyfixed
Need backtrace: http://bugs.php.net/fix.php?id=42232r=needtrace
Need Reproduce Script:http://bugs.php.net/fix.php?id=42232r=needscript
Try newer version:http://bugs.php.net/fix.php?id=42232r=oldversion
Not developer issue: http://bugs.php.net/fix.php?id=42232r=support
Expected behavior:http://bugs.php.net/fix.php?id=42232r=notwrong
Not enough info:
http://bugs.php.net/fix.php?id=42232r=notenoughinfo
Submitted twice:
http://bugs.php.net/fix.php?id=42232r=submittedtwice
register_globals: http://bugs.php.net/fix.php?id=42232r=globals
PHP 3 support discontinued: http://bugs.php.net/fix.php?id=42232r=php3
Daylight Savings: http://bugs.php.net/fix.php?id=42232r=dst
IIS Stability:http://bugs.php.net/fix.php?id=42232r=isapi
Install GNU Sed: http://bugs.php.net/fix.php?id=42232r=gnused
Floating point limitations: http://bugs.php.net/fix.php?id=42232r=float
No Zend Extensions: http://bugs.php.net/fix.php?id=42232r=nozend
MySQL
#42232 [Opn]: Crash after exit main() function
ID: 42232
User updated by: filipski at mail dot md
-Summary: Crash after exit mai function
Reported By: filipski at mail dot md
Status: Open
Bug Type: Reproducible crash
Operating System: Windows
PHP Version: 5.2.4RC1
New Comment:
summary edit
Previous Comments:
[2007-08-07 09:49:16] filipski at mail dot md
Description:
A problem with php5activescript.dll
I created a new Win32 Console application in VisualStudio2005.
Everything runs fine until the very end. But after returning from
function main() the program waits some time and crashes.
So, it:
1. It unload slowly
2. It crashes
When doing the same with Python, PerlScript, JScript, VBScript there is
no problem after the function main exits. The program runs fine, invokes
the script dispatch functions, exits ok, quick and with no crashes.
BTW after the program ends, the engine unloads very slowly. Much slower
than other engines I tried Python, PerlScript, JScript, VBScript.
Reproduce code:
---
int main(){...CoInitialize();...{
IActiveScriptSite* pSite = new MyActiveScriptSite();
CComPtrIActiveScript pas;
CComPtrIDispatch pDisp;
HRESULT hr;
CComPtrIActiveScriptParse pasp;
hr = pasp.CoCreateInstance(LPHPScript, 0, CLSCTX_ALL);
hr = pasp-InitNew();
hr = pasp-QueryInterface(pas);
hr = pas-SetScriptSite(pSite);
EXCEPINFO ei;
wchar_t *pwszCode = L some PHP code in UNICODE format...
hr = pasp-ParseScriptText(pwszCode, 0, 0, 0, 0, 0,
SCRIPTTEXT_ISPERSISTENT,
0, ei);
...
}
CoUninitialize();
Expected result:
I expect the engine to unload imediately, quickly and with no crashes.
Actual result:
--
A diallog box with a crash report is shown:
Unhandled exception at 0x011aa455 in eval.exe: 0xC005: Access
violation reading location 0x019eceb8.
This is the call stack, maybe it could be helpful:
php5ts.dll!011aa455()
[Frames below may be incorrect and/or missing, no symbols loaded for
php5ts.dll]
php5ts.dll!011aa1a8()
php5ts.dll!011aa1c4()
php5ts.dll!01199a97()
php5ts.dll!01101f22()
php5ts.dll!011db5e6()
php5activescript.dll!10001fa2()
ntdll.dll!7c91056d()
kernel32.dll!7c80995a()
ntdll.dll!7c91056d()
msvcrt.dll!77c2c2de()
msvcrt.dll!77c2c2e3()
kernel32.dll!7c80996d()
MSCTFIME.IME!755d9c87()
MSCTFIME.IME!755d9fb8()
php5activescript.dll!10006611()
ntdll.dll!7c9011a7()
ntdll.dll!7c923f31()
ntdll.dll!7c96cd11()
ntdll.dll!7c910945()
ntdll.dll!7c91094e()
kernel32.dll!7c81cd76()
ntdll.dll!7c960af8()
ntdll.dll!7c960bf0()
ntdll.dll!7c960bcc()
ntdll.dll!7c91056d()
eval.exe!_free_base(void * pBlock=0x7ffddc00) Line 109 + 0x12
bytes C
ntdll.dll!7c90f0aa()
kernel32.dll!7c80e62b()
kernel32.dll!7c80e45c()
kernel32.dll!7c81cdee()
eval.exe!__crtExitProcess(int status=0) Line 684 C
eval.exe!doexit(int code=0, int quick=0, int retcaller=0) Line 596 +
0x9 bytes C
eval.exe!exit(int code=0) Line 398 + 0xd bytes C
eval.exe!__tmainCRTStartup() Line 333 C
eval.exe!mainCRTStartup() Line 196 C
kernel32.dll!7c816fd7()
--
Edit this bug report at http://bugs.php.net/?id=42232edit=1
#42232 [Opn-Bgs]: Crash after exit main() function
ID: 42232
Updated by: [EMAIL PROTECTED]
Reported By: filipski at mail dot md
-Status: Open
+Status: Bogus
Bug Type: Reproducible crash
Operating System: Windows
PHP Version: 5.2.4RC1
New Comment:
This is a PECL package, report bugs on it here instead:
http://pecl.php.net/bugs/report.php?package=PHPScript
Previous Comments:
[2007-08-07 09:50:05] filipski at mail dot md
summary edit
[2007-08-07 09:49:16] filipski at mail dot md
Description:
A problem with php5activescript.dll
I created a new Win32 Console application in VisualStudio2005.
Everything runs fine until the very end. But after returning from
function main() the program waits some time and crashes.
So, it:
1. It unload slowly
2. It crashes
When doing the same with Python, PerlScript, JScript, VBScript there is
no problem after the function main exits. The program runs fine, invokes
the script dispatch functions, exits ok, quick and with no crashes.
BTW after the program ends, the engine unloads very slowly. Much slower
than other engines I tried Python, PerlScript, JScript, VBScript.
Reproduce code:
---
int main(){...CoInitialize();...{
IActiveScriptSite* pSite = new MyActiveScriptSite();
CComPtrIActiveScript pas;
CComPtrIDispatch pDisp;
HRESULT hr;
CComPtrIActiveScriptParse pasp;
hr = pasp.CoCreateInstance(LPHPScript, 0, CLSCTX_ALL);
hr = pasp-InitNew();
hr = pasp-QueryInterface(pas);
hr = pas-SetScriptSite(pSite);
EXCEPINFO ei;
wchar_t *pwszCode = L some PHP code in UNICODE format...
hr = pasp-ParseScriptText(pwszCode, 0, 0, 0, 0, 0,
SCRIPTTEXT_ISPERSISTENT,
0, ei);
...
}
CoUninitialize();
Expected result:
I expect the engine to unload imediately, quickly and with no crashes.
Actual result:
--
A diallog box with a crash report is shown:
Unhandled exception at 0x011aa455 in eval.exe: 0xC005: Access
violation reading location 0x019eceb8.
This is the call stack, maybe it could be helpful:
php5ts.dll!011aa455()
[Frames below may be incorrect and/or missing, no symbols loaded for
php5ts.dll]
php5ts.dll!011aa1a8()
php5ts.dll!011aa1c4()
php5ts.dll!01199a97()
php5ts.dll!01101f22()
php5ts.dll!011db5e6()
php5activescript.dll!10001fa2()
ntdll.dll!7c91056d()
kernel32.dll!7c80995a()
ntdll.dll!7c91056d()
msvcrt.dll!77c2c2de()
msvcrt.dll!77c2c2e3()
kernel32.dll!7c80996d()
MSCTFIME.IME!755d9c87()
MSCTFIME.IME!755d9fb8()
php5activescript.dll!10006611()
ntdll.dll!7c9011a7()
ntdll.dll!7c923f31()
ntdll.dll!7c96cd11()
ntdll.dll!7c910945()
ntdll.dll!7c91094e()
kernel32.dll!7c81cd76()
ntdll.dll!7c960af8()
ntdll.dll!7c960bf0()
ntdll.dll!7c960bcc()
ntdll.dll!7c91056d()
eval.exe!_free_base(void * pBlock=0x7ffddc00) Line 109 + 0x12
bytes C
ntdll.dll!7c90f0aa()
kernel32.dll!7c80e62b()
kernel32.dll!7c80e45c()
kernel32.dll!7c81cdee()
eval.exe!__crtExitProcess(int status=0) Line 684 C
eval.exe!doexit(int code=0, int quick=0, int retcaller=0) Line 596 +
0x9 bytes C
eval.exe!exit(int code=0) Line 398 + 0xd bytes C
eval.exe!__tmainCRTStartup() Line 333 C
eval.exe!mainCRTStartup() Line 196 C
kernel32.dll!7c816fd7()
--
Edit this bug report at http://bugs.php.net/?id=42232edit=1
#42232 [Bgs-Csd]: Crash after exit main() function
ID: 42232
User updated by: filipski at mail dot md
Reported By: filipski at mail dot md
-Status: Bogus
+Status: Closed
Bug Type: Reproducible crash
Operating System: Windows
PHP Version: 5.2.4RC1
New Comment:
Thanks, I just have reported on PHP Script
Previous Comments:
[2007-08-07 10:16:19] [EMAIL PROTECTED]
This is a PECL package, report bugs on it here instead:
http://pecl.php.net/bugs/report.php?package=PHPScript
[2007-08-07 09:50:05] filipski at mail dot md
summary edit
[2007-08-07 09:49:16] filipski at mail dot md
Description:
A problem with php5activescript.dll
I created a new Win32 Console application in VisualStudio2005.
Everything runs fine until the very end. But after returning from
function main() the program waits some time and crashes.
So, it:
1. It unload slowly
2. It crashes
When doing the same with Python, PerlScript, JScript, VBScript there is
no problem after the function main exits. The program runs fine, invokes
the script dispatch functions, exits ok, quick and with no crashes.
BTW after the program ends, the engine unloads very slowly. Much slower
than other engines I tried Python, PerlScript, JScript, VBScript.
Reproduce code:
---
int main(){...CoInitialize();...{
IActiveScriptSite* pSite = new MyActiveScriptSite();
CComPtrIActiveScript pas;
CComPtrIDispatch pDisp;
HRESULT hr;
CComPtrIActiveScriptParse pasp;
hr = pasp.CoCreateInstance(LPHPScript, 0, CLSCTX_ALL);
hr = pasp-InitNew();
hr = pasp-QueryInterface(pas);
hr = pas-SetScriptSite(pSite);
EXCEPINFO ei;
wchar_t *pwszCode = L some PHP code in UNICODE format...
hr = pasp-ParseScriptText(pwszCode, 0, 0, 0, 0, 0,
SCRIPTTEXT_ISPERSISTENT,
0, ei);
...
}
CoUninitialize();
Expected result:
I expect the engine to unload imediately, quickly and with no crashes.
Actual result:
--
A diallog box with a crash report is shown:
Unhandled exception at 0x011aa455 in eval.exe: 0xC005: Access
violation reading location 0x019eceb8.
This is the call stack, maybe it could be helpful:
php5ts.dll!011aa455()
[Frames below may be incorrect and/or missing, no symbols loaded for
php5ts.dll]
php5ts.dll!011aa1a8()
php5ts.dll!011aa1c4()
php5ts.dll!01199a97()
php5ts.dll!01101f22()
php5ts.dll!011db5e6()
php5activescript.dll!10001fa2()
ntdll.dll!7c91056d()
kernel32.dll!7c80995a()
ntdll.dll!7c91056d()
msvcrt.dll!77c2c2de()
msvcrt.dll!77c2c2e3()
kernel32.dll!7c80996d()
MSCTFIME.IME!755d9c87()
MSCTFIME.IME!755d9fb8()
php5activescript.dll!10006611()
ntdll.dll!7c9011a7()
ntdll.dll!7c923f31()
ntdll.dll!7c96cd11()
ntdll.dll!7c910945()
ntdll.dll!7c91094e()
kernel32.dll!7c81cd76()
ntdll.dll!7c960af8()
ntdll.dll!7c960bf0()
ntdll.dll!7c960bcc()
ntdll.dll!7c91056d()
eval.exe!_free_base(void * pBlock=0x7ffddc00) Line 109 + 0x12
bytes C
ntdll.dll!7c90f0aa()
kernel32.dll!7c80e62b()
kernel32.dll!7c80e45c()
kernel32.dll!7c81cdee()
eval.exe!__crtExitProcess(int status=0) Line 684 C
eval.exe!doexit(int code=0, int quick=0, int retcaller=0) Line 596 +
0x9 bytes C
eval.exe!exit(int code=0) Line 398 + 0xd bytes C
eval.exe!__tmainCRTStartup() Line 333 C
eval.exe!mainCRTStartup() Line 196 C
kernel32.dll!7c816fd7()
--
Edit this bug report at http://bugs.php.net/?id=42232edit=1
#42225 [Opn-Bgs]: XML Parser or array is not return characters back before a accent
ID: 42225
Updated by: [EMAIL PROTECTED]
Reported By: tcreamean at starsolutionsllc dot com
-Status: Open
+Status: Bogus
Bug Type: *XML functions
Operating System: gentoo
PHP Version: 5.2.4RC1
New Comment:
Thank you for taking the time to write to us, but this is not
a bug. Please double-check the documentation available at
http://www.php.net/manual/ and the instructions on how to report
a bug at http://bugs.php.net/how-to-report.php
A quick search of the bugs would have told you character data can be
chunked, so might not come all at once to the handler.
Previous Comments:
[2007-08-06 20:35:50] tcreamean at starsolutionsllc dot com
Description:
When I parse a xml file with fopen with latian accents it returns the
word chopped off in php 5.2.3.
So Austrália comes back on the web page like this ália in 5.2.3.
When I downgraded to 4.4.7 all is working great Austrália comes back as
Austrália.
Reproduce code:
---
?xml version=1.0 encoding=ISO-8859-1?
accessNumbers
accessCntry
countryNameAlemanha/countryName
countryID96/countryID
dialingCode49/dialingCode
/accessCntry
accessCntry
countryNameArgentina/countryName
countryID14/countryID
dialingCode54/dialingCode
/accessCntry
accessCntry
countryNameAustrália/countryName
countryID20/countryID
dialingCode61/dialingCode
/accessCntry
/accessNumbers
?php
if
(!([EMAIL
PROTECTED](http://xml.cordiaip.com/?ixAcct=accessNumbersCountrieslangId=3,r;)))
die (Couldn't open XML.);
$usercount=0;
$userdata=array();
$state='';
if (!($xml_parser = xml_parser_create('iso-8859-1'))) die(Couldn't
create parser.);
//xml_parser_set_option($fp, XML_OPTION_CASE_FOLDING, 0);
//xml_parser_set_option($fp, XML_OPTION_SKIP_WHITE, 1);
function startElementHandler ($parser,$element,$attrib){
global $usercount, $userdata, $state;
switch ($element) {
case $element==ACCESSCNTRY : {
$userdata[$usercount][id] = $attrib[ID];
break;
}
default : {
$state = $element;
break;
}
}
}
function endElementHandler ($parser,$element){
global $usercount, $userdata, $state;
$state='';
if($element==ACCESSCNTRY) {
$usercount++;
}
}
function characterDataHandler ($parser, $data) {
global $usercount, $userdata, $state;
if (!$state) {
return;
}
if ($state == COUNTRYNAME) {
$userdata[$usercount][countryname] = $data;
}
if ($state == COUNTRYID) {
$userdata[$usercount][countryID] = $data;
}
}
xml_set_element_handler($xml_parser,startElementHandler,endElementHandler);
xml_set_character_data_handler( $xml_parser, characterDataHandler);
while( $data = fread($fp, 8192)){
if(!xml_parse($xml_parser, $data, feof($fp))) {
break;
}
}
xml_parser_free($xml_parser);
for ($i=0;$i$usercount; $i++) {
$x = $i+1;
echo $userdata[$i][countryID];
echo $userdata[$i][countryname];
}
?
--
Edit this bug report at http://bugs.php.net/?id=42225edit=1
#31114 [Com]: foreach modify array (works with PHP 5.1)
ID: 31114
Comment by: fedotov dot leon at gmail dot com
Reported By: clemens at gutweiler dot net
Status: Assigned
Bug Type: Arrays related
Operating System: Linux 2.4.27
PHP Version: 4CVS
Assigned To: andi
New Comment:
I stumbled across another werd behavior related to this bug:
[php]
$var = array(
a = array(foo),
b = array(fox),
c = x
);
foreach($var as $key = $val) {
echo no matter what happends.$val;
}
/* $var is array(
a = array(foo),
b = array(fox),
c = foo
);
*/
[/php]
Previous Comments:
[2005-05-17 12:01:49] [EMAIL PROTECTED]
Works fine in PHP 5..
[2004-12-16 22:32:14] [EMAIL PROTECTED]
I just tested this on PHP 4.3.1 and 4.3.2 and it behaves in the same
way, making this a non-critical bug and not related to the foreach
speed-up patch. Assigning to Andi, as he might have a clue why this
happens. The new foreach code is definitely not the problem here.
[2004-12-16 13:07:17] [EMAIL PROTECTED]
(The only bug here is that it doesn't give a warning, using $k for both
key and value is not supposed to work!)
[2004-12-16 11:41:54] [EMAIL PROTECTED]
I don't think this was ever supposed to work.
[2004-12-16 10:44:05] clemens at gutweiler dot net
Description:
foreach modifies an array, if key and value are the same variable.
see reproduction code.
Reproduce code:
---
?php
$foo = array( 'foo' = 'bar', 'dings' = 'dongs' );
foreach( $foo as $k = $k ) {}
var_dump( $foo );
?
array(2) {
[foo]=
string(5) dings
[dings]=
NULL
}
Expected result:
array(2) {
[foo]=
string(3) bar
[dings]=
string(5) dongs
}
--
Edit this bug report at http://bugs.php.net/?id=31114edit=1
#42198 [Opn-Fbk]: SCRIPT_NAME and PHP_SELF truncated when inside a userdir and using PATH_INFO
ID: 42198
Updated by: [EMAIL PROTECTED]
Reported By: hans at parse dot nl
-Status: Open
+Status: Feedback
Bug Type: CGI related
Operating System: Linux
PHP Version: 5.2.4RC1
New Comment:
You patch does not fix the issue for anything but the userdir module
and in a very hackish way. For the aliasing part of your (saw your
example on the lighttpd bug report) it does not fix it at all.
When I debugged this I noticed this:
[PATH_TRANSLATED]=
string(17) /opt/www/foo/bar/
[SCRIPT_FILENAME]=
string(16) /home/jani/t.php
[DOCUMENT_ROOT]=
string(9) /opt/www/
[REQUEST_URI]=
string(17) /r/t.php/foo/bar/
Shouldn't DOCUMENT_ROOT be /home/jani/ in this case when it's the
alias? And PATH_TRANSLATED is also wrong..
Previous Comments:
[2007-08-07 09:23:00] hans at parse dot nl
A little more explanation fyi: The problem is that DOCUMENT_ROOT is
always set to the configured document root of the default host or the
vhost, even when calling scripts from a userdir. This is not just in
Lighttpd/FastCGI, also f.e. in Apache setups. In my testcase
DOCUMENT_ROOT is '/var/www/htdocs'.
So if i call http://servername/~hans/info.php/foo/bar , We enter this
bit of code in init_request_info() in sapi/cgi/cgi_main.c:
---
/* figure out docroot
SCRIPT_FILENAME minus SCRIPT_NAME
*/
if (env_document_root)
{
int l = strlen(env_document_root);
int path_translated_len = 0;
char *path_translated = NULL;
if (l env_document_root[l - 1] == '/') {
--l;
}
/* we have docroot, so we should have:
* DOCUMENT_ROOT=/docroot
* SCRIPT_FILENAME=/docroot/info.php
*
* SCRIPT_NAME is the portion of the path beyond docroot
*/
env_script_name = pt + l;
---
Since env_document_root is pretty much always set, we enter the if. pt
is '/home/hans/public_html/info.php' at this point (which is correct). l
becomes 15, the strlen of our DOCUMENT_ROOT '/var/www/htdocs'. The
trailing slash check if loop is skipped since our docroot doesn't have
a trailing slash. After this, SCRIPT_NAME is set to pt + l. pt being
'/home/hans/public_html/info.php' and l being 15, this results in a
invalid SCRIPT_NAME (and thus a PHP_SELF) of 'ic_html/info.php'.
My patch adds a userdir check to the 'if (env_document_root)', to
prevent from entering this if() with a DOCUMENT_ROOT that doesn't match
the actual docroot of the userdir. The code that follows after this if()
handles the userdir requests perfectly and results in correct
SCRIPT_NAME and PHP_SELF vars.
[2007-08-06 16:11:11] hans at parse dot nl
./configure --enable-cgi --enable-fastcgi --enable-force-cgi-redirect
--prefix=/usr --sysconfdir=/etc --with-config-file-path=/etc/php
--with-openssl --with-bz2 --with-gd --with-mysql --with-mysqli
--with-gettext --with-zlib --enable-mbstring --enable-sockets
--enable-sysvsem --enable-sysvshm --enable-debug=no
Direct link to my patch against php-5.2.3 on lighttpd Trac:
http://trac.lighttpd.net/trac/attachment/ticket/405/cgi_main.diff
[2007-08-06 15:45:15] [EMAIL PROTECTED]
What was the configure line used to configure PHP?
[2007-08-06 08:30:01] hans at parse dot nl
Yes, problem found initially in 5.2.3 but i tested and confirmed with
5.2.4RC1 before submitting this bug report.
Turning off cgi.fix_pathinfo results in a No input file specified.
message (url being http://servername/~hans/info.php/foo/bar).
[2007-08-04 14:14:24] [EMAIL PROTECTED]
Also, what is the result if cgi.fix_pathinfo = 0 ?
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/42198
--
Edit this bug report at http://bugs.php.net/?id=42198edit=1
#42198 [Fbk]: SCRIPT_NAME and PHP_SELF truncated when inside a userdir and using PATH_INFO
ID: 42198
Updated by: [EMAIL PROTECTED]
Reported By: hans at parse dot nl
Status: Feedback
Bug Type: CGI related
Operating System: Linux
PHP Version: 5.2.4RC1
New Comment:
Then again same happens with Apache too..
Previous Comments:
[2007-08-07 11:41:19] [EMAIL PROTECTED]
You patch does not fix the issue for anything but the userdir module
and in a very hackish way. For the aliasing part of your (saw your
example on the lighttpd bug report) it does not fix it at all.
When I debugged this I noticed this:
[PATH_TRANSLATED]=
string(17) /opt/www/foo/bar/
[SCRIPT_FILENAME]=
string(16) /home/jani/t.php
[DOCUMENT_ROOT]=
string(9) /opt/www/
[REQUEST_URI]=
string(17) /r/t.php/foo/bar/
Shouldn't DOCUMENT_ROOT be /home/jani/ in this case when it's the
alias? And PATH_TRANSLATED is also wrong..
[2007-08-07 09:23:00] hans at parse dot nl
A little more explanation fyi: The problem is that DOCUMENT_ROOT is
always set to the configured document root of the default host or the
vhost, even when calling scripts from a userdir. This is not just in
Lighttpd/FastCGI, also f.e. in Apache setups. In my testcase
DOCUMENT_ROOT is '/var/www/htdocs'.
So if i call http://servername/~hans/info.php/foo/bar , We enter this
bit of code in init_request_info() in sapi/cgi/cgi_main.c:
---
/* figure out docroot
SCRIPT_FILENAME minus SCRIPT_NAME
*/
if (env_document_root)
{
int l = strlen(env_document_root);
int path_translated_len = 0;
char *path_translated = NULL;
if (l env_document_root[l - 1] == '/') {
--l;
}
/* we have docroot, so we should have:
* DOCUMENT_ROOT=/docroot
* SCRIPT_FILENAME=/docroot/info.php
*
* SCRIPT_NAME is the portion of the path beyond docroot
*/
env_script_name = pt + l;
---
Since env_document_root is pretty much always set, we enter the if. pt
is '/home/hans/public_html/info.php' at this point (which is correct). l
becomes 15, the strlen of our DOCUMENT_ROOT '/var/www/htdocs'. The
trailing slash check if loop is skipped since our docroot doesn't have
a trailing slash. After this, SCRIPT_NAME is set to pt + l. pt being
'/home/hans/public_html/info.php' and l being 15, this results in a
invalid SCRIPT_NAME (and thus a PHP_SELF) of 'ic_html/info.php'.
My patch adds a userdir check to the 'if (env_document_root)', to
prevent from entering this if() with a DOCUMENT_ROOT that doesn't match
the actual docroot of the userdir. The code that follows after this if()
handles the userdir requests perfectly and results in correct
SCRIPT_NAME and PHP_SELF vars.
[2007-08-06 16:11:11] hans at parse dot nl
./configure --enable-cgi --enable-fastcgi --enable-force-cgi-redirect
--prefix=/usr --sysconfdir=/etc --with-config-file-path=/etc/php
--with-openssl --with-bz2 --with-gd --with-mysql --with-mysqli
--with-gettext --with-zlib --enable-mbstring --enable-sockets
--enable-sysvsem --enable-sysvshm --enable-debug=no
Direct link to my patch against php-5.2.3 on lighttpd Trac:
http://trac.lighttpd.net/trac/attachment/ticket/405/cgi_main.diff
[2007-08-06 15:45:15] [EMAIL PROTECTED]
What was the configure line used to configure PHP?
[2007-08-06 08:30:01] hans at parse dot nl
Yes, problem found initially in 5.2.3 but i tested and confirmed with
5.2.4RC1 before submitting this bug report.
Turning off cgi.fix_pathinfo results in a No input file specified.
message (url being http://servername/~hans/info.php/foo/bar).
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/42198
--
Edit this bug report at http://bugs.php.net/?id=42198edit=1
#37814 [Opn-WFx]: Php shoul have class friends
ID: 37814
Updated by: [EMAIL PROTECTED]
Reported By: henke dot andersson at comhem dot se
-Status: Open
+Status: Wont fix
Bug Type: Feature/Change Request
-Operating System: Linux Redhat 9
+Operating System: *
-PHP Version: 6CVS-2006-06-15 (CVS)
+PHP Version: *
New Comment:
We decided against those complex features.
Previous Comments:
[2007-08-06 22:29:49] michael at chunkycow dot com dot au
The whole C++ friends thing is a mess, use an interface between your
super friendly classes and simply don`t use it if the classes aren`t
joined at the hip, this would even help to keep nice low coupling and
aid re-use.
Private inner classes have some merit but are not a cure for common
sense.
[2006-06-15 10:33:27] henke dot andersson at comhem dot se
Description:
Php should have a friend structure for classes, like c++.
That way some normaly private things can be used by selected other
classes and functions.
An alternative would be to do it like Java with inner classes, but
personaly I think that while inner classes could be usefull in php,
friend classes should also exist like in c++.
Reproduce code:
---
?php
//my suggestion for the syntax
class A {
static function callB(B $b) {
$b-privatefunction();
}
}
class B {
friend class A;
friend function C;
private function privatefunction() {
echo 'privatefunction!';
}
}
function C(B $b) {
$b-privatefunction();
}
$b=new B();
A::callB($b);
C($b);
Expected result:
Class A and function C should be able to call B::privatefunction.
Actual result:
--
Since this functionality doesn't exist the code wont even compile.
--
Edit this bug report at http://bugs.php.net/?id=37814edit=1
#42198 [Fbk-Opn]: SCRIPT_NAME and PHP_SELF truncated when inside a userdir and using PATH_INFO
ID: 42198
User updated by: hans at parse dot nl
Reported By: hans at parse dot nl
-Status: Feedback
+Status: Open
Bug Type: CGI related
Operating System: Linux
PHP Version: 5.2.4RC1
New Comment:
Heh i was pondering and typing a apache2handler example and then i saw
your Apache comment. Here it is anyway:
--
Yes i agree, my patch is kinda hacky but solved my personal userdir
problem ;) The alias problem was someone else's which i overlooked.
Your alias example suffers from the same problem as userdirs, being
that the DOCUMENT_ROOT always points to the docroot of the host, but as
i already pointed out, this is also the case in apache/mod_php5 or
apache2handler, not just cgi-fcgi.
apache2handler actually is an even bigger mess :) for example:
request: http://www.site.com/~hans/info.php/foo/bar
result:
_SERVER[DOCUMENT_ROOT]/var/www/site.com/www/htdocs
_SERVER[REQUEST_URI] /~hans/info.php/foo/bar
_SERVER[SCRIPT_NAME] /~hans/info.php
_SERVER[PATH_INFO]/foo/bar
_SERVER[PATH_TRANSLATED] /var/www/site.com/www/htdocs/foo/bar
_SERVER[PHP_SELF] /~hans/info.php/foo/bar
Not really consistent, and also an invalid PATH_TRANSLATED, and
PATH_INFO added to PHP_SELF ?!
Anyway, back to Lighttpd. I'll try to whip up a less hacky fix that
also handles the aliases.
Previous Comments:
[2007-08-07 11:51:55] [EMAIL PROTECTED]
Then again same happens with Apache too..
[2007-08-07 11:41:19] [EMAIL PROTECTED]
You patch does not fix the issue for anything but the userdir module
and in a very hackish way. For the aliasing part of your (saw your
example on the lighttpd bug report) it does not fix it at all.
When I debugged this I noticed this:
[PATH_TRANSLATED]=
string(17) /opt/www/foo/bar/
[SCRIPT_FILENAME]=
string(16) /home/jani/t.php
[DOCUMENT_ROOT]=
string(9) /opt/www/
[REQUEST_URI]=
string(17) /r/t.php/foo/bar/
Shouldn't DOCUMENT_ROOT be /home/jani/ in this case when it's the
alias? And PATH_TRANSLATED is also wrong..
[2007-08-07 09:23:00] hans at parse dot nl
A little more explanation fyi: The problem is that DOCUMENT_ROOT is
always set to the configured document root of the default host or the
vhost, even when calling scripts from a userdir. This is not just in
Lighttpd/FastCGI, also f.e. in Apache setups. In my testcase
DOCUMENT_ROOT is '/var/www/htdocs'.
So if i call http://servername/~hans/info.php/foo/bar , We enter this
bit of code in init_request_info() in sapi/cgi/cgi_main.c:
---
/* figure out docroot
SCRIPT_FILENAME minus SCRIPT_NAME
*/
if (env_document_root)
{
int l = strlen(env_document_root);
int path_translated_len = 0;
char *path_translated = NULL;
if (l env_document_root[l - 1] == '/') {
--l;
}
/* we have docroot, so we should have:
* DOCUMENT_ROOT=/docroot
* SCRIPT_FILENAME=/docroot/info.php
*
* SCRIPT_NAME is the portion of the path beyond docroot
*/
env_script_name = pt + l;
---
Since env_document_root is pretty much always set, we enter the if. pt
is '/home/hans/public_html/info.php' at this point (which is correct). l
becomes 15, the strlen of our DOCUMENT_ROOT '/var/www/htdocs'. The
trailing slash check if loop is skipped since our docroot doesn't have
a trailing slash. After this, SCRIPT_NAME is set to pt + l. pt being
'/home/hans/public_html/info.php' and l being 15, this results in a
invalid SCRIPT_NAME (and thus a PHP_SELF) of 'ic_html/info.php'.
My patch adds a userdir check to the 'if (env_document_root)', to
prevent from entering this if() with a DOCUMENT_ROOT that doesn't match
the actual docroot of the userdir. The code that follows after this if()
handles the userdir requests perfectly and results in correct
SCRIPT_NAME and PHP_SELF vars.
[2007-08-06 16:11:11] hans at parse dot nl
./configure --enable-cgi --enable-fastcgi --enable-force-cgi-redirect
--prefix=/usr --sysconfdir=/etc --with-config-file-path=/etc/php
--with-openssl --with-bz2 --with-gd --with-mysql --with-mysqli
--with-gettext --with-zlib --enable-mbstring --enable-sockets
--enable-sysvsem --enable-sysvshm --enable-debug=no
Direct link to my patch against php-5.2.3 on lighttpd Trac:
http://trac.lighttpd.net/trac/attachment/ticket/405/cgi_main.diff
[2007-08-06 15:45:15] [EMAIL PROTECTED]
What was the configure line used to configure PHP?
The remainder of the comments for this report are too long. To view
the rest of the comments, please view the bug
#42226 [Opn-Fbk]: microtime is not save under windows
ID: 42226
Updated by: [EMAIL PROTECTED]
Reported By: bjoern at xrow dot de
-Status: Open
+Status: Feedback
Bug Type: Date/time related
Operating System: Windows
PHP Version: 5.2.4RC1
New Comment:
Have you tried calling microtime(1) -- this returns you a floating
point number directly.
Previous Comments:
[2007-08-06 22:04:47] bjoern at xrow dot de
Description:
This bug occurs under php4 and php5.
It might occur that the micro time might output a date older then the
date it had output before.
php5 does worse then php4.
Reproduce code:
---
?php
$last = null;
for ($i=1;$i=10;$i++)
{
list($micro,$time)=explode( ,microtime());
$add=$micro+$time;
if ( $last !== null )
print ($add$last ? 'Run '.$i.' Last:'.$last.'
-Current:'.$add.\r\n : '');
$last=$add;
}
?
Expected result:
C:\workspacephp microtimebug.php
(nothing)
C:\workspaceC:\php5\php.exe microtimebug.php
(nothing)
Actual result:
--
C:\workspacephp microtimebug.php
Run 2690 Last:1186437375.2899 -Current:1186437374.2495
Run 23377 Last:1186437375.4714 -Current:1186437374.437
Run 30341 Last:1186437375.534 -Current:1186437374.4995
Run 36083 Last:1186437375.5787 -Current:1186437374.5464
Run 49990 Last:1186437375.6881 -Current:1186437374.6557
Run 62669 Last:1186437375.7984 -Current:1186437374.7651
Run 68143 Last:1186437375.8433 -Current:1186437374.7964
Run 75918 Last:1186437375.8971 -Current:1186437374.8745
Run 82398 Last:1186437375.9586 -Current:1186437374.9214
Run 90123 Last:1186437376.0163 -Current:1186437374.9839
Run 99605 Last:1186437376.0827 -Current:1186437375.062
C:\workspaceC:\php5\php.exe microtimebug.php
Run 11 Last:1186436769.93 -Current:1186436768.89
Run 260 Last:1186436769.96 -Current:1186436768.92
Run 998 Last:1186436770.04 -Current:1186436769
Run 1392 Last:1186436770.08 -Current:1186436769.05
Run 2180 Last:1186436770.17 -Current:1186436769.14
Run 3123 Last:1186436770.27 -Current:1186436769.25
Run 3657 Last:1186436770.34 -Current:1186436769.31
Run 4137 Last:1186436770.4 -Current:1186436769.36
Run 4514 Last:1186436770.44 -Current:1186436769.41
Run 4900 Last:1186436770.47 -Current:1186436769.45
Run 5317 Last:1186436770.53 -Current:1186436769.5
Run 5639 Last:1186436770.56 -Current:1186436769.53
Run 6138 Last:1186436770.62 -Current:1186436769.59
Run 6299 Last:1186436770.63 -Current:1186436769.61
Run 7112 Last:1186436770.73 -Current:1186436769.7
Run 7402 Last:1186436770.77 -Current:1186436769.73
Run 8066 Last:1186436770.85 -Current:1186436769.81
Run 8496 Last:1186436770.9 -Current:1186436769.86
Run 8904 Last:1186436770.94 -Current:1186436769.91
Run 9161 Last:1186436770.97 -Current:1186436769.94
Run 9971 Last:1186436771.07 -Current:1186436770.03
Run 10375 Last:1186436771.12 -Current:1186436770.08
Run 10738 Last:1186436771.16 -Current:1186436770.12
Run 10950 Last:1186436771.18 -Current:1186436770.14
Run 11612 Last:1186436771.26 -Current:1186436770.22
Run 11819 Last:1186436771.27 -Current:1186436770.25
Run 12361 Last:1186436771.33 -Current:1186436770.31
Run 12690 Last:1186436771.38 -Current:1186436770.34
Run 13394 Last:1186436771.46 -Current:1186436770.42
Run 13677 Last:1186436771.49 -Current:1186436770.45
Run 13728 Last:1186436771.5 -Current:1186436770.47
Run 14085 Last:1186436771.53 -Current:1186436770.5
Run 14553 Last:1186436771.58 -Current:1186436770.56
Run 14636 Last:1186436771.6 -Current:1186436770.56
Run 14978 Last:1186436771.65 -Current:1186436770.61
Run 15380 Last:1186436771.69 -Current:1186436770.66
Run 15750 Last:1186436771.73 -Current:1186436770.7
Run 16024 Last:1186436771.77 -Current:1186436770.73
Run 16719 Last:1186436771.84 -Current:1186436770.81
Run 17586 Last:1186436771.94 -Current:1186436770.91
Run 18366 Last:1186436772.03 -Current:1186436771
Run 18911 Last:1186436772.09 -Current:1186436771.06
Run 19178 Last:1186436772.13 -Current:1186436771.09
Run 19516 Last:1186436772.16 -Current:1186436771.12
Run 19743 Last:1186436772.19 -Current:1186436771.16
Run 20118 Last:1186436772.23 -Current:1186436771.19
Run 20527 Last:1186436772.27 -Current:1186436771.23
Run 21095 Last:1186436772.34 -Current:1186436771.31
Run 21526 Last:1186436772.39 -Current:1186436771.36
Run 22115 Last:1186436772.46 -Current:1186436771.42
Run 22320 Last:1186436772.49 -Current:1186436771.45
Run 23076 Last:1186436772.56 -Current:1186436771.53
Run 23278 Last:1186436772.6 -Current:1186436771.56
Run 23943 Last:1186436772.67 -Current:1186436771.64
Run 24733 Last:1186436772.75 -Current:1186436771.73
Run 25046 Last:1186436772.79 -Current:1186436771.77
Run 25635 Last:1186436772.87 -Current:1186436771.83
Run 25839 Last:1186436772.88 -Current:1186436771.86
Run 26264 Last:1186436772.94 -Current:1186436771.91
Run 27403 Last:1186436773.07 -Current:1186436772.03
Run 27747 Last:1186436773.1 -Current:1186436772.08
Run 28045 Last:1186436773.14 -Current:1186436772.11
Run
#42211 [Opn-Asn]: property_exists() fails to find protected properties from a parent class
ID: 42211
Updated by: [EMAIL PROTECTED]
Reported By: dominics at gmail dot com
-Status: Open
+Status: Assigned
Bug Type: Class/Object related
Operating System: *
PHP Version: 5.2.4RC1
-Assigned To:
+Assigned To: dmitry
Previous Comments:
[2007-08-05 23:07:45] crrodriguez at suse dot de
If this is not a bug, there is a bug in the documentation ;)
--TEST--
#42211 property_exists( ) fails to find protected properties from a
parent class
--FILE--
?php
class A {
function foo() {
echo __CLASS__ .\n;
var_dump(property_exists('B', 'publicBar'));
var_dump(property_exists('B', 'protectedBar'));
var_dump(property_exists('B', 'privateBar'));
}
}
class B extends A {
public $publicBar;
protected $protectedBar;
private $privateBar;
function __construct()
{echo __CLASS__ .\n;
var_dump(property_exists('B', 'publicBar'));
var_dump(property_exists('B', 'protectedBar'));
var_dump(property_exists('B', 'privateBar'));
}
}
$b = new B();
$b-foo();
echo No scope\n;
var_dump(property_exists('B', 'publicBar'));
var_dump(property_exists('B', 'protectedBar'));
var_dump(property_exists('B', 'privateBar'));
?
--EXPECT--
B
bool(true)
bool(true)
bool(true)
A
bool(true)
bool(true)
bool(false)
No scope
bool(true)
bool(false)
bool(false)
Index: Zend/zend_builtin_functions.c
===
RCS file: /repository/ZendEngine2/zend_builtin_functions.c,v
retrieving revision 1.277.2.12.2.22
diff -u -p -r1.277.2.12.2.22 zend_builtin_functions.c
--- Zend/zend_builtin_functions.c 2 Aug 2007 20:32:44 -
1.277.2.12.2.22
+++ Zend/zend_builtin_functions.c 5 Aug 2007 23:06:02 -
@@ -974,7 +974,7 @@ ZEND_FUNCTION(property_exists)
if (!(property_info = zend_get_property_info(ce,
*property, 1 TSRMLS_CC)) || property_info == EG(std_property_info)) {
RETURN_FALSE;
}
- if (property_info-flags ZEND_ACC_PUBLIC) {
+ if (property_info-flags ZEND_ACC_PUBLIC ||
((property_info-flags ZEND_ACC_PROTECTED)
zend_check_protected(property_info-ce, EG(scope {
RETURN_TRUE;
}
zend_unmangle_property_name(property_info-name,
property_info-name_length, class_name, prop_name);
ps: will be nice to have a attachment feature
Cheers
Cristian (aka judas_isc ;) )
[2007-08-05 14:14:36] dominics at gmail dot com
Description:
When using property_exists() from a parent class, and checking for the
existence of a protected property in the subclass, property_exists()
fails to find the property.
The documentation for property_exists() says that the property must be
'accessible from the current scope'. In this case, the property _is_,
because A is a parent class and protected visibility is defined in the
documentation as 'limits access to inherited and parent classes'.
As further evidence that protectedBar is accessible from foo(), trying
to manipulate privateBar causes an error, while manipulating
protectedBar doesn't.
Reproduce code:
---
?php
class A {
function foo() {
var_dump(property_exists('B', 'publicBar'));
var_dump(property_exists('B', 'protectedBar'));
var_dump(property_exists('B', 'privateBar'));
}
}
class B extends A {
public $publicBar;
protected $protectedBar;
private $privateBar;
}
$b = new B();
$b-foo();
Expected result:
bool(true) bool(true) bool(false)
Actual result:
--
bool(true) bool(false) bool(false)
--
Edit this bug report at http://bugs.php.net/?id=42211edit=1
#31892 [NoF-Fbk]: PHP_SELF incorrect without cgi.fix_pathinfo, but turning on screws up PATH_INFO
ID: 31892
Updated by: [EMAIL PROTECTED]
Reported By: ceefour at gauldong dot net
-Status: No Feedback
+Status: Feedback
Bug Type: CGI related
Operating System: *
PHP Version: 5CVS, 4CVS (2005-02-11)
New Comment:
This patch (against latest CVS checkout of PHP_5_2 branch) should fix
the issues with PHP_SELF/PATH_INFO/etc. I tested under Apache 2 and it
works fine now:
http://pecl.php.net/~jani/patches/bug_31892.patch
Please test it ASAP! We're about to roll 5.2.4 and it would be really
nice to fix this issue once and for all..
Previous Comments:
[2007-07-26 19:18:25] mccammos at onid dot oregonstate dot edu
I just tried a July 26, 2007 snapshot of php5.2 and can report that the
bug still remains unfixed.
[2007-07-18 01:00:00] php-bugs at lists dot php dot net
No feedback was provided for this bug for over a week, 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.
[2007-07-10 11:34:53] [EMAIL PROTECTED]
Please try using this CVS snapshot:
http://snaps.php.net/php5.2-latest.tar.gz
For Windows (zip):
http://snaps.php.net/win32/php5.2-win32-latest.zip
For Windows (installer):
http://snaps.php.net/win32/php5.2-win32-installer-latest.msi
[2006-05-29 18:47:35] php dot net at jon dot limedaley dot com
I assume this isn't going to be fixed? since it has been a year since
it was reported, and it is still in the verified state.
I figured php5 would be stable by now, but it appears that php_self is
broken with cgi.fix_pathinfo=0 and _SERVER[PATH_INFO] is broken with
cgi.fix_pathinfo=1.
Is the official solution to use php4 instead?
[2006-05-11 14:34:54] kk at keppler-it dot de
These patches are based on the code from Dave; the work fine within our
hosting environment.
http://www.keppler-it.de/tmp/patch-31892-4.4.2.diff
http://www.keppler-it.de/tmp/patch-31892-5.1.4.diff
Comments welcome. :-)
Here's the code in clear text (nearly identical for 4.x and 5.x):
--- php-4.4.2/sapi/cgi/cgi_main.c.orig 2006-01-01 14:47:01.0
+0100
+++ php-4.4.2/sapi/cgi/cgi_main.c 2006-05-11 16:23:51.0
+0200
@@ -871,11 +871,25 @@
} else {
#endif
/* pre 4.3 behaviour, shouldn't be used but
provides BC */
+ /*
if (env_path_info) {
SG(request_info).request_uri =
env_path_info;
} else {
SG(request_info).request_uri =
env_script_name;
}
+ */
+ /* [EMAIL PROTECTED] PHP_SELF := SCRIPT_NAME +
PATH_INFO */
+ /* Patch based upon
http://spoonguard.org/dave/classes/cs345/bugfix/php-5.1.2-31892.diff */
+ SG(request_info).request_uri =
sapi_cgibin_getenv(SCRIPT_NAME, 0 TSRMLS_CC);
+ if (SG(request_info).request_uri
(env_path_info = sapi_cgibin_getenv(PATH_INFO, 0 TSRMLS_CC))) {
+ int request_uri_len =
strlen(SG(request_info).request_uri) + strlen(env_path_info) + 1;
+ char *request_uri = (char *)
emalloc(request_uri_len);
+ *request_uri = '\0';
+ strcat(request_uri,
SG(request_info).request_uri);
+ strcat(request_uri, env_path_info);
+ SG(request_info).request_uri =
request_uri;
+ }
+ /* /kk */
#if !DISCARD_PATH
if (env_path_translated)
script_path_translated =
env_path_translated;
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/31892
--
Edit this bug report at http://bugs.php.net/?id=31892edit=1
#42226 [Fbk-Opn]: microtime is not save under windows
ID: 42226
User updated by: bjoern at xrow dot de
Reported By: bjoern at xrow dot de
-Status: Feedback
+Status: Open
Bug Type: Date/time related
Operating System: Windows
PHP Version: 5.2.4RC1
New Comment:
Here is the script with the additional param. It works as expected.
Unfortunatelly php4 doesn`t have this param so this seems to be only a
workaround for php5.
?php
// only use this on windows! Linux/Unix is not affected.
$last = null;
for ($i=1;$i=10;$i++)
{
$add=microtime(1);
if ( $last !== null )
print ($add$last ? 'Run '.$i.' Last:'.$last.'
-Current:'.$add.\r\n : '');
$last=$add;
}
?
Previous Comments:
[2007-08-07 12:51:49] [EMAIL PROTECTED]
Have you tried calling microtime(1) -- this returns you a floating
point number directly.
[2007-08-06 22:04:47] bjoern at xrow dot de
Description:
This bug occurs under php4 and php5.
It might occur that the micro time might output a date older then the
date it had output before.
php5 does worse then php4.
Reproduce code:
---
?php
$last = null;
for ($i=1;$i=10;$i++)
{
list($micro,$time)=explode( ,microtime());
$add=$micro+$time;
if ( $last !== null )
print ($add$last ? 'Run '.$i.' Last:'.$last.'
-Current:'.$add.\r\n : '');
$last=$add;
}
?
Expected result:
C:\workspacephp microtimebug.php
(nothing)
C:\workspaceC:\php5\php.exe microtimebug.php
(nothing)
Actual result:
--
C:\workspacephp microtimebug.php
Run 2690 Last:1186437375.2899 -Current:1186437374.2495
Run 23377 Last:1186437375.4714 -Current:1186437374.437
Run 30341 Last:1186437375.534 -Current:1186437374.4995
Run 36083 Last:1186437375.5787 -Current:1186437374.5464
Run 49990 Last:1186437375.6881 -Current:1186437374.6557
Run 62669 Last:1186437375.7984 -Current:1186437374.7651
Run 68143 Last:1186437375.8433 -Current:1186437374.7964
Run 75918 Last:1186437375.8971 -Current:1186437374.8745
Run 82398 Last:1186437375.9586 -Current:1186437374.9214
Run 90123 Last:1186437376.0163 -Current:1186437374.9839
Run 99605 Last:1186437376.0827 -Current:1186437375.062
C:\workspaceC:\php5\php.exe microtimebug.php
Run 11 Last:1186436769.93 -Current:1186436768.89
Run 260 Last:1186436769.96 -Current:1186436768.92
Run 998 Last:1186436770.04 -Current:1186436769
Run 1392 Last:1186436770.08 -Current:1186436769.05
Run 2180 Last:1186436770.17 -Current:1186436769.14
Run 3123 Last:1186436770.27 -Current:1186436769.25
Run 3657 Last:1186436770.34 -Current:1186436769.31
Run 4137 Last:1186436770.4 -Current:1186436769.36
Run 4514 Last:1186436770.44 -Current:1186436769.41
Run 4900 Last:1186436770.47 -Current:1186436769.45
Run 5317 Last:1186436770.53 -Current:1186436769.5
Run 5639 Last:1186436770.56 -Current:1186436769.53
Run 6138 Last:1186436770.62 -Current:1186436769.59
Run 6299 Last:1186436770.63 -Current:1186436769.61
Run 7112 Last:1186436770.73 -Current:1186436769.7
Run 7402 Last:1186436770.77 -Current:1186436769.73
Run 8066 Last:1186436770.85 -Current:1186436769.81
Run 8496 Last:1186436770.9 -Current:1186436769.86
Run 8904 Last:1186436770.94 -Current:1186436769.91
Run 9161 Last:1186436770.97 -Current:1186436769.94
Run 9971 Last:1186436771.07 -Current:1186436770.03
Run 10375 Last:1186436771.12 -Current:1186436770.08
Run 10738 Last:1186436771.16 -Current:1186436770.12
Run 10950 Last:1186436771.18 -Current:1186436770.14
Run 11612 Last:1186436771.26 -Current:1186436770.22
Run 11819 Last:1186436771.27 -Current:1186436770.25
Run 12361 Last:1186436771.33 -Current:1186436770.31
Run 12690 Last:1186436771.38 -Current:1186436770.34
Run 13394 Last:1186436771.46 -Current:1186436770.42
Run 13677 Last:1186436771.49 -Current:1186436770.45
Run 13728 Last:1186436771.5 -Current:1186436770.47
Run 14085 Last:1186436771.53 -Current:1186436770.5
Run 14553 Last:1186436771.58 -Current:1186436770.56
Run 14636 Last:1186436771.6 -Current:1186436770.56
Run 14978 Last:1186436771.65 -Current:1186436770.61
Run 15380 Last:1186436771.69 -Current:1186436770.66
Run 15750 Last:1186436771.73 -Current:1186436770.7
Run 16024 Last:1186436771.77 -Current:1186436770.73
Run 16719 Last:1186436771.84 -Current:1186436770.81
Run 17586 Last:1186436771.94 -Current:1186436770.91
Run 18366 Last:1186436772.03 -Current:1186436771
Run 18911 Last:1186436772.09 -Current:1186436771.06
Run 19178 Last:1186436772.13 -Current:1186436771.09
Run 19516 Last:1186436772.16 -Current:1186436771.12
Run 19743 Last:1186436772.19 -Current:1186436771.16
Run 20118 Last:1186436772.23 -Current:1186436771.19
Run 20527 Last:1186436772.27 -Current:1186436771.23
Run 21095 Last:1186436772.34 -Current:1186436771.31
Run 21526 Last:1186436772.39 -Current:1186436771.36
Run 22115 Last:1186436772.46 -Current:1186436771.42
Run 22320 Last:1186436772.49 -Current:1186436771.45
Run 23076 Last:1186436772.56
#42198 [Opn-Fbk]: SCRIPT_NAME and PHP_SELF truncated when inside a userdir and using PATH_INFO
ID: 42198
Updated by: [EMAIL PROTECTED]
Reported By: hans at parse dot nl
-Status: Open
+Status: Feedback
Bug Type: CGI related
Operating System: Linux
PHP Version: 5.2.4RC1
New Comment:
See bug #31892 (It's about Apache)
I fixed the issues there with this patch (against latest CVS checkout
of PHP_5_2):
http://pecl.php.net/~jani/patches/bug_31892.patch
I then tried the same on lighttpd but no luck: Lighttpd sets
PATH_TRANSLATED incorrectly, debugged it and saw it was set to this:
PATH_TRANSLATED: /opt/www//foo/bar/
PATH_INFO: /foo/bar/
SCRIPT_FILENAME: /home/jani/t.php
SCRIPT_NAME: /r/t.php
PHP_SELF: /r/t.php
REQUEST_URI: /r/t.php/foo/bar/?bar=foo
Obviously when there's this alias/userdir lighttpd still uses document
root to set the PATH_TRANSLATED with (I checked the actual value
lighttpd sets it to, it's not the one PHP modifies..).
Lighttpd seems to ignore the script name totally too. Under apache it
now works (when my patch is applied) as expected:
PATH_TRANSLATED: /home/jani/t.php/foo/bar/
PATH_INFO: /foo/bar/
SCRIPT_FILENAME: /home/jani/t.php
SCRIPT_NAME: /r/t.php/foo/bar/
PHP_SELF: /r/t.php/foo/bar/
REQUEST_URI: /r/t.php/foo/bar/?bar=foo
Previous Comments:
[2007-08-07 12:35:44] hans at parse dot nl
Heh i was pondering and typing a apache2handler example and then i saw
your Apache comment. Here it is anyway:
--
Yes i agree, my patch is kinda hacky but solved my personal userdir
problem ;) The alias problem was someone else's which i overlooked.
Your alias example suffers from the same problem as userdirs, being
that the DOCUMENT_ROOT always points to the docroot of the host, but as
i already pointed out, this is also the case in apache/mod_php5 or
apache2handler, not just cgi-fcgi.
apache2handler actually is an even bigger mess :) for example:
request: http://www.site.com/~hans/info.php/foo/bar
result:
_SERVER[DOCUMENT_ROOT]/var/www/site.com/www/htdocs
_SERVER[REQUEST_URI] /~hans/info.php/foo/bar
_SERVER[SCRIPT_NAME] /~hans/info.php
_SERVER[PATH_INFO]/foo/bar
_SERVER[PATH_TRANSLATED] /var/www/site.com/www/htdocs/foo/bar
_SERVER[PHP_SELF] /~hans/info.php/foo/bar
Not really consistent, and also an invalid PATH_TRANSLATED, and
PATH_INFO added to PHP_SELF ?!
Anyway, back to Lighttpd. I'll try to whip up a less hacky fix that
also handles the aliases.
[2007-08-07 11:51:55] [EMAIL PROTECTED]
Then again same happens with Apache too..
[2007-08-07 11:41:19] [EMAIL PROTECTED]
You patch does not fix the issue for anything but the userdir module
and in a very hackish way. For the aliasing part of your (saw your
example on the lighttpd bug report) it does not fix it at all.
When I debugged this I noticed this:
[PATH_TRANSLATED]=
string(17) /opt/www/foo/bar/
[SCRIPT_FILENAME]=
string(16) /home/jani/t.php
[DOCUMENT_ROOT]=
string(9) /opt/www/
[REQUEST_URI]=
string(17) /r/t.php/foo/bar/
Shouldn't DOCUMENT_ROOT be /home/jani/ in this case when it's the
alias? And PATH_TRANSLATED is also wrong..
[2007-08-07 09:23:00] hans at parse dot nl
A little more explanation fyi: The problem is that DOCUMENT_ROOT is
always set to the configured document root of the default host or the
vhost, even when calling scripts from a userdir. This is not just in
Lighttpd/FastCGI, also f.e. in Apache setups. In my testcase
DOCUMENT_ROOT is '/var/www/htdocs'.
So if i call http://servername/~hans/info.php/foo/bar , We enter this
bit of code in init_request_info() in sapi/cgi/cgi_main.c:
---
/* figure out docroot
SCRIPT_FILENAME minus SCRIPT_NAME
*/
if (env_document_root)
{
int l = strlen(env_document_root);
int path_translated_len = 0;
char *path_translated = NULL;
if (l env_document_root[l - 1] == '/') {
--l;
}
/* we have docroot, so we should have:
* DOCUMENT_ROOT=/docroot
* SCRIPT_FILENAME=/docroot/info.php
*
* SCRIPT_NAME is the portion of the path beyond docroot
*/
env_script_name = pt + l;
---
Since env_document_root is pretty much always set, we enter the if. pt
is '/home/hans/public_html/info.php' at this point (which is correct). l
becomes 15, the strlen of our DOCUMENT_ROOT '/var/www/htdocs'. The
trailing slash check if loop is skipped since our docroot doesn't have
a trailing slash. After this, SCRIPT_NAME is set to pt + l. pt being
'/home/hans/public_html/info.php' and l being 15, this results in a
invalid SCRIPT_NAME (and thus a PHP_SELF) of 'ic_html/info.php'.
My patch adds a userdir check to the 'if (env_document_root)', to
prevent from entering this if() with a DOCUMENT_ROOT
#42198 [Fbk]: SCRIPT_NAME and PHP_SELF truncated when inside a userdir and using PATH_INFO
ID: 42198
Updated by: [EMAIL PROTECTED]
Reported By: hans at parse dot nl
Status: Feedback
Bug Type: CGI related
Operating System: Linux
PHP Version: 5.2.4RC1
New Comment:
And FYI, about PHP_SELF:
http://www.php.net/reserved.variables
(yes, it's supposed to contain PATH_INFO..)
Previous Comments:
[2007-08-07 13:08:05] [EMAIL PROTECTED]
See bug #31892 (It's about Apache)
I fixed the issues there with this patch (against latest CVS checkout
of PHP_5_2):
http://pecl.php.net/~jani/patches/bug_31892.patch
I then tried the same on lighttpd but no luck: Lighttpd sets
PATH_TRANSLATED incorrectly, debugged it and saw it was set to this:
PATH_TRANSLATED: /opt/www//foo/bar/
PATH_INFO: /foo/bar/
SCRIPT_FILENAME: /home/jani/t.php
SCRIPT_NAME: /r/t.php
PHP_SELF: /r/t.php
REQUEST_URI: /r/t.php/foo/bar/?bar=foo
Obviously when there's this alias/userdir lighttpd still uses document
root to set the PATH_TRANSLATED with (I checked the actual value
lighttpd sets it to, it's not the one PHP modifies..).
Lighttpd seems to ignore the script name totally too. Under apache it
now works (when my patch is applied) as expected:
PATH_TRANSLATED: /home/jani/t.php/foo/bar/
PATH_INFO: /foo/bar/
SCRIPT_FILENAME: /home/jani/t.php
SCRIPT_NAME: /r/t.php/foo/bar/
PHP_SELF: /r/t.php/foo/bar/
REQUEST_URI: /r/t.php/foo/bar/?bar=foo
[2007-08-07 12:35:44] hans at parse dot nl
Heh i was pondering and typing a apache2handler example and then i saw
your Apache comment. Here it is anyway:
--
Yes i agree, my patch is kinda hacky but solved my personal userdir
problem ;) The alias problem was someone else's which i overlooked.
Your alias example suffers from the same problem as userdirs, being
that the DOCUMENT_ROOT always points to the docroot of the host, but as
i already pointed out, this is also the case in apache/mod_php5 or
apache2handler, not just cgi-fcgi.
apache2handler actually is an even bigger mess :) for example:
request: http://www.site.com/~hans/info.php/foo/bar
result:
_SERVER[DOCUMENT_ROOT]/var/www/site.com/www/htdocs
_SERVER[REQUEST_URI] /~hans/info.php/foo/bar
_SERVER[SCRIPT_NAME] /~hans/info.php
_SERVER[PATH_INFO]/foo/bar
_SERVER[PATH_TRANSLATED] /var/www/site.com/www/htdocs/foo/bar
_SERVER[PHP_SELF] /~hans/info.php/foo/bar
Not really consistent, and also an invalid PATH_TRANSLATED, and
PATH_INFO added to PHP_SELF ?!
Anyway, back to Lighttpd. I'll try to whip up a less hacky fix that
also handles the aliases.
[2007-08-07 11:51:55] [EMAIL PROTECTED]
Then again same happens with Apache too..
[2007-08-07 11:41:19] [EMAIL PROTECTED]
You patch does not fix the issue for anything but the userdir module
and in a very hackish way. For the aliasing part of your (saw your
example on the lighttpd bug report) it does not fix it at all.
When I debugged this I noticed this:
[PATH_TRANSLATED]=
string(17) /opt/www/foo/bar/
[SCRIPT_FILENAME]=
string(16) /home/jani/t.php
[DOCUMENT_ROOT]=
string(9) /opt/www/
[REQUEST_URI]=
string(17) /r/t.php/foo/bar/
Shouldn't DOCUMENT_ROOT be /home/jani/ in this case when it's the
alias? And PATH_TRANSLATED is also wrong..
[2007-08-07 09:23:00] hans at parse dot nl
A little more explanation fyi: The problem is that DOCUMENT_ROOT is
always set to the configured document root of the default host or the
vhost, even when calling scripts from a userdir. This is not just in
Lighttpd/FastCGI, also f.e. in Apache setups. In my testcase
DOCUMENT_ROOT is '/var/www/htdocs'.
So if i call http://servername/~hans/info.php/foo/bar , We enter this
bit of code in init_request_info() in sapi/cgi/cgi_main.c:
---
/* figure out docroot
SCRIPT_FILENAME minus SCRIPT_NAME
*/
if (env_document_root)
{
int l = strlen(env_document_root);
int path_translated_len = 0;
char *path_translated = NULL;
if (l env_document_root[l - 1] == '/') {
--l;
}
/* we have docroot, so we should have:
* DOCUMENT_ROOT=/docroot
* SCRIPT_FILENAME=/docroot/info.php
*
* SCRIPT_NAME is the portion of the path beyond docroot
*/
env_script_name = pt + l;
---
Since env_document_root is pretty much always set, we enter the if. pt
is '/home/hans/public_html/info.php' at this point (which is correct). l
becomes 15, the strlen of our DOCUMENT_ROOT '/var/www/htdocs'. The
trailing slash check if loop is skipped since our docroot doesn't have
a trailing slash. After this, SCRIPT_NAME is set to pt + l. pt being
'/home/hans/public_html/info.php' and l being 15, this
#42233 [NEW]: Problems with ��� in extract()
From: hkb at hkb dot it Operating system: Windows 2003 PHP version: 5.2.4RC1 PHP Bug Type: Unknown/Other Function Bug description: Problems with æøå in extract() Description: I Just updated PHP today from 5.2.0 to PHP 5.2.3 and found that extract() didnt work if the array containes the danish letters æ, ø or å... Try running the code below ant you will see that $æ is empty when it should be 2... I hope you will fix this bug for your next release... Reproduce code: --- $test[0] = array(e = 2, æ = 2); print_r($test[0]); extract($test[0]); echo br /br /.$e. - .$test[0]['e']; echo br /br /.$æ. - .$test[0]['æ']; Expected result: Array ( [e] = 2 [æ] = 2 ) 2 - 2 2 - 2 Actual result: -- Array ( [e] = 2 [æ] = 2 ) 2 - 2 - 2 -- Edit bug report at http://bugs.php.net/?id=42233edit=1 -- Try a CVS snapshot (PHP 4.4): http://bugs.php.net/fix.php?id=42233r=trysnapshot44 Try a CVS snapshot (PHP 5.2): http://bugs.php.net/fix.php?id=42233r=trysnapshot52 Try a CVS snapshot (PHP 6.0): http://bugs.php.net/fix.php?id=42233r=trysnapshot60 Fixed in CVS: http://bugs.php.net/fix.php?id=42233r=fixedcvs Fixed in release: http://bugs.php.net/fix.php?id=42233r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=42233r=needtrace Need Reproduce Script:http://bugs.php.net/fix.php?id=42233r=needscript Try newer version:http://bugs.php.net/fix.php?id=42233r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=42233r=support Expected behavior:http://bugs.php.net/fix.php?id=42233r=notwrong Not enough info: http://bugs.php.net/fix.php?id=42233r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=42233r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=42233r=globals PHP 3 support discontinued: http://bugs.php.net/fix.php?id=42233r=php3 Daylight Savings: http://bugs.php.net/fix.php?id=42233r=dst IIS Stability:http://bugs.php.net/fix.php?id=42233r=isapi Install GNU Sed: http://bugs.php.net/fix.php?id=42233r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=42233r=float No Zend Extensions: http://bugs.php.net/fix.php?id=42233r=nozend MySQL Configuration Error:http://bugs.php.net/fix.php?id=42233r=mysqlcfg
#42198 [Fbk-Opn]: SCRIPT_NAME and PHP_SELF truncated when inside a userdir and using PATH_INFO
ID: 42198 User updated by: hans at parse dot nl Reported By: hans at parse dot nl -Status: Feedback +Status: Open Bug Type: CGI related Operating System: Linux PHP Version: 5.2.4RC1 New Comment: Ah, i didn't know about the Apache ticket but it looks like exactly the same issue. Nice work on that, hope it makes it into php-5.2.4 :) I applied your patch to php-5.2.4RC1 and adapted Lighttpd mod_fastcgi.c so it exactly matches your Apache results. My patch for lighttpd-1.4.16 can be found here: http://home.parse.nl/~hans/temp/mod_fastcgi.diff Can you please check if you get proper results with it aswell? Would be great if we can tackle this :) Previous Comments: [2007-08-07 13:10:10] [EMAIL PROTECTED] And FYI, about PHP_SELF: http://www.php.net/reserved.variables (yes, it's supposed to contain PATH_INFO..) [2007-08-07 13:08:05] [EMAIL PROTECTED] See bug #31892 (It's about Apache) I fixed the issues there with this patch (against latest CVS checkout of PHP_5_2): http://pecl.php.net/~jani/patches/bug_31892.patch I then tried the same on lighttpd but no luck: Lighttpd sets PATH_TRANSLATED incorrectly, debugged it and saw it was set to this: PATH_TRANSLATED: /opt/www//foo/bar/ PATH_INFO: /foo/bar/ SCRIPT_FILENAME: /home/jani/t.php SCRIPT_NAME: /r/t.php PHP_SELF: /r/t.php REQUEST_URI: /r/t.php/foo/bar/?bar=foo Obviously when there's this alias/userdir lighttpd still uses document root to set the PATH_TRANSLATED with (I checked the actual value lighttpd sets it to, it's not the one PHP modifies..). Lighttpd seems to ignore the script name totally too. Under apache it now works (when my patch is applied) as expected: PATH_TRANSLATED: /home/jani/t.php/foo/bar/ PATH_INFO: /foo/bar/ SCRIPT_FILENAME: /home/jani/t.php SCRIPT_NAME: /r/t.php/foo/bar/ PHP_SELF: /r/t.php/foo/bar/ REQUEST_URI: /r/t.php/foo/bar/?bar=foo [2007-08-07 12:35:44] hans at parse dot nl Heh i was pondering and typing a apache2handler example and then i saw your Apache comment. Here it is anyway: -- Yes i agree, my patch is kinda hacky but solved my personal userdir problem ;) The alias problem was someone else's which i overlooked. Your alias example suffers from the same problem as userdirs, being that the DOCUMENT_ROOT always points to the docroot of the host, but as i already pointed out, this is also the case in apache/mod_php5 or apache2handler, not just cgi-fcgi. apache2handler actually is an even bigger mess :) for example: request: http://www.site.com/~hans/info.php/foo/bar result: _SERVER[DOCUMENT_ROOT]/var/www/site.com/www/htdocs _SERVER[REQUEST_URI] /~hans/info.php/foo/bar _SERVER[SCRIPT_NAME] /~hans/info.php _SERVER[PATH_INFO]/foo/bar _SERVER[PATH_TRANSLATED] /var/www/site.com/www/htdocs/foo/bar _SERVER[PHP_SELF] /~hans/info.php/foo/bar Not really consistent, and also an invalid PATH_TRANSLATED, and PATH_INFO added to PHP_SELF ?! Anyway, back to Lighttpd. I'll try to whip up a less hacky fix that also handles the aliases. [2007-08-07 11:51:55] [EMAIL PROTECTED] Then again same happens with Apache too.. [2007-08-07 11:41:19] [EMAIL PROTECTED] You patch does not fix the issue for anything but the userdir module and in a very hackish way. For the aliasing part of your (saw your example on the lighttpd bug report) it does not fix it at all. When I debugged this I noticed this: [PATH_TRANSLATED]= string(17) /opt/www/foo/bar/ [SCRIPT_FILENAME]= string(16) /home/jani/t.php [DOCUMENT_ROOT]= string(9) /opt/www/ [REQUEST_URI]= string(17) /r/t.php/foo/bar/ Shouldn't DOCUMENT_ROOT be /home/jani/ in this case when it's the alias? And PATH_TRANSLATED is also wrong.. 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/42198 -- Edit this bug report at http://bugs.php.net/?id=42198edit=1
#42233 [Opn]: Problems with ��� in extract()
ID: 42233 Updated by: [EMAIL PROTECTED] Reported By: hkb at hkb dot it Status: Open Bug Type: Variables related Operating System: Windows 2003 PHP Version: 5.2.4RC1 New Comment: This happens because extract() uses isalpha() for checking the validity of variable name. Fix brewing.. Previous Comments: [2007-08-07 13:11:23] hkb at hkb dot it Description: I Just updated PHP today from 5.2.0 to PHP 5.2.3 and found that extract() didnt work if the array containes the danish letters æ, ø or å... Try running the code below ant you will see that $æ is empty when it should be 2... I hope you will fix this bug for your next release... Reproduce code: --- $test[0] = array(e = 2, æ = 2); print_r($test[0]); extract($test[0]); echo br /br /.$e. - .$test[0]['e']; echo br /br /.$æ. - .$test[0]['æ']; Expected result: Array ( [e] = 2 [æ] = 2 ) 2 - 2 2 - 2 Actual result: -- Array ( [e] = 2 [æ] = 2 ) 2 - 2 - 2 -- Edit this bug report at http://bugs.php.net/?id=42233edit=1
#42233 [Opn]: [PATCH] Problems with ��� in extract()
ID: 42233 Updated by: [EMAIL PROTECTED] -Summary: Problems with æøå in extract() Reported By: hkb at hkb dot it Status: Open Bug Type: Variables related Operating System: Windows 2003 PHP Version: 5.2.4RC1 New Comment: My not-so-elegant patch to fix the issue: http://pecl.php.net/~jani/patches/bug_42233.patch Previous Comments: [2007-08-07 14:57:21] [EMAIL PROTECTED] This happens because extract() uses isalpha() for checking the validity of variable name. Fix brewing.. [2007-08-07 13:11:23] hkb at hkb dot it Description: I Just updated PHP today from 5.2.0 to PHP 5.2.3 and found that extract() didnt work if the array containes the danish letters æ, ø or å... Try running the code below ant you will see that $æ is empty when it should be 2... I hope you will fix this bug for your next release... Reproduce code: --- $test[0] = array(e = 2, æ = 2); print_r($test[0]); extract($test[0]); echo br /br /.$e. - .$test[0]['e']; echo br /br /.$æ. - .$test[0]['æ']; Expected result: Array ( [e] = 2 [æ] = 2 ) 2 - 2 2 - 2 Actual result: -- Array ( [e] = 2 [æ] = 2 ) 2 - 2 - 2 -- Edit this bug report at http://bugs.php.net/?id=42233edit=1
#42233 [Opn-Ver]: [PATCH] Problems with ��� in extract()
ID: 42233 Updated by: [EMAIL PROTECTED] Reported By: hkb at hkb dot it -Status: Open +Status: Verified Bug Type: Variables related Operating System: Windows 2003 PHP Version: 5.2.4RC1 Previous Comments: [2007-08-07 15:00:44] [EMAIL PROTECTED] My not-so-elegant patch to fix the issue: http://pecl.php.net/~jani/patches/bug_42233.patch [2007-08-07 14:57:21] [EMAIL PROTECTED] This happens because extract() uses isalpha() for checking the validity of variable name. Fix brewing.. [2007-08-07 13:11:23] hkb at hkb dot it Description: I Just updated PHP today from 5.2.0 to PHP 5.2.3 and found that extract() didnt work if the array containes the danish letters æ, ø or å... Try running the code below ant you will see that $æ is empty when it should be 2... I hope you will fix this bug for your next release... Reproduce code: --- $test[0] = array(e = 2, æ = 2); print_r($test[0]); extract($test[0]); echo br /br /.$e. - .$test[0]['e']; echo br /br /.$æ. - .$test[0]['æ']; Expected result: Array ( [e] = 2 [æ] = 2 ) 2 - 2 2 - 2 Actual result: -- Array ( [e] = 2 [æ] = 2 ) 2 - 2 - 2 -- Edit this bug report at http://bugs.php.net/?id=42233edit=1
#42198 [Opn-Asn]: SCRIPT_NAME and PHP_SELF truncated when inside a userdir and using PATH_INFO
ID: 42198 Updated by: [EMAIL PROTECTED] Reported By: hans at parse dot nl -Status: Open +Status: Assigned Bug Type: CGI related Operating System: Linux PHP Version: 5.2.4RC1 -Assigned To: +Assigned To: jani New Comment: Yes, that's one way to do it..though I still think the issue is more in how mod_alias/mod_userdir handle the doc_root and might be the proper place to fix it..but I'm not so familiar with lighttpd internals so I could be wrong. Including my patch in 5.2.4 is up to Ilia to decide. :) Previous Comments: [2007-08-07 14:56:13] hans at parse dot nl Ah, i didn't know about the Apache ticket but it looks like exactly the same issue. Nice work on that, hope it makes it into php-5.2.4 :) I applied your patch to php-5.2.4RC1 and adapted Lighttpd mod_fastcgi.c so it exactly matches your Apache results. My patch for lighttpd-1.4.16 can be found here: http://home.parse.nl/~hans/temp/mod_fastcgi.diff Can you please check if you get proper results with it aswell? Would be great if we can tackle this :) [2007-08-07 13:10:10] [EMAIL PROTECTED] And FYI, about PHP_SELF: http://www.php.net/reserved.variables (yes, it's supposed to contain PATH_INFO..) [2007-08-07 13:08:05] [EMAIL PROTECTED] See bug #31892 (It's about Apache) I fixed the issues there with this patch (against latest CVS checkout of PHP_5_2): http://pecl.php.net/~jani/patches/bug_31892.patch I then tried the same on lighttpd but no luck: Lighttpd sets PATH_TRANSLATED incorrectly, debugged it and saw it was set to this: PATH_TRANSLATED: /opt/www//foo/bar/ PATH_INFO: /foo/bar/ SCRIPT_FILENAME: /home/jani/t.php SCRIPT_NAME: /r/t.php PHP_SELF: /r/t.php REQUEST_URI: /r/t.php/foo/bar/?bar=foo Obviously when there's this alias/userdir lighttpd still uses document root to set the PATH_TRANSLATED with (I checked the actual value lighttpd sets it to, it's not the one PHP modifies..). Lighttpd seems to ignore the script name totally too. Under apache it now works (when my patch is applied) as expected: PATH_TRANSLATED: /home/jani/t.php/foo/bar/ PATH_INFO: /foo/bar/ SCRIPT_FILENAME: /home/jani/t.php SCRIPT_NAME: /r/t.php/foo/bar/ PHP_SELF: /r/t.php/foo/bar/ REQUEST_URI: /r/t.php/foo/bar/?bar=foo [2007-08-07 12:35:44] hans at parse dot nl Heh i was pondering and typing a apache2handler example and then i saw your Apache comment. Here it is anyway: -- Yes i agree, my patch is kinda hacky but solved my personal userdir problem ;) The alias problem was someone else's which i overlooked. Your alias example suffers from the same problem as userdirs, being that the DOCUMENT_ROOT always points to the docroot of the host, but as i already pointed out, this is also the case in apache/mod_php5 or apache2handler, not just cgi-fcgi. apache2handler actually is an even bigger mess :) for example: request: http://www.site.com/~hans/info.php/foo/bar result: _SERVER[DOCUMENT_ROOT]/var/www/site.com/www/htdocs _SERVER[REQUEST_URI] /~hans/info.php/foo/bar _SERVER[SCRIPT_NAME] /~hans/info.php _SERVER[PATH_INFO]/foo/bar _SERVER[PATH_TRANSLATED] /var/www/site.com/www/htdocs/foo/bar _SERVER[PHP_SELF] /~hans/info.php/foo/bar Not really consistent, and also an invalid PATH_TRANSLATED, and PATH_INFO added to PHP_SELF ?! Anyway, back to Lighttpd. I'll try to whip up a less hacky fix that also handles the aliases. [2007-08-07 11:51:55] [EMAIL PROTECTED] Then again same happens with Apache too.. The remainder of the comments for this report are too long. To view the rest of the comments, please view the bug report online at http://bugs.php.net/42198 -- Edit this bug report at http://bugs.php.net/?id=42198edit=1
#42105 [Fbk-Bgs]: CLI binary segfaults on ldap_bind(), Apache module works fine
ID: 42105 Updated by: [EMAIL PROTECTED] Reported By: paul at moonkhan dot org -Status: Feedback +Status: Bogus Bug Type: CGI related Operating System: RHEL4 PHP Version: 5.2CVS-2007-07-26 Assigned To: jani New Comment: I could not reproduce and the issue seems to be in the ldap or ssl libs anyway. Previous Comments: [2007-08-01 10:52:00] [EMAIL PROTECTED] Is it possible to provide me access to such server using SSL..? I don't know any and I really don't have time to setup one myself.. [2007-07-26 17:26:29] [EMAIL PROTECTED] Those two options configure said are unknown have actually never existed. The correct ones are --enable-libxml and --enable-sigchild. I'll try with your configure line and try to reproduce this. [2007-07-26 15:38:38] paul at moonkhan dot org Here is the configure line: Configure Command = './configure' '--with-apxs2=/usr/local/httpd-2.2.4/bin/apxs' '--prefix=/usr/local/php-5.2.1' '--sysconfdir=/usr/local/etc/php' '--with-config-file-path=/usr/local/etc/php' '--with-gd' '--with-zlib-dir=/usr' '--with-jpeg-dir=/usr' '--with-ldap' '--with-mcrypt' '--with-mhash' '--with-curl' '--with-openssl' '--with-xsl' '--with-libxml' '--with-pear=/usr/local/pear' '--with-mysql' '--with-oci8=instantclient,/usr/src/instantclient_10_2' '--with-sigchild' '--with-custom-odbc=/usr/local/odbc32v52' '--with-ttf' '--with-freetype-dir=/usr' Just ignore the weird --prefix - I had no intention of doing a make install on this compile :) Also, on the snapshot configure, it mentioned that --with-libxml and --with-sigchild are not real options anymore but I just left them in there anyways. Thanks, -Paul [2007-07-26 15:29:31] [EMAIL PROTECTED] What was the full configure line used? (check from CLI php with -i option :) [2007-07-26 14:09:39] paul at moonkhan dot org The CVS snapshot didn't fix the segfaulting when using the command line binary. 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/42105 -- Edit this bug report at http://bugs.php.net/?id=42105edit=1
#42225 [Bgs]: XML Parser or array is not return characters back before a accent
ID: 42225
User updated by: tcreamean at starsolutionsllc dot com
Reported By: tcreamean at starsolutionsllc dot com
Status: Bogus
Bug Type: *XML functions
Operating System: gentoo
PHP Version: 5.2.4RC1
New Comment:
Hello rrichards,
Sorry I did do a search and got nothing back several times as well as
poring over the manuals to find a hint about this. I have never seen
this behavior before with a array getting chunked on a accent it was
unexpected behavior from a array call. So I call the array twice and
concatenated the values to return the true whole value of the element
which is now in two chunks. I don't know why this is expected behavior
when 4.4.7 returns a whole value of countryname O well I am sure there
is a good reason. Thanks for your help and tips for tracking this down
keep up the good work.
if ($state == COUNTRYNAME) {
$userdata[$usercount][countryname] =
$userdata[$usercount][countryname].$data;
Previous Comments:
[2007-08-07 11:31:46] [EMAIL PROTECTED]
Thank you for taking the time to write to us, but this is not
a bug. Please double-check the documentation available at
http://www.php.net/manual/ and the instructions on how to report
a bug at http://bugs.php.net/how-to-report.php
A quick search of the bugs would have told you character data can be
chunked, so might not come all at once to the handler.
[2007-08-06 20:35:50] tcreamean at starsolutionsllc dot com
Description:
When I parse a xml file with fopen with latian accents it returns the
word chopped off in php 5.2.3.
So Austrália comes back on the web page like this ália in 5.2.3.
When I downgraded to 4.4.7 all is working great Austrália comes back as
Austrália.
Reproduce code:
---
?xml version=1.0 encoding=ISO-8859-1?
accessNumbers
accessCntry
countryNameAlemanha/countryName
countryID96/countryID
dialingCode49/dialingCode
/accessCntry
accessCntry
countryNameArgentina/countryName
countryID14/countryID
dialingCode54/dialingCode
/accessCntry
accessCntry
countryNameAustrália/countryName
countryID20/countryID
dialingCode61/dialingCode
/accessCntry
/accessNumbers
?php
if
(!([EMAIL
PROTECTED](http://xml.cordiaip.com/?ixAcct=accessNumbersCountrieslangId=3,r;)))
die (Couldn't open XML.);
$usercount=0;
$userdata=array();
$state='';
if (!($xml_parser = xml_parser_create('iso-8859-1'))) die(Couldn't
create parser.);
//xml_parser_set_option($fp, XML_OPTION_CASE_FOLDING, 0);
//xml_parser_set_option($fp, XML_OPTION_SKIP_WHITE, 1);
function startElementHandler ($parser,$element,$attrib){
global $usercount, $userdata, $state;
switch ($element) {
case $element==ACCESSCNTRY : {
$userdata[$usercount][id] = $attrib[ID];
break;
}
default : {
$state = $element;
break;
}
}
}
function endElementHandler ($parser,$element){
global $usercount, $userdata, $state;
$state='';
if($element==ACCESSCNTRY) {
$usercount++;
}
}
function characterDataHandler ($parser, $data) {
global $usercount, $userdata, $state;
if (!$state) {
return;
}
if ($state == COUNTRYNAME) {
$userdata[$usercount][countryname] = $data;
}
if ($state == COUNTRYID) {
$userdata[$usercount][countryID] = $data;
}
}
xml_set_element_handler($xml_parser,startElementHandler,endElementHandler);
xml_set_character_data_handler( $xml_parser, characterDataHandler);
while( $data = fread($fp, 8192)){
if(!xml_parse($xml_parser, $data, feof($fp))) {
break;
}
}
xml_parser_free($xml_parser);
for ($i=0;$i$usercount; $i++) {
$x = $i+1;
echo $userdata[$i][countryID];
echo $userdata[$i][countryname];
}
?
--
Edit this bug report at http://bugs.php.net/?id=42225edit=1
#42235 [NEW]: Overloaded properties not allowing modification
From: stephen dot cuppett at webmastersinc dot net
Operating system: Windows and Linux
PHP version: 5.2.4RC1
PHP Bug Type: Class/Object related
Bug description: Overloaded properties not allowing modification
Description:
Also documented in: http://pear.php.net/bugs/bug.php?id=11775
There appears to be a regression as to Bug #39449:
http://bugs.php.net/bug.php?id=39449
On 5.2.4RC1, I'm getting the immutable overloaded properties problem with
DB_DataObject and in the simple test below.
Also bugs:
41116, 40828, 40823, 39990
Reproduce code:
---
?php
class MyObj {
private $map;
public function __construct() {
$this-map = array();
}
public function __set($vn, $value) {
$this-map[$vn] = $value;
}
public function __get($vn) {
return $this-map[$vn];
}
}
$myvar = new MyObj();
$myvar-test_var = array();
$myvar-test_var['tester'] = 3;
$myvar-test_var['tester2'] = 5;
var_dump($myvar-test_var);
?
Expected result:
C:\temp\dataobject_testphp simpletest.php
array(2) {
[tester]=
int(3)
[tester2]=
int(5)
}
Actual result:
--
C:\temp\dataobject_testphp simpletest.php
PHP Notice: Indirect modification of overloaded property MyObj::$test_var
has no effect in C:\temp\dataobject_test\simpletest.php on line 16
Notice: Indirect modification of overloaded property MyObj::$test_var has
no effect in C:\temp\dataobject_test\simpletest.php on line 16
PHP Notice: Indirect modification of overloaded property MyObj::$test_var
has no effect in C:\temp\dataobject_test\simpletest.php on line 17
Notice: Indirect modification of overloaded property MyObj::$test_var has
no effect in C:\temp\dataobject_test\simpletest.php on line 17
array(0) {
}
--
Edit bug report at http://bugs.php.net/?id=42235edit=1
--
Try a CVS snapshot (PHP 4.4):
http://bugs.php.net/fix.php?id=42235r=trysnapshot44
Try a CVS snapshot (PHP 5.2):
http://bugs.php.net/fix.php?id=42235r=trysnapshot52
Try a CVS snapshot (PHP 6.0):
http://bugs.php.net/fix.php?id=42235r=trysnapshot60
Fixed in CVS: http://bugs.php.net/fix.php?id=42235r=fixedcvs
Fixed in release:
http://bugs.php.net/fix.php?id=42235r=alreadyfixed
Need backtrace: http://bugs.php.net/fix.php?id=42235r=needtrace
Need Reproduce Script:http://bugs.php.net/fix.php?id=42235r=needscript
Try newer version:http://bugs.php.net/fix.php?id=42235r=oldversion
Not developer issue: http://bugs.php.net/fix.php?id=42235r=support
Expected behavior:http://bugs.php.net/fix.php?id=42235r=notwrong
Not enough info:
http://bugs.php.net/fix.php?id=42235r=notenoughinfo
Submitted twice:
http://bugs.php.net/fix.php?id=42235r=submittedtwice
register_globals: http://bugs.php.net/fix.php?id=42235r=globals
PHP 3 support discontinued: http://bugs.php.net/fix.php?id=42235r=php3
Daylight Savings: http://bugs.php.net/fix.php?id=42235r=dst
IIS Stability:http://bugs.php.net/fix.php?id=42235r=isapi
Install GNU Sed: http://bugs.php.net/fix.php?id=42235r=gnused
Floating point limitations: http://bugs.php.net/fix.php?id=42235r=float
No Zend Extensions: http://bugs.php.net/fix.php?id=42235r=nozend
MySQL Configuration Error:http://bugs.php.net/fix.php?id=42235r=mysqlcfg
#42235 [Opn]: Overloaded properties not allowing modification
ID: 42235
User updated by: stephen dot cuppett at webmastersinc dot net
Reported By: stephen dot cuppett at webmastersinc dot net
Status: Open
Bug Type: Class/Object related
Operating System: Windows and Linux
PHP Version: 5.2.4RC1
New Comment:
It should be noted that the supposed congruent case works:
?php
class MyObj {
public $test_var;
}
$myvar = new MyObj();
$myvar-test_var = array();
$myvar-test_var['tester'] = 3;
$myvar-test_var['tester2'] = 5;
var_dump($myvar-test_var);
?
C:\temp\dataobject_testphp simpletest.php
array(2) {
[tester]=
int(3)
[tester2]=
int(5)
}
Previous Comments:
[2007-08-07 16:27:23] stephen dot cuppett at webmastersinc dot net
Description:
Also documented in: http://pear.php.net/bugs/bug.php?id=11775
There appears to be a regression as to Bug #39449:
http://bugs.php.net/bug.php?id=39449
On 5.2.4RC1, I'm getting the immutable overloaded properties problem
with DB_DataObject and in the simple test below.
Also bugs:
41116, 40828, 40823, 39990
Reproduce code:
---
?php
class MyObj {
private $map;
public function __construct() {
$this-map = array();
}
public function __set($vn, $value) {
$this-map[$vn] = $value;
}
public function __get($vn) {
return $this-map[$vn];
}
}
$myvar = new MyObj();
$myvar-test_var = array();
$myvar-test_var['tester'] = 3;
$myvar-test_var['tester2'] = 5;
var_dump($myvar-test_var);
?
Expected result:
C:\temp\dataobject_testphp simpletest.php
array(2) {
[tester]=
int(3)
[tester2]=
int(5)
}
Actual result:
--
C:\temp\dataobject_testphp simpletest.php
PHP Notice: Indirect modification of overloaded property
MyObj::$test_var has no effect in C:\temp\dataobject_test\simpletest.php
on line 16
Notice: Indirect modification of overloaded property MyObj::$test_var
has no effect in C:\temp\dataobject_test\simpletest.php on line 16
PHP Notice: Indirect modification of overloaded property
MyObj::$test_var has no effect in C:\temp\dataobject_test\simpletest.php
on line 17
Notice: Indirect modification of overloaded property MyObj::$test_var
has no effect in C:\temp\dataobject_test\simpletest.php on line 17
array(0) {
}
--
Edit this bug report at http://bugs.php.net/?id=42235edit=1
#42236 [NEW]: unwanted array reset within recursive call
From: remy215 at laposte dot net
Operating system: debian
PHP version: 5.2.4RC1
PHP Bug Type: Arrays related
Bug description: unwanted array reset within recursive call
Description:
I have an array of nested arrays (ie. each id can have nested children).
The function returns the parent of the provided id but end in an infinite
loop when the id does not exists !
Parent array at the top of the hierarchy seems to undergo an unwanted
reset();
Reproduce code:
---
?php
$array=array('a0'=array('a1'=array('a2'=array(),'b2'=array()),'b1'=array()),'b0'=array());
$searched=array(); // to avoid infinite loop
function getParent($id,$_subtree=null) {
if(!$_subtree) { // if first call
global $array;
$_subtree=$array; // entire tree
}
global $searched; // to avoid infinite loop
$found_parent=null;
foreach($_subtree as $parent=$children) {
if(in_array($parent,$searched)) { // if already looped = stop
(ie.
infinite loop)
die('Infinite loop: '.$parent);
}
array_push($searched,$parent); // to avoid infinite loop
if(in_array($id,array_keys($children))) {
$found_parent=$parent;
break;
} elseif($found_parent=getParent($id,$children)) {
break;
}
}
return $found_parent;
}
$search='a0';
echo 'parent of '.$search.' is: '.getParent($search);
?
Expected result:
When you provide as argument a nested id, the function works ('b2' returns
'a1').
When you provide a non-existing id, or one of the top parent ids ('a0' or
'b0') the function should return null.
Actual result:
--
When you provide a non-existing id, or one of the top parent ids ('a0' or
'b0') the function end up in an infinite loop.
Parent array at the top of the hierarchy seems to undergo an unwanted
reset();
--
Edit bug report at http://bugs.php.net/?id=42236edit=1
--
Try a CVS snapshot (PHP 4.4):
http://bugs.php.net/fix.php?id=42236r=trysnapshot44
Try a CVS snapshot (PHP 5.2):
http://bugs.php.net/fix.php?id=42236r=trysnapshot52
Try a CVS snapshot (PHP 6.0):
http://bugs.php.net/fix.php?id=42236r=trysnapshot60
Fixed in CVS: http://bugs.php.net/fix.php?id=42236r=fixedcvs
Fixed in release:
http://bugs.php.net/fix.php?id=42236r=alreadyfixed
Need backtrace: http://bugs.php.net/fix.php?id=42236r=needtrace
Need Reproduce Script:http://bugs.php.net/fix.php?id=42236r=needscript
Try newer version:http://bugs.php.net/fix.php?id=42236r=oldversion
Not developer issue: http://bugs.php.net/fix.php?id=42236r=support
Expected behavior:http://bugs.php.net/fix.php?id=42236r=notwrong
Not enough info:
http://bugs.php.net/fix.php?id=42236r=notenoughinfo
Submitted twice:
http://bugs.php.net/fix.php?id=42236r=submittedtwice
register_globals: http://bugs.php.net/fix.php?id=42236r=globals
PHP 3 support discontinued: http://bugs.php.net/fix.php?id=42236r=php3
Daylight Savings: http://bugs.php.net/fix.php?id=42236r=dst
IIS Stability:http://bugs.php.net/fix.php?id=42236r=isapi
Install GNU Sed: http://bugs.php.net/fix.php?id=42236r=gnused
Floating point limitations: http://bugs.php.net/fix.php?id=42236r=float
No Zend Extensions: http://bugs.php.net/fix.php?id=42236r=nozend
MySQL Configuration Error:http://bugs.php.net/fix.php?id=42236r=mysqlcfg
#42237 [NEW]: stream_copy_to_stream returns invalid values for memmapped streams
From: andrew dot minerd at sellingsource dot com
Operating system: Gentoo
PHP version: 5.2.4RC1
PHP Bug Type: Streams related
Bug description: stream_copy_to_stream returns invalid values for memmapped
streams
Description:
When copying from a memmapped stream, stream_copy_to_stream returns the
length of the memory-mapped segment, regardless of how much data was
actually written to the recipient stream.
Reproduce code:
---
?php
class DummyWriteStream
{
function stream_open($path, $mode, $options, $opened_path) { return
TRUE; }
function stream_write($data) { return 0; }
}
stream_wrapper_register('test2', 'DummyWriteStream');
$fp1 = fopen('/etc/hosts', 'r');
$fp2 = fopen('test2://test', 'w');
var_dump(stream_copy_to_stream($fp1, $fp2, 8192));
?
Expected result:
int(0)
Actual result:
--
int(1228)
--
Edit bug report at http://bugs.php.net/?id=42237edit=1
--
Try a CVS snapshot (PHP 4.4):
http://bugs.php.net/fix.php?id=42237r=trysnapshot44
Try a CVS snapshot (PHP 5.2):
http://bugs.php.net/fix.php?id=42237r=trysnapshot52
Try a CVS snapshot (PHP 6.0):
http://bugs.php.net/fix.php?id=42237r=trysnapshot60
Fixed in CVS: http://bugs.php.net/fix.php?id=42237r=fixedcvs
Fixed in release:
http://bugs.php.net/fix.php?id=42237r=alreadyfixed
Need backtrace: http://bugs.php.net/fix.php?id=42237r=needtrace
Need Reproduce Script:http://bugs.php.net/fix.php?id=42237r=needscript
Try newer version:http://bugs.php.net/fix.php?id=42237r=oldversion
Not developer issue: http://bugs.php.net/fix.php?id=42237r=support
Expected behavior:http://bugs.php.net/fix.php?id=42237r=notwrong
Not enough info:
http://bugs.php.net/fix.php?id=42237r=notenoughinfo
Submitted twice:
http://bugs.php.net/fix.php?id=42237r=submittedtwice
register_globals: http://bugs.php.net/fix.php?id=42237r=globals
PHP 3 support discontinued: http://bugs.php.net/fix.php?id=42237r=php3
Daylight Savings: http://bugs.php.net/fix.php?id=42237r=dst
IIS Stability:http://bugs.php.net/fix.php?id=42237r=isapi
Install GNU Sed: http://bugs.php.net/fix.php?id=42237r=gnused
Floating point limitations: http://bugs.php.net/fix.php?id=42237r=float
No Zend Extensions: http://bugs.php.net/fix.php?id=42237r=nozend
MySQL Configuration Error:http://bugs.php.net/fix.php?id=42237r=mysqlcfg
#42237 [Opn]: stream_copy_to_stream returns invalid values for memmapped streams
ID: 42237
User updated by: andrew dot minerd at sellingsource dot com
Reported By: andrew dot minerd at sellingsource dot com
Status: Open
Bug Type: Streams related
Operating System: Gentoo
PHP Version: 5.2.4RC1
New Comment:
Patch:
--- streams.c 2007-01-15 09:07:07.0 -0800
+++ streams2.c 2007-08-07 13:23:14.0 -0700
@@ -1309,11 +1309,11 @@
p = php_stream_mmap_range(src, php_stream_tell(src),
maxlen, PHP_STREAM_MAP_MODE_SHARED_READONLY, mapped);
if (p) {
- haveread = php_stream_write(dest, p, mapped);
+ written = php_stream_write(dest, p, mapped);
php_stream_mmap_unmap(src);
- return mapped;
+ return written;
}
}
Previous Comments:
[2007-08-07 20:24:04] andrew dot minerd at sellingsource dot com
Description:
When copying from a memmapped stream, stream_copy_to_stream returns the
length of the memory-mapped segment, regardless of how much data was
actually written to the recipient stream.
Reproduce code:
---
?php
class DummyWriteStream
{
function stream_open($path, $mode, $options, $opened_path) { return
TRUE; }
function stream_write($data) { return 0; }
}
stream_wrapper_register('test2', 'DummyWriteStream');
$fp1 = fopen('/etc/hosts', 'r');
$fp2 = fopen('test2://test', 'w');
var_dump(stream_copy_to_stream($fp1, $fp2, 8192));
?
Expected result:
int(0)
Actual result:
--
int(1228)
--
Edit this bug report at http://bugs.php.net/?id=42237edit=1
#42237 [Opn]: stream_copy_to_stream returns invalid values for memmapped streams
ID: 42237
User updated by: andrew dot minerd at sellingsource dot com
Reported By: andrew dot minerd at sellingsource dot com
Status: Open
Bug Type: Streams related
Operating System: Gentoo
PHP Version: 5.2.4RC1
New Comment:
Erm, I changed haveread to written for clarity... obviously you'd have
to define the variable, etc -- that was missing from my patch. :-p
Previous Comments:
[2007-08-07 20:26:00] andrew dot minerd at sellingsource dot com
Patch:
--- streams.c 2007-01-15 09:07:07.0 -0800
+++ streams2.c 2007-08-07 13:23:14.0 -0700
@@ -1309,11 +1309,11 @@
p = php_stream_mmap_range(src, php_stream_tell(src),
maxlen, PHP_STREAM_MAP_MODE_SHARED_READONLY, mapped);
if (p) {
- haveread = php_stream_write(dest, p, mapped);
+ written = php_stream_write(dest, p, mapped);
php_stream_mmap_unmap(src);
- return mapped;
+ return written;
}
}
[2007-08-07 20:24:04] andrew dot minerd at sellingsource dot com
Description:
When copying from a memmapped stream, stream_copy_to_stream returns the
length of the memory-mapped segment, regardless of how much data was
actually written to the recipient stream.
Reproduce code:
---
?php
class DummyWriteStream
{
function stream_open($path, $mode, $options, $opened_path) { return
TRUE; }
function stream_write($data) { return 0; }
}
stream_wrapper_register('test2', 'DummyWriteStream');
$fp1 = fopen('/etc/hosts', 'r');
$fp2 = fopen('test2://test', 'w');
var_dump(stream_copy_to_stream($fp1, $fp2, 8192));
?
Expected result:
int(0)
Actual result:
--
int(1228)
--
Edit this bug report at http://bugs.php.net/?id=42237edit=1
#42238 [NEW]: var_dump of preg_match array hangs script
From: redsandro at gmail dot com Operating system: Linux / WinXP PHP version: 5.2.4RC1 PHP Bug Type: Scripting Engine problem Bug description: var_dump of preg_match array hangs script Description: When preg_matching a multiline string containing '?', dumping the resulting $matches array hangs the script engine. I've noticed the same in php 4.4.1 and 5.2.1. Reproduce code: --- ?php echo 'pre'; $var = ? // - Remove first two chars and this script won't hang.; $pattern = /^(.+)$/s; preg_match($pattern, $var, $matches); print_r($matches); exit; Expected result: Array ( [0] = ? // - Remove first two chars and this script won't hang. [1] = ? // - Remove first two chars and this script won't hang. ) Actual result: -- Array ( -- Edit bug report at http://bugs.php.net/?id=42238edit=1 -- Try a CVS snapshot (PHP 4.4): http://bugs.php.net/fix.php?id=42238r=trysnapshot44 Try a CVS snapshot (PHP 5.2): http://bugs.php.net/fix.php?id=42238r=trysnapshot52 Try a CVS snapshot (PHP 6.0): http://bugs.php.net/fix.php?id=42238r=trysnapshot60 Fixed in CVS: http://bugs.php.net/fix.php?id=42238r=fixedcvs Fixed in release: http://bugs.php.net/fix.php?id=42238r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=42238r=needtrace Need Reproduce Script:http://bugs.php.net/fix.php?id=42238r=needscript Try newer version:http://bugs.php.net/fix.php?id=42238r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=42238r=support Expected behavior:http://bugs.php.net/fix.php?id=42238r=notwrong Not enough info: http://bugs.php.net/fix.php?id=42238r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=42238r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=42238r=globals PHP 3 support discontinued: http://bugs.php.net/fix.php?id=42238r=php3 Daylight Savings: http://bugs.php.net/fix.php?id=42238r=dst IIS Stability:http://bugs.php.net/fix.php?id=42238r=isapi Install GNU Sed: http://bugs.php.net/fix.php?id=42238r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=42238r=float No Zend Extensions: http://bugs.php.net/fix.php?id=42238r=nozend MySQL Configuration Error:http://bugs.php.net/fix.php?id=42238r=mysqlcfg
#42238 [Opn-Bgs]: var_dump of preg_match array hangs script
ID: 42238 Updated by: [EMAIL PROTECTED] Reported By: redsandro at gmail dot com -Status: Open +Status: Bogus Bug Type: Scripting Engine problem Operating System: Linux / WinXP PHP Version: 5.2.4RC1 New Comment: When you know you have an older version at least try upgrading it before reporting a bug. Can't reproduce though. Previous Comments: [2007-08-07 21:26:04] redsandro at gmail dot com Description: When preg_matching a multiline string containing '?', dumping the resulting $matches array hangs the script engine. I've noticed the same in php 4.4.1 and 5.2.1. Reproduce code: --- ?php echo 'pre'; $var = ? // - Remove first two chars and this script won't hang.; $pattern = /^(.+)$/s; preg_match($pattern, $var, $matches); print_r($matches); exit; Expected result: Array ( [0] = ? // - Remove first two chars and this script won't hang. [1] = ? // - Remove first two chars and this script won't hang. ) Actual result: -- Array ( -- Edit this bug report at http://bugs.php.net/?id=42238edit=1
#42239 [NEW]: class member is broken after retrieving vom Session
From: peter dot evertz at snafu dot de
Operating system: Linux 2.6.18
PHP version: 5.2.4RC1
PHP Bug Type: Session related
Bug description: class member is broken after retrieving vom Session
Description:
I found this while using propel. It uses DateTime class for storing.
After retrieving the class from a Session the member is broken.
The code creates a session variabel v with the given class if not
found.On the second call to the script the class is retrievies from
session. The member x is broken.
Reproduce code:
---
?php
class c {
protected $v;
function print_type() {
if ( $this-v instanceof DateTime ) {
print x is DateTime\n;
}
}
function get_v() {
return $this-v;
}
function set_v($i) {
$this-v=$i;
}
}
session_start();
if ( !isset($_SESSION[x] )) {
$x = new c();
$x-set_v( new DateTime());
$_SESSION[x]=$x;
print New object created\n;
}
$_SESSION[x]-print_type();
print $_SESSION[x]-get_v()-format(d.m.Y);
?
Expected result:
First call:
New object created x is DateTime 08.08.2007
Second call:
x is DateTime 08.08.2007
Actual result:
--
First call:
New object created x is DateTime 08.08.2007
Second call:
x is DateTime Warning: DateTime::format(): The DateTime object has not
been correctly initialized by its constructor in
/home/peter/workspace/Kurse/html/t1.php on line 28
--
Edit bug report at http://bugs.php.net/?id=42239edit=1
--
Try a CVS snapshot (PHP 4.4):
http://bugs.php.net/fix.php?id=42239r=trysnapshot44
Try a CVS snapshot (PHP 5.2):
http://bugs.php.net/fix.php?id=42239r=trysnapshot52
Try a CVS snapshot (PHP 6.0):
http://bugs.php.net/fix.php?id=42239r=trysnapshot60
Fixed in CVS: http://bugs.php.net/fix.php?id=42239r=fixedcvs
Fixed in release:
http://bugs.php.net/fix.php?id=42239r=alreadyfixed
Need backtrace: http://bugs.php.net/fix.php?id=42239r=needtrace
Need Reproduce Script:http://bugs.php.net/fix.php?id=42239r=needscript
Try newer version:http://bugs.php.net/fix.php?id=42239r=oldversion
Not developer issue: http://bugs.php.net/fix.php?id=42239r=support
Expected behavior:http://bugs.php.net/fix.php?id=42239r=notwrong
Not enough info:
http://bugs.php.net/fix.php?id=42239r=notenoughinfo
Submitted twice:
http://bugs.php.net/fix.php?id=42239r=submittedtwice
register_globals: http://bugs.php.net/fix.php?id=42239r=globals
PHP 3 support discontinued: http://bugs.php.net/fix.php?id=42239r=php3
Daylight Savings: http://bugs.php.net/fix.php?id=42239r=dst
IIS Stability:http://bugs.php.net/fix.php?id=42239r=isapi
Install GNU Sed: http://bugs.php.net/fix.php?id=42239r=gnused
Floating point limitations: http://bugs.php.net/fix.php?id=42239r=float
No Zend Extensions: http://bugs.php.net/fix.php?id=42239r=nozend
MySQL Configuration Error:http://bugs.php.net/fix.php?id=42239r=mysqlcfg
#41350 [Com]: Error in my_thread_global_end()
ID: 41350 Comment by: xavier at codewordx dot com Reported By: graham at directhostinguk dot com Status: Assigned Bug Type: MySQL related Operating System: Windows 2003 PHP Version: 5.2.3 Assigned To: edink New Comment: So, it looks like this problem has not been fixed. Has it? Is there a CVS snap to php 521? Or can somebody just email me the correct libmysql.dll? It would be great to finally fix this issue. Thanks, Xavier Previous Comments: [2007-08-02 14:01:32] phpuser at gmail dot com Please don't forget about php_pdo_mysql.dll! [2007-07-24 10:45:26] [EMAIL PROTECTED] Assigning to edink since we need to upgrade the bundled MySQL libraries. [2007-07-24 10:24:18] nick dot dixon at gmail dot com I see the same with 5.2.3 on Windows 2000 whenever php_mysql or php_mysqli (or both) are enabled So either the fault is in both php_mysql.dll AND php_mysqli.dll, or it's a problem with the MySQL client library (libmySQL.dll). Setting mysql.allow_persistent = Off makes no difference. MySQL version is 5.0.45, with the libmySQL.dll copied to a directory that's in the PATH (the PHP ext directory) Minimal test case using PHP cli: php -v PHP 5.2.3 (cli) (built: May 31 2007 09:37:22) Copyright (c) 1997-2007 The PHP Group Zend Engine v2.2.0, Copyright (c) 1998-2007 Zend Technologies Now if I run the CLI and send EOF: php ^Z (...pause of about 6 seconds...) Error in my_thread_global_end(): 1 threads didn't exit [2007-07-19 11:16:47] ng dot sick dot no at gmail dot com Tried the latest CVS snaps today (php5.2-win32-200707120030.zip) with php5apache22.dll, MySQL 5.0.45 Server on Windows XP, but Apache 2.2.4's log still shows up: Error in my_thread_global_end(): 1 threads didn't exit [2007-07-18 23:27:32] aaronbair at hotmail dot com CLI and FAST-CGI can not handle persistent MySQL connections. How can an unloaded processes remember a connection? Turn that option off in php.ini and the error goes away. mysql.allow_persistent = Off The real problem here is that this option is set On in php.ini-recommended 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/41350 -- Edit this bug report at http://bugs.php.net/?id=41350edit=1
#42237 [Opn-Csd]: [PATCH] stream_copy_to_stream returns invalid values for memmapped streams
ID: 42237
Updated by: [EMAIL PROTECTED]
Reported By: andrew dot minerd at sellingsource dot com
-Status: Open
+Status: Closed
Bug Type: Streams related
Operating System: Gentoo
PHP Version: 5.2.4RC1
New Comment:
This bug has been fixed in CVS.
Snapshots of the sources are packaged every three hours; this change
will be in the next snapshot. You can grab the snapshot at
http://snaps.php.net/.
Thank you for the report, and for helping us make PHP better.
Previous Comments:
[2007-08-07 20:37:07] andrew dot minerd at sellingsource dot com
Erm, I changed haveread to written for clarity... obviously you'd have
to define the variable, etc -- that was missing from my patch. :-p
[2007-08-07 20:26:00] andrew dot minerd at sellingsource dot com
Patch:
--- streams.c 2007-01-15 09:07:07.0 -0800
+++ streams2.c 2007-08-07 13:23:14.0 -0700
@@ -1309,11 +1309,11 @@
p = php_stream_mmap_range(src, php_stream_tell(src),
maxlen, PHP_STREAM_MAP_MODE_SHARED_READONLY, mapped);
if (p) {
- haveread = php_stream_write(dest, p, mapped);
+ written = php_stream_write(dest, p, mapped);
php_stream_mmap_unmap(src);
- return mapped;
+ return written;
}
}
[2007-08-07 20:24:04] andrew dot minerd at sellingsource dot com
Description:
When copying from a memmapped stream, stream_copy_to_stream returns the
length of the memory-mapped segment, regardless of how much data was
actually written to the recipient stream.
Reproduce code:
---
?php
class DummyWriteStream
{
function stream_open($path, $mode, $options, $opened_path) { return
TRUE; }
function stream_write($data) { return 0; }
}
stream_wrapper_register('test2', 'DummyWriteStream');
$fp1 = fopen('/etc/hosts', 'r');
$fp2 = fopen('test2://test', 'w');
var_dump(stream_copy_to_stream($fp1, $fp2, 8192));
?
Expected result:
int(0)
Actual result:
--
int(1228)
--
Edit this bug report at http://bugs.php.net/?id=42237edit=1
#42240 [NEW]: Consecutive calls to imap_mail_compose drops parameter arrays
From: php dot net dot alias at fremnet dot net
Operating system: Linux
PHP version: 5CVS-2007-08-08 (snap)
PHP Bug Type: IMAP related
Bug description: Consecutive calls to imap_mail_compose drops parameter arrays
Description:
Consecutive calls to imap_mail_compose drops the arrays passed in parts[]
Note the missing '; name=file1.ext' and '; filename=file1.ext' for the
second echo in the actual result.
I've tested (and had this tested) on several Linux versions and two
windows versions. Before posting I built a Linux PHP from the latest
snapshot.
Reproduce code:
---
$Envelope = array('date' = date('r'));
$Parts = array(
array('type' = TYPEMULTIPART, 'subtype' = 'mixed'),
array('description' = 'file1.ext',
'type' = TYPEAPPLICATION, 'subtype' =
'octet-binary','encoding' = ENCBINARY,
'type.parameters' = array('name' = 'file1.ext'),
'disposition.type' = 'attachment', 'disposition' =
array('filename' = 'file1.ext'),
'contents.data' = 'the contents of file1'),
array('type' = TYPETEXT, 'subtype' = 'PLAIN', 'contents.data' =
'Any body will do')
);
echo imap_mail_compose($Envelope, $Parts).\n\n\n;
echo imap_mail_compose($Envelope, $Parts);
Expected result:
Date: Wed, 08 Aug 2007 13:23:36 +1000
MIME-Version: 1.0
Content-Type: MULTIPART/mixed;
BOUNDARY=8323328-1804289383-1186543416=:27980
--8323328-1804289383-1186543416=:27980
Content-Type: APPLICATION/octet-binary; name=file1.ext
Content-Transfer-Encoding: BASE64
Content-Description: file1.ext
Content-Disposition: attachment; filename=file1.ext
dGhlIGNvbnRlbnRzIG9mIGZpbGUx
--8323328-1804289383-1186543416=:27980
Content-Type: TEXT/PLAIN; CHARSET=US-ASCII
Any body will do
--8323328-1804289383-1186543416=:27980--
Date: Wed, 08 Aug 2007 13:23:36 +1000
MIME-Version: 1.0
Content-Type: MULTIPART/mixed;
BOUNDARY=8323328-1804289383-1186543416=:27980
--8323328-1804289383-1186543416=:27980
Content-Type: APPLICATION/octet-binary; name=file1.ext
Content-Transfer-Encoding: BASE64
Content-Description: file1.ext
Content-Disposition: attachment; filename=file1.ext
dGhlIGNvbnRlbnRzIG9mIGZpbGUx
--8323328-1804289383-1186543416=:27980
Content-Type: TEXT/PLAIN; CHARSET=US-ASCII
Any body will do
--8323328-1804289383-1186543416=:27980--
Actual result:
--
Date: Wed, 08 Aug 2007 13:24:15 +1000
MIME-Version: 1.0
Content-Type: MULTIPART/mixed;
BOUNDARY=8323328-1804289383-1186543455=:27987
--8323328-1804289383-1186543455=:27987
Content-Type: APPLICATION/octet-binary; name=file1.ext
Content-Transfer-Encoding: BASE64
Content-Description: file1.ext
Content-Disposition: attachment; filename=file1.ext
dGhlIGNvbnRlbnRzIG9mIGZpbGUx
--8323328-1804289383-1186543455=:27987
Content-Type: TEXT/PLAIN; CHARSET=US-ASCII
Any body will do
--8323328-1804289383-1186543455=:27987--
Date: Wed, 08 Aug 2007 13:24:15 +1000
MIME-Version: 1.0
Content-Type: MULTIPART/mixed;
BOUNDARY=8323328-846930886-1186543455=:27987
--8323328-846930886-1186543455=:27987
Content-Type: APPLICATION/octet-binary
Content-Transfer-Encoding: BASE64
Content-Description: file1.ext
Content-Disposition: attachment
dGhlIGNvbnRlbnRzIG9mIGZpbGUx
--8323328-846930886-1186543455=:27987
Content-Type: TEXT/PLAIN; CHARSET=US-ASCII
Any body will do
--8323328-846930886-1186543455=:27987--
--
Edit bug report at http://bugs.php.net/?id=42240edit=1
--
Try a CVS snapshot (PHP 4.4):
http://bugs.php.net/fix.php?id=42240r=trysnapshot44
Try a CVS snapshot (PHP 5.2):
http://bugs.php.net/fix.php?id=42240r=trysnapshot52
Try a CVS snapshot (PHP 6.0):
http://bugs.php.net/fix.php?id=42240r=trysnapshot60
Fixed in CVS: http://bugs.php.net/fix.php?id=42240r=fixedcvs
Fixed in release:
http://bugs.php.net/fix.php?id=42240r=alreadyfixed
Need backtrace: http://bugs.php.net/fix.php?id=42240r=needtrace
Need Reproduce Script:http://bugs.php.net/fix.php?id=42240r=needscript
Try newer version:http://bugs.php.net/fix.php?id=42240r=oldversion
Not developer issue: http://bugs.php.net/fix.php?id=42240r=support
Expected behavior:http://bugs.php.net/fix.php?id=42240r=notwrong
Not enough info:
http://bugs.php.net/fix.php?id=42240r=notenoughinfo
Submitted twice:
http://bugs.php.net/fix.php?id=42240r=submittedtwice
register_globals: http://bugs.php.net/fix.php?id=42240r=globals
PHP 3 support discontinued: http://bugs.php.net/fix.php?id=42240r=php3
Daylight Savings: http://bugs.php.net/fix.php?id=42240r=dst
IIS Stability:http://bugs.php.net/fix.php?id=42240r=isapi
Install GNU Sed: http://bugs.php.net/fix.php?id=42240r=gnused
Floating point limitations: http://bugs.php.net/fix.php?id=42240r=float
No Zend Extensions: http://bugs.php.net/fix.php?id=42240r=nozend
MySQL Configuration Error:
