Opened 12 years ago
Closed 12 years ago
Last modified 11 years ago
#10970 closed Bug Report - General (fixed)
Mythbackend failed recordings, deadlocks
Reported by: | Owned by: | ||
---|---|---|---|
Priority: | minor | Milestone: | 0.26 |
Component: | MythTV - General | Version: | Master Head |
Severity: | medium | Keywords: | |
Cc: | Ticket locked: | no |
Description
In the last week or so, my backend has been getting into a state where all recordings fail to start. Killing mythbackend and running it again makes things record again for a day or two.
This afternoon two recordings failed to start and mythbackend stopped responding through mythweb or the internal webserver.
I followed the instructions on the wiki for attaching gdb and generating a backtrace. Let me know what other information I can provide.
Running version v0.26-alpha-79-gb379de3. Possibly related to #10870.
Attachments (3)
Change History (10)
Changed 12 years ago by
Attachment: | mythbackend.tar.bz2 added |
---|
comment:1 Changed 12 years ago by
Status: | new → infoneeded_new |
---|
What is your "ulimit -u" output ?
Also, what is the output of "cat /proc/sys/vm/overcommit_memory" ?
comment:3 Changed 12 years ago by
As far as I can tell this shouldn't be happening.
StreamHandler::Start() seems to be waiting for the thread to start. It's waiting for either _running or _error to be set. I don't see any way that DVBStreamHandler::run() can exit without setting either of those. It also seems like DVBStreamHandler::RunTS() is running a piece of code that would only be run after setting _running to true, however that could be in service of another stream. It is possible that MTHread::start() has called QThread::start(), but the thread was never started because we ran out of memory or we exceeded our process allocation. However, that shouldn't occur with any normally configured Linux system. Finally, while _running is not declared as volatile, the while loop that checks it calls a function outside the current translation unit so gcc should not optimise the check away since it can't know that _running isn't set by that call.
comment:5 Changed 12 years ago by
Owner: | set to Daniel Kristjansson <danielk@…> |
---|---|
Resolution: | → fixed |
Status: | infoneeded_new → closed |
comment:6 Changed 12 years ago by
Milestone: | unknown → 0.26 |
---|
Backend log