[mythtv-commits] Ticket #12709: Segmentation fault playing a recording with file missing
MythTV
noreply at mythtv.org
Thu Apr 7 01:22:42 UTC 2016
#12709: Segmentation fault playing a recording with file missing
-----------------------------------------+-----------------------------
Reporter: Peter Bennett <pgbennett@…> | Owner: jyavenard
Type: Bug Report - Crash | Status: new
Priority: minor | Milestone: 0.28
Component: MythTV - Video Playback | Version: Master Head
Severity: medium | Resolution:
Keywords: | Ticket locked: 0
-----------------------------------------+-----------------------------
Comment (by knight):
Hi Roger!
Replying to [comment:2 rsiddons]:
> The video player (mythfrontend::main::internal_play_media()) plays video
from any source. For instance Gallery uses it for camera videos and
!MythBrowser and !SetupWizard use it for downloaded videos. So it has to
fail in a generic/independent way.
>
> "Try it and handle failure" is a more robust strategy than "Check first,
do it and handle unexpected failure" (file disappears between check and
play ?). It also avoids having to retrieve a remote file twice.
Assuming I correctly understood what you said I do not fully agree with
this...
The null pointer check should be there regardless but it sounds to me like
it is a null pointer because the file is missing so we already know before
we reach that point that something is wrong.
Why should we rely on a side effect of protecting our code against coding
errors and the like to handle something which should be handle long before
starting to initialize the UI.
I have not tried Peter's patch but unless you tell me that with it in
place the user is told what is actually wrong I do not consider that only
handling the null pointer at this point is a good solution. From a
programmer standpoint we "handled" the problem and did not crash but it
would not be very user friendly.
If we want it to fail in a generic/independent way maybe we should
actually remove all the code that does file handling from all of this
function/method client's and (Gallery, MythBrowser, etc...), make it
common and make it handle all of the possible failures this should
encounter.
Yes, we should protect our code against using null pointers but this
should not be the only thing we do to handle those kind of errors...
I am very far from a C++ guru but in the languages I do program in I both
program my code against using null pointers (even if it supposed to have
been taken care of earlier) and try to catch the error as soon as we know
it exists...
We are way too close to release to do little more than what Peter put in
place however so this solution so Peter's current forthcoming solution
will have to do...
Have a nice day!
Nicolas
--
Ticket URL: <https://code.mythtv.org/trac/ticket/12709#comment:7>
MythTV <http://www.mythtv.org>
MythTV Media Center
More information about the mythtv-commits
mailing list