[Openmrcp-users] RE : OpenMRCP memory allocation

[Arsen Chaloyan]

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.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.freeswitch.org/pipermail/openmrcp-users/attachments/20080218/a8ba3c93/attachment.html