[mythtv-commits] Ticket #6734: Memory leak in EIT scanner (UK DVB-T)

[MythTV]

#6734: Memory leak in EIT scanner (UK DVB-T)
-----------------------------------------------------------------+----------
 Reporter:  Nick Morrott <knowledgejunkie (at) gmail (dot) com>  |       Owner:  stuarta   
     Type:  defect                                               |      Status:  new       
 Priority:  minor                                                |   Milestone:  unknown   
Component:  MythTV - EIT                                         |     Version:  0.21-fixes
 Severity:  medium                                               |     Mlocked:  0         
-----------------------------------------------------------------+----------
 There have been reports from some users of constant mythbackend memory
 growth on the stable release when EIT scanning is enabled. My production
 backend is no exception and I see VSZ memory growth of ~8MiB/day when
 active EIT scanning is enabled.

 I've finally gotten around to running valgrind on latest 0.21-fixes, and
 have attached the valgrind log to this ticket, having been run with
 options:

 {{{
 valgrind --leak-check=full --show-reachable=yes --verbose [[BR]]
 --log-file=/tmp/valgrind-021-fixes-0453.log [[BR]]
 /usr/local/bin/mythbackend --noupnp -v important,general,eit,channel
 [[BR]]
 > /tmp/mythbackend-valgrind-021-fixes.log
 }}}

 UPNP was disabled on the backend, and only one of the 3 cards (all KWorld
 DVB Xperts) has active EIT scanning enabled. Build details (source was
 exported from a checkout at r20947) are:

 {{{
 MythTV Version   : exported
 MythTV Branch    : branches/release-0-21-fixes
 Library API      : 0.21.20080304-1
 Network Protocol : 40
 Options compiled in:
  linux debug use_hidesyms using_oss using_alsa using_backend [[BR]]
 using_dvb using_frontend using_iptv using_ivtv using_lirc [[BR]]
 using_opengl_vsync using_opengl_video using_v4l using_valgrind [[BR]]
 using_x11 using_xrandr using_xv using_xvmc using_xvmcw [[BR]]
 using_xvmc_vld using_bindings_perl using_bindings_python [[BR]]
 using_opengl using_ffmpeg_threads using_live
 }}}


 The summary of the leaktest (valgrind was run for approx 1 hour) was:

 {{{
 ==20475== LEAK SUMMARY:
 ==20475==    definitely lost: 2,276 bytes in 31 blocks.
 ==20475==    indirectly lost: 302,980 bytes in 8,410 blocks.
 ==20475==      possibly lost: 2,829,856 bytes in 40 blocks.
 ==20475==    still reachable: 3,387,744 bytes in 56,158 blocks.
 }}}

 Multiplying up the ~300KiB/hr lost memory over a 24hr period would seem to
 agree well with my observed memory growth of ~8MiB/day. I don't know if
 this is an allowable 'leap' to make.

-- 
Ticket URL: <http://svn.mythtv.org/trac/ticket/6734>
MythTV <http://www.mythtv.org/>
MythTV