Hi Alastair,
I have added JIRAs for all of these Issues.
Thanks a lot for your issues.
Regards
lahiru
On Thu, 2008-01-03 at 10:53 -0800, Alastair FETTES wrote:
> Apache Axis2/C Team:
>
> During our work with Axis2/C version 1.1 we have run into a number of
> issues that we would like to convey back to this group. The main
> problem that we have found is a lack of documentation regarding
> ownership of memory in input parameters and return parameters. Here
> is the laundry list of items so far.
>
> 1. Function axis2_svc_client_remove_all_headers:
>
> <snippet>
> 98 for (i = 0; i < size; i++)
> 99 {
> 100 /*axiom_node_t *node = NULL;
> 101 node = axutil_array_list_get(svc_client->headers,
> env,i);
> 102
> 103 if (node)
> 104 {
> 105 axiom_node_free_tree(node, env);
> 106 node = NULL;
> 107 } */
> 108 axutil_array_list_remove(svc_client->headers, env, i);
> 109 }
>
>
> 110 AXIS2_EXTERN void *AXIS2_CALL
> 111 axutil_array_list_remove(
> 112 struct axutil_array_list *array_list,
> 113 const axutil_env_t * env,
> 114 int index)
> 115 {
> 116 void *result = NULL;
> 117 int i = 0;
> 118 AXIS2_PARAM_CHECK (env->error, array_list, AXIS2_FAILURE);
> 119
> 120 if (axutil_array_list_check_bound_exclusive(array_list, env,
> index))
> 121 {
> 122 result = array_list->data[index];
> 123 for (i = index; i < array_list->size - 1; i++)
> 124 array_list->data[i] = array_list->data[i + 1];
> 125 array_list->size--;
> 126 }
> 127
> 128 return result;
> 129 }
> </snippet>
>
> Problem: There is a possible bug in
> "axis2_svc_client_remove_all_headers" function. The call to
> "axutil_array_list_remove" (line 108) is where the problem stems from.
> Since the for-loop (line 98) is incrementing, and the value of
> "array_list->size" (line 125) is decrementing, eventually line 120
> will fail, and some of the headers will not be cleared out.
>
> Solution: The call to axutil_array_list_remove should be decrementing
> (line 108 is a possible solution):
>
> <snippet>
> 98 for (i = 0; i < size; i--)
> 99 {
> 100 /*axiom_node_t *node = NULL;
> 101 node = axutil_array_list_get(svc_client->headers,
> env,i);
> 102
> 103 if (node)
> 104 {
> 105 axiom_node_free_tree(node, env);
> 106 node = NULL;
> 107 } */
> 108 axutil_array_list_remove(svc_client->headers, env, (size -
> i) - 1);
> 109 }
> </snippet>
>
> 2. Function axiom_element_create.
>
> <snippet>
> AXIS2_EXTERN
> axiom_element_t* axiom_element_create(
> const axutil_env_t* env,
> axiom_node_t* parent,
> const axis2_char_t* localname,
> axiom_namespace_t* ns,
> axiom_node_t** node)
> </snippet>
>
> Problem: The axiom_node_t instance node has responsibility for the
> returned axion_element_t*. Therefore, calls to axiom_node_free_tree
> will free this returned element (in addition to all the child nodes of
> node). The memory allocated for the return value should not be
> de-allocated using axiom_element_free in this scenario, since it is
> internally tied to the node.
>
> Solution: Document memory ownership for parameters and return value.
>
> 3. Function axiom_element_set_text:
>
> <snippet>
> AXIS2_EXTERN
> axis2_status_t axiom_element_set_text(
> axiom_element_t* om_element,
> const axutil_env_t* env,
> const axis2_char_t* text,
> axiom_node_t* element_node)
> </snippet>
>
> Problem: Currently, the om_element has no use and is not used by the
> function axiom_element_set_text therefore could probably be set NULL.
> The function does not take control of the string text within text.
>
> Solution: Document memory ownership for parameters and return value.
>
> 4. Function axiom_xml_reader_create_for_memory
>
> <snippet>
> AXIS2_EXTERN
> axiom_xml_reader_t* axiom_xml_reader_create_for_memory(
> const axutil_env_t* env,
> void* container,
> int size,
> const axis2_char_t* encoding,
> int type)
> </snippet>
>
> Problem: The return value of type axiom_xml_reader_t* takes control of
> the data contained within container.
>
> Solution: Document memory ownership for parameters and return value.
>
> 5. Function axiom_stax_builder_create
>
> <snippet>
> AXIS2_EXTERN
> axiom_stax_builder_t* axiom_stax_builder_create(
> const axutil_env_t* env,
> axiom_xml_reader_t* parser)
> </snippet>
>
> Problem: The return value of type axiom_stax_t* takes responsibility
> for the memory allocated for parser.
>
> Solution: Document memory ownership for parameters and return value.
>
> 6. Function axiom_document_create:
>
> <snippet>
> AXIS2_EXTERN
> axiom_document_t* axiom_document_create(
> const axutil_env_t* env,
> axiom_node_t* root,
> axiom_stax_builder_t* builder)
> </snippet>
>
> Problem: The return value of type axiom_document_t* takes
> responsibility for the memory allocated for root. Any child node that
> is added to root will be free-ed when the function axiom_document_free
> is called. The return value of type axiom_document_t* does not takes
> responsibility for the memory allocated for builder (as of v1.1.0,
> this seems odd, since the internal structure maintains a pointer to
> builder, but does not free builder. So this may create a dangling
> pointer situation).
>
> Solution: Document memory ownership for parameters and return value.
> Investigate use of pointers in internal structure.
>
> 7. Function axiom_document_build_all:
>
> <snippet>
> AXIS2_EXTERN
> axiom_node_t* axiom_document_build_all(
> struct axiom_document* document,
> const axutil_env_t* env)
> </snippet>
>
> Problem: The caller of this function is not given responsibility for
> the return value of type axiom_node_t*, since (as of v1.1.0) the
> return value is free-ed by the function axiom_document_free. If the
> caller calls the function axiom_document_free_self, the return value
> is NOT free-ed. So a memory leak is possible here.
>
> Solution: Document memory ownership for parameters and return value.
> Investigate the use of free functions and pointers in regards to
> possible memory leak.
>
> 8. Function axiom_namespace_create:
>
> <snippet>
> AXIS2_EXTERN
> axiom_namespace_t* axiom_namespace_create(
> const axutil_env_t* env,
> const axis2_char_t* uri,
> const axis2_char_t* prefix)
> </snippet>
>
> Problem: This function and return value of type axiom_namespace_t*
> does not take responsibility for the memory allocated for the
> parameters uri, prefix, and of course env.
>
> Solution: Document memory ownership for parameters and return value.
>
> 9. Function axiom_attribute_create:
>
> <snippet>
> AXIS2_EXTERN
> axiom_attribute_t* axiom_attribute_create(
> const axutil_env_t* env,
> const axis2_char_t* localname,
> const axis2_char_t* value,
> axiom_namespace_t* ns)
> </snippet>
>
> Problem: This return value of type axiom_attribute_t* does not take
> responsibility for the memory allocated for localname, value, ns, and
> env. Although, if the return value is added to an axiom_node_t using
> axiom_element_add_attribute, the responsibility of the namespace of
> the attribute is given to the axiom_node_t.
>
> Solution: Document memory ownership for parameters and return value.
> Investigate the ownership of the namespace parameter.
>
> 10. Function axiom_element_add_attribute:
>
> <snippet>
> AXIS2_EXTERN
> axis2_status_t axiom_element_add_attribute(
> axiom_element_t* om_element,
> const axutil_env_t* env,
> axiom_attribute_t* attribute,
> axiom_node_t* element_node)
> </snippet>
>
> Problem: The parameter om_element takes responsibility for the memory
> allocated for the parameter attribute, thus a call to
> axiom_element_free will de-allocated the data for attribute. The
> parameter om_element also takes responsibility for the namespace
> associated with attribute.
>
> Solution: Document memory ownership for parameters and return value.
>
> 11. Function axutil_env_create_all:
>
> <snippet>
> AXIS2_EXTERN
> axutil_env_t* axutil_env_create_all(
> const axis2_char_t* log_file,
> const axutil_log_levels_t log_level)
> </snippet>
>
> Problem: This function does not take responsibility for the memory
> allocated by log_file.
>
> Solution: Document memory ownership for parameters and return value.
>
> 12. Function axiom_output_create:
>
> <snippet>
> AXIS2_EXTERN
> axiom_output_t* axiom_output_create(
> const axutil_env_t* env,
> axiom_xml_writer_t* xml_writer)
> </snippet>
>
> Problem: The return value of type axiom_output_t* takes responsibility
> for the memory allocated to the parameter xml_writer.
>
> Solution: Document memory ownership for parameters and return value.
>
> 13. Function axis2_svc_client_send_receive_non_blocking:
>
> <snippet>
> AXIS2_EXTERN
> void axis2_svc_client_send_receive_non_blocking(
> axis2_svc_client_t* svc_client,
> const axutil_env_t* env,
> const axiom_node_t* payload,
> axis2_callback_t* callback)
> </snippet>
>
> Problem: This function takes responsibility for the memory allocated
> for the parameter payload (assumed due to access violations for
> free-ing), as well as the custom headers that have been added to the
> parameter svc_client (again, assumed because of access violations on
> free-ing). This function also takes responsibility for the memory
> allocated at callback, through the following call tree:
>
> axis2_svc_client_send_receive_non_blocking
> axis2_svc_client_send_receive_non_blocking_with_op_qname
> axis2_op_client_set_callback
>
> The memory is free-ed with a call to axis2_op_client_free (it is
> assumed that someone calls this)
>
> Solution: Document memory ownership for parameters and return value.
>
> 14. Function axis2_svc_client_add_header:
>
> <snippet>
> AXIS2_EXTERN
> axis2_status_t axis2_svc_client_add_header(
> axis2_svc_client_t* svc_client,
> const axutil_env_t* env,
> axiom_node_t* header)
> </snippet>
>
> The parameter svc_client does not take responsibility for the memory
> allocated for header, although it does maintain an internal pointer to
> the data. This can result in dangling pointer situations if the caller
> deletes the memory passed using header before svc_client has a chance
> to remove the header.
>
> Solution: Document memory ownership for parameters and return value.
> Investigate the use of pointers in the internal structure to avoid
> dangling pointer situations.
>
> 15. Function axis2_svc_client_remove_all_headers:
>
> <snippet>
> AXIS2_EXTERN
> axis2_status_t axis2_svc_client_remove_all_headers(
> axis2_svc_client_t* svc_client,
> const axutil_env_t* env)
> </snippet>
>
> This function does not take responsibility for the memory allocated to
> the pointers passed to it. In addition, the memory passed to the
> function axis2_svc_client_add_header through the parameter header is
> not de-allocated by this function
> (axis2_svc_client_remove_all_headers). This can create a possible
> memory leak. When in used in conjunction with a call to
> axis2_svc_client_send_receive_non_blocking, this is not a problem as
> this function will clean up the headers itself (this is assumed, since
> when you free the header nodes, an access violations occur when the
> SOAP message is sent and the calling function tries to free the SOAP
> message data, i.e. the header nodes).
>
> Solution: Document memory ownership for parameters and return value.
> Investigate potential memory leak.
>
> <end/>
>
> Thanks very much for your time and efforts.
>
> Alastair Fettes
>
> This e-mail and any attachments are intended solely for the use of the
> intended recipient(s) and may contain legally privileged, proprietary
> and/or confidential information. Any use, disclosure, dissemination,
> distribution or copying of this e-mail and any attachments for any
> purposes that have not been specifically authorized by the sender is
> strictly prohibited. If you are not the intended recipient, please
> immediately notify the sender by reply e-mail and permanently delete
> all copies and attachments.
>
> The entire content of this e-mail is for "information purposes" only
> and should not be relied upon by the recipient in any way unless
> otherwise confirmed in writing by way of letter or facsimile.
>
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
