[omniORB] Memory leak in cdrEncapsulationStream (cdrMemoryStream)

[Harri Pasanen]

Hmm... on further reflection, I assume now this is valid behaviour, 
cdrMemoryStream mostly being used as a fancy allocator for other 
objects...

A breakpoint I put to cdrMemoryStream desctructor's delete statement 
was never entered, which I did find puzzling.

Tricky..

Have a nice weekend,

Harri

On Friday 22 October 2004 14:40, Harri Pasanen wrote:
> Hi,
>
> I'm strongly suspecting a memory leak in cdEncapsulationStream.
> ( cdrMemoryStream.cc,v   Revision 1.1.4.10  2003/02/17 01:24:04
> dgrisby)
>
> Because in cdrEncapsulationStream::getOctetStream it sets the
> pd_readonly_and_external_buffer = 1, the cdrMemoryStream destructor
> never releases pd_bufp.
>
> Unfortunately, the collaboration between various classes here in
> sharing the pd_bufp pointer is convoluted enough, that I have yet
> to come up with a proper fix.
>
> Following valgrind stack trace is what leads me to believe there is
> a leak.  The stack allocated cdrEncapsulationStream s in ior.cc_316
> seems to leak the pd_pufb.
>
> ==4131== 446720 bytes in 1747 blocks are still reachable in loss
> record 601 of 604
> ==4131==    at 0x1B907214: operator new[](unsigned)
> (vg_replace_malloc.c:139)
> ==4131==    by 0x1BC6A8CC:
> cdrMemoryStream::reserveOutputSpace(omni::alignment_t, unsigned)
> (cdrMemoryStream.cc:226)
> ==4131==    by 0x1BC6A20E:
> cdrMemoryStream::cdrMemoryStream(unsigned long, bool)
> (cdrMemoryStream.cc:93)
> ==4131==    by 0x1BC6B45E:
> cdrEncapsulationStream::cdrEncapsulationStream(unsigned long, bool)
> (cdrMemoryStream.cc:432)
> ==4131==    by 0x1BC27C46: IIOP::encodeProfile(IIOP::ProfileBody
> const&, IOP::TaggedProfile&) (ior.cc:316)
> ==4131==    by 0x1BC38B60: omniIOR::omniIOR(char const*, unsigned
> char const*, int) (omniIOR.cc:157)
> ==4131==    by 0x1BC35248: omni::createLocalObjRef(char const*,
> char const*, omniObjTableEntry*) (omniInternal.cc:1063)
> ==4131==    by 0x1BC59747:
> PortableServer::ServantBase::_do_this(char const*)
> (portableserver.cc:278)
>
> As I said, there are so many different ways pd_bufp can be
> initialized, and shared, that my simple minded attempts for fixing
> have only broken it completely.  I'm actually tempted to make it a
> shared pointer...
>
> For the moment I'll probably punt, and only fix it for ior.cc case,
> and see if it comes up elsewhere.
>
>
> -Harri
>
>
> This message, including any attachments, is intended only for the
> person(s) to whom it is addressed. If you received it in error,
> please let us know and delete the message from your system. This
> message may be confidential and may fall under the duty of
> non-disclosure. Any use by others than the intended addressee is
> prohibited. Trema shall not be liable for any damage related to the
> electronic transmission of this message, such as failure or delay
> of its delivery, interception or manipulation by third parties, or
> transmission of viruses or other malicious code.
>
>
> _______________________________________________
> omniORB-list mailing list
> omniORB-list at omniorb-support.com
> http://www.omniorb-support.com/mailman/listinfo/omniorb-list


This message, including any attachments, is intended only for the person(s) to whom it is addressed. If you received it in error, please let us know and delete the message from your system. This message may be confidential and may fall under the duty of non-disclosure. Any use by others than the intended addressee is prohibited. Trema shall not be liable for any damage related to the electronic transmission of this message, such as failure or delay of its delivery, interception or manipulation by third parties, or transmission of viruses or other malicious code.