Any known memory leak in nta?

[tenge-amzn]

Hi,
It's great to find out someone is actively working on this old lib.
I recently discovered memory leak when calling the sofia lib, but haven't find out exact location.

I was browsing the code in nta, in incoming_reclaim, it seems the irq->irq_rq(the request headers which is a linked list) isn't freed, but I'm not sure if I missed somewhere else.

[davehorton]

Do you have a simple scenario that illustrates the memory leak? If so, that would be helpful to me in trying to troubleshoot. I am not aware of any leaks in sofia-sip, but my investigation has not been exhaustive so I welcome any detailed bug reports.

[tenge-amzn]

I was simply using valgrind to detect the memory leaks. It seems all the definite lost are from sofia lib.
But on my second thought, it could be the code that using the lib in a wrong way.

I read about the docs of sofia lib, and all the memory allocation with the lib is home-based.
So what life cycle of the home object would be appropriated? Per SIP transaction? Currently home object is initialized at service starting up and deinit when service down.

==25605== 6,788 (2,096 direct, 4,692 indirect) bytes in 1 blocks are definitely lost in loss record 1,501 of 1,539
==25605== at 0x4C2A975: calloc (vg_replace_malloc.c:711)
==25605== by 0x7357C31: su_hash_alloc (su_alloc.c:390)
==25605== by 0x7357D54: sub_alloc (su_alloc.c:444)
==25605== by 0x7358858: su_alloc (su_alloc.c:784)
==25605== by 0x72B1677: msg_header_alloc (msg_parser.c:2312)
==25605== by 0x72ABB41: msg_header_copy_one_as (msg_header_copy.c:115)
==25605== by 0x72ABC9F: msg_header_copy_as (msg_header_copy.c:161)
==25605== by 0x72C421B: sip_call_id_copy (sip_protos.h:2422)
==25605== by 0x72D6BB4: incoming_create (nta.c:5316)
==25605== by 0x72D51EC: leg_recv (nta.c:4750)
==25605== by 0x72CE9E1: agent_recv_request (nta.c:2972)
==25605== by 0x72CD4A0: agent_recv_message (nta.c:2753)
==25605==
==25605== 7,058 (231 direct, 6,827 indirect) bytes in 1 blocks are definitely lost in loss record 1,502 of 1,539
==25605== at 0x4C28BE3: malloc (vg_replace_malloc.c:299)
==25605== by 0x7357FE2: sub_alloc (su_alloc.c:490)
==25605== by 0x7358858: su_alloc (su_alloc.c:784)
==25605== by 0x72B1677: msg_header_alloc (msg_parser.c:2312)
==25605== by 0x72AEE18: header_parse (msg_parser.c:1114)
==25605== by 0x72AECAC: extract_header (msg_parser.c:1071)
==25605== by 0x72AE948: extract_next (msg_parser.c:1001)
==25605== by 0x72AE46E: msg_extract (msg_parser.c:903)
==25605== by 0x7378B3D: tport_parse (tport.c:2901)
==25605== by 0x7378A7E: tport_recv_event (tport.c:2874)
==25605== by 0x73786EF: tport_base_wakeup (tport.c:2775)
==25605== by 0x7378674: tport_wakeup (tport.c:2761)
==25605==
==25605== 7,059 (152 direct, 6,907 indirect) bytes in 1 blocks are definitely lost in loss record 1,503 of 1,539
==25605== at 0x4C28BE3: malloc (vg_replace_malloc.c:299)
==25605== by 0x7357FE2: sub_alloc (su_alloc.c:490)
==25605== by 0x7358858: su_alloc (su_alloc.c:784)
==25605== by 0x72B1677: msg_header_alloc (msg_parser.c:2312)
==25605== by 0x72ABB41: msg_header_copy_one_as (msg_header_copy.c:115)
==25605== by 0x72ABC9F: msg_header_copy_as (msg_header_copy.c:161)
==25605== by 0x72C3E7E: sip_request_copy (sip_protos.h:280)
==25605== by 0x72D6B45: incoming_create (nta.c:5313)
==25605== by 0x72D51EC: leg_recv (nta.c:4750)
==25605== by 0x72CE9E1: agent_recv_request (nta.c:2972)
==25605== by 0x72CD4A0: agent_recv_message (nta.c:2753)
==25605== by 0x73793AE: tport_base_deliver (tport.c:3026)