Bug 3086 - tcp attr leak when reusing connection in http driver
: tcp attr leak when reusing connection in http driver
Status: RESOLVED FIXED
: XIO
Globus XIO
: development
: PC Linux
: P3 normal
: ---
Assigned To:
:
:
:
:
  Show dependency treegraph
 
Reported: 2005-04-06 08:02 by
Modified: 2005-12-01 13:33 (History)


Attachments
patch for memory leak in xio (764 bytes, patch)
2005-09-28 08:49, Kuba Rozkwitalski
Details


Note

You need to log in before you can comment on or make changes to this bug.


Description From 2005-04-06 08:02:45
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.
------- Comment #1 From 2005-09-02 08:08:30 -------
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.
------- Comment #2 From 2005-09-28 08:47:47 -------
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:
'valgrind --leak-check=full
$GLOBUS_LOCATION/test/globus_c_wsrf_sample_counter_client_test/test-counter
http://localhost.localdomain:32785/wsrf/services/CounterService'

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
(globus_soap_message_transport.c:990)
==8170==    by 0x1BE1BE76: globus_l_soap_client_request_callback
(globus_soap_client_request.c:346)
==8170==    by 0x1BE1BBEE: globus_l_soap_client_request_done_callback
(globus_soap_client_request.c:234)
==8170==    by 0x1BDE57EB: globus_l_handler_callback_call_next
(globus_handler_chain.c:683)
==8170==    by 0x1BF58CA2: globus_callback_space_poll
(globus_callback_nothreads.c:1430)
==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.
------- Comment #3 From 2005-09-28 08:49:37 -------
Created an attachment (id=708) [details]
patch for memory leak in xio
------- Comment #4 From 2005-12-01 13:33:55 -------
this is resolved and in the trunk now.