Bugzilla – Bug 3086
tcp attr leak when reusing connection in http driver
Last modified: 2005-12-01 13:33:55
You need to
before you can comment on or make changes to this bug.
It looks like there's a leak of the TCP open attributes when a cached handle is
used by the http driver.
The problem case seems to be:
- http open is called
- finds a cached handle and calls globus_xio_driver_merge_handle with the op
- register a write with the handle
- when write callback happens, finishes the open
- when write callback returns to XIO, globus_xio_driver_write_delivered frees
the op without clearing the open_attr
Not sure if the problem is a driver problem or a xio core problem.
I'm working on this bug now, but I cannot reproduce it.
I tried to run tests under valgrind but it no errors showed up.
Joe, please give me details how you found the bug, and how to reproduce it.
I managed to resolve the leak I sent in email earlier.
It can be reproduced from current HEAD with:
1) starting container: 'globus-wsc-container -nosec'
2) running sample counter with contact string given from above, for example:
The leak I repaired was:
==8170== 88 bytes in 1 blocks are definitely lost in loss record 30 of 41
==8170== at 0x1B9002CF: malloc (in /usr/lib/valgrind/vgpreload_memcheck.so)
==8170== by 0x1BE86C0E: globus_l_xio_tcp_attr_copy (globus_xio_tcp_driver.c:733)
==8170== by 0x1BE47D40: globus_xio_register_open (globus_xio_handle.c:2148)
==8170== by 0x1BDE06D5: globus_soap_message_register_open
==8170== by 0x1BE1BE76: globus_l_soap_client_request_callback
==8170== by 0x1BE1BBEE: globus_l_soap_client_request_done_callback
==8170== by 0x1BDE57EB: globus_l_handler_callback_call_next
==8170== by 0x1BF58CA2: globus_callback_space_poll
==8170== by 0x1BE1A8A9: globus_soap_client_operation (globus_soap_client.c:192)
==8170== by 0x1B90BCA2: CounterPortType_add_epr (CounterService_client.c:2258)
==8170== by 0x804925C: main (test_counter.c:132)
I will attach the patch in a minute. It's generated against HEAD (namely 1.45
release of the file) and resolves this leak. I tested it with globus-xio-tests,
and globus-c-wsrf-* and didn't notice any regression.
I hope it resolves this bug.
Created an attachment (id=708) [details]
patch for memory leak in xio
this is resolved and in the trunk now.