invalid fastbin entry (free) on playback start (mythfrontend, mythcommflag)

[Chad Sawatzky <chad.sawatzky@…>]

I have had a persistent problem with mythfrontend crashing during playback while in livetv or recorded playback. This has been happening for many months. I had been waiting to see if package updates (from rpmfusion) would include a fix for the issue, but the problem continues. In fact, it seems to be getting worse. It may only happen after a couple of hours, and other times this can occur repeatedly only minutes/seconds apart (frustrating trying to watch - resorted to running mythfrontend in while true loop).

I have had mythfrontend running on other computers during this same time and I have not been experiencing the the issue in either of those cases (Fedora 14 and 16). There are differences in these cases as I do not run mythfrontend continually and I don't run a backend on them. The crash only seems to effect the the htpc (Fedora 14) connected to the TV and running the backend.

I also noticed that there may be similar problems effecting mythcommflag. I saw this while looking at the mythbackend.log. Since I started collecting coredumps I notice that I have one for mythcommflag to, so I'll include the backtrace for that also.

*** glibc detected *** /usr/bin/mythcommflag: invalid fastbin entry (free): 0xb6249b38 ***
======= Backtrace: =========
/lib/libc.so.6[0x749fb6]
/lib/libc.so.6[0x768cb2]
/lib/libc.so.6(tzset+0x3d)[0x768f1d]
/usr/lib/libQtCore.so.4(_ZN5QTime11currentTimeEv+0x42)[0x6851cc2]
/usr/lib/libQtCore.so.4(_ZN5QTime5startEv+0x1e)[0x6851dfe]
/usr/lib/libmythdb-0.24.so.0(_ZN10MythSocket15writeStringListER11QStringList+0xd47)[0x6bc7e97]
/usr/lib/libmythdb-0.24.so.0(_ZN10RemoteFile4ReadEPvi+0x4d7)[0x6c30017]
/usr/lib/libmythtv-0.24.so.0(_ZN10RingBuffer9safe_readEP10RemoteFilePvj+0x3b)[0x73aa28b]
/usr/lib/libmythtv-0.24.so.0(_ZN10RingBuffer3runEv+0x9b3)[0x73aebb3]
/usr/lib/libQtCore.so.4[0x6841603]
/usr/lib/nvidia/libGL.so.1[0x458e78d]
/lib/libc.so.6(clone+0x5e)[0x7b2d2e]

Reproducing Problem:

• Run mythfrontend
• Watch livetv or recorded programs
• Wait (happens during playback, not paused)

I've installed updates as new packages have become available, so I'm attached a backtraces for each one.

• Nov 20 13:50:19 Updated: mythtv-frontend-0.24.1-3.fc14.i686
• Dec 08 21:44:06 Updated: mythtv-frontend-0.24.1-5.fc14.i686

Current Version:
Please attach all output as a file in bug reports.
MythTV Version   : 0.24.1-5.fc14 (e89d6a9f7e)
MythTV Branch    : 
Network Protocol : 63
Library API      : 0.24.20110505-1
QT Version       : 4.7.4
Options compiled in:
 linux release using_alsa using_jack using_oss using_pulse using_pulseoutput using_backend using_bindings_perl using_bindings_python using_crystalhd using_dvb using_firewire using_frontend using_hdhomerun using_hdpvr using_iptv using_ivtv using_joystick_menu using_libfftw3 using_lirc using_mheg using_opengl_video using_opengl_vsync using_qtdbus using_qtwebkit using_v4l using_x11 using_xrandr using_xv using_xvmc using_xvmc_vld using_xvmcw using_bindings_perl using_bindings_python using_mythtranscode using_opengl using_vdpau using_ffmpeg_threads using_live using_mheg

Let me know what more I can do to help resolve this issue. Thanks --Chad

[Chad Sawatzky <chad.sawatzky@…>]

I have rebuild my htpc to the latest Fedora 16 release. I continue to have the same problem I reported previously. I'm not really sure where to go from here? I can guess at several of the components to look at, but I'm not sure how to determine where/why it is failing.

Seems like I might be the only person experiencing this error. I wondered if it might be related to hardware. I ran a some memory tests to see if I could see any problem. All the memory tests came back ok.

I also tried running with the nouveau, rather then nvidia, driver to see if that made any difference.

I'll attach the backtrace I did after the upgrade. Please, let me know what else I can do to help. --Chad

[Chad Sawatzky <chad.sawatzky@…>]

# rpm -q --whatprovides  /lib/libc.so.6
glibc-2.14.90-24.fc16.4.i686

# /lib/libc.so.6 --version
GNU C Library development release version 2.14.90, by Roland McGrath et al.
Copyright (C) 2011 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.
There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A
PARTICULAR PURPOSE.
Compiled by GNU CC version 4.6.2 20111027 (Red Hat 4.6.2-1).
Compiled on a Linux 3.1.5 system on 2011-12-22.
Available extensions:
	Support for some architectures added on, not maintained in glibc core.
	The C stubs add-on version 2.1.2.
	crypt add-on version 2.1 by Michael Glad and others
	GNU Libidn by Simon Josefsson
	Native POSIX Threads Library by Ulrich Drepper et al
	BIND-8.2.3-T5B
	RT using linux kernel aio
libc ABIs: UNIQUE IFUNC
For bug reporting instructions, please see:
<http://www.gnu.org/software/libc/bugs.html>.

[Chad Sawatzky <chad.sawatzky@…>]

What Playback Profile Group do you have selected...

I have a playback profile selected that I created called Test. I like standard def played back using a particular deinterlacer better then using VDPAU.

It is set with two playback resolutions.

• if rez>=1280 720 -> vdpau & vdpau
• if rez > 0 0 -> ffmpeg & XVideo

I still have to setup my HD capture, so at the moment content recorded in SD. The settings for rez 0 0 is as follows:

• Decoder: Standard
• Video renderer: xv-blit
• OSD renderer: softblend
• Primary deinterlacer: Linear blend
• Fallback deint: None

I will run with the Slim profile right now and see how that works out. I will need an update or to rebuild the nvidia driver before I try vdpau. There is some problem with a recent nvidia rpm package at present that causes persistent segfaults with all of mythtv (so it appears).

[Chad Sawatzky <chad.sawatzky@…>]

Here is an update...

I have tried the playback profiles Slim and VDPAU Slim. Both settings continued to result in the same error. I noticed that the setting I had was similar to Slim, but with the higher rez using vdpau.

I while doing some reading on free and malloc I noticed that MALLOC_CHECK_ can be set in the environ. I have been running mythfrontend with MALLOC_CHECK_=1. This makes the glibc memory checking ignore some detected errors.

"...if set to 1, a diagnostic message is printed on stderr..."

I've been running like this for about 2 weeks and this has eliminated the crashing I was experiencing. I was still expecting to see a fastbin error, but I have not seen one while running with MALLOC_CHECK_=1.

Although this does not resolve the root cause, it does make running mythfrontend far more usable for me. Since this was a free() error, I was wondering if I might end up with a memory leak so I ran a check on memory use by mythfrontend every hour for 4 days. I didn't see any memory leak running it this way, the memory usage look stable.

When exiting mythfrontend after running for a few days I ended up with a segfault in libQtCore. I'm not sure if this would be related or just some stray event. I have not seen it happen since.

Feb  4 00:33:13 htpc kernel: [352223.369133] mythfrontend[2507]: segfault at 24 ip 45823db6 sp b19debd0 error 4 in libQtCore.so.4.8.0[4569f000+2d8000]
Feb  4 00:33:13 htpc lircd-0.9.0[1154]: removed client
Feb  4 00:33:26 htpc abrtd: Directory 'ccpp-2012-02-04-00:33:13-2490' creation detected
Feb  4 00:33:26 htpc abrt[23389]: Saved core dump of pid 2490 (/usr/bin/mythfrontend) to /var/spool/abrt/ccpp-2012-02-04-00:33:13-2490 (432857088 bytes)

I'm not sure if this is somehow related to my specific combination of hardware or software (like libQtcore or glibc) or what is going on. In searching for more information I've concluded that I may be the only one experiencing this particular error. If you're interested (not sure if it will help) you can find my hw profile here ​http://www.smolts.org/client/show_all/pub_443bc76a-cb20-4511-ba20-c0fb8bf6d19e

I was thinking that it might be time to try using valgrind. If I do, I will provide an update if there is anything interesting.

If there is anything more you can think for me to try or information you would like, please let me know. I will continue to investigate to see if there is something more I can learn, though for now at least I seem to have found a way stabilize my setup.

Thanks --CS

[stuartm]

without further reports of the same problem from other users I'm assuming for now that this is particular to your machine somehow. Faulty memory or similar perhaps

[dag@…]

Well. I have exactly this same problem in my Minimyth installation so here is another one. Haven't tried the MALLOC_CHECK_=1 trick yet.

[myth@…]

Similar issue - mythcommflag was failing with "* glibc detected * /usr/bin/mythcommflag: invalid fastbin entry (free): 0xb6249b38 *" errors.

Backend is an older Fedora 14 server. Problem appears to be glibc -- see ​https://bugzilla.redhat.com/show_bug.cgi?id=593396

#yum upgrade glibc

solved it for me.

[willem@…]

Exactly the same problem here, ubuntu 12.04, mythfrontend version: fixes/0.25 [v0.25.3-44-g94d67fc] www.mythtv.org

I will try the MALLOC_CHECK_=1 trick

[d.quist@…]

Same thing here, Ubuntu 12.10. Mythfronted version: fixes /0.26 [v0.26-171-gbfd2408]. It started when I upgraded Mythtv to 0.26 from 0.24 and Ubuntu to 12.10 from 12.04 which ran perfectly.

[stuartm]

As noted by someone 6 weeks ago, this is a glibc bug not a mythtv one and it's only affecting distros using that specific version of glibc.

[sphery]

The issue reported here by Chad (the OP) and mentioned by D. Hugh Redelmeier at ​https://bugs.launchpad.net/mythbuntu/+bug/1186626 and ​http://www.gossamer-threads.com/lists/mythtv/users/544688#544688 (and likely the same one mentioned by others in that thread--though I can't be sure since they didn't get backtraces) is not the due to the broken test in glibc that was shipped with some versions of Red-Hat-based distros. (Chad confirmed he had the fix for the glibc issue at ​http://www.gossamer-threads.com/lists/mythtv/users/501857#501857 and Ubuntu 12.10 is using a post-fix release of eglibc.)

That said, the abort is occurring in (e)glibc, seemingly when tzset_internal() calls free on old_tz (a pointer to the previously-set time zone), which seems to be pointing to an invalid area of memory. This code was reached when MythTV called start() on a MythTimer? (which calls start() on a QTime). I don't see any obvious issues with the MythTV code, so I'm still leaning toward an upstream problem with one of the libraries.

If anyone sees a problem with the MythTV code that I'm missing, please let me know.

[sphery]

Daniel K. pointed out that we're no longer using QTime in master/unstable/development since 440573f3f . So, it's very likely that even if there is an issue in an underlying library, we're no longer using the code that triggers it.