hi all
we have this in our todo/release:
* Apache->server_root_relative: needs to default to current pool (pconf at startup, r->pool at request time) - solution: require the pool object to be passed. if a user doesn't have one, make them create one, e.g.: Apache::server_root_relative(APR::Pool->new, ....). Must make sure that the returned SV has a copy of that string and doesn't rely on anything that it's in pool, which will be now destroyed.
as far as I can tell, this makes Apache::server_root_relative() behave exactly like ap_server_root_relative() wrt requiring a pool.
well, I think originally doug who has written that entry meant that server_root_relative should be able to figure out which pool to use on its own. I could be wrong. Your proposed change makes the API more complex (though it now maps 1:1 to the C API) and incompatible with mp1.
What do you think about the following: keep things as they are now - i.e. you can call $r->server_root_relative(), $c->server_root_relative(), etc. but if you call Apache::server_root_relative() it'll just use APR::Pool->new (in C of course) behind the scenes? We discussed several times about having a state variable/function which can tell us which phase we are in, so later on if we implement it we could assist ourselves using it and for example pick pconf if we figure that we are in one of the startup phases.
so, it looks to me like mod_perl doesn't need to intervene on this call at anymore, but I wanted to make sure I haven't missed something vital before a commit. the comments made me nervous, since I couldn't remember if the discussion at apachecon was that the SV definitely needed to be a copy, or if it just needed to be checked for integrity - I traced the pool calls back and didn't see anything that seemed to require the pool stick around, but I'm not entirely sure I'm looking at it right.
anyway, I added a few tests, including one that destroys the pool then attempts to reuse the SV. everything passes for me on worker, including t/SMOKE but I could use another set of eyes.
I think it just happens to work for you, since the freed memory wasn't overwritten by somebody else. It doesn't make sense if it works without making a copy of the string. If the pool goes away all its memory goes invalid, if you have a pointer to that memory, it now points to invalid memory (which may still contain seemingly good data). I'd add a debug print of the pointer when the string is allocated and then dump the SV to see if it's the same pointer, or simply look at the code to see whether it gets copied somewhere.
Notice that we need to ensure the copy only if use APR::Pool->new, with any other pool it's the responsibility of the user not to use that variable after the pool is gone. Oh, may be it's a bad assumption and we should always copy it. The biggest problem with not copying is that users will have hard time tracking this issue down, if they use a variable after the pool has gone out of scope. Sometimes it will work (if the freed memory is still free), sometimes it won't (and crash).
__________________________________________________________________ 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]
