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

Allen Edwards allen.p.edwards at gmail.com
Fri Feb 6 04:10:19 UTC 2009


 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
>>>
>>>
>>> _______________________________________________
>>> mythtv-users mailing list
>>> mythtv-users at mythtv.org
>>> http://mythtv.org/cgi-bin/mailman/listinfo/mythtv-users
>>
>
>
> _______________________________________________
> mythtv-users mailing list
> mythtv-users at mythtv.org
> http://mythtv.org/cgi-bin/mailman/listinfo/mythtv-users
>
>



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


More information about the mythtv-users mailing list