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

[SP GLE]

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