Opened 18 years ago

Closed 17 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 18 years ago.
mythbackend.log (1.4 KB ) - added by Wolfgang <mthtv@…> 18 years ago.
gdb.2.txt (85.4 KB ) - added by Wolfgang <mythtv@…> 17 years ago.
new backtrace
mythbackend.2.log (5.0 KB ) - added by Wolfgang <mythtv@…> 17 years ago.
new logfile for mythbackend -v record,channel,siparser

Download all attachments as: .zip

Change History (8)

by anonymous, 18 years ago

Attachment: gdb.txt added

by Wolfgang <mthtv@…>, 18 years ago

Attachment: mythbackend.log added

comment:1 by danielk, 17 years ago

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

by Wolfgang <mythtv@…>, 17 years ago

Attachment: gdb.2.txt added

new backtrace

by Wolfgang <mythtv@…>, 17 years ago

Attachment: mythbackend.2.log added

new logfile for mythbackend -v record,channel,siparser

comment:2 by Wolfgang <mythtv@…>, 17 years ago

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

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

Resolution: invalid
Status: infoneeded_newclosed

info requested but not provided

Note: See TracTickets for help on using tickets.