Opened 14 years ago

Closed 14 years ago

Last modified 14 years ago

#956 closed defect (fixed)

"Watch Recordings" screen segfault (QObject::disconnectInternal)

Reported by: torbjorn.jansson@… Owned by: danielk
Priority: minor Milestone: 0.19
Component: mythtv Version: head
Severity: medium Keywords:
Cc: Ticket locked: no

Description

I'm using a frontend (epia box) at rev 8513 and i've managed to get the "Watch Recordings" screen to segfault. This has happend many times.

The crash happends when i have finished watching a recording and quickly exit the "Watch Recording" screen. I have the setting turned on that gives you a menu when you exit playback (4 choices) if i choose to delete the recording and then select yes and exit the watch recording screen the same type of segfault happends.

The backtrace is from a coredump so it only contains one thread, but i hope it's enough to tell why it happend.

Attachments (1)

segfault.txt (15.2 KB) - added by torbjorn.jansson@… 14 years ago.
backtrace from a coredump

Download all attachments as: .zip

Change History (5)

Changed 14 years ago by torbjorn.jansson@…

Attachment: segfault.txt added

backtrace from a coredump

comment:1 Changed 14 years ago by Isaac Richards

Owner: changed from Isaac Richards to danielk

Thought this had been reported before - it's a bug in the preview generate thread code.

comment:2 Changed 14 years ago by danielk

Milestone: 0.19
Version: head

Different problem, the other preview segfault report (along with a few other segfault reports) were due to corrupted memory; I believe the memory gets corrupted in clear_xv_buffers() on some playback startup failure. There are two other candidates: one in MythPhone? and one in the locale library, but these are less likely to be causing preview and playback to segfault.

This looks like a missing null pointer check, I thikn it may be related to the recordings getting autoexpired.

comment:3 Changed 14 years ago by danielk

Resolution: fixed
Status: newclosed

(In [8529]) Fixes #956.

This should allow any previewgenerator instance to be disconnected from the playbackbox safely.

comment:4 Changed 14 years ago by danielk

(In [8717]) Fixes #1078. References #956.

The fix for #956 made the invalid assumption that shutting down the ~PlaybackBox?() should never take longer than 500 ms to finish. This was a zombie prevention measure. I've removed the timeout, and I've also implemented a deleteLater() function which cleans up some things early, and should give us snappier preview response.

Torbjorn, can you run with '-v playback' for a while, and then grep for "previewThreadDone took" in the logs, I'd like some info on how long this takes in the longest case on your system. On my system it never takes longer than 7 ms, which is why I thought a 500 ms timeout would be safe. Maybe I can use a 5 minute timeout or something like that..

Note: See TracTickets for help on using tickets.