mark at digivation
Jan 25, 2010, 4:28 PM
Post #3 of 4
(960 views)
Permalink
|
On 11/17/2009 12:32 AM, Daniel Kristjansson wrote:
> On Mon, 2009-11-16 at 21:16 +1100, Mark Spieth wrote:
>
>> Ive just seen this.
>>
>> 2009-11-16 20:00:29.883 Scheduler: Update next_record for 17202
>> 2009-11-16 20:00:29.896 ERROR: Master backend tried to connect back to
>> itself!
>>
>> after which a restart watchdog kicked in.
>>
>> any suggestions where to look?
>>
> Add an assert(false); right after the "ERROR: .. " message so we
> can locate and remove the offending code. :)
>
> (Compile with debugging and either under gdb or with coredumps
> enabled so that you can get a good backtrace.)
>
ok Ive finally got a useful backtrace. attached.
symptom is that the backend stops responding.
search for
"this=0xa7ba90|mtx = 0xa7bb5[89]"
4 threads want this lock. the one that has it is the TVRec::RunTV
TVRec::StartRecording thread which should be ok
Expirer thread
and HttpStatus request handling thread.
it appears as though the RunTV thread is wating for hwlock but cant get
it which means one of the other threads may be holding it.
I suspect DVBChannel hwlock should be inited as QMutex::Recursive
that should fix this.
will test but it doesn't happen often so feedback will take a while.
mark
|
gcore.log.1264390476.gz
