Project

General

Profile

Bug #4684

tvh crashes on certain dvr-filenames

Added by ullix tv about 4 years ago. Updated about 4 years ago.

Status:
New
Priority:
Normal
Assignee:
-
Category:
Crashes
Target version:
-
Start date:
2017-10-24
Due date:
% Done:

0%

Estimated time:
Found in version:
4.3-516~gd7d83b6 (2017-10-02T21:12:15+0000)
Affected Versions:

Description

In playing with the recordings-database files under */dvr/log/ I came across this issue resulting in tvheadend crashing, while I think it should be doing no more than ignoring the problem.

Example: filename "49bf21b031017e849621ef5f30dba0f6" represents one original recording, created by tvh. I copied this file into the same directory (with same owner, group, permission) with the filename renamed at the last "6" to a "7". This resulted in a crash; from syslog (more in attached file):

 idnode: Id node collission (49bf21b031017e849621ef5f30dba0f6)  (short)
 CRASH: Signal: 6 in PRG: /usr/bin/tvheadend (4.3-516~gd7d83b6) [aad0af1eb9505b6ec4578b2cb7f7b7a1e99647a6] CWD: /
 CRASH: Fault address 0x7d000029ef (N/A)

The same crash results when the filename is modified with an "a" instead of "7". But it does NOT crash with an "x", though the Finished Recordings list on the web interface still don't show this extra recording.

Whatever the reason (checksum?), tvh should not crash.


Files

syslog-tvh-crash (2.15 KB) syslog-tvh-crash syslog section with crash info ullix tv, 2017-10-24 13:17

History

#1

Updated by Em Smith about 4 years ago

The log says it terminating with Signal 6. A "kill -l" shows that 6 is SIGABRT, i.e., the programmer is aborting the program due to constraint violations.

So Tvheadend has correctly detected someone incorrectly modifying files, determined that it has no means of detecting which recordings are valid or invalid, and correctly aborting to prevent any corruption. It has no means to continue, it has to exit. It aborts so that it can be diagnosed.

It's relatively common practice that when something is fundamentally wrong to abort due to save the user from further problems.

#2

Updated by Jaroslav Kysela about 4 years ago

The file name (id) must be persistent in the whole tree. For short (32-bit) ids (used for some historic reasons) the last eight hexa numbers must differ. So try to find duplicate files with the '*30dba0f6' pattern. Every injection directly to the maintained directory tree is problematic. We have (or should have) a HTTP API for the data/entry handling,

#3

Updated by ullix tv about 4 years ago

I see 2 issues here:

#1: A strict filename requirement is ok, but must this be handled by crashing the program? If - for whatever reason - it cannot be simply ignored, then an exit with an error message would be nice.

#2: An API would be a whole lot nicer! Can you provide info or direct me to the info? I want to add a video file on the local file system to the list of files known to tvh.

Also available in: Atom PDF