Re： Re: Orbacus 4.1.3 memory leak ? who cares?

we use Microsoft debugging tool dumdh.exe to analyse
memory leaks of clien_dll_poa.exe, the results are in
the attached file.
--- Darren Middleman <[email protected]>写道:

> 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
> 



	

	
		
___________________________________________________________ 
雅虎免费G邮箱－中国第一绝无垃圾邮件骚扰超大邮箱 
http://cn.mail.yahoo.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