[mythtv-users] mythbackend crashes every 6-7 hours

Rob Verduijn rob.verduijn at gmail.com
Sun Oct 31 22:31:14 UTC 2010


Valgrind produced a log file of over 1 megabyte plain text.
How do I even start with that one, I have no c programming experience I
wouldn't know where to start looking in that file, it's huge.

most of the errors are like this one
2 bytes in 1 blocks are possibly lost in loss record 2 of 2,812
and after a huge amount of those I get a leak summary
==12720==    definitely lost: 0 bytes in 0 blocks
==12720==    indirectly lost: 0 bytes in 0 blocks
==12720==      possibly lost: 81,333 bytes in 1,641 blocks
==12720==    still reachable: 169,581 bytes in 1,794 blocks
==12720==         suppressed: 0 bytes in 0 blocks
==12720== Reachable blocks (those to which a pointer was found) are not
shown.
==12720== To see them, rerun with: --leak-check=full --show-reachable=yes
==12720==
==12720== For counts of detected and suppressed errors, rerun with: -v
==12720== ERROR SUMMARY: 1189 errors from 1189 contexts (suppressed: 3 from
3)

after which I get an awfull lot of these :
--12720-- Warning: unhandled socketcall 0x12

interrupted by this once (I started apache here to enable mythweb)
==12720== Thread 18:
==12720== Conditional jump or move depends on uninitialised value(s)
==12720==    at 0x551CBAE: QTransform::fromScale(double, double) (in
/usr/lib/libQtGui.so.4.6.3)
==12720==    by 0x542ABAE: QImage::scaled(QSize const&, Qt::AspectRatioMode,
Qt::TransformationMode) const (in /usr/lib/libQtGui.so.4.6.3)
==12720==    by 0x81431A5: ??? (in /usr/bin/mythbackend)
==12720==    by 0x814CCD2: ??? (in /usr/bin/mythbackend)
==12720==    by 0x4A9EC0F: HttpServer::DelegateRequest(HttpWorkerThread*,
HTTPRequest*) (in /usr/lib/libmythupnp-0.23.1.so.0.23.1)
==12720==    by 0x4A9F288: HttpWorkerThread::ProcessWork() (in
/usr/lib/libmythupnp-0.23.1.so.0.23.1)
==12720==    by 0x4A9C287: WorkerThread::WakeForWork() (in
/usr/lib/libmythupnp-0.23.1.so.0.23.1)
==12720==    by 0x4A9C4F1: WorkerEvent::customEvent(QEvent*) (in
/usr/lib/libmythupnp-0.23.1.so.0.23.1)
==12720==    by 0x5F3A99B: QObject::event(QEvent*) (in
/usr/lib/libQtCore.so.4.6.3)
==12720==    by 0x5F28058: QCoreApplicationPrivate::notify_helper(QObject*,
QEvent*) (in /usr/lib/libQtCore.so.4.6.3)
==12720==    by 0x5F280D7: QCoreApplication::notify(QObject*, QEvent*) (in
/usr/lib/libQtCore.so.4.6.3)
==12720==    by 0x5F27E0D: QCoreApplication::notifyInternal(QObject*,
QEvent*) (in /usr/lib/libQtCore.so.4.6.3)
==12720==

a lot more of these
--12720-- Warning: unhandled socketcall 0x12

untill it crashes at the end with this message
==12720==
==12720==     Valgrind's memory management: out of memory:
==12720==        newSuperblock's request for 4194304 bytes failed.
==12720==        3034054656 bytes have already been allocated.
==12720==     Valgrind cannot continue.  Sorry.
==12720==
==12720==     There are several possible reasons for this.
==12720==     - You have some kind of memory limit in place.  Look at the
==12720==       output of 'ulimit -a'.  Is there a limit on the size of
==12720==       virtual memory or address space?
==12720==     - You have run out of swap space.
==12720==     - Valgrind has a bug.  If you think this is the case or you
are
==12720==     not sure, please let us know and we'll try to fix it.
==12720==     Please note that programs can take substantially more memory
than
==12720==     normal when running under Valgrind tools, eg. up to twice or
==12720==     more, depending on the tool.  On a 64-bit machine, Valgrind
==12720==     should be able to make use of up 32GB memory.  On a 32-bit
==12720==     machine, Valgrind should be able to use all the memory
available
==12720==     to a single process, up to 4GB if that's how you have your
==12720==     kernel configured.  Most 32-bit Linux setups allow a maximum
of
==12720==     3GB per process.
==12720==
==12720==     Whatever the reason, Valgrind cannot continue.  Sorry.

For me the log file might as well be empty because I cannot make anything
from it.

Rob Verduijn

2010/10/31 Brian J. Murrell <brian at interlinx.bc.ca>

> On Sun, 2010-10-31 at 20:49 +0000, James Courtier-Dutton wrote:
> >
> > myth does not have a memory leak here.
>
> What you mean is that myth does not have a memory leak for your
> use-case.  You cannot of course know for sure that myth doesn't have a
> memory leak for some use-case which does not apply to you.
>
> > I use the SVN version, and it is compiled with debug switched on.
> > It sits on about 700M of virtual memory and about 3% CPU, but I have a
> > fast CPU and my mythfrontend is on a different PC.
>
> And again, doesn't leak for _your_use-case_.  That of course doesn't
> mean that OP's use-case doesn't follow some different code path that is
> leaking memory.
>
> > If you want to track this down, I would try the same, get the SVN
> > version, compile it in debug mode.
>
> Well, no.  The right way to track it down has already been suggested and
> that's to actually audit the memory use with a tool like valgrind.
> Simply switching to a different tool does neither prove nor disprove
> that the previous tool was faulty and leaves you guessing, at best.
>
> b.
>
>
> _______________________________________________
> 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/20101031/0530bd78/attachment.htm>


More information about the mythtv-users mailing list