Return-Path: Delivered-To: apmail-httpd-dev-archive@www.apache.org Received: (qmail 89570 invoked from network); 2 Nov 2005 21:46:25 -0000 Received: from hermes.apache.org (HELO mail.apache.org) (209.237.227.199) by minotaur.apache.org with SMTP; 2 Nov 2005 21:46:25 -0000 Received: (qmail 34425 invoked by uid 500); 2 Nov 2005 21:46:22 -0000 Delivered-To: apmail-httpd-dev-archive@httpd.apache.org Received: (qmail 34377 invoked by uid 500); 2 Nov 2005 21:46:21 -0000 Mailing-List: contact dev-help@httpd.apache.org; run by ezmlm Precedence: bulk Reply-To: dev@httpd.apache.org list-help: list-unsubscribe: List-Post: List-Id: Delivered-To: mailing list dev@httpd.apache.org Received: (qmail 34366 invoked by uid 99); 2 Nov 2005 21:46:21 -0000 X-ASF-Spam-Status: No, hits=-10.0 required=10.0 tests=ALL_TRUSTED X-Spam-Check-By: apache.org Received: from [209.237.227.194] (HELO minotaur.apache.org) (209.237.227.194) by apache.org (qpsmtpd/0.29) with SMTP; Wed, 02 Nov 2005 13:46:20 -0800 Received: (qmail 89256 invoked by uid 2161); 2 Nov 2005 21:46:00 -0000 Received: from [192.168.2.4] (euler.heimnetz.de [192.168.2.4]) by cerberus.heimnetz.de (Postfix on SuSE Linux 7.0 (i386)) with ESMTP id 7B02E1721C for ; Wed, 2 Nov 2005 22:45:44 +0100 (CET) Message-ID: <43693392.6050002@apache.org> Date: Wed, 02 Nov 2005 22:45:54 +0100 From: Ruediger Pluem User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.12) Gecko/20050920 X-Accept-Language: de, en, de-de, en-gb, cy, zu, xh MIME-Version: 1.0 To: dev@httpd.apache.org Subject: Re: Potential memory leak in /modules/cache/mod_mem_cache.c References: In-Reply-To: X-Enigmail-Version: 0.90.2.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-Virus-Checked: Checked by ClamAV on apache.org X-Spam-Rating: minotaur.apache.org 1.6.2 0/1000/N On 11/02/2005 09:58 PM, Christophe Jaillet wrote: > Comments agains httpd-2.1.8-beta > ================================= > > In file mod_mem_cache.c (/modules/cache) around line 558, there is a malloc > (*obj). > A few lines later, another malloc (buf) is performed. > > If the second malloc fails, then we have (*obj = NULL) but I don't see > anyway to free the memory allocated. > I would have imagined something like > free (*obj); > *obj = NULL; > > Unless, as a newbie in apache, there is something I don't know about memory > management in apache... Well spotted. mod_mem_cache currently does not get much attention from developer side as we all focus on mod_disk_cache which seems to be even faster in most situations than mod_mem_cache. Finding calls to malloc and friends in the code of mod_mem_cache is a clear documentation that there is no development care of this code as they should not be used inside of httpd code. Throughout the httpd code memory pools will be used to aquire memory for storing data structures. As we have recently cleaned up all dead MPM's from the 2.2.x branch, should we do the same with mod_mem_cache? It seems really unmaintained to me. Regards R�diger