After siting idle in the menus for a while, mythfrontend is crashing with a sigpipe. Last bit of the terminal output: 2015-09-22 22:28:28.845772 I New DB connection, total: 3 2015-09-22 22:28:28.845845 I New DB connection, total: 3 2015-09-23 00:02:50.119640 N Entering standby mode after 90 minutes of inactivity 2015-09-23 00:02:50.121737 I New DB connection, total: 3 2015-09-23 08:25:20.093133 N Leaving standby mode 2015-09-23 09:58:39.996177 N Entering standby mode after 90 minutes of inactivity I was able to catch a backtrace: Program received signal SIGPIPE, Broken pipe. [Switching to Thread 0x7fff2bc73700 (LWP 4880)] 0x00007fffea49a54b in send () from /lib64/libpthread.so.0 (gdb) bt #0 0x00007fffea49a54b in send () from /lib64/libpthread.so.0 #1 0x00007fffc9301f52 in vio_write () from /usr/lib64/libmysqlclient.so.18 #2 0x00007fffc92ea4d5 in net_write_packet () from /usr/lib64/libmysqlclient.so.18 #3 0x00007fffc92ea669 in net_flush () from /usr/lib64/libmysqlclient.so.18 #4 0x00007fffc92eaa5d in net_write_command () from /usr/lib64/libmysqlclient.so.18 #5 0x00007fffc92e6607 in cli_advanced_command () from /usr/lib64/libmysqlclient.so.18 #6 0x00007fffc92e3fd2 in mysql_close () from /usr/lib64/libmysqlclient.so.18 #7 0x00007fffd8240dc1 in ?? () from /usr/lib64/qt4/plugins/sqldrivers/libqsqlmysql.so #8 0x00007ffff538b037 in ?? () from /usr/lib64/libmythbase-0.27.so.0 #9 0x00007ffff5390122 in MDBManager::PurgeIdleConnections(bool) () from /usr/lib64/libmythbase-0.27.so.0 #10 0x00007ffff53909fd in MDBManager::popConnection(bool) () from /usr/lib64/libmythbase-0.27.so.0 #11 0x00007ffff5391883 in MSqlQuery::InitCon(MSqlQuery::ConnectionReuse) () from /usr/lib64/libmythbase-0.27.so.0 #12 0x00007ffff53ceedf in StorageGroup::FindDirs(QString, QString, QStringList*) () from /usr/lib64/libmythbase-0.27.so.0 #13 0x00007ffff53d042f in StorageGroup::Init(QString, QString, bool) () from /usr/lib64/libmythbase-0.27.so.0 #14 0x00007ffff53d1f15 in StorageGroup::StorageGroup(QString, QString, bool) () from /usr/lib64/libmythbase-0.27.so.0 #15 0x00007ffff4acdd63 in ProgramInfo::GetPlaybackURL(bool, bool) const () from /usr/lib64/libmyth-0.27.so.0 #16 0x00007ffff4aceda4 in ProgramInfo::IsFileReadable() const () from /usr/lib64/libmyth-0.27.so.0 #17 0x00000000005727f9 in ?? () #18 0x000000000057482f in ?? () #19 0x00007fffeb09002c in QApplicationPrivate::notify_helper(QObject*, QEvent*) () from /usr/lib64/qt4/libQtGui.so.4 #20 0x00007fffeb096605 in QApplication::notify(QObject*, QEvent*) () from /usr/lib64/qt4/libQtGui.so.4 #21 0x00007fffea82123c in QCoreApplication::notifyInternal(QObject*, QEvent*) () from /usr/lib64/qt4/libQtCore.so.4 #22 0x00007fffea8243b0 in QCoreApplicationPrivate::sendPostedEvents(QObject*, int, QThreadData*) () from /usr/lib64/qt4/libQtCore.so.4 #23 0x00007fffea84e2de in ?? () from /usr/lib64/qt4/libQtCore.so.4 #24 0x00007fffe5df0dbb in g_main_context_dispatch () from /usr/lib64/libglib-2.0.so.0 #25 0x00007fffe5df0fd0 in ?? () from /usr/lib64/libglib-2.0.so.0 #26 0x00007fffe5df1074 in g_main_context_iteration () from /usr/lib64/libglib-2.0.so.0 #27 0x00007fffea84daee in QEventDispatcherGlib::processEvents(QFlags<QEventLoop: :ProcessEventsFlag>) () from /usr/lib64/qt4/libQtCore.so.4 #28 0x00007fffea81feb7 in QEventLoop::processEvents(QFlags<QEventLoop::ProcessEventsFlag>) () from /usr/lib64/qt4/libQtCore.so.4 #29 0x00007fffea82017d in QEventLoop::exec(QFlags<QEventLoop::ProcessEventsFlag>) () from /usr/lib64/qt4/libQtCore.so.4 #30 0x00007fffea71e9cf in QThread::exec() () from /usr/lib64/qt4/libQtCore.so.4 #31 0x00007ffff5377369 in MThread::run() () from /usr/lib64/libmythbase-0.27.so.0 #32 0x00007fffea7210bf in ?? () from /usr/lib64/qt4/libQtCore.so.4 #33 0x00007fffea493354 in start_thread () from /lib64/libpthread.so.0 #34 0x00007fffe99cd53d in clone () from /lib64/libc.so.6 This is most likely an unstream issue, but I figured it would be worthwhile to mention it here to block this version from going to stable. If I have time, I will start bisecting this issue, but it will take a long time before I can get back with a result. Reproducible: Always Steps to Reproduce: 1. Use mythfrontend casually, without closing or restarting. 2. Frontend eventually crashes, typically in the same day.
media-tv/mythtv-0.27.4_p20150124 was not affected by this issue.
media-tv/mythtv-0.27.5_p20150627 is affected by this issue.
Further testing with media-tv/mythtv-0.27.5_p20150627 indicates a single false positive, sorry for the misinformation.
So if you go back to a previous version, e.g. media-tv/mythtv-0.27.5_p20150627 this issue does not happen? I'm guessing you've had changes on your system that are dependencies of MythTV (e.g. MySQL/MariaDB) and that's where the issue is coming from. What is your MySQL provider and what version do you have? What are the USE flags? (e.g. emerge --info mysql)
Past the first false positive, I have not hit this sigpipe with media-tv/mythtv-0.27.5_p20150627. Before I filed this bug, I re-emerged mysql and qtsql:4. The only recent mysql update was the mandatory 5.6.24 -> 5.6.26 security update. dev-db/mysql-5.6.26::gentoo was built with the following: USE="community perl ssl (-cluster) -debug -embedded -extraengine -jemalloc -latin1 -minimal -profiling (-selinux) -static -static-libs -systemtap -tcmalloc -test" ABI_X86="32 64 -x32" CFLAGS="-O2 -march=bdver1 -mprefer-avx128 -mvzeroupper -pipe -fno-strict-aliasing" CXXFLAGS="-O2 -march=bdver1 -mprefer-avx128 -mvzeroupper -pipe -fno-strict-aliasing -felide-constructors -fno-exceptions -fno-rtti -fno-strict-aliasing"
(In reply to kisak42 from comment #5) > Past the first false positive, I have not hit this sigpipe with > media-tv/mythtv-0.27.5_p20150627. > > Before I filed this bug, I re-emerged mysql and qtsql:4. The only recent > mysql update was the mandatory 5.6.24 -> 5.6.26 security update. > > dev-db/mysql-5.6.26::gentoo was built with the following: > USE="community perl ssl (-cluster) -debug -embedded -extraengine -jemalloc > -latin1 -minimal -profiling (-selinux) -static -static-libs -systemtap > -tcmalloc -test" ABI_X86="32 64 -x32" > CFLAGS="-O2 -march=bdver1 -mprefer-avx128 -mvzeroupper -pipe > -fno-strict-aliasing" > CXXFLAGS="-O2 -march=bdver1 -mprefer-avx128 -mvzeroupper -pipe > -fno-strict-aliasing -felide-constructors -fno-exceptions -fno-rtti > -fno-strict-aliasing" I can't replicate this with the same versions and same USE flags for MySQL. The errror you're seeing in your backtrace is deep inside the MySQL library from the Qt integration so its doubtful to me that this change would be anything related to MythTV. Especially considering the changes between the two versions.
On my system, the reliable reproduction steps are: at a terminal: gdb -ex=r mythfrontend.real goto Watch Recordings leave overnight observe backtrace in the morning.
Okay, two things. First, I reproduced this again with 0.27.5_p20150627's commit, and second, multiple DB standby -> active -> standby cycles while staying in Watch Recordings have to occur to encounter this issue. I'm of the opinion this is not a show stopper as there is a large margin of normal operation before encountering this. It is at the discretion of the package maintainers whether to disregard this report. I have expanded my bisection to cover commits going back to media-tv/mythtv-0.27.4_p20141018, eventually I will report the result.
I'm closing this at this time as I no longer believe there is any action to be taken by gentoo mythtv package maintainers. My bisection revealed this issue goes back further than I'm willing to test. It is my opinion there is a race condition between the frontend re-establishing the database connection and any db requests that are fired off. Changes between 0.27.4_p20141018 and 0.27.5_p20150904 have made some mysql queries more complex, which seems to make this race easier to trigger, but the underlying issue has been there for longer than 0.27's branch point. For those wanting to test this, set the standby time very low in the frontend's setup, and do many standby-wake cycles in Watch Recordings.
