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 [EMAIL PROTECTED] changed: What |Removed |Added ---------------------------------------------------------------------------- AssignedTo|[email protected] |[EMAIL PROTECTED] Status|NEEDINFO |ASSIGNED ------- Additional Comments From [EMAIL PROTECTED] 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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
