#50723 [Com]: Bug in garbage collector causes crash
ID: 50723 Comment by: garretts at microsoft dot com Reported By: garretts at microsoft dot com Status: No Feedback Bug Type: Reproducible crash Operating System: Windows PHP Version: 5.3.2RC1 New Comment: I've tested again with: PHP 5.3.3-dev (cli) (built: Feb 1 2010 12:22:19) And it is still crashing on the script. G Previous Comments: [2010-01-19 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". [2010-01-12 19:11:37] garretts at microsoft dot com Unfortunately, snapshots aren't working, but I updated from SVN this morning and compiled again, and the bug is still there. It's only happening on Windows, not Linux: Platform -- Linux 5.3.1 (from source) no Linux 5.3.2-rc1 (from source) no Win 5.2.12.1 (nts vc6) no Win 5.3.1 (nts vc9) no Win 5.3.2-rc1 (nts vc9) yes Win 5.3.3-svn (nts vc9) yes I'm not familiar with the garbage collector; I poked around, but I didn't get anywhere. [2010-01-11 23:29:51] johan...@php.net Please try using this snapshot: http://snaps.php.net/php5.3-latest.tar.gz For Windows: http://windows.php.net/snapshots/ I couldn't reproduce this on different configurations (not on windows though) and recently there were some fixes for gc. Could you please try the latest snapshot to make sure you're still seeing this after the changes went in? ---- [2010-01-11 23:06:32] garretts at microsoft dot com Description: I've got a script which I've pared down from a much larger one, that causes a crash when php exits. This happens in 5.3.3 as well. The repro script is 340 lines. Removing any code (even a print statement) makes the problem go away. Reproduce code: --- Repro script: http://fearthecowboy.com/downloads/test-crash.php.txt Expected result: It shouldn't crash. Actual result: -- trace: Function Arg 1 Arg 2 Arg 3 Source php5!gc_collect_cycles+505 008aff78 01d2f6c4 52f33031 php5!gc_collect_cycles+3ba 01d2f6e4 52fd49dc php5!gc_collect_cycles+54 0078 000d 01d2f720 php5!zend_deactivate+b2 0001 0088 0083be10 php5!php_request_shutdown+259 02eb0100 00980150 php!main+1526 0002 00984a10 009828d8 php!_setjmp3+160 7efde000 01d2fce4 771f9d72 kernel32!BaseThreadInitThunk+e 7efde000 d0f01e21 ntdll!__RtlUserThreadStart+70 00c934ea 7efde000 ntdll!_RtlUserThreadStart+1b 00c934ea 7efde000 -- Edit this bug report at http://bugs.php.net/?id=50723&edit=1
#50723 [Com]: Bug in garbage collector causes crash
ID: 50723 Comment by: garretts at microsoft dot com Reported By: garretts at microsoft dot com Status: Feedback Bug Type: Reproducible crash Operating System: Windows PHP Version: 5.3.2RC1 New Comment: Unfortunately, snapshots aren't working, but I updated from SVN this morning and compiled again, and the bug is still there. It's only happening on Windows, not Linux: Platform -- Linux 5.3.1 (from source) no Linux 5.3.2-rc1 (from source) no Win 5.2.12.1 (nts vc6) no Win 5.3.1 (nts vc9) no Win 5.3.2-rc1 (nts vc9) yes Win 5.3.3-svn (nts vc9) yes I'm not familiar with the garbage collector; I poked around, but I didn't get anywhere. Previous Comments: [2010-01-11 23:29:51] johan...@php.net Please try using this snapshot: http://snaps.php.net/php5.3-latest.tar.gz For Windows: http://windows.php.net/snapshots/ I couldn't reproduce this on different configurations (not on windows though) and recently there were some fixes for gc. Could you please try the latest snapshot to make sure you're still seeing this after the changes went in? ---- [2010-01-11 23:06:32] garretts at microsoft dot com Description: I've got a script which I've pared down from a much larger one, that causes a crash when php exits. This happens in 5.3.3 as well. The repro script is 340 lines. Removing any code (even a print statement) makes the problem go away. Reproduce code: --- Repro script: http://fearthecowboy.com/downloads/test-crash.php.txt Expected result: It shouldn't crash. Actual result: -- trace: Function Arg 1 Arg 2 Arg 3 Source php5!gc_collect_cycles+505 008aff78 01d2f6c4 52f33031 php5!gc_collect_cycles+3ba 01d2f6e4 52fd49dc php5!gc_collect_cycles+54 0078 000d 01d2f720 php5!zend_deactivate+b2 0001 0088 0083be10 php5!php_request_shutdown+259 02eb0100 00980150 php!main+1526 0002 00984a10 009828d8 php!_setjmp3+160 7efde000 01d2fce4 771f9d72 kernel32!BaseThreadInitThunk+e 7efde000 d0f01e21 ntdll!__RtlUserThreadStart+70 00c934ea 7efde000 ntdll!_RtlUserThreadStart+1b 00c934ea 7efde000 -- Edit this bug report at http://bugs.php.net/?id=50723&edit=1
#50723 [NEW]: Bug in garbage collector causes crash
From: garretts at microsoft dot com Operating system: Windows PHP version: 5.3.2RC1 PHP Bug Type: Reproducible crash Bug description: Bug in garbage collector causes crash Description: I've got a script which I've pared down from a much larger one, that causes a crash when php exits. This happens in 5.3.3 as well. The repro script is 340 lines. Removing any code (even a print statement) makes the problem go away. Reproduce code: --- Repro script: http://fearthecowboy.com/downloads/test-crash.php.txt Expected result: It shouldn't crash. Actual result: -- trace: Function Arg 1 Arg 2 Arg 3 Source php5!gc_collect_cycles+505 008aff78 01d2f6c4 52f33031 php5!gc_collect_cycles+3ba 01d2f6e4 52fd49dc php5!gc_collect_cycles+54 0078 000d 01d2f720 php5!zend_deactivate+b2 0001 0088 0083be10 php5!php_request_shutdown+259 02eb0100 00980150 php!main+1526 0002 00984a10 009828d8 php!_setjmp3+160 7efde000 01d2fce4 771f9d72 kernel32!BaseThreadInitThunk+e 7efde000 d0f01e21 ntdll!__RtlUserThreadStart+70 00c934ea 7efde000 ntdll!_RtlUserThreadStart+1b 00c934ea 7efde000 -- Edit bug report at http://bugs.php.net/?id=50723&edit=1 -- Try a snapshot (PHP 5.2): http://bugs.php.net/fix.php?id=50723&r=trysnapshot52 Try a snapshot (PHP 5.3): http://bugs.php.net/fix.php?id=50723&r=trysnapshot53 Try a snapshot (PHP 6.0): http://bugs.php.net/fix.php?id=50723&r=trysnapshot60 Fixed in SVN: http://bugs.php.net/fix.php?id=50723&r=fixed Fixed in SVN and need be documented: http://bugs.php.net/fix.php?id=50723&r=needdocs Fixed in release: http://bugs.php.net/fix.php?id=50723&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=50723&r=needtrace Need Reproduce Script: http://bugs.php.net/fix.php?id=50723&r=needscript Try newer version: http://bugs.php.net/fix.php?id=50723&r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=50723&r=support Expected behavior: http://bugs.php.net/fix.php?id=50723&r=notwrong Not enough info: http://bugs.php.net/fix.php?id=50723&r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=50723&r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=50723&r=globals PHP 4 support discontinued: http://bugs.php.net/fix.php?id=50723&r=php4 Daylight Savings:http://bugs.php.net/fix.php?id=50723&r=dst IIS Stability: http://bugs.php.net/fix.php?id=50723&r=isapi Install GNU Sed: http://bugs.php.net/fix.php?id=50723&r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=50723&r=float No Zend Extensions: http://bugs.php.net/fix.php?id=50723&r=nozend MySQL Configuration Error: http://bugs.php.net/fix.php?id=50723&r=mysqlcfg
#47999 [Opn->Bgs]: tempnam() fails to create file
ID: 47999 Updated by: garre...@php.net Reported By: phpbug at danf dot oib dot com -Status: Open +Status: Bogus Bug Type: Filesystem function related Operating System: win32 only - Windows Server 2003 PHP Version: 5.2.9 -Assigned To: +Assigned To: garretts New Comment: I'm unable to reproduce this with PHP 5.2.9-2 and PHP 5.3. I used your repro code, and tried: the command line: Successfully created C:\Users\garretts\AppData\Local\Temp\ran81CC.tmp. from a web page: Successfully created C:\Windows\Temp\ranBFA6.tmp. Previous Comments: [2009-04-17 16:41:22] phpbug at danf dot oib dot com Yes, D:\temp has Modify permission for Everyone. Remember, this worked in PHP 5.2.3 on the same server, so it can't be a permissions issue, assuming the method the tempnam() function uses to determine which directory to use was consistent from 5.2.3 forward. [2009-04-17 10:45:00] j...@php.net Check the permissions on the temporary files path (TEMP / TMP, or whatever it is set to in your system) or pass a path that is writable. [2009-04-17 03:34:46] phpbug at danf dot oib dot com Description: tempnam() does not create a temporary file, and silently fails. This worked fine in PHP 5.2.3, but starting failing in 5.2.6 (or somewhere in between). It still does not work in 5.2.8 or 5.2.9-1. I've tested with both the IIS module (php5isapi.dll) and php-cgi.exe, with the same results. open_basedir is off. Reproduce code: --- Expected result: Successfully created D:\temp\ran1E42.tmp. Actual result: -- Can't create tmpfile. -- Edit this bug report at http://bugs.php.net/?id=47999&edit=1
#48190 [Ver]: Content-type parameter "boundary" is not case-insensitive in HTTP uploads
ID: 48190 Updated by: garre...@php.net Reported By: carsten_sttgt at gmx dot de Status: Verified Bug Type: HTTP related Operating System: Windows NT PHP Version: 5.*CVS, 6CVS (2009-05-08) -Assigned To: +Assigned To: garretts New Comment: I'm testing a fix I've built for this right now. Previous Comments: [2009-10-07 02:04:34] ba dot mariam92 at yahoo dot com i don't now the answer f that up [2009-05-09 04:08:27] j...@php.net Yes, I know it's not an upload per se, but the code that handles is one that most of the time takes care of file uploads. :) Problem is in rfc1867.c:804, strstr() should be replaced with something that does the same but case-insensitively. [2009-05-08 23:23:57] carsten_sttgt at gmx dot de > Just curious, but what client actually uses > uppercase/mixed case "boundary" parameter name? I'm using imap_mail_compose() to build the 'header' and 'content' keys in the stream_context_create() options array. And then using this context with e.g. file_get_contents() to make the POST request. BTW: The above example is a HTTP POST request without a file upload. [2009-05-08 22:05:58] j...@php.net Just curious, but what client actually uses uppercase/mixed case "boundary" parameter name? (and [2009-05-08 21:41:55] carsten_sttgt at gmx dot de In my first post I have refereed to RFC2045, but RFC2616 is also very clear about this [1]: | The type, subtype, and parameter attribute names are | case- insensitive. Parameter values might or might | not be case-sensitive, depending on the semantics | of the parameter name. type = MULTIPART subtype = form-data parameter attribute name = BOUNDARY parameter value = 250-16659-1241787336=:9320 [1] http://www.w3.org/Protocols/rfc2616/rfc2616-sec3.html#sec3.7 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/48190 -- Edit this bug report at http://bugs.php.net/?id=48190&edit=1
#48959 [Opn]: is_readable() and filezise() do not return correctly
ID: 48959
Updated by: garre...@php.net
Reported By: trutas dot ctx at gmail dot com
Status: Open
Bug Type: Filesystem function related
Operating System: win32 - Windows Server 2003 x64
PHP Version: 5.3.0
Assigned To: pajoye
New Comment:
>> I'm using Windows 2003 x64 with PHP x64 via fastcgi.
I have a few questions:
1) Does this happen when you use the 32bit PHP binary on Windows 2003?
2) Does this only happen running under IIS (ie, can you replicate the
results from the command line?).
3) What user is your app running as?
G
Previous Comments:
[2009-08-10 17:30:47] trutas dot ctx at gmail dot com
I'm sorry for the DOMPDF_TEMP_DIR,
Initially this problem was discovered when using dompdf in this
environment - file_get_contents was a proxy workaround.
I have fully tested this version:
Reproduce code:
---
http://9tree.net/favicon.ico";);
//save it
file_put_contents($resolved_url, $image);
//tests
if(is_readable($resolved_url)) print "file readable, ";
if(filesize($resolved_url)) print "filezise found.";
?>
In Unix/Win32 it works perfectly.
This is only happening in Windows Server 2003 x64 IIS 6.0 where
tempnam("/tmp", "test_") returns something like
"C:\WINDOWS\Temp\tes20FB.tmp".
in the case of filesize i get a warning - "stat failed for
C:\WINDOWS\Temp\tes20FB.tmp ..."
Regards,
Carlos
[2009-08-10 15:27:03] paj...@php.net
I have no idea what DOMPDF_ is and how it is used.
Please provide a standalone script I can use to reproduce your problem,
as well as which paths are used by the script.
"- Please note that this problem does not happen in local folder to the
execution base (eg. "tmp_sub_folder/" ) - this only happens in the
system tmp folder in this setup."
It looks like a permission problem to me.
[2009-07-17 16:09:18] trutas dot ctx at gmail dot com
The environment could be the problem here,
I'm using Windows 2003 x64 with PHP x64 via fastcgi.
These are two IIS Servers with load balancer and a separate cluster
that serves the actual run files.
PHP is installed on D:\PHP on each IIS machine.
The problem came up using the library dompdf - it saves document
images content to temporary files in order to build the final pdf
document.
I've reduced the problem to the test code i've attached.
DOMPDF_TEMP_DIR is /tmp and writes to C:\Windows\tmp ...
- Please note that this problem does not happen in local folder to the
execution base (eg. "tmp_sub_folder/" ) - this only happens in the
system tmp folder in this setup.
This is the same setup environment as the one reported in the bug
48852 (about file_put_contents)
Regards,
[2009-07-17 15:34:47] paj...@php.net
Cannot reproduce on 2k8, vista and win7. Pls note that I replaced the
my_file_... with the normal file_get_contents function.
Can you paste a working script pls?
[2009-07-17 15:08:28] trutas dot ctx at gmail dot com
Just tested - file_exists() returns false incorrectly too.
I´ve worked around it all with checking for fopen($file, 'r') and
forcing file_get_contents() - it works, file exists, is readable and
returns the content.
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/48959
--
Edit this bug report at http://bugs.php.net/?id=48959&edit=1
#44994 [NoF]: exec() produces zombie processes on Windows, hangs Apache
ID: 44994
Updated by: garre...@php.net
Reported By: dbarrett at vistaprint dot com
Status: No Feedback
Bug Type: Program Execution
Operating System: win32 only - 2003 Server, 64-bit
PHP Version: 5.2.6
Assigned To: garretts
New Comment:
I'm trying to come up with a reproducible test case for this bug.
If anyone has a complete test scenario for this please post it. I
simply can't replicate the effects here.
G
Previous Comments:
[2009-08-27 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".
[2009-08-19 19:06:40] garre...@php.net
Please try using this snapshot:
http://snaps.php.net/php5.3-latest.tar.gz
For Windows:
http://windows.php.net/snapshots/
[2009-08-19 17:26:55] garre...@php.net
I've seen this happen in other languages too.
This happens when the pipe between the parent and child fills up, and
cmd.exe ends up blocking and creates a race condition. (Windows script
host languages trip up on this quickly)
in popen_ex() ( in tsrm_win32.c) the pipe is creates with a 2k buffer:
if (!str_len || !CreatePipe(&in, &out, &security, 2048L)) {
this should probably be significantly larger. I'd certainly go with at
least 16k or 32k. (hey, it's only memory :D)
as well, the elimination of the unrequired cmd.exe as the immediate
child process would eliminate the possibility that *it's* buffer gets
overwhelmed too. (which solves bug #43327, and I've passed a patch to
Pierre for that.)
[2009-06-08 16:40:15] alex at bartl dot net
Reproducable with PHP 5.2.9-1 on Windows2003 Server with Apache2.2
Workaround with calling session_write_close() before calling exec()
confirmed working
NOT reproducable with PHP 5.2.1 on Windows 2000 Server with IIS5
anyway, seems to be a duplicate of Bug#44942
[2009-05-04 14:56:29] mk1992 at hotmail dot com
same problem here, php 5.2.9, w2k3, IIS: shell_exec hanging on
production server but not on development server. Can't do downgrade to
5.1.x.
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/44994
--
Edit this bug report at http://bugs.php.net/?id=44994&edit=1
#49244 [Ver]: Floating point NaN cause garbage characters
ID: 49244
Updated by: garre...@php.net
Reported By: ronlentjes at yahoo dot com dot au
Status: Verified
Bug Type: Scripting Engine problem
Operating System: Linux Fedora 8
PHP Version: 5.3.0
New Comment:
sjoerd -- That fix works fine for me.
Can you commit that?
Previous Comments:
[2009-08-20 19:19:13] sjoerd-php at linuxonly dot nl
The problem is with calling php_sprintf_appendstring. Its 9th parameter
is not precision, it is length.
Index: ext/standard/formatted_print.c
===
--- ext/standard/formatted_print.c (revision 287513)
+++ ext/standard/formatted_print.c (working copy)
@@ -232,14 +232,14 @@
if (zend_isnan(number)) {
is_negative = (number<0);
php_sprintf_appendstring(buffer, pos, size, "NaN", 3, 0,
padding,
-alignment,
precision, is_negative, 0, always_sign);
+alignment, 3,
is_negative, 0, always_sign);
return;
}
if (zend_isinf(number)) {
is_negative = (number<0);
php_sprintf_appendstring(buffer, pos, size, "INF", 3, 0,
padding,
-alignment,
precision, is_negative, 0, always_sign);
+alignment, 3,
is_negative, 0, always_sign);
return;
}
[2009-08-20 11:15:47] sjoerd-php at linuxonly dot nl
Could reproduce with PHP 5.2.10.
[2009-08-14 04:25:22] ronlentjes at yahoo dot com dot au
Perhaps you test it differently than I do. I'll give you the easiest
way to see it happen:
put this in a file called test.php:
---
---
Output will be (bash, Fedora 8, Linux):
# php test.php
---
NaN*A
---
Output for browser will be NaN??? or NaN???F or other variations of
that.
This is reporducable on versions 4.2.2 (crash), 5.2.4, 5.3.0 (as
indicated previously).
I just retried this now.
Cheers,
Ron Lentjes
LC CLS.
[2009-08-13 14:29:39] ras...@php.net
I am unable to reproduce this in neither 5.2 nor 5.3, and Valgrind is
clean on Debian.
[2009-08-13 14:14:51] ronlentjes at yahoo dot com dot au
Description:
This has been an issue since 4.2.2 and still in 5.3.0.
$d = pow (-1.0, 0.3); // or anything causing NaN
echo "$d\n";
-> NAN
printf ("%f\n", $d);
(4.2.2) -> crash
(5.2.4) -> NaN
(5.3.0) -> NaN
(viewed in browser as NaN???)
Two issues here:
Inconsistent display of NAN for echo and NaN for printf.
Output of bogus characters after the 3 letters NaN for printf.
I think you are missing a '\0' null termination after the NaN
characters which probably cause a runaway to crash 4.2.2 but is just
'hanging' in there for the newer versions.
Cheers,
Ron Lentjes
LC CLS.
Reproduce code:
---
$d = pow (-1.0, 0.3);
echo "$d\n";
printf ("%f\n", $d);
Expected result:
NaN
NaN
Actual result:
--
(4.2.2)
NAN
crash
(5.2.4)
NAN
NaN
(5.3.0)
NAN
NaN
(viewed in browser as NaN???)
--
Edit this bug report at http://bugs.php.net/?id=49244&edit=1
#49148 [Opn]: combination of stream_get_line and fseek does not work correctly
ID: 49148 Updated by: garre...@php.net Reported By: mugeso at mugeso dot com Status: Open Bug Type: Streams related Operating System: win32 only - Windows XP SP3 PHP Version: 5.2.10 New Comment: This is reproduceable on Linux too. Previous Comments: [2009-08-04 07:44:16] mugeso at mugeso dot com Description: When use in combination of stream_get_line and fseek, reading a file which has only 2 lines without ending on EOF(like below) does fail. This happens on only Windows and with only "2lines file without ending on EOF". Reproduce code: --- 2lines.txt -- a b phpfile: -- http://bugs.php.net/?id=49148&edit=1
#44994 [Asn->Fbk]: exec() produces zombie processes on Windows, hangs Apache
ID: 44994
Updated by: garre...@php.net
Reported By: dbarrett at vistaprint dot com
-Status: Assigned
+Status: Feedback
Bug Type: Program Execution
Operating System: win32 only - 2003 Server, 64-bit
PHP Version: 5.2.6
Assigned To: garretts
New Comment:
Please try using this snapshot:
http://snaps.php.net/php5.3-latest.tar.gz
For Windows:
http://windows.php.net/snapshots/
Previous Comments:
[2009-08-19 17:26:55] garre...@php.net
I've seen this happen in other languages too.
This happens when the pipe between the parent and child fills up, and
cmd.exe ends up blocking and creates a race condition. (Windows script
host languages trip up on this quickly)
in popen_ex() ( in tsrm_win32.c) the pipe is creates with a 2k buffer:
if (!str_len || !CreatePipe(&in, &out, &security, 2048L)) {
this should probably be significantly larger. I'd certainly go with at
least 16k or 32k. (hey, it's only memory :D)
as well, the elimination of the unrequired cmd.exe as the immediate
child process would eliminate the possibility that *it's* buffer gets
overwhelmed too. (which solves bug #43327, and I've passed a patch to
Pierre for that.)
[2009-06-08 16:40:15] alex at bartl dot net
Reproducable with PHP 5.2.9-1 on Windows2003 Server with Apache2.2
Workaround with calling session_write_close() before calling exec()
confirmed working
NOT reproducable with PHP 5.2.1 on Windows 2000 Server with IIS5
anyway, seems to be a duplicate of Bug#44942
[2009-05-04 14:56:29] mk1992 at hotmail dot com
same problem here, php 5.2.9, w2k3, IIS: shell_exec hanging on
production server but not on development server. Can't do downgrade to
5.1.x.
[2009-04-28 22:52:53] diackne at gmail dot com
I have the same issue in windows 2008 web server iis 7 !!!
[2009-04-22 02:03:38] aliks0905 at gmail dot com
I have the same issue as well. I use the exec() function to
simultaneously upload files and sometimes cmd.exe freezes and all
following uploads fail.
I run on a Windows 2003 Server using Apache 2.2.11 and PHP 5.2.9
Looking forward to hearing a solution.
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/44994
--
Edit this bug report at http://bugs.php.net/?id=44994&edit=1
#43327 [Csd]: wrong return value from mail(), if sendmail_path is wrong
ID: 43327
Updated by: garre...@php.net
Reported By: carsten_sttgt at gmx dot de
Status: Closed
Bug Type: Mail related
Operating System: win32 only (?)
PHP Version: 5.*, 6 (2009-08-07)
Assigned To: garretts
New Comment:
Carsten,
Can you retest with the latest 5.3 snapshot, and post feedback?
Thanks
Previous Comments:
[2009-08-19 18:43:46] s...@php.net
Automatic comment from SVN on behalf of pajoye
Revision: http://svn.php.net/viewvc/?view=revision&revision=287480
Log: - fixed #43327, wrong return value from mail(), if sendmail_path
is wrong
[2009-08-19 16:15:49] garre...@php.net
or, it will be once I get some karma in /TSRM ...
[2009-08-19 16:10:43] garre...@php.net
This occurs because popen_ex executes the command using the comspec
('cmd.exe'), which will always create a valid process--but intended
actual child process fails.
I'm patching this so that it skips using cmd.exe--there is really no
reason this should be here, if this introduces other problems (which I
can't see what they could possibly be), then those should be fixed
appropriately.
Patched in all branches (5.2.11-dev, 5.3.1-dev and trunk)
[2009-07-20 10:08:36] carsten_sttgt at gmx dot de
After some delay...
If've just test this with PHP 5.3.0 and mail() still returns TRUE, even
if PHP can't find the sendmail binary or the sendmail binary returns an
errorlevel != 0.
Regards,
Carsten)
[2008-08-26 23:28:16] j...@php.net
Pierre, this is the real issue, sendmail_path is not checked or
something?
The remainder of the comments for this report are too long. To view
the rest of the comments, please view the bug report online at
http://bugs.php.net/43327
--
Edit this bug report at http://bugs.php.net/?id=43327&edit=1
#48547 [Opn->Bgs]: DirectoryIterator Slash issue with getPathname Windows with Apache
ID: 48547
Updated by: garre...@php.net
Reported By: BinaryKitten at jkrswebsolutions dot co dot uk
-Status: Open
+Status: Bogus
Bug Type: SPL related
Operating System: win32 only - WinXP SP3
PHP Version: 5.2.9
-Assigned To:
+Assigned To: garretts
New Comment:
Use the FilesystemIterator class (a subclass of DirectorIterator) if
you want to force the directory separator to the forward slash.
Directory iterator only supports the default platform slash.
http://us.php.net/manual/en/class.filesystemiterator.php
// will use forward slashes.
$dir = new FilesystemIterator( $path, 8192 );
Previous Comments:
[2009-06-14 19:22:59] webmaster at asylum-et dot cm
I have tested this on Windows XP SP3 with PHP 5.2.5 and have the same
findings as BinaryKitten at jkrswebsolutions dot co dot uk
[2009-06-14 11:47:49] BinaryKitten at jkrswebsolutions dot co dot uk
Description:
When using the DirectoryIterator to go through files/folders on Windows
under apache, the path has a mismatch of \ and /
Reproduce code:
---
".$dir->getPath()."";
foreach($dir as $file ) {
$dirName = $file->getPathname();
echo $dirName."";
}
?>
Expected result:
With the Document root as C:\HTDOCS Apache returns
$_SERVER['DOCUMENT_ROOT'] as c:/HTDOCS
Expected Output
C:/HTDOCS/.
C:/HTDOCS/..
C:/HTDOCS/css
C:/HTDOCS/index.php
C:/HTDOCS/js
C:/HTDOCS/
Actual result:
--
C:/HTDOCS\.
C:/HTDOCS\..
C:/HTDOCS\css
C:/HTDOCS\index.php
C:/HTDOCS\js
--
Edit this bug report at http://bugs.php.net/?id=48547&edit=1
#44994 [Asn]: exec() produces zombie processes on Windows, hangs Apache
ID: 44994
Updated by: garre...@php.net
Reported By: dbarrett at vistaprint dot com
Status: Assigned
Bug Type: Program Execution
Operating System: win32 only - 2003 Server, 64-bit
PHP Version: 5.2.6
Assigned To: garretts
New Comment:
I've seen this happen in other languages too.
This happens when the pipe between the parent and child fills up, and
cmd.exe ends up blocking and creates a race condition. (Windows script
host languages trip up on this quickly)
in popen_ex() ( in tsrm_win32.c) the pipe is creates with a 2k buffer:
if (!str_len || !CreatePipe(&in, &out, &security, 2048L)) {
this should probably be significantly larger. I'd certainly go with at
least 16k or 32k. (hey, it's only memory :D)
as well, the elimination of the unrequired cmd.exe as the immediate
child process would eliminate the possibility that *it's* buffer gets
overwhelmed too. (which solves bug #43327, and I've passed a patch to
Pierre for that.)
Previous Comments:
[2009-06-08 16:40:15] alex at bartl dot net
Reproducable with PHP 5.2.9-1 on Windows2003 Server with Apache2.2
Workaround with calling session_write_close() before calling exec()
confirmed working
NOT reproducable with PHP 5.2.1 on Windows 2000 Server with IIS5
anyway, seems to be a duplicate of Bug#44942
[2009-05-04 14:56:29] mk1992 at hotmail dot com
same problem here, php 5.2.9, w2k3, IIS: shell_exec hanging on
production server but not on development server. Can't do downgrade to
5.1.x.
[2009-04-28 22:52:53] diackne at gmail dot com
I have the same issue in windows 2008 web server iis 7 !!!
[2009-04-22 02:03:38] aliks0905 at gmail dot com
I have the same issue as well. I use the exec() function to
simultaneously upload files and sometimes cmd.exe freezes and all
following uploads fail.
I run on a Windows 2003 Server using Apache 2.2.11 and PHP 5.2.9
Looking forward to hearing a solution.
[2009-02-27 18:58:20] alex at alexi dot ch
Hi all,
I can fully confirm the above behaviour on the Windows platform. We are
using Apache FOP to create PDF-Files out of PHP, so we are invoking
exec() to start the command line FOP processor.
With several versions of PHP 5.2.x (5.2.4, 5.2.6, 5.2.8), this problem
occurs soon as more than one user is invoking the exec().
Luckily we could not reproduce this behaviour using PHP 5.1.x, so
downgrading to a 5.1.x version might also be an option for you.
Regards
alex
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/44994
--
Edit this bug report at http://bugs.php.net/?id=44994&edit=1
#43327 [Csd]: wrong return value from mail(), if sendmail_path is wrong
ID: 43327
Updated by: garre...@php.net
Reported By: carsten_sttgt at gmx dot de
Status: Closed
Bug Type: Mail related
Operating System: win32 only (?)
PHP Version: 5.*, 6 (2009-08-07)
Assigned To: garretts
New Comment:
or, it will be once I get some karma in /TSRM ...
Previous Comments:
[2009-08-19 16:10:43] garre...@php.net
This occurs because popen_ex executes the command using the comspec
('cmd.exe'), which will always create a valid process--but intended
actual child process fails.
I'm patching this so that it skips using cmd.exe--there is really no
reason this should be here, if this introduces other problems (which I
can't see what they could possibly be), then those should be fixed
appropriately.
Patched in all branches (5.2.11-dev, 5.3.1-dev and trunk)
[2009-07-20 10:08:36] carsten_sttgt at gmx dot de
After some delay...
If've just test this with PHP 5.3.0 and mail() still returns TRUE, even
if PHP can't find the sendmail binary or the sendmail binary returns an
errorlevel != 0.
Regards,
Carsten)
[2008-08-26 23:28:16] j...@php.net
Pierre, this is the real issue, sendmail_path is not checked or
something?
[2008-01-18 21:52:18] aaron at gwmicro dot com
I have confirmed this issue under a Windows Server 2003 environment,
and it continues to exist in 5.3 dev. Using the imap_mail.dll and
changing all references from mail() to imap_mail() seems to resolve the
problem, although changing that reference everywhere is not a reasonable
solution for most everyone (including us).
[2007-11-19 14:40:55] j...@php.net
Propably due to wrong usage of popen() and not VCWD_POPEN(). I don't
have win32 dev environment setup so someone else should deal with this.
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/43327
--
Edit this bug report at http://bugs.php.net/?id=43327&edit=1
#43327 [Asn->Csd]: wrong return value from mail(), if sendmail_path is wrong
ID: 43327
Updated by: garre...@php.net
Reported By: carsten_sttgt at gmx dot de
-Status: Assigned
+Status: Closed
Bug Type: Mail related
Operating System: win32 only (?)
PHP Version: 5.*, 6 (2009-08-07)
-Assigned To: pajoye
+Assigned To: garretts
New Comment:
This occurs because popen_ex executes the command using the comspec
('cmd.exe'), which will always create a valid process--but intended
actual child process fails.
I'm patching this so that it skips using cmd.exe--there is really no
reason this should be here, if this introduces other problems (which I
can't see what they could possibly be), then those should be fixed
appropriately.
Patched in all branches (5.2.11-dev, 5.3.1-dev and trunk)
Previous Comments:
[2009-07-20 10:08:36] carsten_sttgt at gmx dot de
After some delay...
If've just test this with PHP 5.3.0 and mail() still returns TRUE, even
if PHP can't find the sendmail binary or the sendmail binary returns an
errorlevel != 0.
Regards,
Carsten)
[2008-08-26 23:28:16] j...@php.net
Pierre, this is the real issue, sendmail_path is not checked or
something?
[2008-01-18 21:52:18] aaron at gwmicro dot com
I have confirmed this issue under a Windows Server 2003 environment,
and it continues to exist in 5.3 dev. Using the imap_mail.dll and
changing all references from mail() to imap_mail() seems to resolve the
problem, although changing that reference everywhere is not a reasonable
solution for most everyone (including us).
[2007-11-19 14:40:55] j...@php.net
Propably due to wrong usage of popen() and not VCWD_POPEN(). I don't
have win32 dev environment setup so someone else should deal with this.
[2007-11-19 13:46:20] carsten_sttgt at gmx dot de
> Are you sure the path is actually set? Try this:
Yes:
| D:\PHP>php -d sendmail_path=/foo/bar -r \
| "var_dump(ini_get('sendmail_path'));"
| string(8) "/foo/bar"
|
|D:\PHP>
Of course, setting "sendmail_path" from the command line was just for
you. The same happens if I set a wrong sendmail_path in "php.ini".
And as I've written above:
mail() returns also TRUE, if "sendmail_path" is correct, but the
sendmail binary exit with an error code != 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/43327
--
Edit this bug report at http://bugs.php.net/?id=43327&edit=1
#28038 [Asn->Csd]: Sent incorrect RCPT TO commands to SMTP server
ID: 28038
Updated by: garre...@php.net
Reported By: jordi at jcanals dot net
-Status: Assigned
+Status: Closed
Bug Type: Mail related
Operating System: win32 only
PHP Version: 5.*, 6SVN
-Assigned To: pajoye
+Assigned To: garretts
New Comment:
I've fixed this in PHP-5.3.1-dev.
I added in code to use the contents between angle brackets < > if there
is a pair of angle brackets passed in.
If the angle brackets are not passed in as a pair, this patch doesn't
alter the contents (missing one angle bracket is clearly invalid), and
should likely be rejected by the SMTP server.
And, for the record SMTP (RFC 2821) doesn't have its addresses defined
by RFC 2822 for "MAIL FROM:" and "RCPT TO:" -- they should be just the
undecorated mailbox address. (see RFC 2821- 4.1.2 Command Argument
Syntax)
Previous Comments:
[2009-04-06 14:29:44] php at shitware dot nl
I'm no C expert, but wouldn't this provide a quick fix:
instead of:
snprintf(Buffer, MAIL_BUFFER_SIZE, "RCPT TO:<%s>\r\n", token);
use:
snprintf(Buffer, MAIL_BUFFER_SIZE, token[(strlen(token)-1)] == ">" ?
"RCPT TO:%s\r\n" : "RCPT TO:<%s>\r\n", token);
for EVERY use of token (including RPath)?
(plain e-mail addresses are still placed between <...>, formatted
e-mail addresses get in the transaction unaltered)
I tried setting up the Windows build environment to test this, but got
lost in the different how-to's ...
[2009-02-24 23:25:22] mark at lbisat dot com
By modifying the following in PHP.ini
[mail function]
sendmail_from = em...@domain.com
It fixed the issue for me on Windows 2003 Server SP2.
[2009-01-12 11:49:18] julioworld at hotmail dot com
I also had this problem and I solved it by adding this line in the
php.ini in the section [mail function]:
[mail function]
sendmail_from = em...@domain.com
[2009-01-06 19:41:42] ghooey at gmail dot com
Unlike with a linux server the email address in
ini_set('sendmail_from', 'm...@domain.com); has to be a valid email
address
[2008-12-10 19:46:45] jordi at jcanals dot net
You did not understand where the bug is (or was). We pass the proper
headers exactly the same in any platform. PHP mail layer change them to
the wrong format, by adding extra signs.
What you say we have to consider, Is what we are doing. Read carefully
the bug description, the headers sent to PHP mail function, and the
headers sent by the mail layer to the mail server.
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/28038
--
Edit this bug report at http://bugs.php.net/?id=28038&edit=1
#45808 [Asn]: stream_socket_enable_crypto() blocks and eats CPU
ID: 45808 Updated by: garre...@php.net Reported By: six at aegis-corp dot org Status: Assigned Bug Type: Streams related Operating System: Linux 2.6 PHP Version: 5.3.0alpha1 Assigned To: pajoye New Comment: FYI: I can't repro this on Windows with the build off the snaps' box (VC9 x86 Non Thread Safe (2009-Aug-18 16:00:00)). It: blocks until connection using telnet[expected] doens't consume any CPU[expected] and returns 'bool(false)' [expected -- I assume the same as 'int(0)'] and exits[expected] G Previous Comments: [2008-10-30 11:03:57] xl269 at cam dot ac dot uk just to confirm that this bug still exists in php5.3-200810292330 [2008-09-25 17:59:37] singularity_control at rcpt dot at This makes a serious security issue. It is a very effective DoS on all single process PHP servers with SSL and a slightly less bad DoS on multi-process PHP servers. [2008-09-25 16:07:31] nasam at mailvault dot com Bug is in ext/openssl/xp_ssl.c Function handle_ssl_error: (line 107) case SSL_ERROR_WANT_READ: case SSL_ERROR_WANT_WRITE: /* re-negotiation, or perhaps the SSL layer needs more * packets: retry in next iteration */ errno = EAGAIN; retry = is_init ? 1 : sslsock->s.is_blocked; //BUG break; it sets retry to 1 in php_openssl_enable_crypto no matter if socket is blocking or not. [2008-09-25 10:06:09] six at aegis-corp dot org the bug is still present in php5.3-200809232030 [2008-09-24 01:20:29] six at aegis-corp dot org the bug is still present in php5.3-200809232030 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/45808 -- Edit this bug report at http://bugs.php.net/?id=45808&edit=1
#47627 [Asn->Bgs]: "No input file specified" causing crash
ID: 47627 Updated by: garre...@php.net Reported By: danielc at analysisandsolutions dot com -Status: Assigned +Status: Bogus Bug Type: CGI related Operating System: win32 only - WinXP Pro SP3 PHP Version: 5.3CVS-2009-03-11 (snap) Assigned To: garretts New Comment: I'm unable to reproduce this with Apache 2.2.13, mod_fcgid and php5.3.1-dev. I'd recommend a couple of things: - Since Apache 1.3 isn't really supported at all these days, moving up to 2.2 would be a good idea. - Regardless, Apache should be configured to not pass thru requests to fcgi handlers for files that don't exist. Previous Comments: [2009-03-11 19:37:28] danielc at analysisandsolutions dot com Description: In PHP 5.3, pointing my browser to a .php file that does not exist causes php-cgi to crash and Apache to return a 500 error. In PHP 5.2.6, doing so returns output saying "No input file specified." During the crash, Windows displays the "Please tell Microsoft about this problem" dialog box. The title is "CGI / FastCGI". The "To see what data this error report contains" sub dialog box says: Error signature szAppName : php-cgi.exe szAppVer : 5.3.0.0 szModName : php5ts.dll szModVer : 5.3.0.0 offset : 000cea5d The "To view technical information about the error report" sub sub dialog box contains: C:\DOCUME~1\ADMINI~1\LOCALS~1\Temp\WERc9f6.dir00\php-cgi.exe.mdmp C:\DOCUME~1\ADMINI~1\LOCALS~1\Temp\WERc9f6.dir00\appcompat.txt My Apache 1.3 error log message shows: [Wed Mar 11 14:59:02 2009] [error] [client 127.0.0.1] Premature end of script headers: c:/program files/php/php-cgi.exe My PHP version is: PHP 5.3.0beta2-dev (cgi-fcgi) (built: Mar 11 2009 17:04:23) -- Edit this bug report at http://bugs.php.net/?id=47627&edit=1
#49223 [Opn->Csd]: Inconsistency using get_defined_constants(true)
ID: 49223 Updated by: garre...@php.net Reported By: carlos dot ballesteros at softonic dot com -Status: Open +Status: Closed Bug Type: Scripting Engine problem Operating System: win32 only PHP Version: 5.3.1-dev New Comment: This bug has been fixed in SVN. The internal module mhash was improperly registered Previous Comments: [2009-08-17 21:28:23] s...@php.net Automatic comment from SVN on behalf of garretts Revision: http://svn.php.net/viewvc/?view=revision&revision=287429 Log: - Fix for bug #49223 Inconsistency using get_defined_constants(true) [2009-08-11 19:00:43] j...@php.net Seems to be windows only issue. [2009-08-11 12:59:00] carlos dot ballesteros at softonic dot com It's not working even in the lastest snapshot. C:\dev\php53>php -v PHP 5.3.1-dev (cli) (built: Aug 11 2009 10:52:16) Copyright (c) 1997-2009 The PHP Group Zend Engine v2.3.0, Copyright (c) 1998-2009 Zend Technologies C:\dev\php53>php -r"print_r(get_defined_constants(true));" | more Array ( [mhash] => Array ( [E_ERROR] => 1 ... [2009-08-11 11:29:29] j...@php.net Please try using this snapshot: http://snaps.php.net/php5.3-latest.tar.gz For Windows: http://windows.php.net/snapshots/ 'Core' is correct. Dunno about windows, might be fixed now. Try the snapshot. [2009-08-11 10:43:48] carlos dot ballesteros at softonic dot com Description: Before PHP 5.3, get_defined_constants with a parameter returned the core constants in a key called "internal". In PHP5.3 in linux it's returning them as "Core" key. But in windows it's returned as key "mhash". It's pretty weird. It's similar to this bug: http://bugs.php.net/bug.php?id=47549 But at least in windows "mhash" key is wrong. And about linux, if the key changed from 'internal' to 'Core', I think it should, at least, be specified in the documentation. http://es2.php.net/get_defined_constants Reproduce code: --- print_r(get_defined_constants(true)); Expected result: Array ( [internal] => Array ( [E_ERROR] => 1 [E_RECOVERABLE_ERROR] => 4096 ... Actual result: -- Linux: -bash-3.2# php -r"print_r(get_defined_constants(true));" | more Array ( [Core] => Array ( [E_ERROR] => 1 [E_RECOVERABLE_ERROR] => 4096 ... -bash-3.2# php -v PHP 5.3.0 (cli) (built: Jun 30 2009 21:37:54) Copyright (c) 1997-2009 The PHP Group Zend Engine v2.3.0, Copyright (c) 1998-2009 Zend Technologies Windows: C:\>php -r"print_r(get_defined_constants(true));" | more Array ( [mhash] => Array ( [E_ERROR] => 1 [E_RECOVERABLE_ERROR] => 4096 ... C:\>php -v PHP 5.3.0 (cli) (built: Jun 29 2009 21:55:01) Copyright (c) 1997-2009 The PHP Group Zend Engine v2.3.0, Copyright (c) 1998-2009 Zend Technologies -- Edit this bug report at http://bugs.php.net/?id=49223&edit=1
#48911 [Csd]: embed sapi misses SAPI_API
ID: 48911
Updated by: garre...@php.net
Reported By: thomas at koch dot ro
Status: Closed
Bug Type: Compile Failure
Operating System: Debian Lenny
PHP Version: 5.3.0
New Comment:
This patch breaks building php5embed on Windows.
On Windows, php5embed is built as a static library, and doesnt need
these functions to be marked as SAPI_API.
Can I suggest we instead use "EMBED_SAPI_API"?
-
#ifndef PHP_WIN32
#define EMBED_SAPI_API SAPI_API
#else
#define EMBED_SAPI_API
#endif
BEGIN_EXTERN_C()
EMBED_SAPI_API int php_embed_init(int argc, char **argv PTSRMLS_DC);
EMBED_SAPI_API void php_embed_shutdown(TSRMLS_D);
extern EMBED_SAPI_API sapi_module_struct php_embed_module;
END_EXTERN_C()
Previous Comments:
[2009-07-28 21:07:52] j...@php.net
This bug has been fixed in SVN.
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.
[2009-07-28 21:07:43] s...@php.net
Automatic comment from SVN on behalf of jani
Revision: http://svn.php.net/viewvc/?view=revision&revision=286468
Log: - Fixed bug #48911 (embed sapi misses SAPI_API)
[2009-07-14 07:16:45] thomas at koch dot ro
Description:
I try the most simple program that uses the embed sapi. Due to missing
SAPI_API macros the symbols
int php_embed_init(int argc, char **argv PTSRMLS_DC);
void php_embed_shutdown(TSRMLS_D);
extern sapi_module_struct php_embed_module;
get visibility hidden in the resulting libphp5.so.
Fix: put SAPI_API before these symbols in sapi/embed/php_embed.c.
(Also in php_embed.h ?)
Thanks to ScottMac for the hint on IRC!
Reproduce code:
---
#include
int main(int argc, char *argv[])
{
PHP_EMBED_START_BLOCK(argc,argv)
PHP_EMBED_END_BLOCK()
return 0;
}
Expected result:
should compile without problems
Actual result:
--
gcc -c -I/usr/local/include/php/ -I/usr/local/include/php/main -
I/usr/local/include/php/Zend -I/usr/local/include/php/TSRM -Wall -g -o
worker.o worker.c
gcc -L/usr/local/lib -lphp5 -o worker worker.o
worker.o: In function `main':
/var/checkouts/gearman-php-worker/worker.c:5: undefined reference to
`php_embed_init'
/var/checkouts/gearman-php-worker/worker.c:6: undefined reference to
`php_embed_shutdown'
collect2: ld returned 1 exit status
make: *** [all] Error
--
Edit this bug report at http://bugs.php.net/?id=48911&edit=1
#42832 [Com]: scandir() fails unless user has permissions in the parent directory
ID: 42832
Comment by: garretts at microsoft dot com
Reported By: jmboyd at bluebottle dot com
Status: Assigned
Bug Type: Directory function related
Operating System: win32 only - Windows 2000/XP
PHP Version: 5.2CVS-2008-08-25
Assigned To: pajoye
New Comment:
I've tested this for
PHP5.3-dev (today's snapshot)
PHP5.2.9-1
on
Windows 2003,
Windows Vista,
Windows 7,
and it performs as expected (able to find files in subdirectory where
parent is ACL'd to deny).
I don't have a XP box handy, I'll see if I can't spin up an XP VM in
the next day or two.
jmboyd: What Service Pack level are you running on Windows XP
G
Previous Comments:
[2009-03-16 19:09:20] jmboyd at bluebottle dot com
Just tested with the newest 5.2.9-1 win32 binaries under XP (no longer
have Win2k handy to test with) and the behavior is still the same.
My initial test shows the script running twice to help show when the
bug landed -- using php 5.2.1 there is no problem, but starting with
version 5.2.2 the bug appears.
[2009-03-02 19:06:29] paj...@php.net
Tested on Win 2008 and Vista:
C:\tmp\test\l2>cd ..
Access is denied.
C:\tmp\test\l2>\tmp\php530ntsvc9\php.exe \tmp\php530ntsvc9\acl.php
.
..
C:\tmp\test\l2>C:\Users\pierre\Documents\test\php53nts\php.exe
\tmp\php530ntsvc9
\acl.php
.
..
I saw in your test that you called two times the script, the first run
works, is it a copy/paste error or does it actually work in the 1st
pass?
[2008-10-27 13:45:42] j...@php.net
Assigned to the windows port maintainer.
[2008-08-25 14:56:47] jmboyd at bluebottle dot com
Hey, I did provide feedback! Lousy robot.
Just tried it again with the latest 5.3.0alpha2-dev build stamped Mon,
25 Aug 2008 10:05:33 -0400, same result. I can post the output if
needed, but it's exactly the same as the 18 Aug 5:54pm UTC comment
above.
[2008-08-18 17:54:24] jmboyd at bluebottle dot com
Same result with the snapshot (from Mon, 18 Aug 2008 14:03:00 -0400):
C:\parentdir\subdir>\php53dev\php -r "foreach(scandir('.') as $f)
{echo($f); }"
Warning: scandir(.): failed to open dir: Bad file descriptor in Command
line code on line 1
Warning: scandir(): (errno 9): Bad file descriptor in Command line code
on line 1
Warning: Invalid argument supplied for foreach() in Command line code
on line 1
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/42832
--
Edit this bug report at http://bugs.php.net/?id=42832&edit=1
