Opened 13 years ago
Closed 12 years ago
#5217 closed defect (invalid)
mythbackend segfault when call QMutexLocker with back to back recordings
Reported by: | Owned by: | Isaac Richards | |
---|---|---|---|
Priority: | minor | Milestone: | unknown |
Component: | mythtv | Version: | unknown |
Severity: | medium | Keywords: | |
Cc: | Ticket locked: | no |
Description
I have accidentally set EITCrawIdleStart to 1. This discovers a segfault with back to back recordings. The backend crash if it the active eit scanner thread starts direct after the first recording and call QMutexLocker lock(&stateChangeLock) from the TVRec::SetChannel? function. I don't know about QMutexLocker, so I don't now why it crashes when it try to lock. Maybe a simple solution where to prevent setting the EITCrawIdleStart value to a low value. I think the first crashes came with the multirec merge. The backtrace is from svn 16501.
Attachments (4)
Change History (8)
Changed 13 years ago by
Attachment: | mythbackend.log added |
---|
comment:1 Changed 12 years ago by
Status: | new → infoneeded_new |
---|
Changed 12 years ago by
Attachment: | mythbackend.2.log added |
---|
new logfile for mythbackend -v record,channel,siparser
comment:2 Changed 12 years ago by
Added fresh backtrace and log from release-0-21-fixes revision 19763. Mythtv crashed after about 3 hours continuous back to back recording.
comment:3 Changed 12 years ago by
This backtrace appears to be in the preview generation code, which should not (AFAIK) take down the backend, since it's in a separate process. Is this repeatable?
comment:4 Changed 12 years ago by
Resolution: | → invalid |
---|---|
Status: | infoneeded_new → closed |
info requested but not provided
We're going to need a "mythbackend -v record,channel,siparser' log, and a fresh backtrace. You are getting a segfault because the channel instance pointer is null when SetChannel?() is called, that should not happen..