From mboxrd@z Thu Jan 1 00:00:00 1970 From: Yasushi SHOJI Subject: Re: [patch] possible memory leak in diff.c::diff_free_filepair() Date: Tue, 16 Aug 2005 12:05:16 +0900 Message-ID: <8764u6ponn.wl@mail2.atmark-techno.com> References: <87y876gl1r.wl@mail2.atmark-techno.com> <7viry9my6k.fsf@assigned-by-dhcp.cox.net> <877jepo87m.wl@mail2.atmark-techno.com> <7viry9le0g.fsf@assigned-by-dhcp.cox.net> Mime-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Content-Type: text/plain; charset=US-ASCII Cc: git@vger.kernel.org X-From: git-owner@vger.kernel.org Tue Aug 16 05:06:39 2005 Return-path: Received: from vger.kernel.org ([209.132.176.167]) by ciao.gmane.org with esmtp (Exim 4.43) id 1E4rla-00017v-T4 for gcvg-git@gmane.org; Tue, 16 Aug 2005 05:05:31 +0200 Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S965075AbVHPDF0 (ORCPT ); Mon, 15 Aug 2005 23:05:26 -0400 Received: (majordomo@vger.kernel.org) by vger.kernel.org id S965079AbVHPDF0 (ORCPT ); Mon, 15 Aug 2005 23:05:26 -0400 Received: from shop.atmark-techno.com ([210.191.215.173]:28099 "EHLO mail2.atmark-techno.com") by vger.kernel.org with ESMTP id S965075AbVHPDFZ (ORCPT ); Mon, 15 Aug 2005 23:05:25 -0400 Received: from smtp.local-network (dns1.atmark-techno.com [210.191.215.170]) by mail2.atmark-techno.com (Postfix) with ESMTP id 2A1FC53E; Tue, 16 Aug 2005 12:05:23 +0900 (JST) Received: from wat.atmark-techno.com (unknown [192.168.10.81]) by smtp.local-network (Postfix) with ESMTP id 624A7B61F; Tue, 16 Aug 2005 12:08:04 +0900 (JST) To: Junio C Hamano In-Reply-To: <7viry9le0g.fsf@assigned-by-dhcp.cox.net> User-Agent: Wanderlust/2.14.0 Sender: git-owner@vger.kernel.org Precedence: bulk X-Mailing-List: git@vger.kernel.org At Sat, 13 Aug 2005 14:31:59 -0700, Junio C Hamano wrote: > > Yasushi SHOJI writes: > > > oops. probably my english wasn't clear. my patch fixes > > diff_free_filepair(). > > When the command is run on linux-2.6 repository, virtual memory > consumption of git-diff-tree command skyrockets to about half a > gig, because it maps all files in two adjacent revisions of the > entire kernel tree. But it seems to reclaim things reasonably > well and goes back down to less than 10m when it starts to > process the next commit pair. it tunes out that, at least for my problem is to populating filespec data in parepare_temp_file() and not freeing it after creating temp file with prep_temp_blob(). parepare_temp_file() and diff_populate_filespec() has a lot in similarity. so it'd be nice to refactor some. and re-introduce diff_free_filespec_data() and call right after prep_temp_blob() in prepare_temp_file(). Junio, did you also mean to clean-up these functions when you said in the thread of "Re: gitweb - option to disable rename detection"? regards, -- yashi