From dev-return-1018-daniel=haxx.se@subversion.apache.org Fri Jan 8 03:43:57 2010 Return-Path: Received: from mail.apache.org (hermes.apache.org [140.211.11.3]) by giant.haxx.se (8.14.3/8.14.3/Debian-9) with SMTP id o082huce023084 for ; Fri, 8 Jan 2010 03:43:56 +0100 Received: (qmail 63417 invoked by uid 500); 8 Jan 2010 02:43:52 -0000 Mailing-List: contact dev-help@subversion.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Delivered-To: mailing list dev@subversion.apache.org Delivered-To: moderator for dev@subversion.apache.org Received: (qmail 66482 invoked by uid 99); 8 Jan 2010 00:16:28 -0000 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 (nike.apache.org: domain of bojan@rexursive.com designates 150.101.121.179 as permitted sender) Subject: Re: Hashtable data freed before pool cleanup From: Bojan Smojver To: Neil Conway Cc: Ruediger Pluem , APR Developer List , dev@subversion.apache.org In-Reply-To: References: <004001ca8fab$c7089b10$5519d130$@qqmail.nl> <4B45FD1C.3070907@apache.org> Content-Type: text/plain; charset="UTF-8" Date: Fri, 08 Jan 2010 11:15:58 +1100 Message-ID: <1262909758.1880.13.camel@shrek.rexursive.com> Mime-Version: 1.0 X-Mailer: Evolution 2.28.2 (2.28.2-1.fc12) Content-Transfer-Encoding: 7bit X-Virus-Checked: Checked by ClamAV on apache.org On Thu, 2010-01-07 at 11:00 -0800, Neil Conway wrote: > Well, the suggested fix of using a sibling pool to the hash table's > pool would work, I think -- I'd be happy to prepare patches to > implement that. What would you hang the destruction of the array_pool against? The parent pool? If so, we may have a different memory leak on our hands (i.e. hash's pool gets whacked, but array_pool persists until the parent goes away, which could be a long way away). Hanging it off the hash's pool probably won't work, because depending on the order of cleanups, this may not run last. So, again, we may end up with some pool cleanups referring to things that have been deallocated. Given the code of apr_hash.c, the only place array_pool gets used is here: ----------- static apr_hash_entry_t **alloc_array(apr_hash_t *ht, unsigned int max) { return apr_pcalloc(ht->array_pool, sizeof(*ht->array) * (max + 1)); } ----------- Why can't we just use malloc() for this and hang a cleanup off the pool? It would use less memory anyway than having another pool for this. Just tossing ideas around... -- Bojan