
mythtv at cvs
Jul 17, 2009, 10:49 PM
Post #1 of 25
(2485 views)
Permalink
|
|
Ticket #6734: Memory leak in EIT scanner (UK DVB-T)
|
|
#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 _______________________________________________ mythtv-commits mailing list mythtv-commits [at] mythtv http://mythtv.org/cgi-bin/mailman/listinfo/mythtv-commits
|