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 Add Comment Developer Edit
Welcome back! If you're the original bug submitter, here's where you can edit the bug or add additional notes.
If this is not your bug, you can add a comment by following this link.
If this is your bug, but you forgot your password, you can retrieve your password here.
Password:
Status:
Package:
Bug Type:
Summary:
From: felix-php at 7val dot com
New email:
PHP Version: OS:

 

 [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

Add a Patch

Pull Requests

Add a Pull Request

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-2024 The PHP Group
All rights reserved. 		Last updated: Thu Apr 18 23:01:27 2024 UTC