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 <[EMAIL PROTECTED]> 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 <[EMAIL PROTECTED]> > > 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: [EMAIL PROTECTED] > > > > For additional commands, e-mail: [EMAIL PROTECTED] > > > > > > > > > > > > > > > > > > > > > > > > > -- > > > Samisa Abeysinghe > > > Software Architect; WSO2 Inc. > > > > > > http://www.wso2.com/ - "Oxygenating the Web Service Platform." > > > > > > > > > --------------------------------------------------------------------- > > > To unsubscribe, e-mail: [EMAIL PROTECTED] > > > For additional commands, e-mail: [EMAIL PROTECTED] > > > > > > > > > > > > ------------------------------------------------------------------------ > > > > > > --------------------------------------------------------------------- > > > To unsubscribe, e-mail: [EMAIL PROTECTED] > > > For additional commands, e-mail: [EMAIL PROTECTED] > > > > > > ------------------------------------------------------------------------ > > > > > > 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: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > -- East or West Mahindians are the Best... !
