Opened 12 years ago

Closed 11 years ago

#5217 closed defect (invalid)

mythbackend segfault when call QMutexLocker with back to back recordings

Reported by: Wolfgang <mythtv@…> 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)

gdb.txt (49.6 KB) - added by anonymous 12 years ago.
mythbackend.log (1.4 KB) - added by Wolfgang <mthtv@…> 12 years ago.
gdb.2.txt (85.4 KB) - added by Wolfgang <mythtv@…> 11 years ago.
new backtrace
mythbackend.2.log (5.0 KB) - added by Wolfgang <mythtv@…> 11 years ago.
new logfile for mythbackend -v record,channel,siparser

Download all attachments as: .zip

Change History (8)

Changed 12 years ago by anonymous

Attachment: gdb.txt added

Changed 12 years ago by Wolfgang <mthtv@…>

Attachment: mythbackend.log added

comment:1 Changed 11 years ago by danielk

Status: newinfoneeded_new

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..

Changed 11 years ago by Wolfgang <mythtv@…>

Attachment: gdb.2.txt added

new backtrace

Changed 11 years ago by Wolfgang <mythtv@…>

Attachment: mythbackend.2.log added

new logfile for mythbackend -v record,channel,siparser

comment:2 Changed 11 years ago by Wolfgang <mythtv@…>

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 11 years ago by Dibblah

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 11 years ago by danielk

Resolution: invalid
Status: infoneeded_newclosed

info requested but not provided

Note: See TracTickets for help on using tickets.