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]
