On Sun, Oct 05, 2025 at 12:42:42PM +0200, Ruediger Pluem wrote: > I think we have a design issue below. mod_socache_dbm uses ctx->pool for many > operations (retrieve, store, expire, etc.), but > ctx->pool is a child of the pconf pool and the same pool for all threads. I > see two possible ways forward: > > Either create a subpool each time or use a another external thread specific > pool like r->pool. > A subpool might be more memory efficient but comes with the penalty of a > process lock for creation and destroying > while something like r->pool might consume more memory but does not require > additional locking. > Any opinions?
Why isn't it using the pool passed to retrieve()/store() etc? That pool is explicitly documented as "Pool for temporary allocations"? There should already be a global lock held by API consumer, since the socache provider is marked with AP_SOCACHE_FLAG_NOTMPSAFE. It looks like mod_authn_socache is protecting entry to the socache provider inside a global mutex without checking that flag - overkill but should be safe. Regards, Joe > > Regards > > Rüdiger > > > -------- Forwarded Message -------- > Subject: [Bug 69841] New: "double free or corruption" with mod_socache_dbm > (socache_dbm_retrieve() + database_cleanup()) > Date: Sun, 05 Oct 2025 08:39:23 +0000 > From: [email protected] > Reply-To: Apache HTTPD Bugs Notification List <[email protected]> > To: [email protected] > > https://bz.apache.org/bugzilla/show_bug.cgi?id=69841 > > Bug ID: 69841 > Summary: "double free or corruption" with mod_socache_dbm > (socache_dbm_retrieve() + database_cleanup()) > Product: Apache httpd-2 > Version: 2.4.65 > Hardware: PC > OS: Linux > Status: NEW > Severity: normal > Priority: P2 > Component: mod_socache_(dbm|dc|memcache|shmcb) > Assignee: [email protected] > Reporter: [email protected] > Target Milestone: --- > > >
