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

go to bug id or search bugs for

Bug #48676 CURLOPT_FILE increases file handle refcount
Submitted: 2009-06-24 14:17 UTC Modified: 2009-09-10 08:02 UTC
Votes:1
Avg. Score:4.0 ± 0.0
Reproduced:1 of 1 (100.0%)
Same Version:1 (100.0%)
Same OS:1 (100.0%)
From: felix-php at 7val dot com Assigned:
Status: Not a bug Package: cURL related
PHP Version: 5.2.10 OS: Debian Linux (etch)
Private report: No CVE-ID: None
View Developer Edit
Anyone can comment on a bug. Have a simpler test case? Does it work for you on a different platform? Let us know!
Just going to say 'Me too!'? Don't clutter the database with that please !
Your email address:
MUST BE VALID
Solve the problem:
44 - 11 = ?
Subscribe to this entry?

 
 [2009-06-24 14:17 UTC] felix-php at 7val dot com 
Description:
------------
When passing an open, writable file handle to Curl as the CURLOPT_FILE 
option, the refcount to that file handle is increased without being 
decreased when calling curl_close.

Thus the file handle has to be closed TWICE to actually being flushed 
and closed. In the reproduce code the file handle is still a valid 
resource after the first call to fclose().

The bug is reproducable in PHP 5.2.10. In 5.2.9 the code works as 
expected.

In 5.2.10 in ext/curl/interface.c:1440 the call 
zend_list_addref(Z_LVAL_PP(zvalue));
was added. Maybe the problem origins here, if there is no corresponding 
delref in curl_close()?

Reproduce code:
---------------
$fh = fopen('curl.out', 'w');

$c = curl_init('http://example.com');
curl_setopt($c, CURLOPT_FILE, $fh);
curl_exec($c);

fclose($fh);
echo "content 1: ". file_get_contents('curl.out') ."\n";
if (is_resource($fh)) {
        echo "file still open -> wrong\n";
} else {
        echo "file closed -> correct\n";
        exit;
}
fclose($fh);
if (is_resource($fh)) {
        echo "file open 2\n";
}

curl_close($c);
echo "content 2: ". file_get_contents('curl.out') ."\n";


Expected result:
----------------
content 1: <HTML>
<HEAD>
  <TITLE>Example Web Page</TITLE>
</HEAD> 
[..]

file closed -> correct


Actual result:
--------------
content 1: 
file still open -> wrong
content 2: <HTML>
<HEAD>
  <TITLE>Example Web Page</TITLE>
</HEAD> 
[..]

Patches

Pull Requests

History

AllCommentsChangesGit/SVN commitsRelated reports
 [2009-06-24 14:21 UTC] felix-php at 7val dot com 
The reproduce code is not completly correct: The curl_close() call was 
meant to be after curl_exec() and before the first fclose().

But interestingly this does not change the behaviour in neither 5.2.9 
nor 5.2.10.
 [2009-06-26 23:19 UTC] jani@php.net 
See bug #48518 (same issue)
 [2009-06-29 12:43 UTC] felix-php at 7val dot com 
I have installed the latest snapshot to check if bug #48518 has also 
fixed my issue.

now the content can be read from the outfile directly after curl_exec().

but:
1. the problem remains using the multi-api
2. my reproduce code still shows that fclose() does not close the 
handle. it has to be called twice to actually have is_resouce() return 
false.

i think the new fflush() call introduced in curl_exec() just workarounds 
the problem. fclose() will usually flush the file handle itself. thus 
the reproduce code has worked with php 5.2.10 by fclose'ing twice.
 [2009-09-10 08:02 UTC] sjoerd@php.net 
This bug has been filed again as #49517.
 
PHP Copyright © 2001-2025 The PHP Group
All rights reserved. 		Last updated: Tue Oct 28 17:00:02 2025 UTC