Re: [Linphone-developers] Memory leak in Linphone 3.3.2

[Simon Morlat]

Hi,

Indeed you are right there is a memory leak in
update_contact_from_response(). I just fixed it on git.

Thank you for your analysis.

Simon

Le vendredi 22 octobre 2010 à 22:32 +0530, Raseel Bhagat a écrit :
> Hi, 
> 
> I noticed while making calls between 2 PCs with Linphone 3.3.2 that
> the %MEM column of "top" command kept steadily increasing for the
> linphone-3 process.
> 
> Running valgrind on linphone, I found that  there were a few "Invalid
> reads" in the libavcodec, but lots of "definitely lost" errors for SIP
> as well as RTP modules.
> 
> Since I am using Linphone-3.3.2 on the Beagleboard, this problem
> became obvious very quickly on the board. Another thing I could notice
> on the board was that as the %MEM value kept on increasing, so did the
> %CPU. At one point of time, about 10 minutes into a call, the CPU
> consumption was about 95% causing a very choppy video and a major lag.
> 
> I could not replicate the CPU consumption issue on my Core 2 duo
> processor Laptop.
> 
> I am attaching a snippet of  my valgrind log file for linphone-3.3.2
> using H.264 and PCMU.
> 
> ==7191== 78 (16 direct, 62 indirect) bytes in 1 blocks are definitely
> lost in loss record 7,834 of 9,462
> ==7191==    at 0x4024C1C: malloc (vg_replace_malloc.c:195)
> ==7191==    by 0x59AAE83: osip_from_init
> (in /usr/lib/libosipparser2.so.4.2.0)
> ==7191==    by 0x40C7AB3: sal_address_new (sal_eXosip2.c:1630)
> ==7191==    by 0x40C5562: update_contact_from_response
> (sal_eXosip2.c:836)
> ==7191==    by 0x40C73F6: other_request_reply (sal_eXosip2.c:1460)
> ==7191==    by 0x40C785D: process_event (sal_eXosip2.c:1574)
> ==7191==    by 0x40C790B: sal_iterate (sal_eXosip2.c:1592)
> ==7191==    by 0x40BDAFF: linphone_core_iterate (linphonecore.c:1766)
> ==7191==    by 0x805396B: linphone_gtk_iterate (main.c:443)
> ==7191==    by 0x498E53B: ??? (in /lib/libglib-2.0.so.0.2200.3)
> ==7191==    by 0x498DE87: g_main_context_dispatch
> (in /lib/libglib-2.0.so.0.2200.3)
> ==7191==    by 0x499172F: ??? (in /lib/libglib-2.0.so.0.2200.3)
> ==7191==    by 0x4991B9E: g_main_loop_run
> (in /lib/libglib-2.0.so.0.2200.3)
> ==7191==    by 0x4239418: gtk_main (gtkmain.c:1218)
> ==7191==    by 0x80561F6: main (main.c:1333)
> ==7191==
> ==7191== 78 (16 direct, 62 indirect) bytes in 1 blocks are definitely
> lost in loss record 7,835 of 9,462
> ==7191==    at 0x4024C1C: malloc (vg_replace_malloc.c:195)
> ==7191==    by 0x59AAE83: osip_from_init
> (in /usr/lib/libosipparser2.so.4.2.0)
> ==7191==    by 0x40C7AB3: sal_address_new (sal_eXosip2.c:1630)
> ==7191==    by 0x40C5562: update_contact_from_response
> (sal_eXosip2.c:836)
> ==7191==    by 0x40C566F: call_proceeding (sal_eXosip2.c:863)
> ==7191==    by 0x40C56B3: call_ringing (sal_eXosip2.c:870)
> ==7191==    by 0x40C7612: process_event (sal_eXosip2.c:1515)
> ==7191==    by 0x40C790B: sal_iterate (sal_eXosip2.c:1592)
> ==7191==    by 0x40BDAFF: linphone_core_iterate (linphonecore.c:1766)
> ==7191==    by 0x805396B: linphone_gtk_iterate (main.c:443)
> ==7191==    by 0x498E53B: ??? (in /lib/libglib-2.0.so.0.2200.3)
> ==7191==    by 0x498DE87: g_main_context_dispatch
> (in /lib/libglib-2.0.so.0.2200.3)
> ==7191==    by 0x499172F: ??? (in /lib/libglib-2.0.so.0.2200.3)
> ==7191==    by 0x4991B9E: g_main_loop_run
> (in /lib/libglib-2.0.so.0.2200.3)
> ==7191==    by 0x4239418: gtk_main (gtkmain.c:1218)
> ==7191==    by 0x80561F6: main (main.c:1333)
> 
> <snip>
> 
> ==7191== 156 (32 direct, 124 indirect) bytes in 2 blocks are
> definitely lost in loss record 8,303 of 9,462
> ==7191==    at 0x4024C1C: malloc (vg_replace_malloc.c:195)
> ==7191==    by 0x59AAE83: osip_from_init
> (in /usr/lib/libosipparser2.so.4.2.0)
> ==7191==    by 0x40C7AB3: sal_address_new (sal_eXosip2.c:1630)
> ==7191==    by 0x40C5562: update_contact_from_response
> (sal_eXosip2.c:836)
> ==7191==    by 0x40C566F: call_proceeding (sal_eXosip2.c:863)
> ==7191==    by 0x40C75ED: process_event (sal_eXosip2.c:1511)
> ==7191==    by 0x40C790B: sal_iterate (sal_eXosip2.c:1592)
> ==7191==    by 0x40BDAFF: linphone_core_iterate (linphonecore.c:1766)
> ==7191==    by 0x805396B: linphone_gtk_iterate (main.c:443)
> ==7191==    by 0x498E53B: ??? (in /lib/libglib-2.0.so.0.2200.3)
> ==7191==    by 0x498DE87: g_main_context_dispatch
> (in /lib/libglib-2.0.so.0.2200.3)
> ==7191==    by 0x499172F: ??? (in /lib/libglib-2.0.so.0.2200.3)
> ==7191==    by 0x4991B9E: g_main_loop_run
> (in /lib/libglib-2.0.so.0.2200.3)
> ==7191==    by 0x4239418: gtk_main (gtkmain.c:1218)
> ==7191==    by 0x80561F6: main (main.c:1333)
> 
> <snip>
> 
> ==7191== 2,184 (768 direct, 1,416 indirect) bytes in 2 blocks are
> definitely lost in loss record 9,289 of 9,462
> ==7191==    at 0x4024D12: realloc (vg_replace_malloc.c:476)
> ==7191==    by 0x48FC951: ??? (in /usr/lib/libfontconfig.so.1.3.0)
> ==7191==    by 0x48FD3C7: ??? (in /usr/lib/libfontconfig.so.1.3.0)
> ==7191==    by 0x48FDA0B: ??? (in /usr/lib/libfontconfig.so.1.3.0)
> ==7191==    by 0x48F996D: FcFontRenderPrepare
> (in /usr/lib/libfontconfig.so.1.3.0)
> ==7191==    by 0x46A9C5C: ???
> (in /usr/lib/libpangoft2-1.0.so.0.2600.0)
> ==7191==    by 0x46AA1E0: ???
> (in /usr/lib/libpangoft2-1.0.so.0.2600.0)
> ==7191==    by 0x48406FE: pango_fontset_foreach
> (in /usr/lib/libpango-1.0.so.0.2600.0)
> ==7191==    by 0x483CFC1: ??? (in /usr/lib/libpango-1.0.so.0.2600.0)
> ==7191==    by 0x483D66D: ??? (in /usr/lib/libpango-1.0.so.0.2600.0)
> ==7191==    by 0x483DCAE: pango_itemize_with_base_dir
> (in /usr/lib/libpango-1.0.so.0.2600.0)
> ==7191==    by 0x4846908: ??? (in /usr/lib/libpango-1.0.so.0.2600.0)
> ==7191==    by 0x4847F53: ??? (in /usr/lib/libpango-1.0.so.0.2600.0)
> ==7191==    by 0x422FC17: gtk_label_size_request (gtklabel.c:3074)
> ==7191==    by 0x492A067: g_cclosure_marshal_VOID__BOXED
> (in /usr/lib/libgobject-2.0.so.0.2200.3)
> ==7191==    by 0x491B6F8: ??? (in /usr/lib/libgobject-2.0.so.0.2200.3)
> ==7191==    by 0x491CF97: g_closure_invoke
> (in /usr/lib/libgobject-2.0.so.0.2200.3)
> ==7191==    by 0x49320AF: ??? (in /usr/lib/libgobject-2.0.so.0.2200.3)
> ==7191==    by 0x4933B2C: g_signal_emit_valist
> (in /usr/lib/libgobject-2.0.so.0.2200.3)
> ==7191==    by 0x4933E41: g_signal_emit_by_name
> (in /usr/lib/libgobject-2.0.so.0.2200.3)
> ==7191==    by 0x42AF395: do_size_request (gtksizegroup.c:628)
> ==7191==    by 0x42AF64E: _gtk_size_group_compute_requisition
> (gtksizegroup.c:828)
> ==7191==    by 0x436398E: gtk_widget_size_request (gtkwidget.c:3704)
> ==7191==    by 0x41F827E: gtk_frame_size_request (gtkframe.c:625)
> ==7191==    by 0x492A067: g_cclosure_marshal_VOID__BOXED
> (in /usr/lib/libgobject-2.0.so.0.2200.3)
> ==7191==    by 0x491B6F8: ??? (in /usr/lib/libgobject-2.0.so.0.2200.3)
> ==7191==    by 0x491CF97: g_closure_invoke
> (in /usr/lib/libgobject-2.0.so.0.2200.3)
> ==7191==    by 0x49320AF: ??? (in /usr/lib/libgobject-2.0.so.0.2200.3)
> 
> 281476,67     98%
> 
> <snip>
> 
> ==7191== LEAK SUMMARY:
> ==7191==    definitely lost: 10,214 bytes in 201 blocks
> ==7191==    indirectly lost: 350,913 bytes in 872 blocks
> ==7191==      possibly lost: 5,120,884 bytes in 27,957 blocks
> ==7191==    still reachable: 8,751,175 bytes in 11,006 blocks
> ==7191==         suppressed: 0 bytes in 0 blocks
> 
> Has anyone else noticed the same ? Can anyone confirm this Memory leak
> issue ?
> 
> --
> Raseel
> 
> 
> 
> _______________________________________________
> Linphone-developers mailing list
> address@hidden
> http://lists.nongnu.org/mailman/listinfo/linphone-developers