[mythtv-users] Failed with exit status 140

[Michael T. Dean]

On 06/01/2013 07:08 PM, D. Hugh Redelmeier wrote:
> (Continuing a thread started by Rich.West on April 15)
>
> I'm running Ubuntu 12.04 + mythtv-backend
> 2:0.26.0+fixes.20130530.bfd2408-0ubuntu0mythbuntu1
>
> I get mythcommflag crashes.  The diagnostic is mythcommflag assert
> failure: *** glibc detected *** /usr/bin/mythcommflag: invalid fastbin
> entry (free): 0x00007f22ec0164b0 ***
>
> This looks very much like the problem others experienced in April
>
> http://code.mythtv.org/trac/ticket/10201  describes the symptom I'm
> seeing.  A couple of recent additions by Ubuntu users show that the
> symptom is current.  But I think that the bug in trac is different.  For
> one thing, the glibc patch described is already in Ubuntu's glibc (I
> checked).  And the versions are much different.  A guru has closed the
> trac entry.
>
> I (well automation, with input from me) have created a new bug report
> for the new bug:https://bugs.launchpad.net/mythbuntu/+bug/1186626

FWIW, your issue seems to be different from the 
Fedora-with-specific-glibc-version issue.

An "invalid fastbin entry" message on application abort is a generic 
message prompted by a bit of code added to (a version of) glibc (right 
around the one Red Hat used with the bug) that's supposed to stop code 
before it corrupts the heap meta data, which could allow an attacker to 
execute arbitrary code--i.e. it was put there to pre-emptively stop a 
specific type of attack that was created against a specific code 
construct that someone had found a way to exploit (since that code 
construct could easily exist in real-world applications or libraries).

And, FWIW, since you're using *buntu, you're almost definitely using 
eglibc, not glibc.  That means you have glibc code plus all the changes 
the eglibc team decided to put on top of it (though neither of the areas 
involved in your abort are likely to have been much modified--I don't 
think they've been modified at all).

That said, your specific abort is occurring when MythTV starts a 
MythTimer ( 
https://github.com/MythTV/mythtv/blob/bfd24081b347ced053b7eeb1bbda1ddea572a56a/mythtv/libs/libmythbase/mythtimer.h#L12 
), which calls QTime::start(), which calls QTime::currentTime() (both 
from Qt), which calls __tzset(), which calls tzset_internal() (both from 
glibc/eglibc), which (it seems--though not knowing exactly which version 
of eglibc you're using, I'm just guessing) is trying to free a pointer 
for the old_tz (which stores the value for the previously-set time zone) 
by calling free() (from glibc/eglibc), but that pointer seems to be 
pointing to an invalid area of memory.

So, while I can't, at this point, say the problem is with eglibc/glibc, 
I can say it could well be a problem with eglibc/glibc, with Qt, or 
MythTV's use of one of those libraries.  And, since the MythTV code that 
calls the functions that eventually abort is just calling start() on 
(what seems to be a valid) QTime, it seems like there's a good chance 
the issue is lower level than MythTV.  And, if the issue isn't 
reproducible on lots of similar systems (i.e. using the same 
(e)glibc/Qt/MythTV versions), it could well be even lower level (such as 
memory issues or ...).

I'll see if anyone else can see a problem in MythTV's code, but at this 
point, I think the problem is actually in one of the libraries.  
Unfortunately, I don't see any other reports of similar issues out there.

If you can easily reproduce the issue, it would be interesting to see 
the value of old_tz at the point of the failure.  You'd have to get this 
information by using gdb interactively.  To do this, just make sure you 
have the MythTV debug package installed, then start up gdb directly as 
described at http://www.mythtv.org/wiki/Debugging#Getting_a_Backtrace , 
and see the gdb manual for more ( 
http://sourceware.org/gdb/current/onlinedocs/gdb/ ).

Thanks,
Mike