Mailing-List: contact dev-help@httpd.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@httpd.apache.org
Received-SPF: pass (athena.apache.org: local policy)
From: Stefan Fritsch <sf@sfritsch.de>
To: dev@httpd.apache.org
Subject: Re: memory leak in mod_slotmem_shm
Date: Mon, 27 Sep 2010 16:28:01 +0200
User-Agent: KMail/1.13.5 (Linux/2.6.32-5-amd64; KDE/4.4.5; x86_64; ; )
References: <201009261813.27244.sf@sfritsch.de>
 <F832DB1A-C69D-4175-BC39-CD4824FAC0E6@jaguNET.com>
 <401DEDD7-E5B5-41CE-BFA1-11996490AAA4@jaguNET.com>
In-Reply-To: <401DEDD7-E5B5-41CE-BFA1-11996490AAA4@jaguNET.com>
MIME-Version: 1.0
Content-Type: Text/Plain;
  charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
Message-Id: <201009271628.01835.sf@sfritsch.de>

On Monday 27 September 2010, Jim Jagielski wrote:
> On Sep 27, 2010, at 9:19 AM, Jim Jagielski wrote:
> > On Sep 27, 2010, at 8:17 AM, Jim Jagielski wrote:
> >> Let me look...
> >> 
> >> On Sep 26, 2010, at 12:13 PM, Stefan Fritsch wrote:
> >>> Hi,
> >>> 
> >>> mod_slotmem_shm creates a new global pool on every graceful
> >>> restart but never destroys it.
> >>> 
> >>> From quickly looking at the code it is not clear to me what the
> >>> correct behaviour would be. Should the pool be created from
> >>> pconf instead? Or should it be destroyed in cleanup_slotmem()?
> > 
> > creating from pconf is cleaner...
> 
> Hold on a tic... I'm not seeing the leak. During
> cleanup_slotmem we do destroy next->gpool which
> is set to gpool.

Hmm. There seem to be two issues here:

If no other module uses shm slotmem (i.e. slotmem_create() is never 
called), globallistmem stays NULL and the cleanup does nothing. In 
this case gpool is leaked every time.

The pool is created on every call to pre_config, but the cleanup is 
registered only on the second and subsequent calls to post_config. In 
this case only the first gpool is leaked.

BTW, it is not that obvious that the shm is supposed to be cleaned up 
and re-created on graceful restarts. This should be documented in the 
code.