id	summary	reporter	owner	description	type	status	priority	milestone	component	version	severity	resolution	keywords	cc	mlocked
3692	Memory leak in DVB DummyVideo code	anonymous	danielk	"I originally posted this in #3317 but that ticket got closed without resolving my issue.  For well over 6 months now, I've noticed that the backend slowly increases its virtual memory footprint.  Which eventually leads to slowing the entire machine down (more-so on machines with small amounts of RAM and not enough swap.

Digging into it with pmap, I found lots of these:

{{{
pmap -d `pidof mythbackend`
...
a10de000       4 ----- 00000000a10de000 000:00000   [ anon ]
a10df000    8188 rwx-- 00000000a10df000 000:00000   [ anon ]
...
}}}

(That's 8MB of anonymous memory for those playing along).
And I noticed that the number of these went up everytime I changed a channel.

An 8MB Anonymous page is just what you see when libpthread allocates a new stack when creating a thread, but after several channel changes, I was seeing lots more of these anonymous-memory entries than running threads.  So I surmized that we weren't reclaiming the stack when a thread terminated.

I wrote a utility (included) to track all thread creation and what memory it was associated with (just a wrapper around libpthread) and was able to use it to map pthread_create calls to stack allocations.

Using this, I determined that each time dvbrecorder.cpp::StartDummyVideo was called, the number of anonymous memory entries would increase, and these were never being reclaimed.

Simply adding a:

{{{
pthread_detach(_video_thread);
}}}

right after the pthread_create call (this could alternatively be done using attributes passed to pthread_create I suppose) allows the pthread stacks to be reclaimed once the thread terminates, and now myth no longer increases it's virtual memory footprint by 8MB every time a channel-change occurs.
"	defect	closed	minor	0.21	dvb	head	medium	fixed		Stuart Auchterlonie	0