Bug 3086 – tcp attr leak when reusing connection in http driver

Bug 3086 - tcp attr leak when reusing connection in http driver

Summary:

tcp attr leak when reusing connection in http driver

Status:	RESOLVED FIXED

Product:	XIO
Component:	Globus XIO
Version:	development
Platform:	PC Linux

Importance:	P3 normal
Target Milestone:	---
Assigned To:	John Bresnahan

URL:
Keywords:

Depends on:
Blocks:
	Show dependency tree / graph

Reported:	2005-04-06 08:02 by Joe Bester
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
Add an attachment (proposed patch, testcase, etc.)

Note

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

Description From Joe Bester 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 Kuba Rozkwitalski 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 Kuba Rozkwitalski 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 Kuba Rozkwitalski 2005-09-28 08:49:37 -------

Created an attachment (id=708) [details]
patch for memory leak in xio

------- Comment #4 From John Bresnahan 2005-12-01 13:33:55 -------

this is resolved and in the trunk now.