[Openmrcp-users] RE : Re: RE : Re: RE : OpenMRCP memory allocation

Mon Feb 18 11:38:12 EST 2008

Works fine. 

I looped around my objects creation/destruction and resident memory
is constant.

Thanks for your help.
Regards.

--- Arsen Chaloyan <achaloyan at gmail.com> a écrit :

> No it's not the same pool.
> 
> - global pool is used for client stack one time creation (client,engine,...)
> - connection oriented pools (MRCPv2 connection)
> - session oriented pools (sessions, channels, ..)
> 
> And finally your application isn't forced to use pools at all, however
> lifetime of the objects passed to mrcp stack should much session lifetime.
> 
> Regards,
> Arsen.
> 
> On Feb 18, 2008 7:20 PM, SP GLE <spglegle at yahoo.fr> wrote:
> 
> > Hi,
> > I tried to use subpools to manage memory but some functions still reclaim
> > memory from a global pool, for ex.
> >
> > mrcp_client_start().
> > mrcp_client_session_create();
> >
> > rtsp_engine_create();
> > rtsp_session_create();
> > rtsp_agent_connection_create();
> >
> > ( hardcoded apr_create_pool(&pool,NULL) )
> >
> > Regards.
> >
> > --- Arsen Chaloyan <achaloyan at gmail.com> a écrit :
> >
> > > Hi,
> > > see my comments below
> > >
> > > > - Memory is allocated through allocator_alloc (apr_pools.c:300), each
> > > > allocation seems to be 8,192 Bytes, which is quite large. Is there a
> > > > way to reduce allocation size ?
> > > It's not each alloction, but allocation of the pool consumes 8,192
> > Bytes.
> > >
> > > > I would like to use openMRCP inside a process using one object for
> > each
> > > > client. In my implementation (C++) there is one object for each MRCP
> > > > connection to an MRCP server. Memory pool is common to all objects an
> > > > mrcp_global_destroy() will never be called unless on process exit.
> > > You shouldn't use global memory pool. This will cause you memory leaks,
> > as
> > > all memory allocated from the pool will be freed with apr_pool_destroy
> > > Instead of global pool, context specific memory pools must be used.
> > > See some reference regarding APR pool usage
> > > http://svn.apache.org/viewvc/apr/apr/trunk/docs/pool-design.html?view=co
> > > http://apr.apache.org/docs/apr/trunk/group__apr__pools.html
> > >
> > >
> > > >I upgraded the code to rev 540 (including new apr toolkit) and i have
> > the
> > > same isssues
> > > > (running openmrcpclient on recognizer rassource with removed
> > > apr_terminate() and
> > > > apr_pool_destroy() from main.c ):
> > >
> > > OK, I'm using r540 with valgrind and see no memory leaks (again you
> > should
> > > use context specific pools)
> > > Here is the output
> > >
> > > ==26367==
> > > ==26367== ERROR SUMMARY: 87151 errors from 3 contexts (suppressed: 38
> > from
> > > 1)
> > > ==26367==
> > > ==26367== 271 errors in context 1 of 3:
> > > ==26367== Syscall param socketcall.sendto(msg) points to uninitialised
> > > byte(s)
> > > ==26367==    at 0x4B0308: sendto (in /lib/libpthread-2.5.so)
> > > ==26367==    by 0x417838B: rtp_tx_write_frame (rtp_session.c:388)
> > > ==26367==    by 0x4179696: media_connector_process
> > (media_connector.c:124)
> > > ==26367==    by 0x4179339: media_processor_main (media_processor.c:311)
> > > ==26367==    by 0x4178E97: timer_thread_proc (media_timer.c:147)
> > > ==26367==    by 0x41B08D5: dummy_worker (thread.c:142)
> > > ==26367==    by 0x4A93DA: start_thread (in /lib/libpthread-2.5.so)
> > > ==26367==    by 0x40306D: clone (in /lib/libc-2.5.so)
> > > ==26367==  Address 0x41CDBC4 is 1,748 bytes inside a block of size 8,192
> > > alloc'd
> > > ==26367==    at 0x4005400: malloc (vg_replace_malloc.c:149)
> > > ==26367==    by 0x41A7A50: apr_pool_create_ex (apr_pools.c:323)
> > > ==26367==    by 0x4173DA4: mrcp_client_session_create
> > > (mrcp_client_session.c:36)
> > > ==26367==    by 0x41740D6: mrcp_client_context_session_create
> > > (mrcp_client_context.c:63)
> > > ==26367==    by 0x804AD86: demo_recognizer_run
> > > (demo_recognizer_scenario.c:302)
> > > ==26367==    by 0x804966D: main (main.c:174)
> > > ==26367==
> > > ==26367== 43440 errors in context 2 of 3:
> > > ==26367== Conditional jump or move depends on uninitialised value(s)
> > > ==26367==    at 0x41771F1: g711u_encode (g711.h:255)
> > > ==26367==    by 0x41782C4: rtp_tx_write_frame (rtp_session.c:384)
> > > ==26367==    by 0x4179696: media_connector_process
> > (media_connector.c:124)
> > > ==26367==    by 0x4179339: media_processor_main (media_processor.c:311)
> > > ==26367==    by 0x4178E97: timer_thread_proc (media_timer.c:147)
> > > ==26367==    by 0x41B08D5: dummy_worker (thread.c:142)
> > > ==26367==    by 0x4A93DA: start_thread (in /lib/libpthread-2.5.so)
> > > ==26367==    by 0x40306D: clone (in /lib/libc-2.5.so)
> > > ==26367==
> > > ==26367== 43440 errors in context 3 of 3:
> > > ==26367== Conditional jump or move depends on uninitialised value(s)
> > > ==26367==    at 0x41771D1: g711u_encode (g711.h:238)
> > > ==26367==    by 0x41782C4: rtp_tx_write_frame (rtp_session.c:384)
> > > ==26367==    by 0x4179696: media_connector_process
> > (media_connector.c:124)
> > > ==26367==    by 0x4179339: media_processor_main (media_processor.c:311)
> > > ==26367==    by 0x4178E97: timer_thread_proc (media_timer.c:147)
> > > ==26367==    by 0x41B08D5: dummy_worker (thread.c:142)
> > > ==26367==    by 0x4A93DA: start_thread (in /lib/libpthread-2.5.so)
> > > ==26367==    by 0x40306D: clone (in /lib/libc-2.5.so)
> > > --26367--
> > > --26367-- supp:   38 Fedora-Core-6-hack3-ld25
> > > ==26367==
> > > ==26367== IN SUMMARY: 87151 errors from 3 contexts (suppressed: 38 from
> > 1)
> > > ==26367==
> > > ==26367== malloc/free: in use at exit: 0 bytes in 0 blocks.
> > > ==26367== malloc/free: 53 allocs, 53 frees, 109,400 bytes allocated.
> > > ==26367==
> > > ==26367== All heap blocks were freed -- no leaks are possible.
> > >
> > > I guess errors from the 3 contexts reported by valgrind should be
> > harmless,
> > > but let me find out the origin of those errors.
> > > Thanks,
> > > Arsen.
> > >
> >
> >
> >
> >
> >  ______________________________________________________________________________
> > Yahoo! Mail : un mail innovant avec Messenger compatible Windows Live +
> > stockage illimité. http://mail.yahoo.fr
> >
> 

      ______________________________________________________________________________ 
Yahoo! Mail : un mail innovant avec Messenger compatible Windows Live + stockage illimité. http://mail.yahoo.fr