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@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr