php.net |  support |  documentation |  report a bug |  advanced search |  search howto |  statistics |  random bug |  login

go to bug id or search bugs for

Doc Bug #79166 Notices for read/write failures are not documented
Submitted: 2020-01-24 13:42 UTC Modified: 2022-10-06 10:51 UTC
Votes:25
Avg. Score:4.3 ± 0.9
Reproduced:20 of 21 (95.2%)
Same Version:13 (65.0%)
Same OS:10 (50.0%)
From: michael dot piche at csrt dot ulaval dot ca Assigned:
Status: Verified Package: CGI/CLI related
PHP Version: 7.4 OS: Windows
Private report: No CVE-ID: None
View Developer Edit
 [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

Pull Requests

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.
 [2022-10-06 10:51 UTC] bukka@php.net
-Package: Streams related +Package: CGI/CLI related
 [2022-10-06 10:51 UTC] bukka@php.net 
This might need some investigation on SAPI level as FPM deals with this just fine on Linux so would be good if someone properly look if the same can be done on Windows. In any case this is a SAPI issue really so the documentation would be SAPI related anyway.
 [2022-12-16 08:22 UTC] melindaetinw81 at gmail dot com 
ok  for the link, keep sharing this type of info (https://www.myiclubonline.onl/)github.com
 
PHP Copyright © 2001-2024 The PHP Group
All rights reserved. 		Last updated: Tue Dec 03 17:01:29 2024 UTC