axis-c-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Samisa Abeysinghe <sam...@wso2.com>
Subject hello client in manual broken was [Re: I don't understand what is going on with memory control in a client.]
Date Thu, 27 Mar 2008 03:18:15 GMT
The user seems to run into problems :(

Samisa...

Alex Bolgarov wrote:
> Well, I _am_ using the sample provided by the Axis project - the
> client I'm using is the exact code sample from the "Axis2/C Manual" -
> the manual that is available here:
> http://ws.apache.org/axis2/c/docs/axis2c_manual.html. The sample
> client code I'm using is, without any changes, from this page:
> http://ws.apache.org/axis2/c/docs/hello/client/hello.c.html (I'm
> attaching the file that I was compiling, just in case there are some
> differences I could not see, but I've just copied the code from the
> web browser window and pasted it into XEmacs editor and saved as a
> 'my_client.c' file)
>
> And, as you can see in the sample client code, this sample _releases_
> a payload memory that is passes to the send_receive operation:
>
>     if (payload)
>     {
>         axiom_node_free_tree(payload, env);
>         payload = NULL;
>     }
>
> Is the sample wrong? I will take a look at the samples from the source
> distribution, may be they don't release the payload?
>
> Anyway, when the service _is_ running and the client receives the
> response, why attempt to release the payload tree by the client (which
> this sample client does) does not cause the crash? If the Axis took
> ownership for the payload tree, it should have deleted it already, and
> attempt to delete if in the client code would have caused a crash.
> Something is not right here...
>
>
> Thank you,
>
>     alex.
>
>
>
> On Wed, Mar 26, 2008 at 10:30 AM, Samisa Abeysinghe <samisa@wso2.com> wrote:
>   
>> In short, the AXIOM that you create and pass to service client
>>  send_receive operation would be taken control of by service client. So,
>>  you do not have to free that, even though you will be creating it. Same
>>  with the returned response payload. You can use it, but you do not have
>>  ownership of that. All that you have to delete is the service client
>>  instance.
>>
>>  If you can send in your client code, we can have a look.
>>
>>  Also, the samples follow the convention that I explained above, so if
>>  you follow the samples, you can solve the problems.
>>
>>  Samisa...
>>
>>
>>
>>  Alex Bolgarov wrote:
>>  > Hi,
>>  >
>>  > I don't understand what's going on inside the Axis2/C client. My test
>>  > client crashes. I looked at the Axis source code and did some
>>  > debugging (mostly, I've added a lots of AXIS2_LOG_DEBUG(...) to the
>>  > Axis source code and recompiled - I have a fast enough computer, and
>>  > this way you can receive repeating results, something that hard to get
>>  > with a debugger), and run a client code with valgrind.
>>  >
>>  > I think there might be some mix up in the the
>>  > axis2_op_client_add_msg_ctx() function, which causes the memory that
>>  > is not supposed to be freed by the Axis library (specifically, the
>>  > payload data that is allocated by the client application before it
>>  > calls the axis2_svc_client_send_receive()). Then, when the
>>  > axis2_svc_client_send_receive() returns to my client code, the client
>>  > tries to free the payload it allocated, at which moment the client
>>  > crashes - either silently, or with the glibc reporting "double free or
>>  > corruption".
>>  >
>>  > Now that I've got your attention, here are the details (sorry, this is
>>  > a long message):
>>  >
>>  > First, I'm using Ubuntu 7.10, and I downloaded and compiled sources of
>>  > Axis2/C 1.3.0.
>>  >
>>  > I compiled a SOAP service - virtually unchanged code of the example
>>  > from the user guide, but the service looks to be OK, there is a
>>  > problem with the client.
>>  >
>>  > I compiled a SOAP client - absolutely unchanged code of the client
>>  > from the user guide
>>  > (http://ws.apache.org/axis2/c/docs/hello/client/hello.c.html).
>>  >
>>  > When I'm starting the Axis server (for example, stand-alone
>>  > axis2_http_server application), the client works OK, it sends
>>  > something to the service and receives some response. No crashes.
>>  >
>>  > But if I start the client application _without_ starting a server
>>  > (that is, I expect some kind of timeout or some error about inability
>>  > to conect to the server), the client application crashes.
>>  >
>>  > Here is what I found:
>>  >
>>  > The axis2_svc_client_send_receive() calls
>>  > axis2_svc_client_send_receive_with_op_qname() function that implements
>>  > the sending and receiving of the SOAP messages. If there is an error
>>  > in the low-level sending/receiving of the messages (which really
>>  > happens in my case, because I did not start the SOAP server for this
>>  > test), the res_msg_ctx variable will be NULL, and in the conditional
>>  > statement in the lines 864-872 of the file axis2_svc_client.c is
>>  > executed the 'else' alternative, which calls the
>>  > axis2_op_client_add_msg_ctx() function, passing the res_msg_ctx value
>>  > (which is NULL) to it.
>>  >
>>  > In the axis2_op_client_add_msg_ctx() function, right before the 'if'
>>  > statement in the lines 274-296 (file axis_op_client.c):
>>  >
>>  >     if (out_msg_ctx && !mc)
>>  >
>>  >  value of the out_msg_ctx is not NULL, and value of the mc is not NULL
>>  > (I checked this using the debug logging), so the body of this
>>  > statement is executed. In this body, right before the 'if' statement
>>  > on the line 290:
>>  >
>>  >     if (axutil_strcmp(dump_value, AXIS2_VALUE_TRUE))
>>  >
>>  > the value of the dump_value is NULL (again checked by the debug
>>  > logging), and the axutil_strcmp() returns -1 (which is interpreted as
>>  > a 'true' boolean value), and thus the body of the statement, including
>>  > the call (line 292)
>>  >
>>  >     axis2_msg_ctx_free(out_msg_ctx, env);
>>  >
>>  > is executed.
>>  >
>>  > The out_msg_ctx here points to the same message context object that
>>  > was created in the axis2_svc_client_send_receive_with_op_qname()
>>  > function, before sending the SOAP request - I saw using the debug
>>  > logging that the pointer value returned by the axis2_msg_ctx_create()
>>  > call in the axis2_svc_client_send_receive_with_op_qname() (line 834)
>>  > is the same as the value of the pointer out_msg_ctx here.
>>  >
>>  > But this message context object contains a soap_envelop object that,
>>  > in turn, contains the payload object (tree of the object model nodes)
>>  > that my client application allocated before calling the
>>  > axis2_svc_client_send_receive() (specifically, this soap_envelop is
>>  > filled with the payload in the call
>>  > axis2_svc_client_fill_soap_envelope() (line 838, function
>>  > axis2_svc_client_send_receive_with_op_qname(), file
>>  > axis2_svc_client.c). So, returning back to the the
>>  > axis2_op_client_add_msg_ctx() function, this payload object (tree)
>>  > gets freed here. Then, later, when my client application tries to free
>>  > the payload object after the axis2_svc_client_send_receive() returns
>>  > to it, the application crashes, because this memory is already freed.
>>  >
>>  >
>>  > So, finally, my questions:
>>  >
>>  > What strategy the client application that calls
>>  > axis2_svc_client_send_receive() should use regarding
>>  > allocating/freeing memory? From the current implementation of Axis2/C,
>>  > it looks like a) if the response was received successfully, the client
>>  > application should free the payload, but b) if there was a
>>  > communication error, the Axis library will free the payload itself. Is
>>  > this correct?
>>  >
>>  > Is this a 'by design' feature of the Axis2/C or is this a bug and (in
>>  > theory) there should be more sane rules regarding memory control?
>>  > (And, is there somewhere published the memory management rules for the
>>  > Axis2/C?)
>>  >
>>  >
>>  > Second thing I've noticed when browsing the code of the
>>  > axis2_svc_client_send_receive_with_op_qname() is something that looks
>>  > suspiciously as a potential memory leak. Look at the line 838 of
>>  > fileaxis2_svc_client.c. Here a message context object is created (by
>>  > calling the axis2_msg_ctx_create(), wich allocates a memory for the
>>  > message control object (using an allocator from the environment, which
>>  > is normally malloc()?). Notice that the pointer to the allocated
>>  > message context object is stored in the _local_ variable msg_ctx.
>>  >
>>  > After this follows an 'if' statement (lines 838-842) that calls
>>  > axis2_svc_client_fill_soap_envelope() and if the result is 'false', it
>>  > executes 'return NULL'. The axis2_svc_client_fill_soap_envelope()
>>  > could return a wrong result for different reasons, for example, just
>>  > because the 'soap_version_uri' is not set in the client options (line
>>  > 407, file svc_client.c) - basically, I did not see any guarantee that
>>  > this function will not return 'false' if the message context object
>>  > was successfully allocated.
>>  >
>>  > So, if the axis2_svc_client_fill_soap_envelope() returns 'false', the
>>  > 'if' statement on lines 838-842 just returns NULL, and the
>>  > axis2_svc_client_send_receive_with_op_qname() exits, without freeing
>>  > the memory allocated for the mesasge context object. Because the
>>  > pointer to this memory was stored in the local variable msg_ctx, this
>>  > memory is lost. (Or, at least I think it is lost - I might be wrong
>>  > and there is far more complex processing here to prevent memory leaks
>>  > that I did not recognize :) )
>>  >
>>  >
>>  > Thank you,
>>  >
>>  >     alex.
>>  >
>>  > ---------------------------------------------------------------------
>>  > To unsubscribe, e-mail: axis-c-user-unsubscribe@ws.apache.org
>>  > For additional commands, e-mail: axis-c-user-help@ws.apache.org
>>  >
>>  >
>>  >
>>  >
>>
>>
>>  --
>>  Samisa Abeysinghe
>>  Software Architect; WSO2 Inc.
>>
>>  http://www.wso2.com/ - "Oxygenating the Web Service Platform."
>>
>>
>>  ---------------------------------------------------------------------
>>  To unsubscribe, e-mail: axis-c-user-unsubscribe@ws.apache.org
>>  For additional commands, e-mail: axis-c-user-help@ws.apache.org
>>
>>
>>     
>> ------------------------------------------------------------------------
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: axis-c-user-unsubscribe@ws.apache.org
>> For additional commands, e-mail: axis-c-user-help@ws.apache.org
>> ------------------------------------------------------------------------
>>
>> No virus found in this incoming message.
>> Checked by AVG. 
>> Version: 7.5.519 / Virus Database: 269.22.0/1343 - Release Date: 3/25/2008 7:17 PM


-- 
Samisa Abeysinghe 
Software Architect; WSO2 Inc.

http://www.wso2.com/ - "Oxygenating the Web Service Platform."


---------------------------------------------------------------------
To unsubscribe, e-mail: axis-c-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: axis-c-dev-help@ws.apache.org


Mime
View raw message