[mythtv-users] Backend crash with malloc(): memory corruption (fast)

[Ben Lancaster]

On 6 Feb 2009, at 04:10, Allen Edwards wrote:

> Thu, Feb 5, 2009 at 7:13 PM, tim dennis <tdennis.sub at gmail.com> wrote:
>> Another day another Malloc Bug. The diagnostic message that is  
>> printed to
>> the stderr when using MALLOC_CHECK_=3 function is the same basic  
>> message
>> that appears in the mythtv backend log:
>>
>> Example Diagnostic output:
>>
>> *** glibc detected *** mythbackend: malloc(): memory corruption  
>> (fast):
>> 0x00000000028c8e8f ***
>>
>> Example Mythbackend log:
>>
>> *** glibc detected *** /usr/bin/mythbackend: malloc(): memory  
>> corruption
>> (fast): 0x0000000001c6713f ***
>>
>>
>> There seems to be no particular reason that causes the malloc bug  
>> to occur.
>>
>> "Crashes  in  malloc(),  calloc(), realloc(), or free() are almost
>> always related to heap corruption, such as overflowing an allocated
>> chunk or freeing the same pointer twice."
>>
>> So is this what the backend is doing?
>>
>> Any ideas anybody?
>>
>> t.dennis
>>
>>
>> On Tue, Feb 3, 2009 at 10:18 PM, tim dennis <tdennis.sub at gmail.com>  
>> wrote:
>>>
>>> After the third Malloc Bug today I have started the backend in a  
>>> terminal
>>> with the following command:
>>>
>>> MALLOC_CHECK_=3 mythbackend
>>>
>>> Will report back with result when it occurs next
>>>
>>> t.dennis
>>>
>>>
>>>
>>> On Sun, Feb 1, 2009 at 10:23 AM, Andrew Burgess <aab at cichlid.com>  
>>> wrote:
>>>>
>>>>> *** glibc detected *** /usr/bin/mythbackend: malloc(): memory
>>>> corruption (fast): 0xa895a507 ***
>>>>
>>>> man malloc reveals:
>>>>
>>>> Crashes  in  malloc(),  calloc(), realloc(), or free() are almost
>>>> always related to heap corruption, such as overflowing an allocated
>>>> chunk or freeing the same pointer twice.
>>>>      Recent versions of Linux libc (later than 5.4.23) and glibc  
>>>> (2.x)
>>>> include a malloc() implementation which is tunable via environment
>>>> variables.   When
>>>> MALLOC_CHECK_  is  set, a special (less efficient) implementation  
>>>> is
>>>> used which is designed to be tolerant against simple errors, such  
>>>> as
>>>> double calls
>>>> of free() with the same argument, or overruns of a single byte
>>>> (off-by-one bugs).  Not all such errors can be protected against,
>>>> however,  and  memory
>>>> leaks  can  result.   If  MALLOC_CHECK_ is set to 0, any detected  
>>>> heap
>>>> corruption is silently ignored; if set to 1, a diagnostic message  
>>>> is
>>>> printed on
>>>> stderr; if set to 2, abort(3) is called immediately; if set to 3, a
>>>> diagnostic message is printed on stderr and  the  program  is   
>>>> aborted.
>>>> Using  a
>>>> nonzero  MALLOC_CHECK_  value  can  be useful because otherwise a  
>>>> crash
>>>> may happen much later, and the true cause for the problem is then  
>>>> very
>>>> hard to
>>>> track down.
>>>>
>>>> ---------------------------------
>>>>
>>>> so try starting mythbackend like this:
>>>>
>>>> MALLOC_CHECK_=3 /usr/local/bin/mythbackend <other args>
>>>>
>>>> probably by editing the script in /etc/rc.d/init.d (or wherever  
>>>> yours
>>>> is)
>>>> so you keep the other arguments
>>>>
>>>> HTH
>>>>
>>
> I wonder why mine crashes once in 2 months and yours crashes every
> day.  My system is on all the time.  I only watch TV with it and it is
> ATSC only.  There must be some difference in our systems that would be
> a clue.
>
> Allen

I get exactly the same problem a few times a day, even when I'm not  
watching/recording anything.

Is this related to Avenard's VDPAU backport packages, or "vanilla"  
mythtv? I never used to get these when I was running MythDora, but  
they're frequent on my MythBuntu installation.

Ben