#39991 [Fbk-Opn]: session_write_close
ID: 39991 User updated by: mauricebis at gmail dot com Reported By: mauricebis at gmail dot com -Status: Feedback +Status: Open -Bug Type: Filesystem function related +Bug Type: Session related Operating System: linux -PHP Version: 4.4.4 +PHP Version: 4.4.3-dev New Comment: I have one process P1 which calls session_start() and then sets some session variables. I've another proces P2 which also calls session_start() at the beginning and which is blocked due to the locking policy of session_start() waiting for the lock to be released. P1 now calls session_write_close(). We would then expect P2 to read the new values of the session variables. But I experienced a race condition whereby P2 was allowed to proceed and couldn't read the new values of the session variables. In other words, it seems that in some situations, session_write_close() releases the lock before the possible updates to session variables are made visible to other processes. Previous Comments: [2006-12-30 22:37:32] [EMAIL PROTECTED] Not enough information was provided for us to be able to handle this bug. Please re-read the instructions at http://bugs.php.net/how-to-report.php If you can provide more information, feel free to add it to this bug and change the status back to Open. Thank you for your interest in PHP. [2006-12-30 11:10:35] mauricebis at gmail dot com Description: I experienced a race situation with session_write_close where the lock (acquired in session_start) was released before the updated $_SESSION variables were visible to other processes. Another process blocked on session_start was allowed to proceed but could not read the session variables supposedly written through session_write_close. -- Edit this bug report at http://bugs.php.net/?id=39991edit=1
#39984 [Csd]: Response header sent as 302 despite being set to 301
ID: 39984 User updated by: marc dot bau at gmx dot net Reported By: marc dot bau at gmx dot net Status: Closed Bug Type: IIS related Operating System: WinXP PHP Version: 5.2.0 New Comment: Thank you. I will test the latest Snapshot. Are you able to backport this bugfix? I think this is very important and critical bug for older versions, too. Previous Comments: [2006-12-31 19:22:24] [EMAIL PROTECTED] 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. [2006-12-30 21:23:37] marc dot bau at gmx dot net hi. i've tested this and nothing is changed. I set a 301 and get a 302. HTTP/1.x 302 Object Moved Server: Microsoft-IIS/5.1 Date: Sat, 30 Dec 2006 21:22:05 GMT Connection: close Content-Type: text/html X-Powered-By: PHP/5.2.1RC2-dev Location: http://www.example.com [2006-12-30 13:22:47] [EMAIL PROTECTED] Please try using this CVS snapshot: http://snaps.php.net/php5.2-latest.tar.gz For Windows: http://snaps.php.net/win32/php5.2-win32-latest.zip Using the latests snaps I get: HTTP/1.1 301 Undescribed from both IIS 5.1 and IIS 7. [2006-12-29 19:16:56] marc dot bau at gmx dot net same results with ISAPI Plugin php5isapi.dll: GET /test.php HTTP/1.1 Host: localhost User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; de; rv:1.8.1.1) Gecko/20061204 Firefox/2.0.0.1 Accept: text/xml,application/xml,application/xhtml+xml,text/html;q=0.9,text/plain;q=0.8,image/png,*/*;q=0.5 Accept-Language: de,en;q=0.8,en-us;q=0.6,de-de;q=0.4,es;q=0.2 Accept-Encoding: gzip,deflate Accept-Charset: ISO-8859-1,utf-8;q=0.7,*;q=0.7 Keep-Alive: 300 Connection: keep-alive Cookie: PHPSESSID=m9qi6v871710hj32f7b5cq6317; ASPSESSIONIDQQBCCSTD=MIFPNOKCDKGFBIKNGDIINLMM; CFID=3396; CFTOKEN=156ca9b801cf2d95%2DCF7CD840%2DBCDB%2D4EA9%2D271106C3DB1FE210; JSESSIONID=e0307f68472e511136a6 HTTP/1.x 302 Object Moved Server: Microsoft-IIS/5.1 Date: Fri, 29 Dec 2006 19:15:30 GMT Connection: close Content-Type: text/html X-Powered-By: PHP/5.2.0 Location: http://example.com [2006-12-29 18:36:01] marc dot bau at gmx dot net Installing Apache on Windows makes no sense to me. I know it is working with Apache 2.0 and CGI on a Linux (SuSE 9.3) box. ASP Code Example - works: %@ Language=VBScript % % Response.Status=301 Moved Permanently Response.AddHeader Location, http://www.example.com/; % ASP Headers results: GET /test.asp HTTP/1.1 Host: localhost User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; de; rv:1.8.1.1) Gecko/20061204 Firefox/2.0.0.1 Accept: text/xml,application/xml,application/xhtml+xml,text/html;q=0.9,text/plain;q=0.8,image/png,*/*;q=0.5 Accept-Language: de,en;q=0.8,en-us;q=0.6,de-de;q=0.4,es;q=0.2 Accept-Encoding: gzip,deflate Accept-Charset: ISO-8859-1,utf-8;q=0.7,*;q=0.7 Keep-Alive: 300 Connection: keep-alive Cookie: PHPSESSID=m9qi6v871710hj32f7b5cq6317; ASPSESSIONIDQQBCCSTD=MIFPNOKCDKGFBIKNGDIINLMM HTTP/1.x 301 Moved Permanently Server: Microsoft-IIS/5.1 Date: Fri, 29 Dec 2006 18:27:01 GMT X-Powered-By: ASP.NET Location: http://www.example.com/ Content-Length: 0 Content-Type: text/html Cache-Control: private ColdFusion MX 7.02 Example - Code: CFHEADER statusCode=301 statusText=Moved Permanently CFHEADER name=Location value=http://www.example.com/; CFMX Header Results: GET /test.cfm HTTP/1.1 Host: localhost User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; de; rv:1.8.1.1) Gecko/20061204 Firefox/2.0.0.1 Accept: text/xml,application/xml,application/xhtml+xml,text/html;q=0.9,text/plain;q=0.8,image/png,*/*;q=0.5 Accept-Language: de,en;q=0.8,en-us;q=0.6,de-de;q=0.4,es;q=0.2 Accept-Encoding: gzip,deflate Accept-Charset: ISO-8859-1,utf-8;q=0.7,*;q=0.7 Keep-Alive: 300 Connection: keep-alive Cookie: PHPSESSID=m9qi6v871710hj32f7b5cq6317; ASPSESSIONIDQQBCCSTD=MIFPNOKCDKGFBIKNGDIINLMM HTTP/1.x 301 Moved Permanently Server: Microsoft-IIS/5.1 Date: Fri, 29 Dec 2006 18:33:27 GMT X-Powered-By: ASP.NET Connection: close Set-Cookie: CFID=3396;expires=Fri, 12-Jan-2007 18:33:27 GMT;path=/ Set-Cookie: CFTOKEN=156ca9b801cf2d95%2DCF7CD840%2DBCDB%2D4EA9%2D271106C3DB1FE210;expires=Fri, 12-Jan-2007 18:33:27 GMT;path=/ Set-Cookie: JSESSIONID=e0307f68472e511136a6;path=/ Location: http://www.example.com/ Content-Language: de-DE Content-Type: text/html; charset=UTF-8 All on the same machine this PHP 5.2 is installed, too. Now - i think - IIS is not the cause of this bug.
#39993 [Com]: tr_TR.UTF-8 locale has problems with PHP
ID: 39993 Comment by: tokul at users dot sourceforge dot net Reported By: tunix at raptiye dot org Status: Assigned Bug Type: Date/time related Operating System: Arch Linux PHP Version: 5.2.0 Assigned To: derick New Comment: Issue is not fixed in 5.2.x snapshots (200701011130). You are using locale dependent case insensitive lookups and assume locale independent case sensitivity rules. In Turkish locale 'latin small i' is not same thing as 'latin capital i'. Turks have different case sensitivity rules. Reproduce code (TZ='Europe/Helsinki' /usr/bin/php /path/test-locale.php): --- ?php var_dump(setlocale(LC_ALL,'tr_TR.UTF-8')); var_dump(date_default_timezone_get()); var_dump(setlocale(LC_CTYPE,0)); --- Expected result: --- string(11) tr_TR.UTF-8 string(15) Europe/Helsinki string(11) tr_TR.UTF-8 --- Second line depends on default timezone setting. Make sure that you have 'i' symbol in timezone name. Actual result (PHP 5.2.0-8 debian and PHP 5.2.1RC2-dev snapshot): --- string(11) tr_TR.UTF-8 Fatal error: date_default_timezone_get(): Timezone database is corrupt - this should *never* happen! in /path/test-locale.php on line 3 --- Patch by [EMAIL PROTECTED] is not correct, because it does not preserve existing LC_CTYPE value and makes all strtolower/strtoupper calls locale independent when PHP manual states that these calls are locale dependent. Result after Iliaa's patch is applied: --- string(11) tr_TR.UTF-8 string(15) Europe/Helsinki string(1) C --- Previous Comments: [2006-12-30 23:45:52] [EMAIL PROTECTED] Another option that is a bit more performance friendly is something like this: http://bb.prohost.org/patch/date.txt [2006-12-30 23:08:23] [EMAIL PROTECTED] Its is reproducible with the snapshot. I believe this happens because of strcasecmp() (used in seek_to_tz_position()) behaving weird with tr_TR locale (I remember some similar problems in the past), using something like tolower() memcmp() should do the trick. [2006-12-30 20:46:30] [EMAIL PROTECTED] Please try using this CVS snapshot: http://snaps.php.net/php5.2-latest.tar.gz For Windows: http://snaps.php.net/win32/php5.2-win32-latest.zip [2006-12-30 18:22:08] tunix at raptiye dot org Description: I type ?php echo date(l); ? into an empty php file and then run it in command line prompt, and it prints this error message: Fatal error: date(): Timezone database is corrupt - this should *never* happen! in Command line code on line 1 If I use tr_TR.UTF-8 locale, then I can produce this error. But if I use tr_TR.ISO8859-9 or C locales, it doesn't print the error message. Although, tr_TR.ISO8859-9 and C locales return Saturday which is English. It should return Cumartesi (turkish). GNU date command works fine with UTF-8 locale. [19:07] ([EMAIL PROTECTED] ~)$ TZ=Europe/Istanbul LANG=tr_TR.UTF-8 date +%A Cumartesi Reproduce code: --- [19:06] ([EMAIL PROTECTED] ~)$ TZ=Europe/Istanbul LANG=tr_TR.UTF-8 php -r date(l); Fatal error: date(): Timezone database is corrupt - this should *never* happen! in Command line code on line 1 Expected result: It's supposed to be: [19:06] ([EMAIL PROTECTED] ~)$ TZ=Europe/Istanbul LANG=tr_TR.UTF-8 php -r date(l); Cumartesi -- Edit this bug report at http://bugs.php.net/?id=39993edit=1
#39651 [Asn-Ver]: proc_open() descriptor spec for STDOUT append starts writing from beginning
ID: 39651
Updated by: [EMAIL PROTECTED]
Reported By: rherror404 at gmail dot com
-Status: Assigned
+Status: Verified
Bug Type: Program Execution
Operating System: Windows
-PHP Version: 5.2.0
+PHP Version: *
Assigned To: nlopess
New Comment:
I do verify the bug, but I wasn't able to fix it.
The problem is that I think windows doesn't support the append mode
when using HANDLEs. So, when we call _get_osfhandle() to convert the fd
to an HANDLE, windows loose this information. (yes, we need to convert
to an handle because CreateProcess() requires it).
I'm leacing open as someone might have some idea (no, I don't know how
to emulate it, as after forking we loose the control over the new
process..)
Previous Comments:
[2006-11-27 23:09:11] [EMAIL PROTECTED]
Not reproducible on Linux.
[2006-11-27 22:49:38] rherror404 at gmail dot com
Description:
Defining the descriptor spec for STDOUT for a call to proc_open() to
append to a file instead starts writing from beginning (not at the end
as one would expect).
C:\WINDOWS\Tempphp launch1.php
Reproduce code:
---
C:\WINDOWS\Temptype launch1.php
?
$dspec = array(0 = array(pipe, r)
, 1 = array(file, 'C:\WINDOWS\TEMP\launch_stdout.txt', a)
, 2 = array(file, 'C:\WINDOWS\TEMP\launch_stderr.txt', a)
);
$i = 5; $inputpackage = serialize($i);
$proc = proc_open('php C:\WINDOWS\TEMP\launch2.php', $dspec, $pipes);
if ( is_resource($proc) ) {fwrite($pipes[0], $inputpackage);
fclose($pipes[0]);
proc_close($proc);}
$i = 2; $inputpackage = serialize($i);
$proc = proc_open('php C:\WINDOWS\TEMP\launch2.php', $dspec, $pipes);
if ( is_resource($proc) ) {fwrite($pipes[0], $inputpackage);
fclose($pipes[0]);
proc_close($proc);}
exit();
?
C:\WINDOWS\Temptype launch2.php
?
function tostdout( $x ) {echo date('[Y-m-d H:i:s (T P)]') . PID .
getmypid(
) . $x\r\n;}
$inbuffer = fgets(STDIN, 8192);
$i = unserialize($inbuffer);
for ( $j = 0; $j $i; $j++ ) {tostdout($j : $i); sleep(1);}
exit();
?
C:\WINDOWS\Temp
Expected result:
C:\WINDOWS\Temptype launch_stdout.txt
[2006-11-27 16:33:53 (CST -06:00)] PID 4492 0 : 5
[2006-11-27 16:33:54 (CST -06:00)] PID 4492 1 : 5
[2006-11-27 16:33:55 (CST -06:00)] PID 4492 2 : 5
[2006-11-27 16:33:56 (CST -06:00)] PID 4492 3 : 5
[2006-11-27 16:33:57 (CST -06:00)] PID 4492 4 : 5
[2006-11-27 16:33:58 (CST -06:00)] PID 6808 0 : 2
[2006-11-27 16:33:59 (CST -06:00)] PID 6808 1 : 2
/*
I would expect the second process to append its output
to (the end of) the output of the first process.
*/
Actual result:
--
C:\WINDOWS\Temptype launch_stdout.txt
[2006-11-27 16:33:58 (CST -06:00)] PID 6808 0 : 2
[2006-11-27 16:33:59 (CST -06:00)] PID 6808 1 : 2
[2006-11-27 16:33:55 (CST -06:00)] PID 4492 2 : 5
[2006-11-27 16:33:56 (CST -06:00)] PID 4492 3 : 5
[2006-11-27 16:33:57 (CST -06:00)] PID 4492 4 : 5
/*
The second process has over-written lines one and two
of the output of the first process.
*/
--
Edit this bug report at http://bugs.php.net/?id=39651edit=1
#39997 [Opn]: allow_url_fopen 2.0
ID: 39997 User updated by: phpnet at gwaihir dot net Reported By: phpnet at gwaihir dot net Status: Open Bug Type: Feature/Change Request Operating System: all? PHP Version: 5.2.0 New Comment: I noticed that it's probably more elegant if this yes, an URL is ok here be an option to set in the stream's context. Previous Comments: [2006-12-31 18:58:45] phpnet at gwaihir dot net Description: Securing PHP against accidentally opening a file/stream from a URL instead of the local filesystem is nice, however allow_url_fopen as it is, is just too limited, it needs an explicit only setting in addition to just on or off. In most real world situations, one doesn't want to forbid URL opening server wide, but it would be way nice if it didn't happen by accidental security oversight. So, what I'd really want is a setting that allows URL fopen only if I somehow explicitly tell the function I am using that it should expect a URL. [Similar concerns are voiced in the responses here: http://bugs.php.net/bug.php?id=28684 The poster is asking for a different feature though, so continued this seperate request.] Reproduce code: --- Would go something like this: PHP.ini: allow_url_fopen = explicit Script: //mode 'u' allows me to open from a URL fopen(http://example.org/somefile.txt, 'ua+'); //- should work fine fopen(http://example.org/somefile.txt, 'a+'); //- should give a not allowed error Similar ought to go for all functions capable of URL opening, of course. A default of allow_url_fopen = On still maintains backwards compatibility. -- Edit this bug report at http://bugs.php.net/?id=39997edit=1
#39984 [Opn-Fbk]: Response header sent as 302 despite being set to 301
ID: 39984 Updated by: [EMAIL PROTECTED] Reported By: marc dot bau at gmx dot net -Status: Open +Status: Feedback Bug Type: IIS related Operating System: WinXP PHP Version: 5.2.0 New Comment: you need to use the 5.2 CVS snapshot Previous Comments: [2007-01-01 11:49:00] marc dot bau at gmx dot net same with php6.0-win32-200701010930: HTTP/1.x 302 Object Moved Server: Microsoft-IIS/5.1 Date: Mon, 01 Jan 2007 11:47:42 GMT Connection: close Content-Type: text/html X-Powered-By: PHP/6.0.0-dev Location: http://www.example.com [2007-01-01 11:28:37] marc dot bau at gmx dot net i'm sorry but i must reopen the case. i tested with snapshot php5.2-win32-200701010730 and i got this: Isn't this the CVS Version you talked about? HTTP/1.x 302 Object Moved Server: Microsoft-IIS/5.1 Date: Mon, 01 Jan 2007 11:26:59 GMT Connection: close Content-Type: text/html X-Powered-By: PHP/5.2.1RC2-dev Location: http://www.example.com [2007-01-01 11:12:18] marc dot bau at gmx dot net Thank you. I will test the latest Snapshot. Are you able to backport this bugfix? I think this is very important and critical bug for older versions, too. [2006-12-31 19:22:24] [EMAIL PROTECTED] 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. [2006-12-30 21:23:37] marc dot bau at gmx dot net hi. i've tested this and nothing is changed. I set a 301 and get a 302. HTTP/1.x 302 Object Moved Server: Microsoft-IIS/5.1 Date: Sat, 30 Dec 2006 21:22:05 GMT Connection: close Content-Type: text/html X-Powered-By: PHP/5.2.1RC2-dev Location: http://www.example.com 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/39984 -- Edit this bug report at http://bugs.php.net/?id=39984edit=1
#39984 [Fbk-Opn]: Response header sent as 302 despite being set to 301
ID: 39984 User updated by: marc dot bau at gmx dot net Reported By: marc dot bau at gmx dot net -Status: Feedback +Status: Open Bug Type: IIS related Operating System: WinXP PHP Version: 5.2.0 New Comment: But i have used the Snapshot php5.2-win32-200701010730 !? Previous Comments: [2007-01-01 16:17:05] [EMAIL PROTECTED] you need to use the 5.2 CVS snapshot [2007-01-01 11:49:00] marc dot bau at gmx dot net same with php6.0-win32-200701010930: HTTP/1.x 302 Object Moved Server: Microsoft-IIS/5.1 Date: Mon, 01 Jan 2007 11:47:42 GMT Connection: close Content-Type: text/html X-Powered-By: PHP/6.0.0-dev Location: http://www.example.com [2007-01-01 11:28:37] marc dot bau at gmx dot net i'm sorry but i must reopen the case. i tested with snapshot php5.2-win32-200701010730 and i got this: Isn't this the CVS Version you talked about? HTTP/1.x 302 Object Moved Server: Microsoft-IIS/5.1 Date: Mon, 01 Jan 2007 11:26:59 GMT Connection: close Content-Type: text/html X-Powered-By: PHP/5.2.1RC2-dev Location: http://www.example.com [2007-01-01 11:12:18] marc dot bau at gmx dot net Thank you. I will test the latest Snapshot. Are you able to backport this bugfix? I think this is very important and critical bug for older versions, too. [2006-12-31 19:22:24] [EMAIL PROTECTED] 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. 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/39984 -- Edit this bug report at http://bugs.php.net/?id=39984edit=1
#39984 [Opn-Csd]: Response header sent as 302 despite being set to 301
ID: 39984 Updated by: [EMAIL PROTECTED] Reported By: marc dot bau at gmx dot net -Status: Open +Status: Closed Bug Type: IIS related Operating System: WinXP PHP Version: 5.2.0 New Comment: Then it is probably due to IIS overwriting the Status code. Based on the current code in the CVS right now PHP sends the redirect code set by your application. Previous Comments: [2007-01-01 16:22:47] marc dot bau at gmx dot net But i have used the Snapshot php5.2-win32-200701010730 !? [2007-01-01 16:17:05] [EMAIL PROTECTED] you need to use the 5.2 CVS snapshot [2007-01-01 11:49:00] marc dot bau at gmx dot net same with php6.0-win32-200701010930: HTTP/1.x 302 Object Moved Server: Microsoft-IIS/5.1 Date: Mon, 01 Jan 2007 11:47:42 GMT Connection: close Content-Type: text/html X-Powered-By: PHP/6.0.0-dev Location: http://www.example.com [2007-01-01 11:28:37] marc dot bau at gmx dot net i'm sorry but i must reopen the case. i tested with snapshot php5.2-win32-200701010730 and i got this: Isn't this the CVS Version you talked about? HTTP/1.x 302 Object Moved Server: Microsoft-IIS/5.1 Date: Mon, 01 Jan 2007 11:26:59 GMT Connection: close Content-Type: text/html X-Powered-By: PHP/5.2.1RC2-dev Location: http://www.example.com [2007-01-01 11:12:18] marc dot bau at gmx dot net Thank you. I will test the latest Snapshot. Are you able to backport this bugfix? I think this is very important and critical bug for older versions, 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/39984 -- Edit this bug report at http://bugs.php.net/?id=39984edit=1
#39984 [Csd]: Response header sent as 302 despite being set to 301
ID: 39984 Updated by: [EMAIL PROTECTED] Reported By: marc dot bau at gmx dot net Status: Closed Bug Type: IIS related Operating System: WinXP PHP Version: 5.2.0 New Comment: From the PHP end of things the issue is resolved, if IIS does not properly handle the Status header in the event of redirects, that's hardly a PHP problem, no? Previous Comments: [2007-01-01 16:50:41] marc dot bau at gmx dot net But this won't help me anything if you tell me it should be fixed and it isn't. You should test this on IIS, while it is not working as expected and i cannot fix this myself. So - this problem is OPEN until the bug is really fixed. I don't know why your are closing it until it is working. [2007-01-01 16:32:16] [EMAIL PROTECTED] Then it is probably due to IIS overwriting the Status code. Based on the current code in the CVS right now PHP sends the redirect code set by your application. [2007-01-01 16:22:47] marc dot bau at gmx dot net But i have used the Snapshot php5.2-win32-200701010730 !? [2007-01-01 16:17:05] [EMAIL PROTECTED] you need to use the 5.2 CVS snapshot [2007-01-01 11:49:00] marc dot bau at gmx dot net same with php6.0-win32-200701010930: HTTP/1.x 302 Object Moved Server: Microsoft-IIS/5.1 Date: Mon, 01 Jan 2007 11:47:42 GMT Connection: close Content-Type: text/html X-Powered-By: PHP/6.0.0-dev Location: http://www.example.com 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/39984 -- Edit this bug report at http://bugs.php.net/?id=39984edit=1
#39984 [Csd]: Response header sent as 302 despite being set to 301
ID: 39984 User updated by: marc dot bau at gmx dot net Reported By: marc dot bau at gmx dot net Status: Closed Bug Type: IIS related Operating System: WinXP PHP Version: 5.2.0 New Comment: If Perl, ColdFusion and ASP Pages are correct and PHP not, what do you think is wrong? I think PHP! Maybe there is something wrong in the way how the status is set or how the status is transfered to IIS... i don't know if there is something special in IIS, but it looks like a PHP Bug, while all other script languages are correct. Previous Comments: [2007-01-01 16:53:35] [EMAIL PROTECTED] From the PHP end of things the issue is resolved, if IIS does not properly handle the Status header in the event of redirects, that's hardly a PHP problem, no? [2007-01-01 16:50:41] marc dot bau at gmx dot net But this won't help me anything if you tell me it should be fixed and it isn't. You should test this on IIS, while it is not working as expected and i cannot fix this myself. So - this problem is OPEN until the bug is really fixed. I don't know why your are closing it until it is working. [2007-01-01 16:32:16] [EMAIL PROTECTED] Then it is probably due to IIS overwriting the Status code. Based on the current code in the CVS right now PHP sends the redirect code set by your application. [2007-01-01 16:22:47] marc dot bau at gmx dot net But i have used the Snapshot php5.2-win32-200701010730 !? [2007-01-01 16:17:05] [EMAIL PROTECTED] you need to use the 5.2 CVS snapshot 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/39984 -- Edit this bug report at http://bugs.php.net/?id=39984edit=1
#39998 [NEW]: php.exe in downloadable .ZIP package compiled with different API than modules
From: solomierdaybasura at yahoo dot es Operating system: Windows XP PHP version: 5.2.0 PHP Bug Type: Unknown/Other Function Bug description: php.exe in downloadable .ZIP package compiled with different API than modules Description: I've downloaded PHP 5.2.0 from .ZIP and from the installer for windows. They do not contain the same php.exe file. php.exe in the .ZIP file is compiled with an old API (20050922), as I constantly got errors from module such as MySQL/MySQLi extensions not working because they are compiled with API 20060613. However, the files provided with the installer DO WORK, as php.exe is compiled correctly and matches the modules' API. Reproduce code: --- - Download PHP 5.2.0 .zip package (windows binaries) from http://www.php.net/downloads.php - Uncompress and place php.ini under c:\windows, properly configure it to activate mysql and mysqli extensions. - Type 'php -m' on the command line Expected result: [PHP Modules] . . mysql mysqli . . [Zend Modules] Actual result: -- PHP Warning: PHP Startup: mysql: Unable to initialize module Module compiled with module API=20060613 PHPcompiled with module API=20050922 These options need to match -- Edit bug report at http://bugs.php.net/?id=39998edit=1 -- Try a CVS snapshot (PHP 4.4): http://bugs.php.net/fix.php?id=39998r=trysnapshot44 Try a CVS snapshot (PHP 5.2): http://bugs.php.net/fix.php?id=39998r=trysnapshot52 Try a CVS snapshot (PHP 6.0): http://bugs.php.net/fix.php?id=39998r=trysnapshot60 Fixed in CVS: http://bugs.php.net/fix.php?id=39998r=fixedcvs Fixed in release: http://bugs.php.net/fix.php?id=39998r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=39998r=needtrace Need Reproduce Script:http://bugs.php.net/fix.php?id=39998r=needscript Try newer version:http://bugs.php.net/fix.php?id=39998r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=39998r=support Expected behavior:http://bugs.php.net/fix.php?id=39998r=notwrong Not enough info: http://bugs.php.net/fix.php?id=39998r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=39998r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=39998r=globals PHP 3 support discontinued: http://bugs.php.net/fix.php?id=39998r=php3 Daylight Savings: http://bugs.php.net/fix.php?id=39998r=dst IIS Stability:http://bugs.php.net/fix.php?id=39998r=isapi Install GNU Sed: http://bugs.php.net/fix.php?id=39998r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=39998r=float No Zend Extensions: http://bugs.php.net/fix.php?id=39998r=nozend MySQL Configuration Error:http://bugs.php.net/fix.php?id=39998r=mysqlcfg
#39960 [Fbk-Opn]: dllhost.exe application error
ID: 39960 User updated by: chv at cverdow dot com Reported By: chv at cverdow dot com -Status: Feedback +Status: Open Bug Type: IIS related Operating System: Windows XP SP2 PHP Version: 6CVS-2006-12-27 (CVS) New Comment: Thank you all for your efforts. I can't afford to be without PHP, any longer. I've installed the CGI interface, and that works without issue, including running the phpinfo() shell. I honestly would like to try to help you to track this down, but I have to have a stable production environment, I only have the one machine, and I don't have a serious dump generator anyway. I started life on mainframes, all the way back in the 1980s. I haven't forgotten how useful a good PMD dump can be. Since this is a rather low-level issue, we both know that being able to get one is probably going to be the only way to locate the problem efficiently. Since so many of us seem to be affected by this, and have been for some time, I would like to ask you to continue working on this. It can't be a configuration issue specific to any one machine (e.g., a driver conflict with some obscure utility that no one else would ever install). Too many of us have reported it. You really should be able to see this on any Windows XP box with IIS enabled. And, on one of your machines, you'll have access to a PMD. I'm sure I'm not the first to run out of time for experimenting, and to give up and install the CGI interface. I realise IIS on any flavor of Windows doesn't compare to Apache on Unix. I realise Microsoft would like for us to use ASP when we develop for this environment. But, some of us may be stuck with IIS in a few specific situations, for various reasons, and aren't about to write ASP just for these boxes. I'm sure we would all appreciate your tracking this down and fixing it. Thank you again, and good luck! Cynthia Previous Comments: [2006-12-29 16:54:22] [EMAIL PROTECTED] Could you try the same test with a script without a call to phpinfo(); A simple echo Hello World; or something simple like that. [2006-12-29 00:57:02] chv at cverdow dot com Thank you, Tony. I tried it. I'm still getting the same result -- but the memory address that's trying to write to itself is different. Should it help you to track this down, I am noticing that each time it aborts, the memory location is different, but it's always some location trying to write to itself that is failing. In my initial report, I was mistaked about where the error occurs. It is in the very last phase, after Windows is shutting down is displayed on the screen. Sorry. I was exploring the registry, and noticed two things I thought I'd bring to your attention. I've never been a registry expert. But, these two struck me as curious: HKEY_LOCAL_MACHINE SYSTEM ControlSet001 Control Nls MUILanguages RCV2 This contains a rather long list of .dlls and .exes, but php5isapi.dll is not in the list. HKEY_LOCAL_MACHINE SYSTEM ControlSet001 Services W3SVC Parameters Script Map .php = [PUT PATH HERE]\php5isapi.dll That is the exact text for the value. It has to be finding the API, or phpinfo.php wouldn't be running, right? But, put path here when I specifically browsed out to it when I entered it into IIS? That doesn't seem right. Honestly, neither does the fact that I have to put php.ini in C:\WINDOWS when C:\PHP5 is in my path in environment variables. Thank you again for your efforts. Please let me know if there is anything else I can try. [2006-12-27 09:37:13] [EMAIL PROTECTED] Please try using this CVS snapshot: http://snaps.php.net/php5.2-latest.tar.gz For Windows: http://snaps.php.net/win32/php5.2-win32-latest.zip [2006-12-27 00:45:08] chv at cverdow dot com IIS version is 5.1. [2006-12-27 00:39:14] chv at cverdow dot com Description: I'm basically opening this to let you know that the problem still exists. This references both what appears to be the latest production version (5.2.0 dated 02-Nov-2006), and 6CVS-2006-12-27 (17:30 GMT). I don't have MSVC6 or any other C dev environment on this machine, so I am unable to provide the backtrace you prefer. I have been unable to capture this in any of the dumps and logs that are available to me, possibly due to the place in the shutdown process this occurs. The problem is repeatable. I get it every time I load a local PHP page. I never get it when I only access any page on the Internet. DLL: php6isapi.dll INI: php.ini-recommended, modified as follows: - doc_root = C:\Inetpub\wwwroot; -
#39998 [Opn-Asn]: php.exe in downloadable .ZIP package compiled with different API than modules
ID: 39998 Updated by: [EMAIL PROTECTED] Reported By: solomierdaybasura at yahoo dot es -Status: Open +Status: Assigned Bug Type: Unknown/Other Function Operating System: Windows XP PHP Version: 5.2.0 -Assigned To: +Assigned To: edink Previous Comments: [2007-01-01 20:09:29] solomierdaybasura at yahoo dot es Description: I've downloaded PHP 5.2.0 from .ZIP and from the installer for windows. They do not contain the same php.exe file. php.exe in the .ZIP file is compiled with an old API (20050922), as I constantly got errors from module such as MySQL/MySQLi extensions not working because they are compiled with API 20060613. However, the files provided with the installer DO WORK, as php.exe is compiled correctly and matches the modules' API. Reproduce code: --- - Download PHP 5.2.0 .zip package (windows binaries) from http://www.php.net/downloads.php - Uncompress and place php.ini under c:\windows, properly configure it to activate mysql and mysqli extensions. - Type 'php -m' on the command line Expected result: [PHP Modules] . . mysql mysqli . . [Zend Modules] Actual result: -- PHP Warning: PHP Startup: mysql: Unable to initialize module Module compiled with module API=20060613 PHPcompiled with module API=20050922 These options need to match -- Edit this bug report at http://bugs.php.net/?id=39998edit=1
#39998 [Asn-Bgs]: php.exe in downloadable .ZIP package compiled with different API than modules
ID: 39998 Updated by: [EMAIL PROTECTED] Reported By: solomierdaybasura at yahoo dot es -Status: Assigned +Status: Bogus Bug Type: Unknown/Other Function Operating System: Windows XP PHP Version: 5.2.0 Assigned To: edink New Comment: The distro files are fine. You have most likely a mix up of two (or more) PHP installs. Previous Comments: [2007-01-01 20:09:29] solomierdaybasura at yahoo dot es Description: I've downloaded PHP 5.2.0 from .ZIP and from the installer for windows. They do not contain the same php.exe file. php.exe in the .ZIP file is compiled with an old API (20050922), as I constantly got errors from module such as MySQL/MySQLi extensions not working because they are compiled with API 20060613. However, the files provided with the installer DO WORK, as php.exe is compiled correctly and matches the modules' API. Reproduce code: --- - Download PHP 5.2.0 .zip package (windows binaries) from http://www.php.net/downloads.php - Uncompress and place php.ini under c:\windows, properly configure it to activate mysql and mysqli extensions. - Type 'php -m' on the command line Expected result: [PHP Modules] . . mysql mysqli . . [Zend Modules] Actual result: -- PHP Warning: PHP Startup: mysql: Unable to initialize module Module compiled with module API=20060613 PHPcompiled with module API=20050922 These options need to match -- Edit this bug report at http://bugs.php.net/?id=39998edit=1
