axis-c-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Amadeus Fan" <>
Subject Re: memory leak minis
Date Mon, 01 Oct 2007 16:53:14 GMT
Similar issues as No.1 found at libxml2 reader/writer wrapper codes,
which create "ax*_char *" with libxml2's mechanism, and free them with
axis2/c's mechanism.

On 10/2/07, Amadeus Fan <> wrote:
> What I found when I read the codes while memory leak found.
> 1. dir_handler.c:185 291
> 185:    count = AXIS2_SCANDIR(pathname, &files, dir_select,
> 291:    AXIS2_FREE(env->allocator, files);
> I think the "files" in line 185 is not allocated by env->allocator, while in
> line 291, it is try to free it by env->allocator. It is safe for the default
> implement of env->allocator, for it use the default libc 'malloc' just as
> what the scandir do. But if the env->allocator is customized by developers,
> such as the apache2 mod(which will use apr pools), the destroy maybe not the
> libc 'free', then will cause the memory leak.
> I don't have any further look at other codes for similar issues.
> 2.  axis2_svc_client_send_receive(
>          axis2_svc_client_t *svc_client,
>          const axutil_env_t *env,
>          const axiom_node_t *payload)
> in the implementation, if axis2_svc_client_send_receive() sucess, the
> 'payload' parameter will be owned by soap body, the caller should not
> destroy any more. That's also what the samples show. However, if
> axis2_svc_client_send_receive() failed, it is hard to determine whether or
> not the 'payload' parameter should be destroied or not, it maybe owned by
> soap body internally, maybe not.
> And more, in the method description, it is a "const" parameter, in general,
> it should not be update in the implementation. But, it is cast to "none
> const" in the implementation, and make it unable used by the caller, I don't
> think it is a good cast. I also found similar issues in places elsewhere.

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

View raw message