Stas Bekman <[EMAIL PROTECTED]> writes:
[...]
Any ideas about how to fix the segfaults at startup time too?
I'll try to reproduce it now.
I'm able to get these segfults now, but not reliably.
My first impression is that some APR::Pool SV object
created during post-config, and points at the ptemp pool.
The problem seems to be that the SV has a slightly longer lifespan than the pool does, so when DESTROY is called
on the SV, the (ptemp) pool pointer it has is bogus.
I think APR__Pool.h would be better insulated from this sort of bug if it stored the SV's
"can call apr_pool_destroy"
status in the SV's magic table, instead of the pool's userdata.
Please take a look at the long comments in APR__Pool.h, as I doubt that will work. Any parental pool destroy will call sub-pool destroys, pulling the rug from under the SVs that refer to sub-pools. Unless you mean something else. On the other hand Gozer was planning on doing yet another rewritting of the pool handling, so may be he can chime in and explain what's on his mind.
-- __________________________________________________________________ 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]
