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

tim dennis tdennis.sub at gmail.com
Fri Feb 6 03:13:12 UTC 2009


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
>>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mythtv.org/pipermail/mythtv-users/attachments/20090205/1ad0043e/attachment.htm>


More information about the mythtv-users mailing list