Re: Orbacus 4.1.3 memory leak? who cares?

Hi Zhai,

On Sat, Nov 19, 2005 at 05:10:48PM +0800, Zhai wrote:
> after more test, now we get the following results, it
> seems memory leaks existing in OB413d.dll:
> 
> [I] Starting Purify'd
> D:\zhaimingyu_view\open2000e\src\rtdbms\test_graph\Debug\test_open.exe
> at 2005-11-19 16:42:14
> 
> <snip>
> 
> [I] MPK: Potential memory leak of 27 bytes from 1
> block allocated in OB::Alloc(UINT,DWORD) [OB413d.dll]
> 
> Offset 0x00000008 referenced by 0x0309a400, a location
> in a malloc'd block
> 
> Distribution of potentially leaked blocks
> 
> Allocation location
> 
> malloc [dbgheap.c:129]
> 
> _CRTIMP void * __cdecl malloc (
> 
> size_t nSize
> 
> )
> 
> => {
> 
> void *res = _nh_malloc_dbg(nSize, _newmode,
> _NORMAL_BLOCK, NULL, 0);
> 
> 
> 
> return res;
> 
> OB::Alloc(UINT,DWORD) [Basic.cpp:199]
> 
> CORBA::string_alloc(DWORD) [Basic.cpp:557]
> 
> CORBA::string_dup(char const*) [Basic.cpp:588]
> 
> OB::StrForSeq::=(char const*) [Basic.cpp:875]
> 
> OB::Properties::setProperty(char const*,char const*)
> [Properties.cpp:160]
> 
> OB::ParseArgs(int&,char * *,Properties::OB
> *,Logger::OB *) [ORB_init.cpp:101]
> 
> OBCORBA::ORB_init(int&,char * *,Properties::OB
> *,Logger::OB *,Reactor::OB *,char const*,char const*)
> [ORB_init.cpp:688]
> 
> OBCORBA::ORB_init(int&,char * *,Properties::OB *,char
> const*,char const*) [ORB_init.cpp:941]
> 
> ODB::COrbMgr::InitOrb(char const*)
> [D:\zhaimingyu_view\open2000e\src\rtdbms\odb_lib\src\odb_orbmgr.cpp:97]
> 

I can't really tell what could be causing this potential memory leak without
seeing the code you are using in your application.  I tried running a few
of our demos through purify and I was not seeing the same memory leak
reports that you have included in your email.  Would it be possible to send
a the code for your application that is reporting the leaks or a small demo 
that demonstrates a similar sort of leak?

Another thing to watch out for with Purify is that not all potential memory
leaks turn out to be actual memory leaks.  We have come across situtations
where Purify would report a potential memory leak where one did not occur.
This was because the memory being indicated is not actually freed until
after Purify has detached itself from the process in question.

> [...]
> >
> D:\OB-4.1.3\ob\demo\hello\clien_dll_poa\Debug\clien_dll_poa.exe
> > at 2005-11-12 17:10:52
> >
> > <snip>
> >
> >     [I] MPK: Potential memory leak of 21 bytes from
> > 1
> > block allocated in main [graph_get.exe]
> >             Offset 0x00000008 referenced by
> > 0x02eb48b0, a location in a C++ new block
> >             Distribution of potentially leaked
> > blocks
> >             Allocation location
> >                 malloc         [dbgheap.c:129]
> >                     _CRTIMP void * __cdecl malloc (
> >                             size_t nSize
> >                             )
> >                  => {
> >                             void *res =
> > _nh_malloc_dbg(nSize, _newmode, _NORMAL_BLOCK, NULL,
> > 0);
> >                     
> >                             return res;
> >                 main          
> > [d:\graph_get\test_open.cpp:87]
> >                             CODB_NET ::
> > GRAPH_REAL_RSP_var lp_graph_real_rsp;
> >                     
> >                     
> >                  =>         kk =
> >
> api_net.GraphGetData(graph_real_req,lp_graph_real_rsp);
> >                                 if(kk < 0)
> >                                 {
> >                                         printf("
> > invoke remote rtdbms GraphGetData error\n");
> >                 mainCRTStartup [crtexe.c:338]
> > 	[I] Summary of new memory leaks... {0 bytes, 0
> > blocks}
> >    3.bytes leaks: 0+1256 to 0+122789, and etc.
> >   
> >    More, we observe the client end  using "task
> > manager", the two entries "memory used" and "vitural
> > memory size" varies from 10536K, 50240K to 64748K,
> > 112300K to 80444K, 112488K.
> >   
> >    from above, does the client leak memories?
> > 

Again, it is difficult to tell what could be causing this memory leak
without seeing the code that is being run at the locations in the Purify
report.  A copy of the code or a similar demo that displays the same
problems should help us pinpoint where any memory leaks exist.

Regards,
Darren

-- 
Darren Middleman, Software Engineer
Team Orbacus - Your CORBA Source
Email: mailto:[email protected]
WWW: http://www.orbacus.com/
_______________________________________________
OB-Users Mailing List - [email protected]
http://mail.ooc.nf.ca/mailman/listinfo/ob-users
Visit our support FAQ before you send a message.
http://www.orbacus.com/faq/support.html