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

[Allen Edwards]

On Thu, May 7, 2009 at 7:19 AM, Ben Lancaster <mail at benlancaster.co.uk>wrote:

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


My system is mythbuntu 8.04 and, as I said, it has only crashed a couple
times in the 6 months I have had it running.  It  has not crashed since my
last post on the subject.

Allen
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mythtv.org/pipermail/mythtv-users/attachments/20090507/fb16af3b/attachment.htm>