Stas Bekman wrote:
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

Attachment: signature.asc
Description: OpenPGP digital signature



Reply via email to