On Wed, 24 Sep 2003, Stas Bekman wrote:
Sander says that this shouldn't be an issue, however try this patch. It assigns a unique key based on the pool address without hardcoding anything at all:
Index: xs/APR/Pool/APR__Pool.h =================================================================== RCS file: /home/cvs/modperl-2.0/xs/APR/Pool/APR__Pool.h,v retrieving revision 1.6 diff -u -r1.6 APR__Pool.h --- xs/APR/Pool/APR__Pool.h 9 Sep 2003 17:22:39 -0000 1.6 +++ xs/APR/Pool/APR__Pool.h 25 Sep 2003 06:55:57 -0000 @@ -9,12 +9,15 @@ { apr_pool_t *parent = mpxs_sv_object_deref(obj, apr_pool_t); apr_pool_t *newpool = NULL; + char *key; + (void)apr_pool_create(&newpool, parent);
/* mark the pool as being created via APR::Pool->new() * see mpxs_apr_pool_DESTROY */ - apr_pool_userdata_set((const void *)1, MP_APR_POOL_NEW, - apr_pool_cleanup_null, newpool); + key = apr_psprintf(newpool, "0x%lx", (unsigned long)newpool); + fprintf(stderr, "CREATE key: %s\n", key); + apr_pool_userdata_set((const void *)1, key, NULL, newpool);
return newpool; } @@ -119,7 +122,8 @@
void *flag; apr_pool_t *p; - + char *key; + /* APR::Pool::DESTROY * we only want to call DESTROY on objects created by * APR::Pool->new(), not objects representing native pools @@ -128,7 +132,9 @@
p = mpxs_sv_object_deref(obj, apr_pool_t);
- apr_pool_userdata_get(&flag, MP_APR_POOL_NEW, p); + key = apr_psprintf(p, "0x%lx", (unsigned long)p); + fprintf(stderr, "DESTROY key: %s\n", key); + apr_pool_userdata_get(&flag, key, p);
if (flag) { apr_pool_destroy(p);
Do you get the printf reporting unique addresses, which are used as keys?
Unfortunately, I get back the t/filter/ crash with this patch ...
That just proves that the problem is unrelated to keys, but to the fact that subpools are destroyed. Both your previous patches weren't destroying either the parent or the child pools, hence you had a partial success I believe.
We are adjusting the warning in userdata_set docco to disambiguate the note and tell that the uniqueness is needed only inside the same pool, not even a pool and its sub-pool. it's just that each pool uses its own apr_hash_t to store the keys and the data, that's why uniqueness is needed.
Back to the sketching board. It took me half a day of apr patching to just be able to debug with --enable-pool-debug=all, which didn't quite work out of box :( I wish I had the segfault like you do, it'd make my debugging so much easier, rather than looking at the addresses and trying to figure out what could go wrong when everything seems to be OK.
BTW, does apr pool debugging work for you? Please try building apr as:
cd httpd-2.0/srclib/apr>
make distclean
./configure --enable-pool-debug=all --enable-maintainer-mode --prefix=/home/stas/httpd/prefork && make
make install
of course adjust the prefix ;)
If it segfaults on start like it did for me, I have posted a workaround here: http://marc.theaimsgroup.com/?l=apr-dev&m=106447516910813&w=2 not sure whether it will work for you, since it slashes a global pool's mutex.
now you need to patch the create function to tag the pool, so you can find the relevant messages in the sea of other debug prints.
Index: xs/APR/Pool/APR__Pool.h
===================================================================
RCS file: /home/cvs/modperl-2.0/xs/APR/Pool/APR__Pool.h,v
retrieving revision 1.6
diff -u -r1.6 APR__Pool.h
--- xs/APR/Pool/APR__Pool.h 9 Sep 2003 17:22:39 -0000 1.6
+++ xs/APR/Pool/APR__Pool.h 25 Sep 2003 08:00:32 -0000
@@ -11,6 +11,8 @@
apr_pool_t *newpool = NULL;
(void)apr_pool_create(&newpool, parent);+ apr_pool_tag(newpool, MP_APR_POOL_NEW);
+
/* mark the pool as being created via APR::Pool->new()
* see mpxs_apr_pool_DESTROY */
apr_pool_userdata_set((const void *)1, MP_APR_POOL_NEW,I then use the following tick to fish the messages relevant to the pools we create:
tail -F t/logs/error_log | grep APR::
__________________________________________________________________ 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]
