You are viewing a plain text version of this content. The canonical link for it is here.
Posted to c-user@axis.apache.org by Alex Bolgarov <al...@bolgarov.org> on 2008/03/26 15:17:30 UTC
I don't understand what is going on with memory control in a client.
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
Re: I don't understand what is going on with memory control in a client.
Posted by Dinesh Premalal <xy...@gmail.com>.
Hi Manjula,
Manjula Peiris <ma...@wso2.com> writes:
>> Should not the (wrong) examples in the online user manual be updated too?
>
> Thanks Alex for pointing this out. We will fix this for the next
> release. It is great if you can raise a JIRA issue [1] on this.
I already created a issue for this couple of days ago [1]. :)
thanks,
Dinesh
1.https://issues.apache.org/jira/browse/AXIS2C-1089
--
http://nethu.org
---------------------------------------------------------------------
To unsubscribe, e-mail: axis-c-user-unsubscribe@ws.apache.org
For additional commands, e-mail: axis-c-user-help@ws.apache.org
Re: I don't understand what is going on with memory control in a
client.
Posted by Manjula Peiris <ma...@wso2.com>.
On Fri, 2008-03-28 at 15:20 -0400, Alex Bolgarov wrote:
> I tried with the echo sample - compiled both service and client from
> the source code. All worked OK, without crashes in both cases - when
> the request is successful and when the request fails because I did not
> start the service. And I run the client through the valgrind, there
> are no memory leaks (at least the small leaks that valgrind reports
> are not increasing after I put the call of send_receive() into loop
> and started increasing number of iterations). So it looks that the
> echo sample contains correct sequence of operations.
>
> Should not the (wrong) examples in the online user manual be updated too?
Thanks Alex for pointing this out. We will fix this for the next
release. It is great if you can raise a JIRA issue [1] on this.
[1] http://issues.apache.org/jira/browse/AXIS2C
Thanks,
-Manjula.
>
>
> On Wed, Mar 26, 2008 at 11:10 PM, Samisa Abeysinghe <sa...@wso2.com> wrote:
> > Try with echo sample.
> >
> > 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 <sa...@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-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
>
---------------------------------------------------------------------
To unsubscribe, e-mail: axis-c-user-unsubscribe@ws.apache.org
For additional commands, e-mail: axis-c-user-help@ws.apache.org
Re: I don't understand what is going on with memory control in a client.
Posted by Alex Bolgarov <al...@bolgarov.org>.
I tried with the echo sample - compiled both service and client from
the source code. All worked OK, without crashes in both cases - when
the request is successful and when the request fails because I did not
start the service. And I run the client through the valgrind, there
are no memory leaks (at least the small leaks that valgrind reports
are not increasing after I put the call of send_receive() into loop
and started increasing number of iterations). So it looks that the
echo sample contains correct sequence of operations.
Should not the (wrong) examples in the online user manual be updated too?
On Wed, Mar 26, 2008 at 11:10 PM, Samisa Abeysinghe <sa...@wso2.com> wrote:
> Try with echo sample.
>
> 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 <sa...@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-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
Re: I don't understand what is going on with memory control in a
client.
Posted by Samisa Abeysinghe <sa...@wso2.com>.
Try with echo sample.
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 <sa...@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-user-unsubscribe@ws.apache.org
For additional commands, e-mail: axis-c-user-help@ws.apache.org
Re: hello client in manual broken was [Re: I don't understand what is going on with memory control in a client.]
Posted by lahiru gunathilake <gl...@gmail.com>.
Hi again...,
I just look at the subject of the mail and test whether hello client works
or not. But that is not the issue and I tested the real issue and that's
true. Client crashes when the response is not recieve (As an example after
running the client without starting the server). I will fix the code in
axis2 manual.
Regs
lahiru
On Tue, Apr 8, 2008 at 3:48 PM, lahiru gunathilake <gl...@gmail.com>
wrote:
> Hi Alex...
>
> I've gone through the manul and hello service and client works fine.
> Here's the request and response I recieved
>
> <soapenv:Envelope xmlns:soapenv="http://www.w3.org/2003/05/soap-envelope">
> <soapenv:Header></soapenv:Header>
> <soapenv:Body>
> <greet>Hello Server!</greet>
> </soapenv:Body></soapenv:Envelope>
> ===================================================
> <soapenv:Envelope xmlns:soapenv="http://www.w3.org/2003/05/soap-envelope">
> <soapenv:Header></soapenv:Header>
> <soapenv:Body>
> <greetResponse>Hello Client!</greetResponse>
> </soapenv:Body></soapenv:Envelope>
> ===================================================
>
> Regs
> lahiru
>
>
> On Thu, Mar 27, 2008 at 8:48 AM, Samisa Abeysinghe <sa...@wso2.com>
> wrote:
>
> > 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 <sa...@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
> >
> >
>
>
>
Re: hello client in manual broken was [Re: I don't understand what is going on with memory control in a client.]
Posted by lahiru gunathilake <gl...@gmail.com>.
Hi Alex...
I've gone through the manul and hello service and client works fine.
Here's the request and response I recieved
<soapenv:Envelope xmlns:soapenv="http://www.w3.org/2003/05/soap-envelope">
<soapenv:Header></soapenv:Header>
<soapenv:Body>
<greet>Hello Server!</greet>
</soapenv:Body></soapenv:Envelope>
===================================================
<soapenv:Envelope xmlns:soapenv="http://www.w3.org/2003/05/soap-envelope">
<soapenv:Header></soapenv:Header>
<soapenv:Body>
<greetResponse>Hello Client!</greetResponse>
</soapenv:Body></soapenv:Envelope>
===================================================
Regs
lahiru
On Thu, Mar 27, 2008 at 8:48 AM, Samisa Abeysinghe <sa...@wso2.com> wrote:
> 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 <sa...@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
>
>
--
East or West
Mahindians are the
Best... !
hello client in manual broken was [Re: I don't understand what is
going on with memory control in a client.]
Posted by Samisa Abeysinghe <sa...@wso2.com>.
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 <sa...@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
Re: I don't understand what is going on with memory control in a client.
Posted by Alex Bolgarov <al...@bolgarov.org>.
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 <sa...@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
>
>
Re: I don't understand what is going on with memory control in a
client.
Posted by Samisa Abeysinghe <sa...@wso2.com>.
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