Hi Richard,
thanks for the files. I just gave them a try and using valgrind I could
also see that there's a leak when a search timer update is run.
==4060== 452,152 (6,968 direct, 445,184 indirect) bytes in 134 blocks
are definitely lost in loss record 287 of 287
==4060== at 0x4024F20: malloc (vg_replace_malloc.c:236)
==4060== by 0x4C31C90: ???
==4060== by 0x4C39596: ???
==4060== by 0x4C9FCF2: ???
==4060== by 0x8145D96: cThread::StartThread(cThread*) (thread.c:257)
==4060== by 0x406D96D: start_thread (pthread_create.c:300)
==4060== by 0x4342A4D: clone (clone.S:130)
But unfortunately valgrind does not give me the information where the
leak is caused. Maybe the reason for this is that a search timer update
runs in a separate thread or because plugins are dynamically loaded
shared libraries?
Has anybody an idea how to use valgrind in this case?
Cheers,
Christian
Am 20.08.2011 18:13, schrieb Richard F:
Hi Christian,
To answer your questions...
My server is headless - I user Vomp and a pair of media mvp's.
I'm using vdr V1.6.0.2 (SD only), I use vdradmin-AM and my epgsearch
updates are just on a timer, every 15 mins. Used to be 30 mins but I
don't think this makes a significant difference looking at the memory
graphs. I've disabled epgsearch conflict checks on timers - I used to
have them enabled, but as I look at vdradmin regularly, I can do it
manually, and it only fills up the logs.
I also use xmltv2vdr on a daily cron to update the epg with full
programme details.
I attach a tar'd up copy of all my /etc/vdr configs for you, and
zipped epg.data. If this doesn't show the problem, perhaps you can
tell me how to setup "valgrind" to search for the problem ?
Thanks for your help and a great plugin!
cheers
Richard
On 20/08/2011 14:02, Christian Wieninger wrote:
Hi Richard,
unfortunately I'm not aware of any leaks, if so I would have fixed
them ;)
Perhaps you can find out in which circumstances the memory usage
increases. Candidates are:
- search timer updates, should not matter how you trigger them, e.g. via
svdrpsend.pl plug epgsearch upds
- timer conflict check
- simply navigating through the epgsearch menus in OSD
Using valgrind would also be a good way to search for the leaks. I've
done this before too. But the leak may also depend on your personal
usage of epgsearch (e.g. search timer settings, blacklists,...), and
therefore did not appear in my valgrind checks.
Feel free to send me your VDR configuration (*.conf,
epgsearch-config-dir, epg.data) for testing.
Cheers,
Christian
Am 20.08.2011 12:18, schrieb Richard F:
Hi,
[ Apologies for using this list - the epgsearch bugtracker is broken ]
I've been tracking down memory leaks on my server and narrowed down a
significant leak in the epgsearch plugin
Approx 500 megs / week is lost - recovered by restarting vdr. I'd like
to reduce this obviously.
I updated from 0.9.24 to 0.9.25 beta 22 from git as a fix for a memory
leak was mentioned in the changelog, but the leak is still about the
same. If I remove the plugin from the command line, there is no
significant leak. Attached plot shows.
Anyone have any ideas?
Thanks Richard
_______________________________________________
vdr mailing list
vdr@xxxxxxxxxxx
http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
_______________________________________________
vdr mailing list
vdr@xxxxxxxxxxx
http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
