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

[Brian J. Murrell]

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.

-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 198 bytes
Desc: This is a digitally signed message part
URL: <http://mythtv.org/pipermail/mythtv-users/attachments/20101031/165f0b55/attachment.pgp>