Philippe M. Chiasson wrote:
Stas Bekman wrote:
Philippe M. Chiasson wrote:
Stas Bekman wrote:
Philippe M. Chiasson wrote:
Stas Bekman wrote: [...]
In any case, why the handler is not freed when <Perl> section is done?
That's a certain _leak_ right there.
Is parms->pool freed when config phase is over?
Well, AFAIK, parms->pool is process->pconf, and that doesn't get wiped until the process terminates.
So we need to use a temp pool instead.
Yes, most certainly, and that would have to be parms->temp_pool
Index: src/modules/perl/modperl_cmd.c =================================================================== --- src/modules/perl/modperl_cmd.c (revision 123857) +++ src/modules/perl/modperl_cmd.c (working copy) @@ -420,7 +420,7 @@
MP_CMD_SRV_DECLARE(perl) { - apr_pool_t *p = parms->pool; + apr_pool_t *p = parms->temp_pool; const char *endp = ap_strrchr_c(arg, '>'); const char *errmsg; char *code = ""; @@ -473,7 +473,7 @@
MP_CMD_SRV_DECLARE(perldo) { - apr_pool_t *p = parms->pool; + apr_pool_t *p = parms->temp_pool; server_rec *s = parms->server; apr_table_t *options; modperl_handler_t *handler = NULL;
And that's just for <Perl> sections, and a cursory glance suggests that there could be a bunch of other configuration directives that mistakenly use parms->pool.
I'll have a look and report later.
It's about time we should start thinking about optimizations. I'd check other startup thingies that may use the wrong pool which wastes memory at run-time.
See above!
If it is then this effort is certainly moot.
See above, but I think there is certainly a better solution.
<Pseudo-code> if (!modperl_handler_lookup_handlers()) { modperl_handler_new(); modperl_cmd_push_handlers(); } </Pseudo-code>
I'll submit a patch to illustrate this later on.
Aftering tinkering about this aproach a bit, it seems to me that's it's way overkill. after all, modperl_handler_new() is not a significant overhead for each <Perl> sections and with my suggested patch (above), they are proprely freed on startup.
Any objections to leaving it as is with the patch above ?
-------------------------------------------------------------------------------- Philippe M. Chiasson m/gozer\@(apache|cpan|ectoplasm)\.org/ GPG KeyID : 88C3A5A5 http://gozer.ectoplasm.org/ F9BF E0C2 480E 7680 1AE5 3631 CB32 A107 88C3A5A5
signature.asc
Description: OpenPGP digital signature