Project

General

Profile

Bug #3173

Connection from Kodi tvheadend PVR client crashes Tvheadend

Added by Adrian Strilchuk about 9 years ago. Updated about 9 years ago.

Status:
New
Priority:
Normal
Assignee:
-
Category:
HTSP
Target version:
-
Start date:
2015-10-19
Due date:
% Done:

0%

Estimated time:
Found in version:
4.1-658~g1ca4f29
Affected Versions:

Description

When Kodi connects to tvheadend running on a Raspberry Pi the tvheadend process crashes. This started happening when I upgraded from tvheadend_4.1-540~g93f1b2b to tvheadend_4.1-639~gd7456e7. I've since upgraded to 4.1-658~g1ca4f29 without success.

I've tried Kodi 15.1 on Mac OS X and Openelec Kodi 14.X on a Raspberry Pi with the same result.

I have attached the gdb and tvheadend logs.

Please let me know if I can provide any more information.

Adrian


Files

gdb.txt (9.28 KB) gdb.txt Adrian Strilchuk, 2015-10-19 18:51
tvheadend.log (19.3 KB) tvheadend.log Adrian Strilchuk, 2015-10-19 18:51

History

#1

Updated by Adrian Strilchuk about 9 years ago

I think I've found the culprit. I found the dvr log file shown below. Note under files>info>duration>4294967290

This value is large enough for an uint but obviously not int. If I change this value to max(int) -1, tvheadend no longer crashes on a kodi client connection. I'm not aware of how the value '4294967290' was determined. I noticed that in service.h, elementary_stream_t, es_frame_duration is defined as int. I haven't located where in the source the dvr log files are written or read yet.

{
"enabled": true,
"start": 1444089600,
"start_extra": 0,
"stop": 1444091460,
"stop_extra": 0,
"channel": "6f18478f3714429601472ceeacb2d97a",
"channelname": "57.1 CITYDT",
"title": {
"eng": "The Muppets"
},
"subtitle": {
"eng": "Bear Left Then Bear Write"
},
"description": {
"eng": "\"Bear Left Then Bear Write\" (Series; New; S1E3; TVPG) Nick Offerman assists the gang; Christina Applegate brings Miss Piggy a surprise; Liam Hemsworth, Pepe and Rizzo help Gonzo with online dating."
},
"pri": 2,
"retention": 0,
"container": -1,
"config_name": "669bf494d2f30c2ab63089612c1ac234",
"creator": "192.168.1.209",
"errorcode": 0,
"errors": 0,
"data_errors": 0,
"dvb_eid": 0,
"noresched": false,
"autorec": "bac30d52f186945cf8419462a5947394",
"timerec": "",
"content_type": 0,
"broadcast": 243368,
"episode": "Season 1.Episode 3",
"comment": "Auto recording: Created from EPG query",
"files": [ {
"filename": "/data/recordings/The Muppets/The Muppets-.S01E03.ts",
"info": [ {
"type": "H264",
"width": 16,
"height": 32,
"duration": 4294967290,
"aspect_num": 0,
"aspect_den": 0
}, {
"type": "AC3",
"language": "eng",
"audio_type": 0
}
]
}
]
}

#2

Updated by Jaroslav Kysela about 9 years ago

Could you provide trace using tvh binary with the debugging symbols ?

#3

Updated by Adrian Strilchuk about 9 years ago

When I do the back trace I just get this (gdb --args ~/src/tvheadend/build.linux/tvheadend -c ~/test-conf -d):

#0 0x76b8b8dc in raise () from /lib/arm-linux-gnueabihf/libc.so.6
No symbol table info available.
#1 0x76b8f65c in abort () from /lib/arm-linux-gnueabihf/libc.so.6
No symbol table info available.
#2 0x0000b624 in ?? ()
No symbol table info available.
#3 0x0000b624 in ?? ()
No symbol table info available.
Backtrace stopped: previous frame identical to this frame (corrupt stack?)

Am I doing something wrong?

#4

Updated by Adrian Strilchuk about 9 years ago

I managed to get this trace from gdb:

#0 0x76b8b8dc in __GI_raise (sig=6) at ../nptl/sysdeps/unix/sysv/linux/raise.c:67
#1 0x76b8f65c in __GI_abort () at abort.c:92
#2 0x00040f6c in htsmsg_binary_write (msg=<optimized out>, ptr=0x286a12 "") at src/htsmsg_binary.c:220
#3 0x00040fac in htsmsg_binary_write (msg=<optimized out>, ptr=0x2869e9 "\003\004") at src/htsmsg_binary.c:237
#4 0x00040fac in htsmsg_binary_write (msg=<optimized out>, ptr=0x2869e3 "\001") at src/htsmsg_binary.c:237
#5 0x00040fac in htsmsg_binary_write (msg=<optimized out>, ptr=0x2869a8 "\003\b") at src/htsmsg_binary.c:237
#6 0x00040fac in htsmsg_binary_write (msg=<optimized out>, ptr=0x2869a2 "\001") at src/htsmsg_binary.c:237
#7 0x00041290 in htsmsg_binary_serialize (msg=0x261ce8, datap=0x687fea40, lenp=0x687fea44, maxlen=<optimized out>;) at src/htsmsg_binary.c:281
#8 0x00038748 in htsp_write_scheduler (aux=0x697fe8a0) at src/htsp_server.c:2876
#9 0x0001b7e0 in thread_wrapper (p=0x27c018) at src/wrappers.c:177
#10 0x76d3dc00 in start_thread (arg=0x687ff180) at pthread_create.c:306
#11 0x76c2a728 in ?? () at ../ports/sysdeps/unix/sysv/linux/arm/nptl/../clone.S:116 from /lib/arm-linux-gnueabihf/libc.so.6
#12 0x76c2a728 in ?? () at ../ports/sysdeps/unix/sysv/linux/arm/nptl/../clone.S:116 from /lib/arm-linux-gnueabihf/libc.so.6
Backtrace stopped: previous frame identical to this frame (corrupt stack?)

#5

Updated by Jaroslav Kysela about 9 years ago

Fine. Could you put breakpoint to fcn htsmsg_binary_write() , line 220 - abort() call and inspect structure *f ?

#6

Updated by Adrian Strilchuk about 9 years ago

Breakpoint 1, htsmsg_binary_write (msg=<optimized out>,
ptr=0x27ae8a "53A26%255Eo%25253Aid%25253Dn%2525253A10%25255Ewidth%25253Dn%2525253A26%255Eo%25253Aid%25253Dn%2525253A11%25255Ewidth%25253Dn%2525253A102%255Eo%25253Aid%25253Dn%2525253A12%25255Ewidth%25253Dn%2525253A1"...) at src/htsmsg_binary.c:220
220 abort();
(gdb) print *f
$1 = {hmf_link = {tqe_next = 0x69e0a6d8, tqe_prev = 0x69e0a668}, hmf_name = 0x69e0a6c8 "duration", hmf_type = 6 '\006', hmf_flags = 2 '\002',
u = {s64 = 4751297606863290368, str = 0xff400000 <Address 0xff400000 out of bounds>, bin = {
data = 0xff400000 <Address 0xff400000 out of bounds>, len = 1106247679}, msg = {hm_fields = {tqh_first = 0xff400000,
tqh_last = 0x41efffff}, hm_islist = 0, hm_data = 0x0}, dbl = 4294967290, bool = -12582912}}

Also available in: Atom PDF