Bug #5844
Invalid value in duration field of recording will crash TVH
100%
Description
Recently I recorded 6 programs which had the following entry in the log file:
"duration": 3746854690,
No problems arose subsequently until I restarted tvheadend. After that tvheadend would crash whenever a client with dvr access other than 'basic' or 'htsp' would connect.
Core dump showed:
#0 __GI_raise (sig=sig@entry=6) at ../sysdeps/unix/sysv/linux/raise.c:51
#1 0x74f9e824 in __GI_abort () at abort.c:89
#2 0x0055cbb4 in htsmsg_binary_write (
ptr=0x4 <error: Cannot access memory at address 0x4>,
ptr@entry=0x6ef006f7 "\003\004", msg=<optimized out>)
at src/htsmsg_binary.c:258
#3 0x0055cb68 in htsmsg_binary_write (ptr=0x6ef006f7 "\003\004",
ptr@entry=0x6ef006f1 "\001", msg=<optimized out>)
at src/htsmsg_binary.c:275
#4 0x0055cb68 in htsmsg_binary_write (ptr=0x6ef006f1 "\001",
ptr@entry=0x6ef0068e "\003\b", msg=<optimized out>)
at src/htsmsg_binary.c:275
#5 0x0055cb68 in htsmsg_binary_write (ptr=0x6ef0068e "\003\b",
ptr@entry=0x6ef00688 "\001", msg=<optimized out>)
at src/htsmsg_binary.c:275
#6 0x0055cb68 in htsmsg_binary_write (ptr=0x6ef00688 "\001",
ptr@entry=0x6ef00474 "\002\002", msg=<optimized out>)
at src/htsmsg_binary.c:275
#7 0x0055ccac in htsmsg_binary_serialize (msg=<optimized out>,
datap=datap@entry=0x644f0820, lenp=lenp@entry=0x644f0824,
maxlen=maxlen@entry=2147483647) at src/htsmsg_binary.c:324
#8 0x00551030 in htsp_write_scheduler (aux=0x64cf16a8)
at src/htsp_server.c:3226
#9 0x00528c28 in thread_wrapper (p=0x6e5008f8) at src/wrappers.c:159
#10 0x7514cfc4 in start_thread (arg=0x644f0ef0) at pthread_create.c:458
#11 0x75043038 in ?? () at ../sysdeps/unix/sysv/linux/arm/clone.S:76
from /lib/arm-linux-gnueabihf/libc.so.6
The problem was due to a HMF_DBL field being sent to htsmsg_binary_write(),
which results in an abort() as HMF_DBL is not handled by switch(f->hmf_type).
Ideally, TVH should not be writing values to files that will cause it to crash when read back.
I'm running 4.3 compiled locally. The problem was the same when I tried running 4.3-1857~g221c29b40~raspbianbuster_armhf.deb
Files
Subtasks
Related issues
History
Updated by Flole Systems over 4 years ago
- Has duplicate Bug #5902: TVH crash if htsp client (KODI) connects added
Updated by Flole Systems over 4 years ago
Have you tried adding HMF_DBL to switch(f->hmf_type) to see what happens then? If not, could you please give that a try to see if that is fixing the issue or if an invalid time is then sent out over HTSP.
Updated by Nihil Baxter over 4 years ago
Mmm, i don't know as its the same bug. For me restarting TVH is not a problem, even after installing new build it crashes. Duration entry is present in file, but seems to be ok.
Updated by Flole Systems over 4 years ago
Restarting after the recording was meant here, I think that is exactly what you see. What is the duration entry in the file that causes the crash for you? There must be one (or multiple) files that cause the crash while they are there, when moved away tvheadend should run normally.
Updated by Nihil Baxter over 4 years ago
I recorded a show yesterday, after that i restarted tvh and its ok. Did a restart just before 1 Minute to check that, connected with Kodi, no crash....
As i said, at least with every update (equal which build i install) i'm not able to use Kodi till i delete all logfiles. No prblem for first, as i'm on buster no and there is no new buster build since long time ;-)
Updated by Flole Systems over 4 years ago
Because the new recording wasn't long enough to be considered a HMF_DBL (double). The recording that is mentioned above has a duration of 1040792 hours (so it's most likely an incorrect entry). I am sure that you have the same issue, an incorrect duration entry that just breaks everything. There is no way to figure out how it ended up there now, but I am pretty sure that there are some more memory corruptions somewhere in the code that haven't been found yet.
Updated by Nihil Baxter over 4 years ago
Mmm...but i remember that i backuped my older logs and copied just one of them back after updating the app just to figure out there was an corrupt file. After that i restarted the server and boom, Kodi, crash... Did that with some other one after the other, but no luck. I had to delete them all, my autorecordings are set after each try, that works.
At least i did a complete new setup, scanned all channels, created all my recording profiles, but that didnt help. If i find time maybe i will try on one of my other devices and see if i can reproduce the crash.
Btw, strange thing.
Updated by Nihil Baxter over 4 years ago
Checked my dvr logs again, all recorded have same "duration": 1800," value inside, planned recordings don't have this value....
Updated by Flole Systems over 4 years ago
You need to check that when you have the crashes. It could also be any other field there that is corrupted (like starttime or endtime).
Updated by S Beimer over 4 years ago
I also have this problem, recording is simply unusable at the moment. I run linuxserver/tvheadend docker image with version 4.3.-1880-
I can share recording files from log directory if wanted.
Updated by S Beimer over 4 years ago
looking at the values start and stop is correct (both values, also with start_extra and stop_extra).
duration is 3600 what means 60 minutes? and is wrong as duration is 2h plus start_extra and stop_extra.
Updated by Flole Systems over 4 years ago
First of all a stacktrace is needed to verify that it's indeed the same issue.
Updated by Pablo Zerón over 4 years ago
Hi, here I attach a coredump and a gdb.txt, I don't know if it's ok, but I can try to get the files again if not.
https://drive.google.com/drive/folders/1ejp1yYAqUcRsuYe1hkwSdkP8UsdbOCZA?usp=sharing
Updated by Dave Pickles over 4 years ago
Here is a crash dump from a current GitHub master, together with the dvr log file which caused it - TVH crashes as soon as Kodi connects. The data being handled at the time of the crash is the 'size' parameter from the log file which was newly-added by commit 8d43c6600cf8fec2879a9d1f9633d7f70ba90bed on May 14th. Is it relevant that the size of this recording is over 4Gb?
Updated by Flole Systems over 4 years ago
Thanks, I think I see the issue now: The JSON Parser is not "designed" for int64_t but only for long, whenever the range of a long is exceeded it falls back to a double. A double is not defined in the binary protocol (which is "unexpected" and causes an abort then), so we need to adapt the json parser for int64_t and remove the long (it's no longer used then). If nobody else does it I might come up with a patch during the next few days.
Updated by Flole Systems over 4 years ago
My first attempt to fix this is at the Fix-Long Branch. It's entirely untested so I don't know if it will compile or not. If someone wants to give it a try please go ahead and report back, if not I will need to test it myself when I find some time.
Updated by Dave Pickles over 4 years ago
It compiled after I made a small change (which I've submitted a PR for). The crash when Kodi connects no longer occurs.