php.net |  support |  documentation |  report a bug |  advanced search |  search howto |  statistics |  random bug |  login
Doc Bug #79166 Notices for read/write failures are not documented
Submitted: 2020-01-24 13:42 UTC Modified: 2020-08-18 18:04 UTC
Votes:8
Avg. Score:4.5 ± 0.9
Reproduced:7 of 7 (100.0%)
Same Version:5 (71.4%)
Same OS:5 (71.4%)
From: michael dot piche at csrt dot ulaval dot ca Assigned:
Status: Verified Package: Streams related
PHP Version: 7.4 OS: Windows
Private report: No CVE-ID: None
View Add Comment Developer Edit
Welcome! If you don't have a Git account, you can't do anything here.
You can add a comment by following this link or if you reported this bug, you can edit this bug over here.
(description)
Block user comment
Status: Assign to:
Package:
Bug Type:
Summary:
From: michael dot piche at csrt dot ulaval dot ca
New email:
PHP Version: OS:

 

 [2020-01-24 13:42 UTC] michael dot piche at csrt dot ulaval dot ca
Description:
------------
Since PHP 7.4, the stream php://stderr is giving me a PHP notice "Bad file descriptor". Everything is working fine with PHP 7.3. 

I'm on Windows using mod_fcgid. The notice isn't happening if I run my script directly from the command line.

I've got the same error with php://stdout


Test script:
---------------
$fp = fopen('php://stderr', 'w+');
var_dump($fp);
fwrite($fp, "test\n");

Actual result:
--------------
resource(3) of type (stream) 

Notice: fwrite(): write of 5 bytes failed with errno=9 Bad file descriptor in D:\htdocs\test_code\74.php on line 7

Patches

Add a Patch

Pull Requests

Add a Pull Request

History

AllCommentsChangesGit/SVN commitsRelated reports
 [2020-01-26 16:14 UTC] cmb@php.net
-Status: Open +Status: Verified -Package: *Directory/Filesystem functions +Package: Streams related
 [2020-01-26 16:14 UTC] cmb@php.net
I can confirm that behavior for FastCGI/IIS.
 [2020-01-26 16:17 UTC] nikic@php.net
To clarify, the bug here is that you can open php://stderr despite the webserver SAPI presumably not having an stderr FD?
 [2020-01-27 08:03 UTC] cmb@php.net
-Status: Verified +Status: Feedback -Assigned To: +Assigned To: cmb
 [2020-01-27 08:03 UTC] cmb@php.net
I think so.  @michael, what do you mean with

> Everything is working fine with PHP 7.3.

No notice, or did you actually get some output?
 [2020-01-27 13:28 UTC] michael dot piche at csrt dot ulaval dot ca
-Status: Feedback +Status: Assigned
 [2020-01-27 13:28 UTC] michael dot piche at csrt dot ulaval dot ca
No notice with the same code on 7.3.
 [2020-01-27 13:36 UTC] cmb@php.net
-Summary: PHP 7.4 error with php://stderr +Summary: Notices for read/write failures are not documented -Status: Assigned +Status: Verified -Type: Bug +Type: Documentation Problem -PHP Version: 7.4.2 +PHP Version: 7.4
 [2020-01-27 13:36 UTC] cmb@php.net
> No notice with the same code on 7.3.

That is to be expected, because that notice is only raised as of
PHP 7.4.0; formerly the write error has been silently ignored.
While this change is documented in the migration guide[1], it is
not yet documented in the manual proper, so I'm re-categorizing as
doc bug.

[1] <https://www.php.net/manual/en/migration74.incompatible.php#migration74.incompatible.core.fread-fwrite>
 [2020-01-27 13:36 UTC] cmb@php.net
-Assigned To: cmb +Assigned To:
 [2020-01-27 13:48 UTC] michael dot piche at csrt dot ulaval dot ca
If it isn't possible to write to php://stderr, shouldn't the fopen return FALSE ? 

The notice come from Logger class in Symfony and there is a verification if the stream is a ressource, with is the case.
 [2020-07-28 13:26 UTC] chokolatrix at gmail dot com
> To clarify, the bug here is that you can open php://stderr despite the webserver SAPI presumably not having an stderr FD?

I think this report was created because of lacking documentation. I've opened #79905 [1] "fopen() read-only streams in write mode doesn't fail" which I think is a bug.

If my understanding is correct, stderr should go to Apache's error log as stated by it's docs (see below). PHP failing to write to stderr in FCGI context might be an Apache bug.

Apache 1.3 docs [2]: "Any information written to stderr by a CGI script will be copied directly to the error log" - it also applies to FCGI?

Mod_fastcgi docs [3]: "mod_fastcgi logs FastCGI application error (stderr) output to the server log associated with the request. Errors reported by the FastCGI process manager, fcgi-pm, are reported to the main server log (typically, logs/error_log). Data written to stdout or stderr before entering the FastCGI accept loop or via a mechanism that is not FastCGI protocol aware will also be directed to the main server log"
 

[1] https://httpd.apache.org/docs/1.3/logs.html
[2] https://fastcgi-archives.github.io/mod_fastcgi.html
[3] https://bugs.php.net/bug.php?id=79905
 [2020-07-28 13:35 UTC] chokolatrix at gmail dot com
^ I messed-up the links order ¯\_(ツ)_/¯
 [2020-07-28 15:50 UTC] chokolatrix at gmail dot com
^ I've wrongly quoted *mod_fastcgi* documentation, but I've only tested *mod_fcgid*. 

Haven't found references to logging or stderr in the *mod_fcgid* documentation [1]. 
There are various posts on the web [2] [3] quoting Apache logs containting "mod_fcgid: stderr: ..." so it must work in some combination of OS + Apache + PHP.

[1] https://httpd.apache.org/mod_fcgid/mod/mod_fcgid.html
[2] https://wordpress.org/support/topic/mod_fcgid-stderr-php-warning-exif_read_dataimg_0113-jpg/
[3] https://wordpress.org/support/topic/mod_fcgid-stderr-php-fatal-error-allowed-memory-size-exhausted/
 [2020-08-18 18:04 UTC] michael dot piche at csrt dot ulaval dot ca
> If it isn't possible to write to php://stderr, shouldn't the fopen return FALSE ?

My bug report isn't related to documentation. https://bugs.php.net/bug.php?id=79905 seems like the same bug.
 
PHP Copyright © 2001-2020 The PHP Group
All rights reserved.
Last updated: Mon Nov 30 23:01:24 2020 UTC