Bug #4093
Crash with ATSC OTA EPG assertion error
0%
Description
Hello,
I have been seeing the following error on my Synology (88f6281) with Tvheadend 4.1.2309
tvheadend: src/epggrab/module/psip.c:78: psip_status_destroy: Assertion `st->ps_refcount > 0' failed.
And, here are some background information:
- This doesn't seem to be a new bug. It has been happening since I switched EPG source from XMLTV to PSIP few months ago.
- "Over-the-air: PSIP: ATSC Grabber" is the only enabled EPG Grabber in my setting.
- This error happens only when auto-recording same title programs back to back. But, auto-recording back to back same name program doesn't always cause this error.
- This error happens soon after the recording of the same name program starts.
- There is no warning or error message before this assertion error.
I don't know if they are related to this error, but I'm seeing following EPG related problems, too:
- Occasionally, autorec records a program with completely different name (which doesn't match the regular expression). My autorec settings have empty channel and channel tag, but the wrong recordings are made from the channel where the intended program was broadcasted.
- It's very rare, but multiple recordings happen at the same time with one autorec.
Please let me know if there is anything I can help to root cause this problem.
Thanks,
Susumu Arai
Files
History
Updated by Susumu Arai almost 8 years ago
Updated by - File tvheadend.gz tvheadend.gz added
- File tvheadend.core.gz tvheadend.core.gz added
- File tvh-1219-1659.log.gz tvh-1219-1659.log.gz added
To gather some more information, I reproduced the same failure on an x86_64 Ubuntu PC. Here's the stack trace at the assertion error:
#0 0x00007fa576ff8428 in __GI_raise (sig=sig@entry=6) at ../sysdeps/unix/sysv/linux/raise.c:54
#1 0x00007fa576ffa187 in __GI_abort () at abort.c:118
#2 0x00007fa576ff0bd7 in __assert_fail_base (fmt=<optimized out>,
assertion=assertion@entry=0x562a080c26a3 "st->ps_refcount > 0",
file=file@entry=0x562a080c2630 "src/epggrab/module/psip.c", line=line@entry=78,
function=function@entry=0x562a080c29b0 <__PRETTY_FUNCTION__.11848> "psip_status_destroy")
at assert.c:92
#3 0x00007fa576ff0c82 in __GI___assert_fail (
assertion=assertion@entry=0x562a080c26a3 "st->ps_refcount > 0",
file=file@entry=0x562a080c2630 "src/epggrab/module/psip.c", line=line@entry=78,
function=function@entry=0x562a080c29b0 <__PRETTY_FUNCTION__.11848> "psip_status_destroy")
at assert.c:101
#4 0x0000562a07466823 in psip_status_destroy (mt=0x562a0a26c790) at src/epggrab/module/psip.c:78
#5 0x0000562a0744b16b in mpegts_table_release_ (mt=mt@entry=0x562a0a26c790)
at src/input/mpegts/mpegts_table.c:128
#6 0x0000562a0744b2a7 in mpegts_table_release (mt=0x562a0a26c790)
at /home/sarai/src/tvheadend/src/input/mpegts.h:1034
#7 mpegts_table_destroy_ (mt=mt@entry=0x562a09f89a70) at src/input/mpegts/mpegts_table.c:151
#8 0x0000562a0744b331 in mpegts_table_destroy (mt=0x562a09f89a70)
at src/input/mpegts/mpegts_table.c:161
#9 0x0000562a074649a9 in psip_update_table (type=<optimized out>, pid=4097, ps=<optimized out>)
at src/epggrab/module/psip.c:128
#10 _psip_mgt_callback (mt=0x562a0a1fa4b0,
ptr=0x562a0a1fa5b2 "\001\v\360", <incomplete sequence \371>, len=<optimized out>,
tableid=<optimized out>) at src/epggrab/module/psip.c:687
#11 0x0000562a0744afd8 in mpegts_table_dispatch (sec=<optimized out>, r=<optimized out>,
aux=0x562a0a1fa4b0) at src/input/mpegts/mpegts_table.c:108
#12 0x0000562a0744358d in mpegts_psi_section_reassemble0 (mt=mt@entry=0x562a0a1fa4b0,
logpref=logpref@entry=0x7fa54fffea20 "207.028MHz in ATSC-T Network",
data=data@entry=0x7fa548002824 <incomplete sequence \367>, len=len@entry=184,
start=<optimized out>, crc=crc@entry=1, cb=0x562a0744af40 <mpegts_table_dispatch>,
opaque=0x562a0a1fa4b0) at src/input/mpegts/dvb_psi_lib.c:122
#13 0x0000562a074437e1 in mpegts_psi_section_reassemble (mt=mt@entry=0x562a0a1fa4b0,
logprefix=logprefix@entry=0x7fa54fffea20 "207.028MHz in ATSC-T Network",
tsb=tsb@entry=0x7fa548002820 "G\037\373", <incomplete sequence \367>, crc=1,
cb=0x562a0744af40 <mpegts_table_dispatch>, opaque=opaque@entry=0x562a0a1fa4b0)
at src/input/mpegts/dvb_psi_lib.c:169
#14 0x0000562a0743d6a9 in mpegts_input_table_dispatch (mm=mm@entry=0x562a09f89880,
logprefix=logprefix@entry=0x7fa54fffea20 "207.028MHz in ATSC-T Network",
tsb=tsb@entry=0x7fa548002820 "G\037\373", <incomplete sequence \367>, tsb_len=188)
at src/input/mpegts/mpegts_input.c:1185
#15 0x0000562a0743d8ad in mpegts_input_table_thread (aux=0x7fa568004470)
at src/input/mpegts/mpegts_input.c:1576
#16 0x0000562a073994c5 in thread_wrapper (p=0x562a0a03a440) at src/wrappers.c:159
#17 0x00007fa577c266ba in start_thread (arg=0x7fa54ffff700) at pthread_create.c:333
#18 0x00007fa5770c982d in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:109
Also attached following files:
- tvheadend.gz : x86_64 Ubuntu executable I built from source (unstripped)
- tvheadend.core.gz : Core dump file
- tvh-1219-1659.log.gz : Trace/debug output with EPG related output enabled.
For now, this crash happens everyday and it's easy for me to capture additional data if you need. Please let me know if you have any question.
Updated by
Updated by Susumu Arai almost 8 years ago
Tried your change and it seems working fine.
At least it didn't crash during today's back-to-back same name program recording.
Thanks
Updated by Jaroslav Kysela almost 8 years ago
- Status changed from New to Fixed
Fixed in v4.1-2398-gc38af4c .