Backend crash when tuning livetv

[anonymous]

As request in #4820, I open a new ticket:

Regression from 15910 (this isn't the last one working, could be way newer) As soon as entering livetv, the backend crashes away MythTV version:

mythtv@caipirinha ~ $ mythbackend --version
Please include all output in bug reports.
MythTV Version   : 16384
MythTV Branch    : trunk
Library API      : 0.21.20080224-1
Network Protocol : 40
Options compiled in:
 linux debug using_oss using_alsa using_backend using_dvb using_frontend using_lirc using_opengl_vsync using_v4l using_x11 using_xrandr using_xv using_xvmc using_xvmcw using_bindings_perl using_bindings_python using_opengl using_ffmpeg_threads

Backtrace:

terminate called after throwing an instance of 'std::bad_alloc'
  what():  St9bad_alloc

Program received signal SIGABRT, Aborted.
0xb7f42410 in __kernel_vsyscall ()
(gdb) bt 
#0  0xb7f42410 in __kernel_vsyscall ()
#1  0xb5ddc101 in raise () from /lib/libc.so.6
#2  0xb5ddd8e8 in abort () from /lib/libc.so.6
#3  0xb5fc5510 in __gnu_cxx::__verbose_terminate_handler () from /usr/lib/gcc/i686-pc-linux-gnu/4.1.2/libstdc++.so.6
#4  0xb5fc3235 in ?? () from /usr/lib/gcc/i686-pc-linux-gnu/4.1.2/libstdc++.so.6
#5  0xb5fc3266 in std::terminate () from /usr/lib/gcc/i686-pc-linux-gnu/4.1.2/libstdc++.so.6
#6  0xb5fc336a in __cxa_throw () from /usr/lib/gcc/i686-pc-linux-gnu/4.1.2/libstdc++.so.6
#7  0xb5fc3760 in operator new () from /usr/lib/gcc/i686-pc-linux-gnu/4.1.2/libstdc++.so.6
#8  0xb5fc3829 in operator new[] () from /usr/lib/gcc/i686-pc-linux-gnu/4.1.2/libstdc++.so.6
#9  0xb676ccab in QString::setLength () from /usr/qt/3/lib/libqt-mt.so.3
#10 0xb676ce16 in QString::grow () from /usr/qt/3/lib/libqt-mt.so.3
#11 0xb676f992 in QString::operator+= () from /usr/qt/3/lib/libqt-mt.so.3
#12 0xb677fe7a in QStringList::join () from /usr/qt/3/lib/libqt-mt.so.3
#13 0xb6d12878 in MythSocket::writeStringList () from /usr/lib/libmyth-0.21.so.0
#14 0x080c38ac in ?? ()
#15 0xb64bd618 in QObject::event () from /usr/qt/3/lib/libqt-mt.so.3
#16 0xb6464a05 in QApplication::internalNotify () from /usr/qt/3/lib/libqt-mt.so.3
#17 0xb6465562 in QApplication::notify () from /usr/qt/3/lib/libqt-mt.so.3
#18 0xb64660c4 in QApplication::sendPostedEvents () from /usr/qt/3/lib/libqt-mt.so.3
#19 0xb6466234 in QApplication::sendPostedEvents () from /usr/qt/3/lib/libqt-mt.so.3
#20 0xb641720a in QEventLoop::processEvents () from /usr/qt/3/lib/libqt-mt.so.3
#21 0xb647849d in QEventLoop::enterLoop () from /usr/qt/3/lib/libqt-mt.so.3
#22 0xb6478342 in QEventLoop::exec () from /usr/qt/3/lib/libqt-mt.so.3
#23 0xb646452b in QApplication::exec () from /usr/qt/3/lib/libqt-mt.so.3
#24 0x0809ed1e in ?? ()
#25 0xb5dc8fdc in __libc_start_main () from /lib/libc.so.6
#26 0x080663f1 in ?? ()

[cg@…]

Sorry, forgot my email address

[tim@…]

Here's another similar crash from r16387 (with local modifications):

#0  0x0000003a488708c7 in malloc_consolidate () from /lib64/libc.so.6
#1  0x0000003a48872f3d in _int_malloc () from /lib64/libc.so.6
#2  0x0000003a488748fa in malloc () from /lib64/libc.so.6
#3  0x00002aaaaecfc1ed in operator new () from /usr/lib64/libstdc++.so.6
#4  0x00002aaaaecfc309 in operator new[] () from /usr/lib64/libstdc++.so.6
#5  0x00002aaaae07574d in QString::setLength ()
   from /usr/lib64/qt-3.3/lib/libqt-mt.so.3
#6  0x00002aaaae07945c in QString::operator+= ()
   from /usr/lib64/qt-3.3/lib/libqt-mt.so.3
#7  0x00002aaaae08c02b in QStringList::join ()
   from /usr/lib64/qt-3.3/lib/libqt-mt.so.3
#8  0x00002aaaacf2514a in MythEvent (this=0x952fc0, lmessage=@0x4e616098,
    lextradata=@0x4e6160a0) at mythevent.cpp:25
#9  0x00002aaaacf2599d in MythEvent::clone (this=0x4e616080) at mythevent.h:42
#10 0x00002aaaacf336ed in MythObservable::dispatch (this=0x853ab0,
    event=@0x4e616080) at mythobservable.cpp:45
#11 0x00002aaaacedb6ce in MythContext::dispatch (this=0x853a60,
    event=@0x4e616080) at mythcontext.cpp:3978
#12 0x00002aaaab279bd2 in SignalMonitor::MonitorLoop (this=0x2aaabc036390)
    at signalmonitor.cpp:306
#13 0x00002aaaab279778 in SignalMonitor::SpawnMonitorLoop (self=0x2aaabc036390)
    at signalmonitor.cpp:333
#14 0x00002aaaaea2a407 in start_thread () from /lib64/libpthread.so.0
#15 0x0000003a488d4b0d in clone () from /lib64/libc.so.6

The relevant local modification here is:

MythEvent::MythEvent(const QString &lmessage, const QStringList &lextradata) :
    QCustomEvent(MythEventMessage)
{
    QString crashme;
    crashme=lextradata.join(" // ");
    message   = QDeepCopy<QString>(lmessage);
    extradata = QDeepCopy<QStringList>(lextradata);
    crashme=extradata.join(" // ");
}

It is the *second* crashme, after the deep copy, that has segfaulted.

If I take out the 'crashme's I have scattered about the place, I get segfaults in various places similar to the one submitted by cg; adding the 'crashme's just makes them happen closer to when the corruption occurred.

[danielk]

this code has been reverted away in 0.21-fixes..

[Jon Whitear <jon@…>]

I may be missing something, but the code was reverted in 16382, and the crashes referred to here are in 16384 and 16387.

[anonymous]

The fix was only applied to the -fixes branch, not to head.

[tim@…]

The ticket was opened against "head", not against "-fixes" :-)

I dunno. Personally I'd either (a) open a new ticket against -fixes and then mark that fixed while re-opening this one, or (b) apply the fix to head as well.

[stuartm]

Should be fixed in current trunk.