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

[torbjorn.jansson@…]

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.

[torbjorn.jansson@…]

backtrace from a coredump

[Isaac Richards]

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

[danielk]

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.

[danielk]

(In [8529]) Fixes #956.

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

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