axis-c-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Nandika Jayawardana" <jayaw...@gmail.com>
Subject Re: memory leak minis
Date Tue, 02 Oct 2007 06:22:09 GMT
Hi Amadeus,

The issue with AXIS2_SCANDIR is now fixed in the current svn. As for the
libxml2 reader/writer wrapper codes, we have used libxml2 provided xmlFree
function to free the memory allocated using libxml2's mechanism in most
places. But there are few place's where this is an issue.

Regards
Nandika



On 10/1/07, Amadeus Fan <amadeus.fan@gmail.com> wrote:
>
> 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 <amadeus.fan@gmail.com> 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,
> > AXIS2_ALPHASORT);
> >
> > 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: axis-c-dev-unsubscribe@ws.apache.org
> For additional commands, e-mail: axis-c-dev-help@ws.apache.org
>
>


-- 
http://nandikajayawardana.blogspot.com/
WSO2 Inc: http://www.wso2.com

Mime
View raw message