[mythtv] Mythtv pes_malloc and pes_free

[Roger James]

On 8 May 2017 6:43:32 am Karl Dietz <dekarl at spaetfruehstuecken.org> wrote:

> On 07.05.2017 12:53, Roger James wrote:
>> I would like to propose that we consider reverting to the default heap
>> allocator. There are also a number of alternatives to the ptmalloc
>> allocator that could be consider, for example tcmalloc from Google.
>
> I like the idea. Do you know if it helps? I just read the other day that
> using the standard implementations may contain some nasty surprises...
> https://www.zerotier.com/blog/2017-05-05-theleak.shtml
>
> I hear jemalloc (as used in FreeBSD) is great http://jemalloc.net/
>
> Regards,
> Karl

Hi Karl, Gary,

The pes_alloc stuff is is only used for allocation of PES packet data and 
is of course built on top of malloc. So disabling it does not change our 
exposure to malloc bugs. In fact my new code highlighted a very similar 
problem in the pes_alloc code to that described by zerotier! My SDT and EIT 
changes involve long term caching of PES packet data. Because these long 
term allocations are randomly distributed through pes_alloc pools and the 
usage profile is rapid increase to an initial peak followed by a slow decay 
down to a stable level as knowledge of table section versions is gathered, 
we end up with far more allocated pools than we need. So reducing the 
number of memory allocators with potentially conflicting allocation 
strategies we have layered on top on each other, is always in my view, a 
good thing.

Does it help? Well I have been running it successfully for a couple of days 
now. Only time and greater exposure will tell. It is very easy to try it 
out, just put #define USING_VALGRIND at the start of pespacket.cpp.

As far as the use of other malloc replacements go I can happily leave that 
discussion to you guys. I just want to get back to working on what I wanted 
to do many months ago, having a look at accurate scheduling using now next 
transitions and running status data!

Roger