Bug 3773 - oneway : memory leak after calling oneway with Transport SyncScope
Summary: oneway : memory leak after calling oneway with Transport SyncScope
Status: RESOLVED FIXED
Alias: None
Product: TAO
Classification: Unclassified
Component: ORB (show other bugs)
Version: 1.7.5
Hardware: x86 Linux
: P3 critical
Assignee: DOC Center Support List (internal)
URL:
Depends on: 3682 3825
Blocks:
  Show dependency tree
 
Reported: 2009-12-08 03:07 CST by Didier Becu
Modified: 2011-03-03 06:19 CST (History)
1 user (show)

See Also:


Attachments
source of test example with an oneway operation (9.01 KB, text/plain)
2009-12-08 03:07 CST, Didier Becu
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Didier Becu 2009-12-08 03:07:15 CST
Created attachment 1233 [details]
source of test example with an oneway operation

HOST MACHINE and OPERATING SYSTEM: Linux 2.6.9-42.ELsmp i686, RedHat ES 4 update 4
COMPILER NAME AND VERSION (AND PATCHLEVEL): g++ 3.4.6
THE $ACE_ROOT/ace/config.h FILE : config-linux.h
THE $ACE_ROOT/include/makeinclude/platform_macros.GNU FILE : platform_linux.GNU

with the following idl:

typedef sequence<octet,5000000> spectre_pv_t;

interface IProdSpectrePv {
  oneway void push(in spectre_pv_t f_spectre_pv_elt_in);  
};

When the client calls the oneway operation on the server with the SYNC SCOPE policy set to Transport, the client process memory increases, then the communication between client and server fails.
With the SYNC SCOPE policy set to None, there is no memory leak and all is ok.
(Note : without SyncScope policy setting, there is also a memory leak).

An exemple source is attached (client must be run as root)

The valgrind tool detects the following memory leak in the "copy_if_necessary" in client process :

==32376== 2,400 bytes in 60 blocks are definitely lost in loss record 261 of 273
==32376==    at 0x4004904: operator new(unsigned, std::nothrow_t const&) (vg_replace_malloc.c:180)
==32376==    by 0x410C409: ACE_Message_Block::clone(unsigned long) const (Message_Block.inl:99)
==32376==    by 0x43006E1: TAO_Synch_Queued_Message::copy_if_necessary(ACE_Message_Block const*) (Synch_Queued_Message.cpp:192)
==32376==    by 0x431B2E6: TAO_Transport::cleanup_queue(unsigned) (Transport.cpp:1217)
==32376==    by 0x431AA3A: TAO_Transport::drain_queue_helper(int&, iovec*, TAO::Transport::Drain_Constraints const&) (Transport.cpp:999)
==32376==    by 0x431AE16: TAO_Transport::drain_queue_i(TAO::Transport::Drain_Constraints const&) (Transport.cpp:1100)
==32376==    by 0x4319807: TAO_Transport::send_message_block_chain_i(ACE_Message_Block const*, unsigned&,

 TAO::Transport::Drain_Constraints const&) (Transport.cpp:595)
==32376==    by 0x431B800: TAO_Transport::send_asynchronous_message_i(TAO_Stub*, ACE_Message_Block const*, ACE_Time_Value*) (Transport.cpp:1401)
==32376==    by 0x431B68F: TAO_Transport::send_message_shared_i(TAO_Stub*, TAO_Message_Semantics, ACE_Message_Block const*, ACE_Time_Value*) (Transport.cpp:1334)
==32376==    by 0x4318E43: TAO_Transport::send_message_shared(TAO_Stub*, TAO_Message_Semantics, ACE_Message_Block const*, ACE_Time_Value*) (Transport.cpp:305)
==32376==    by 0x42A8862: TAO_IIOP_Transport::send_message(TAO_OutputCDR&, TAO_Stub*, TAO_Message_Semantics, ACE_Time_Value*) (IIOP_Transport..cpp:242)
==32376==    by 0x42A87C7: TAO_IIOP_Transport::send_request(TAO_Stub*, TAO_ORB_Core*, TAO_OutputCDR&, TAO_Message_Semantics, ACE_Time_Value*) (IIOP_Transport.cpp:217)


Trace from tao are the following when oneway operation is called :

TAO (32387|3086310320) - Transport[8]::send_asynchronous_message_i, trying to send the message (ml = 5000084)
TAO (32387|3086310320) - Transport[8]::cleanup_queue, byte_count = 131072
TAO (32387|3086310320) - Transport[8]::cleanup_queue, after transfer, bc = 0, all_sent = 0, ml = 4869012
TAO (32387|3086310320) - Transport[8]::drain_queue_helper, byte_count = 131072, head_is_empty = 0
TAO (32387|3086310320) - Transport[8]::drain_queue_i, helper retval = 1
TAO (32387|3086310320) - Transport[8]::send_asynchronous_message_i, partial send
 131072 / 5000084 bytes
TAO (32387|3086310320) - Transport[8]::send_asynchronous_message_i, message is queued
TAO (32387|3086310320) - Transport[8]::schedule_output_i
TAO (32387|3086310320) - Transport[8]::send_asynchronous_message_i, flushing transport.
TAO (32387|3086313152) - Transport[8]::handle_output - block_on_io=0, timeout=-1.-00001
TAO (32387|3086313152) - Transport[8]::cleanup_queue, byte_count = 131072
TAO (32387|3086313152) - Transport[8]::cleanup_queue, after transfer, bc = 0, all_sent = 0, ml = 4737940
TAO (32387|3086313152) - Transport[8]::drain_queue_helper, byte_count = 131072, head_is_empty = 0
TAO (32387|3086313152) - Transport[8]::drain_queue_i, helper retval = 1
TAO (32387|3086313152) - Transport[8]::handle_output, drain_queue returns 0/11
TAO (32387|3086310320) - Transport[8]::handle_output - block_on_io=0, timeout=-1.-00001
TAO (32387|3086310320) - Transport[8]::cleanup_queue, byte_count = 114688
TAO (32387|3086310320) - Transport[8]::cleanup_queue, after transfer, bc = 0, all_sent = 0, ml = 4623252
TAO (32387|3086310320) - Transport[8]::drain_queue_helper, byte_count = 114688, head_is_empty = 0
TAO (32387|3086310320) - Transport[8]::drain_queue_i, helper retval = 1
TAO (32387|3086310320) - Transport[8]::handle_output, drain_queue returns 0/11
TAO (32387|3086313152) - Transport[8]::handle_output - block_on_io=0, timeout=-1.-00001
TAO (32387|3086313152) - Transport[8]::cleanup_queue, byte_count = 114688
TAO (32387|3086313152) - Transport[8]::cleanup_queue, after transfer, bc = 0, all_sent = 0, ml = 4508564
.......
.......
.......
TAO (32387|3086313152) - Transport[8]::drain_queue_helper, byte_count = 131072, head_is_empty = 0
TAO (32387|3086313152) - Transport[8]::drain_queue_i, helper retval = 1
TAO (32387|3086313152) - Transport[8]::handle_output, drain_queue returns 0/11
TAO (32387|3086310320) - Transport[8]::handle_output - block_on_io=0, timeout=-1.-00001
TAO (32387|3086310320) - Transport[8]::cleanup_queue, byte_count = 19348
TAO (32387|3086310320) - Transport[8]::cleanup_queue, after transfer, bc = 0, all_sent = 1, ml = 0
TAO (32387|3086310320) - Transport[8]::drain_queue_helper, byte_count = 19348,
head_is_empty = 1
TAO (32387|3086310320) - Transport[8]::drain_queue_i, helper retval = 1
TAO (32387|3086310320) - Transport[8]::cancel_output_i
TAO (32387|3086310320) - Transport[8]::handle_output, drain_queue returns 0/11
TAO (32387|3086310320) - Transport[8]::make_idle
Comment 1 Vladimir Zykov 2009-12-08 04:56:28 CST
I tried to run the provided test and I didn't see any memory leak. However, I see that this bug is related to bug 3682.
Comment 2 Vladimir Zykov 2011-03-03 06:19:10 CST
This is very similar to bug#3825. Now when 3825 is fixed and contents_ (cloned through copy_if_necessary()) is cleaned in all possible paths this bug is also fixed I think.