Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:37713
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: error (pb1.pair.com: domain lerdorf.com from 204.11.219.139 cause and error)
Message-ID: <4830BCF0.1060902@lerdorf.com>
Date: Sun, 18 May 2008 16:34:08 -0700
User-Agent: Thunderbird 2.0.0.4 (Macintosh/20070604)
MIME-Version: 1.0
To: Manuel Mausz <manuel@mausz.at>
CC:  internals@lists.php.net
References: <482E8391.9080004@lerdorf.com> <48309995.4080409@suse.de> <4830B5B1.70602@lerdorf.com> <4830BACD.4000208@mausz.at>
In-Reply-To: <4830BACD.4000208@mausz.at>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
Subject: Re: [PHP-DEV] Curl POST emalloc leak?
From: rasmus@lerdorf.com (Rasmus Lerdorf)

Manuel Mausz wrote:
> Rasmus Lerdorf wrote:
>> Note that you don't actually need to send the request.  It looks like
>> repeatedly doing:
>>
>> $ch = curl_init();
>> curl_setopt($ch, CURLOPT_POSTFIELDS, $args);
>> curl_close($ch);
>>
>> Is enough to do it.  Still looking at the code.  Seems like
>> zend_llist_clean(&ch->to_free.str); isn't doing the right thing somehow.
> 
> Is this really related to curl?
> 
> # php -n -r 'for($i=0;$i<10;$i++) { for($args="",$j=0;$j<75;$j++) $args
> .= "a=$j&"; unset($args); echo memory_get_usage()."\n"; }'
> 55872
> 56100
> 56172
> 56240
> 56304
> 56364
> 56420
> 56420
> 56420
> 56420

Yeah, I noticed that as well as I was simplifying things down further 
and further.  I have gotten to the point where my simplification has 
lost track of the real problem, I think.  My original complicated code 
is leaking hundreds of K per iteration, and I assumed the smaller leak 
in the simplified version was representative of that, but I don't think 
it is.  That would also why I haven't been able to find a bug in this 
curl code I have been looking at.

-Rasmus