httpd-bugs mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From bugzi...@apache.org
Subject DO NOT REPLY [Bug 39985] - mod_dbd shutdown double free via dbd_close
Date Thu, 07 Dec 2006 21:56:12 GMT
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG·
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
<http://issues.apache.org/bugzilla/show_bug.cgi?id=39985>.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND·
INSERTED IN THE BUG DATABASE.

http://issues.apache.org/bugzilla/show_bug.cgi?id=39985


chrisd@pearsoncmg.com changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
         AssignedTo|bugs@httpd.apache.org       |chrisd@pearsoncmg.com
             Status|NEEDINFO                    |ASSIGNED




------- Additional Comments From chrisd@pearsoncmg.com  2006-12-07 13:56 -------
Created an attachment (id=19226)
 --> (http://issues.apache.org/bugzilla/attachment.cgi?id=19226&action=view)
Memory pool fixes for trunk.

These patches aim to prevent the following situation, which I suspect was
the cause of these bug reports.  (I myself have rarely seen the problem,
so if someone who can replicate it reliably could try either of these patches,
that would be very helpful!)

When using a reslist, the reslist internally registers a cleanup function
on the memory pool used for the reslist, specifically the reslist_cleanup()
function.  This function calls the destructor on each resource.  For mod_dbd,
that destructor is dbd_destruct(), which just calls dbd_close().  Now
dbd_close() calls apr_pool_destroy() on the memory sub-pool that was
created in dbd_construct() for use by that particular DB connection; this
is where the connection's prepared statements are created.

Normally, we want this memory pool to be destroyed when dbd_destruct() or
dbd_close() is called -- suppose the reslist is expiring a resource, i.e.,
a DB connection, we want it to (a) close the DB connection and (b) reclaim
the memory used for that connection's prepared statements.

OK, but when the parent memory pool (the one used by the reslist itself)
is destroyed, apr_pool_destroy() first destroys all the sub-pools of that
pool -- in this case, these are the per-connection sub-pools.  Then it calls
all the cleanup functions on the pool, including the reslist cleanup
function, which then calls dbd_destruct() on each connection, causes
apr_pool_destroy() to be called twice for each sub-pool and presumably
sometimes producing the segfaults people have reported.

Let me know if these patches fix the problem (and don't introduce new
problems!) and I'll commit the trunk version, and propose the fix for
2.2.x.	Review of the no-threads logic would be especially helpful.
Thanks!

-- 
Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.

---------------------------------------------------------------------
To unsubscribe, e-mail: bugs-unsubscribe@httpd.apache.org
For additional commands, e-mail: bugs-help@httpd.apache.org


Mime
View raw message