Bug #78007 [Opn]: curl_close() does not honor CURLOPT_STDERR

From: Date: Mon, 13 May 2019 15:35:34 +0000
Subject: Bug #78007 [Opn]: curl_close() does not honor CURLOPT_STDERR
References: 1  Groups: php.bugs 
Request: Send a blank email to php-bugs+get-220845@lists.php.net to get a copy of this message
Edit report at https://bugs.php.net/bug.php?id=78007&edit=1 ID: 78007 Updated by: cmb@php.net Reported by: divinity76 at gmail dot com Summary: curl_close() does not honor CURLOPT_STDERR Status: Open Type: Bug Package: cURL related Operating System: Windows 7 x64 SP1 PHP Version: 7.3.5 Block user comment: N Private report: N New Comment: Indeed, if I apply commit d51c7d6[1] on top of libcurl 7.64.1, no more spurious output appears. So I don't think there's anything wrong here on the PHP side. [1] <https://github.com/curl/curl/pull/3856/commits/d51c7d63e7e850980553729b4c366f4377308bba> Previous Comments: ------------------------------------------------------------------------ [2019-05-13 13:45:40] divinity76 at gmail dot com Daniel Stenberg (the libcurl author) says it's probably related to https://curl.haxx.se/mail/lib-2019-05/0021.html ------------------------------------------------------------------------ [2019-05-13 13:28:26] cmb@php.net I've used the official build[1] and the official deps[2], respectively, i.e. libcurl 7.64.0. I can indeed reproduce the reported behavior with libcurl 7.64.1 on Debian. Will have a look at the Windows side as soon as possible. > those hardcoded logging messages are still supposed to go to > CURLOPT_STDERR, not stderr =/ PHP's CURLOPT_STDERR is a thin wrapper over cURLS's CURL_OPT_STDERR[3], so there *might* be a bug in libcurl. [1] <https://windows.php.net/download/> [2] <https://windows.php.net/downloads/php-sdk/deps/series/packages-7.3-vc15-x64-stable.txt> [3] <https://curl.haxx.se/libcurl/c/CURLOPT_STDERR.html> ------------------------------------------------------------------------ [2019-05-13 13:17:26] divinity76 at gmail dot com update to above: CAN (partially) reproduce on PHP 7.3.5 on Arch Linux x64 kernel 5.0.13, libcurl 7.64.1 @ requinix@php.net : those hardcoded logging messages are still supposed to go to CURLOPT_STDERR, not stderr =/ ------------------------------------------------------------------------ [2019-05-13 12:39:49] requinix@php.net Those messages are indeed coming directly from cURL, not PHP. There's a variety of hardcoded logging statements in it that should, in theory, be controllable by a compile flag and a runtime flag... ------------------------------------------------------------------------ [2019-05-13 12:26:36] divinity76 at gmail dot com .. i wonder if the libcurl versions here are relevant. cmb@php.net add the libcurl version you're on (php -i | grep -i curl) can NOT reproduce on PHP 7.2.15 on Ubuntu 18.04 x64 kernel 4.15.0, libcurl 7.58.0 CAN reproduce on PHP 7.3.4 on Windows 7 x64 SP1, libcurl 7.64.1 CAN (partially) reproduce on PHP 7.3.5 on Arch Linux x64 kernel 5.0.13, libcurl.. ??? (can't check right now, ill make an update when i can) ------------------------------------------------------------------------ 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 https://bugs.php.net/bug.php?id=78007 -- Edit this bug report at https://bugs.php.net/bug.php?id=78007&edit=1

« previous php.bugs (#220845) next »