[mythtv-users] mythbackend crashes every 6-7 hours
Rob Verduijn
rob.verduijn at gmail.com
Mon Nov 1 08:15:45 UTC 2010
Hi again,
I tried the term trick.
I kept the backend running for about 5 mins and the hit it
After this the log file doubles in size to over 2Mb
I now have a four parts in the log file that say 'definitely lost'. (not
counting the summary)
Are the 'definitely lost' blocks the parts of the logs that we're looking
for ?
log is below
Rob Verduijn
First the leak summary
==21026== LEAK SUMMARY:
==21026== definitely lost: 4,536 bytes in 5 blocks
==21026== indirectly lost: 0 bytes in 0 blocks
==21026== possibly lost: 209,488 bytes in 3,100 blocks
==21026== still reachable: 475,959 bytes in 3,156 blocks
==21026== suppressed: 0 bytes in 0 blocks
==21026== Reachable blocks (those to which a pointer was found) are not
shown.
==21026== To see them, rerun with: --leak-check=full --show-reachable=yes
==21026==
==21026== For counts of detected and suppressed errors, rerun with: -v
==21026== ERROR SUMMARY: 1358 errors from 1358 contexts (suppressed: 3 from
3)
first block
==21026== 152 bytes in 1 blocks are definitely lost in loss record 3,742 of
3,963
==21026== at 0x40260BB: calloc (in
/usr/lib/valgrind/vgpreload_memcheck-x86-linux.so)
==21026== by 0x4010E17: allocate_dtv (in /lib/ld-2.11.2.so)
==21026== by 0x40115B8: _dl_allocate_tls (in /lib/ld-2.11.2.so)
==21026== by 0x604D610: pthread_create@@GLIBC_2.1 (in /lib/
libpthread-2.11.2.so)
==21026== by 0x9F74525: my_thread_global_init (in
/usr/lib/libmysqlclient_r.so.16.0.0)
==21026== by 0x9F6EA6B: my_init (in /usr/lib/libmysqlclient_r.so.16.0.0)
==21026== by 0x9F68ED9: mysql_server_init (in
/usr/lib/libmysqlclient_r.so.16.0.0)
==21026== by 0x9F23923: qLibraryInit() (in
/usr/lib/qt4/plugins/sqldrivers/libqsqlmysql.so)
==21026== by 0x9F25231: QMYSQLDriver::QMYSQLDriver(QObject*) (in
/usr/lib/qt4/plugins/sqldrivers/libqsqlmysql.so)
==21026== by 0x9F23145: QMYSQLDriverPlugin::create(QString const&) (in
/usr/lib/qt4/plugins/sqldrivers/libqsqlmysql.so)
==21026== by 0x51B52AE: ??? (in /usr/lib/libQtSql.so.4.6.3)
==21026== by 0x51B5809: QSqlDatabase::addDatabase(QString const&, QString
const&) (in /usr/lib/libQtSql.so.4.6.3)
second block
==21026== 152 bytes in 1 blocks are definitely lost in loss record 3,743 of
3,963
==21026== at 0x40260BB: calloc (in
/usr/lib/valgrind/vgpreload_memcheck-x86-linux.so)
==21026== by 0x4010E17: allocate_dtv (in /lib/ld-2.11.2.so)
==21026== by 0x40115B8: _dl_allocate_tls (in /lib/ld-2.11.2.so)
==21026== by 0x604D610: pthread_create@@GLIBC_2.1 (in /lib/
libpthread-2.11.2.so)
==21026== by 0x5E2EAD7: QThread::start(QThread::Priority) (in
/usr/lib/libQtCore.so.4.6.3)
==21026== by 0x4A7F895: UPnp::Start() (in
/usr/lib/libmythupnp-0.23.1.so.0.23.1)
==21026== by 0x813C1B3: ??? (in /usr/bin/mythbackend)
==21026== by 0x80962D1: ??? (in /usr/bin/mythbackend)
==21026== by 0x61B1C0D: (below main) (in /lib/libc-2.11.2.so)
third block
==21026== 152 bytes in 1 blocks are definitely lost in loss record 3,744 of
3,963
==21026== at 0x40260BB: calloc (in
/usr/lib/valgrind/vgpreload_memcheck-x86-linux.so)
==21026== by 0x4010E17: allocate_dtv (in /lib/ld-2.11.2.so)
==21026== by 0x40115B8: _dl_allocate_tls (in /lib/ld-2.11.2.so)
==21026== by 0x604D610: pthread_create@@GLIBC_2.1 (in /lib/
libpthread-2.11.2.so)
==21026== by 0x5E2EAD7: QThread::start(QThread::Priority) (in
/usr/lib/libQtCore.so.4.6.3)
==21026== by 0x80C7B63: ??? (in /usr/bin/mythbackend)
==21026== by 0x8096616: ??? (in /usr/bin/mythbackend)
==21026== by 0x61B1C0D: (below main) (in /lib/libc-2.11.2.so)
fourth block
==21026== 4,080 bytes in 2 blocks are definitely lost in loss record 3,932
of 3,963
==21026== at 0x40260BB: calloc (in
/usr/lib/valgrind/vgpreload_memcheck-x86-linux.so)
==21026== by 0x74D5729: g_malloc0 (in /usr/lib/libglib-2.0.so.0.2400.1)
==21026== by 0x74ED0D2: g_slice_alloc (in
/usr/lib/libglib-2.0.so.0.2400.1)
==21026== by 0x74A4BEA: g_ptr_array_sized_new (in
/usr/lib/libglib-2.0.so.0.2400.1)
==21026== by 0x74A4C3E: g_ptr_array_new (in
/usr/lib/libglib-2.0.so.0.2400.1)
==21026== by 0x74CBDF0: g_main_context_new (in
/usr/lib/libglib-2.0.so.0.2400.1)
==21026== by 0x5F54B7B:
QEventDispatcherGlibPrivate::QEventDispatcherGlibPrivate(_GMainContext*) (in
/usr/lib/libQtCore.so.4.6.3)
==21026== by 0x5F54C1B:
QEventDispatcherGlib::QEventDispatcherGlib(QObject*) (in
/usr/lib/libQtCore.so.4.6.3)
==21026== by 0x5E2E2C5: ??? (in /usr/lib/libQtCore.so.4.6.3)
==21026== by 0x5E2F025: ??? (in /usr/lib/libQtCore.so.4.6.3)
==21026== by 0x604CB24: start_thread (in /lib/libpthread-2.11.2.so)
==21026== by 0x626E46D: clone (in /lib/libc-2.11.2.so)
2010/11/1 Brian J. Murrell <brian at interlinx.bc.ca>
> On Sun, 2010-10-31 at 15:54 -0700, Gavin Hurlbut wrote:
> >
> > No memory leak. Proof positive. At MOST, you have about 250kByte
> > maybe lost and/or still reachable.
>
> Well, you can't really say that for sure given what happened below...
>
> > > 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.
>
> So valgrind was unable to continue due to ENOMEM, so likely it did not
> get to finish it's accounting.
>
> Perhaps if you "exited" (i.e. kill, gracefully, with an INTR or TERM)
> the backend process before it or valgrind ENOMEMs so that it exits
> properly, valgrind could properly account for it's memory use rather
> than having to throw it's hands up in defeat by getting it's own ENOMEM.
>
> > Secondly: you hit a 3GB process memory limit (whether imposed by
> > ulimit or by the kernel). The ulimit -m unlimited may fix that.
>
> I tend to think that removing the ulimit -m will only delay the ENOMEM
> until physical VM is exhausted rather than the ulimit being bumped.
> Both will have the same problem, so might as well leave the ulimit in
> place to mimic VM exhaustion and not start getting into invoking the OOM
> killer.
>
> > You ran out of memory for that process. There's no way to tell from
> > here what you are using your memory for or what you are making it do.
>
> Right. Which is why he needs to make mythbackend exit before it or
> valgrind ENOMEMs.
>
> > I haven't ever seen the backend approach that kind of memory use, so
> > it's likely something in how you are using it, etc.
>
> Well, of course. But what? That's the question. Valgrind should help
> point out the answer.
>
> 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/20101101/b37155c0/attachment.htm>
More information about the mythtv-users
mailing list