I didn't have an net access for the last 12 hours so I couldn't comment on your followups. Meanwhile it looks like I have found the problem and hopefully solved it. The patch and much more extensive test follows:
So there were two problems happening. You have encountered only one with sub-pools, i have noticed one more caused by parent_get().
Both problems lead to the same result: the same pool was destructed more than once. If you were lucky and no other pool was assigned to the freed space, you didn't see the segfault or may be saw it affecting other things later. However if some other pool was given the space that was allocated to the pool that was destroyed, destroying it again was wrecking havoc.
Problem #1: when a parent pool destroyes a subpool via apr_pool_destroy() it doesn't destroy the sub-pool's perl object which contains the pointer to now invalid pool. When that sub-pool's perl object is destroyed implicitly or explicitly it calls apr_pool_destroy again.
Problem #2: it wasn't actually tested, but it is now. $child->parent_get brings the parent pool perl object. If that object was created by us it'll be marked as destroyable. Now we have two objects (at least) containing a reference to the same pool. When the first object is destroyed it doesn't tell other objects containing the same pool reference that it was already destroyed. So when those are destroyed, they destroy the pool second and third and do forth time (as many times as there are objects pointing to the same pool). But when the first perl object is destroyed it must *not* destroy the pool if there are other objects containing a reference to this pool.
Solution:
a) when creating a new pool, raise a destroyable flag in the pool's data (we had that implemented). when the apr_pool_destroy was called, unset that flag (that's new).
b) Reference counting. Every time we create a perl object increment a reference counter and store that data in the pool's data. Every time a perl object is DESTROYed decrement a reference counter for the pool it points to.
c) only when the destroyable flag is on and a reference counting is zero, apr_pool_destroy can be called.
------------
If you look at the patch, I haven't changed the typemap to handle the reference counting internally. I think that would be a waste of resources, since we really want to have this accounting for pools created by us. It makes thing more error-prone if we add new functions which return pool objects and forget to increment the reference count, but we don't pay the overhead of setting and getting pool data for the normal use, which will probably account to 99.99% of the time.
BTW, I got all both $child->parent_get and $parent->is_ancestor($child) working, here is a chunk from the test that uses both:
# returns how many ancestor generations the pool has (parent,
# grandparent, etc.)
sub ancestry_count {
my $child = shift;
my $gen = 0;
while (my $parent = $child->parent_get) {
# prevent possible endless loops
die "child pool reports to be its own parent, corruption!"
if $parent == $child;
$gen++;
die "child knows its parent, but the parent denies having that child"
unless $parent->is_ancestor($child);
$child = $parent;
}
return $gen;
}Hopefully you will report a success on win32 and we can release 1.99_10 now ;)
__________________________________________________________________ Stas Bekman JAm_pH ------> Just Another mod_perl Hacker http://stason.org/ mod_perl Guide ---> http://perl.apache.org mailto:[EMAIL PROTECTED] http://use.perl.org http://apacheweek.com http://modperlbook.org http://apache.org http://ticketmaster.com
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
