axis-c-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Manjula Peiris (JIRA)" <>
Subject [jira] Resolved: (AXIS2C-1242) Serious memory leak in mod_axis2 when Apache receives non-axis requests
Date Sun, 27 Jul 2008 15:47:31 GMT


Manjula Peiris resolved AXIS2C-1242.

       Resolution: Invalid
    Fix Version/s: Current (Nightly)
         Assignee: Manjula Peiris

Thanks for pointing this out. I changed the code to switch back to apache2 request pools.
In the current code base we don't need such a requirement to use our own pools. Because the
reasons for using our own apr_pool are no longer there in the current codebase.

> Serious memory leak in mod_axis2 when Apache receives non-axis requests
> -----------------------------------------------------------------------
>                 Key: AXIS2C-1242
>                 URL:
>             Project: Axis2-C
>          Issue Type: Bug
>          Components: httpd module
>    Affects Versions: Current (Nightly)
>         Environment: I was running Linux (Ubuntu 8.04), Apache httpd v. 2 2 9, but this
probably affects all platforms.
>            Reporter: alex bolgarov
>            Assignee: Manjula Peiris
>            Priority: Critical
>             Fix For: Current (Nightly)
> A copy of my original e-mail to the Axis2/C mail list with the description of the problem:
> Hi,
> I found another serious memory leak in the mod_axis2.
> Using the SVN's version of the Axis2/C, in the file
>    src/core/transport/http/server/apache2/mod_axis2.c
> in the function axis2_handler():
> at the very beginning of the function there are two function calls:
>    apr_allocator_create(&local_allocator)
>    apr_pool_create_ex(&local_pool, NULL, NULL, local_allocator);
> (right after the local variable declarations).
> These calls apparently allocate memory that is supposed to be released
> by the call
>    axis2_module_pool_allocator_destroy(allocator);
> at the end of the function.
> Apache calls axis2_handler() for every request it receives, not only
> for the Axis requests. So this function checks if this is request for
> the Axis:
>    if (strcmp(req->handler, "axis2_module"))
>    {
>        return DECLINED;
>    }
>    ...
> and returns DECLINED if it it not.
> The problem is that this check is done _after_ the calls of
> apr_allocator_create() and apr_pool_create_ex(). So in the case the
> request is _not_ for Axis, the memory allocated by these functions
> will be lost (leaked).
> On my machine, I'm developing an Axis service and another Apache
> module, completely unrelated to the Axis service. In the Apache config
> I'm loading the Axis module mod_axis2 - even when I'm not working on
> the Axis service.
> Couple of days ago I did a stress-test for this my other module (like,
> running 800 client test threads that all are sending requests to the
> Apache that runs my module, for sustained period of time) and found
> out that the memory in the Apache client processes is exhausting very
> quickly. I have spend these couple of days trying to understand where
> all this  memory goes :(
> Finally, today I removed loading of the mod_axis from the Apache
> config - and the memory leaks stopped :)
> So I looked at the Axis2/C source code, and found the problem as
> described above.
> I did an experiment - I moved those two calls of
> apr_allocator_create() and apr_pool_create_ex() after the check of "if
> (strcmp(req->handler, "axis2_module"))" and re-build the Axis2/C. This
> fixed the memory leak.
> So here I submit this message instead of the patch, as I'm not sure,
> it looks like there are another couple of returns (in case of some
> errors) from the axis2_handler() where the memory allocated by those
> two calls is not released, so please, would someone who is more
> familiar with the code take a look at this?
> Thank you,
>    alex.

This message is automatically generated by JIRA.
You can reply to this email to add a comment to the issue online.

To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message