I'm taking this patch back :( I just had a crash in valgrind while running with this patch applied. There is a definite memory corruption caused by freeing the http_client.
Severity errors such as the following occur: [Thu Feb 22 15:43:15 2007] [error] libxml2_reader_wrapper.c(953) Extra content at the end of the document -- SEVERITY_ERROR [Thu Feb 22 15:43:15 2007] [error] libxml2_reader_wrapper.c(519) error occured in reading xml stream And then transmit threads eventually crash like this: ==7747== Thread 6: ==7747== Invalid read of size 4 ==7747== at 0x1BA8825D: (within /lib/libc-2.3.2.so) ==7747== by 0x1BA878BB: iconv_close (in /lib/libc-2.3.2.so) ==7747== by 0x8258F27: xmlCharEncCloseFunc (encoding.c:2118) ==7747== by 0x81E4F3E: xmlOutputBufferClose (xmlIO.c:2246) ==7747== by 0x824AC17: xmlFreeTextWriter (xmlwriter.c:474) ==7747== by 0x8198CB1: axis2_libxml2_writer_wrapper_free (in /home/build/CENTRAL-20070222/central/app/src/asperacentral) ==7747== by 0x81A2566: axiom_output_free (in /home/build/CENTRAL-20070222/central/app/src/asperacentral) ==7747== by 0x818A99B: axis2_http_transport_sender_invoke (http_transport_sender.c:400) ==7747== by 0x814F9F8: axis2_engine_send (engine.c:330) ==7747== by 0x8184D33: axis2_mep_client_two_way_send (mep_client.c:637) ==7747== by 0x81864F2: axis2_op_client_worker_func (op_client.c:758) ==7747== by 0x81C16B6: dummy_worker (in /home/build/CENTRAL-20070222/central/app/src/asperacentral) ==7747== Address 0x5 is not stack'd, malloc'd or (recently) free'd central term handler: 11 I'll be more careful with any further patches I send in. But there's still an issue here which is rather severe, so I'm hoping this info helps someone find the problem. The leaking of socket handles is obviously problematic, given that the system will run out after a short time. Jared On 2/22/07, Jared Hanson <[EMAIL PROTECTED]> wrote:
Attached is a patch to fix a socket handle and memory leak in soap_over_http_sender. It owns an http_client (sender_impl->client). This was not being free'd, and previously had a comment that said not to, because it will be required in later processing of the message. I stepped through the code, and could not find such a scenario. The only thing that looked risky, was that http_client has a http_simple_response, which in turn has an in_stream (the response). This in_stream has ownership transferred to the msg_ctx. I applied this patch and ran a number of request/response cycles, and didn't detect any ill effects. Someone familiar with this error of the code should review this, in case I'm missing something. Regardless, there is a socket handle leak which is quite severe. Here is the relevant valgrind output which identifies the issue: ==4430== Open AF_INET socket 376: 192.168.10.32:40547 <-> 192.168.1.230:2757 ==4430== at 0x1BB497A2: socket (in /lib/libc-2.3.2.so) ==4430== by 0x818F228: axis2_http_client_send (http_client.c:325) ==4430== by 0x818C1FB: axis2_soap_over_http_sender_send (soap_over_http_sender.c:491) ==4430== by 0x818B23C: axis2_http_transport_sender_write_message (http_transport_sender.c:615) ==4430== by 0x818A535: axis2_http_transport_sender_invoke (http_transport_sender.c:280) ==4430== by 0x814F9F8: axis2_engine_send ( engine.c:330) ==4430== by 0x8184D33: axis2_mep_client_two_way_send (mep_client.c:637) ==4430== by 0x81864F2: axis2_op_client_worker_func (op_client.c:758) ==4430== by 0x81C168E: dummy_worker (in /home/build/CENTRAL-20070222/central/app/src/asperacentral) ==4430== by 0x1B93AE50: pthread_start_thread (in /lib/libpthread- 0.10.so) ==4430== by 0x1BB488A9: clone (in /lib/libc-2.3.2.so)
