Thanks for the qucik response.
And there's also another case will make the user confused, for example, the
axis2/c have a public API "axutil_char_t* method() {/*libxml APIs
called/*}", internally, the method() will allocate the returned string with
libxml's interfaces. Without reading the implement code, the end user will
nerver know how could he release the returned memory, and never know whether
or not his codes will compatible with later releases or not. I noticed the
cases the make the memory leak in 1.0, will have a look at the new SVN.
Thanks & Regards,
Amadeus
On 10/2/07, Nandika Jayawardana <[EMAIL PROTECTED]> wrote:
>
> 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 <[EMAIL PROTECTED]> 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 < [EMAIL PROTECTED]> 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: [EMAIL PROTECTED]
> > For additional commands, e-mail: [EMAIL PROTECTED]
> >
> >
>
>
> --
> http://nandikajayawardana.blogspot.com/
> WSO2 Inc: http://www.wso2.com
