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

[Greg Oliver]

On Sat, Oct 30, 2010 at 5:02 PM, Martin Moores <moores.martin at gmail.com> wrote:
> Rather than having the downtime, if you had any RAM you could swap into the
> box from spare or another machine, then that would help prove either way and
> no worry of complaints from the family!
>
> Martin
>
> On 30 Oct 2010 22:58, "Rob Verduijn" <rob.verduijn at gmail.com> wrote:
>> I'm still not convinced it's worth the hassle of setting up a stress
>> test and risking the wrath of the family.
>>
>> There aren't any weird messages in the message log except "terminate
>> called after throwing an instance of 'std::bad_alloc' "
>> Applied google to this and I get dozens of hits about memory problems
>> due to bad allocation of memory.....doh.....
>> Not a single hit is about faulty hardware.
>>
>> Watching top for a while shows me the mythbackend process chewing up
>> more and more memory doing nothing but waiting for a client to
>> connect.
>> (there were none while I watched it)
>>
>> So there are no weird entries except the one mentioned before.
>> I saw Mythbackend using 2Gb of ram and while I watched I saw it
>> increase it's memory usage to 2.1Gb
>> Mythbackend was idle at that time, no recordings we're active, there
>> were also no clients active.
>>
>> I have no indication that this should be hardware related.
>>
>>
>> Rob Verduijn
>>
>>
>> 2010/10/30 George Poulson <george.poulson at gmail.com>:
>>> On 30 October 2010 20:38, Rob Verduijn <rob.verduijn at gmail.com> wrote:
>>>
>>>>
>>>> Especially elaborate the reason that leads you to believe I have a
>>>> hardware failure.
>>>>
>>>
>>> Sorry.. I was replying to an earlier post and I missed the extra
>>> information
>>> that you posted about your mythbackend process consuming the memory,
>>> though
>>> I've never experienced myth 'eating' memory on this scale.
>>> I have seen many occasions when machines that have been working well
>>> suddenly become very unstable due to hardware faults. It's also possible
>>> for
>>> a "faulty-but-almost-always-unused" area of memory that may have been
>>> unused
>>> for some time to be brought into use due to something as simple as an
>>> additional application being started, and thus crash the machine.
>>> I still think it may be worth running some memory tests if you can -
>>> presumable you have vnc or something similar for remote access? Could you
>>> not keep the family happy by running your tests during a quiet spell?
>>> George

If you do not want to go through the effort of hooking up kvm, then I
would recommend running it under valgrind.  At least then you will
know if it is software related or not.

I assume you are running trunk builds?  If there was no change in
software to cause this behavior, it would be hard to not point the
finger at the hardware..?

-Greg