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