Return-Path: Delivered-To: apmail-httpd-apreq-dev-archive@www.apache.org Received: (qmail 58514 invoked from network); 13 Nov 2006 19:59:23 -0000 Received: from hermes.apache.org (HELO mail.apache.org) (140.211.11.2) by minotaur.apache.org with SMTP; 13 Nov 2006 19:59:23 -0000 Received: (qmail 82394 invoked by uid 500); 13 Nov 2006 19:59:33 -0000 Delivered-To: apmail-httpd-apreq-dev-archive@httpd.apache.org Received: (qmail 82264 invoked by uid 500); 13 Nov 2006 19:59:32 -0000 Mailing-List: contact apreq-dev-help@httpd.apache.org; run by ezmlm Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Id: Delivered-To: mailing list apreq-dev@httpd.apache.org Received: (qmail 82253 invoked by uid 99); 13 Nov 2006 19:59:32 -0000 Received: from herse.apache.org (HELO herse.apache.org) (140.211.11.133) by apache.org (qpsmtpd/0.29) with ESMTP; Mon, 13 Nov 2006 11:59:32 -0800 X-ASF-Spam-Status: No, hits=-0.0 required=10.0 tests=SPF_HELO_PASS,SPF_PASS X-Spam-Check-By: apache.org Received-SPF: pass (herse.apache.org: domain of gcaa-apreq-dev@m.gmane.org designates 80.91.229.2 as permitted sender) Received: from [80.91.229.2] (HELO ciao.gmane.org) (80.91.229.2) by apache.org (qpsmtpd/0.29) with ESMTP; Mon, 13 Nov 2006 11:59:18 -0800 Received: from list by ciao.gmane.org with local (Exim 4.43) id 1Gjhwj-0002CV-Px for apreq-dev@httpd.apache.org; Mon, 13 Nov 2006 20:58:22 +0100 Received: from adsl-065-012-220-185.sip.bct.bellsouth.net ([65.12.220.185]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Mon, 13 Nov 2006 20:58:21 +0100 Received: from joe+gmane by adsl-065-012-220-185.sip.bct.bellsouth.net with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Mon, 13 Nov 2006 20:58:21 +0100 X-Injected-Via-Gmane: http://gmane.org/ Mail-Followup-To: apreq-dev@httpd.apache.org To: apreq-dev@httpd.apache.org From: Joe Schaefer Subject: Re: memory leaking on POST Date: Mon, 13 Nov 2006 14:57:56 -0500 Lines: 25 Message-ID: <87mz6vazln.fsf@gemini.sunstarsys.com> References: <5b3fa8f0611122201ve28c458n9fba67d6a9c313d9@mail.gmail.com> <87wt5zev7w.fsf@gemini.sunstarsys.com> <5b3fa8f0611122238n48754012kb7924b98db45e9bc@mail.gmail.com> <87psbressv.fsf@gemini.sunstarsys.com> <4558BC0A.4060605@p6m7g8.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Complaints-To: usenet@sea.gmane.org X-Gmane-NNTP-Posting-Host: adsl-065-012-220-185.sip.bct.bellsouth.net Mail-Copies-To: never User-Agent: Gnus/5.110004 (No Gnus v0.4) Emacs/21.4 (gnu/linux) Cancel-Lock: sha1:vHPVk0BOQWtb8quVb+7b6Q+3E50= Sender: news X-Virus-Checked: Checked by ClamAV on apache.org "Philip M. Gollucci" writes: > Joe Schaefer wrote: > >> Until someone teaches apreq_brigade_fwrite about spool buckets, >> it probably shouldn't be used for upload brigades. Sorry about that. > I was looking at this a while ago -- APR/U have this function. Really? What's it called? > We custom coded our own -- why ? Because I didn't know apr has something like it? In any case, the "mistake" here is that apreq_brigade_fwrite doesn't consume the brigade, but leaves it "intact". I should have made that function consume the brigade instead- my bad. The fix is easy enough- just use apr_file_read instead of apr_bucket_read when dealing with spool buckets. That'd fix the memory problem for this particular use-case. I wrote a patch last night, but I haven't had the opportunity to write any tests for it yet, and probably won't until the weekend comes around. -- Joe Schaefer