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.
