[ 
https://issues.apache.org/jira/browse/AXIS2C-1242?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12617465#action_12617465
 ] 

Manjula Peiris commented on AXIS2C-1242:
----------------------------------------

Subra,

Only modification was on mod_axis2.c and allocator.c. But we are not sure 
whether there are any modifications to those files after 1.4.0 release. So it 
is not advicable to update only some file while not modifying other files. 
However, you can do a diff between your files and what is available in svn and 
come to a conclusion.

> Serious memory leak in mod_axis2 when Apache receives non-axis requests
> -----------------------------------------------------------------------
>
>                 Key: AXIS2C-1242
>                 URL: https://issues.apache.org/jira/browse/AXIS2C-1242
>             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: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Reply via email to