Project

General

Profile

Bug #4107

Segfaults

Added by Morbid Angel almost 8 years ago. Updated almost 8 years ago.

Status:
Fixed
Priority:
Normal
Assignee:
-
Category:
Crashes
Target version:
-
Start date:
2016-12-04
Due date:
% Done:

100%

Estimated time:
(Total: 0.00 h)
Found in version:
4.1.2346
Affected Versions:

Description

I see several times a day in dmesg these messages:

[469749.391140] tvh:mi-table1597: segfault at 140 ip 00007ff6775e134e sp 00007ff64b7f4968 error 4 in tvheadend[7ff677477000+be4000]

mostly does tvheadend continue to work after this, but sometimes I need to kill it with kill -9 (start script doesnt work)

this is how I have build it:

Configure arguments:
--build=x86_64-redhat-linux-gnu --host=x86_64-redhat-linux-gnu --program-prefix= --disable-dependency-tracking --prefix=/usr --exec-prefix=/usr --bindir=/usr/bin --sbindir=/usr/sbin --sysconfdir=/etc --datadir=/usr/share --includedir=/usr/include --libdir=/usr/lib64 --libexecdir=/usr/libexec --localstatedir=/var --sharedstatedir=/var/lib --mandir=/usr/share/man --infodir=/usr/share/info --disable-lockowner --enable-bundle --disable-ffmpeg_static --disable-hdhomerun_static

Compiler:
Using C compiler: ccache cc
Using C flags: -O2 -g -pipe -Wall -Wp,-D_FORTIFY_SOURCE=2 -fexceptions -fstack-protector-strong --param=ssp-buffer-size=4 -grecord-gcc-switches -m64 -mtune=generic
Using LD flags: -Wl,-z,relro
Build for arch: x86_64

Binaries:
Using PYTHON: python
Using GZIP: gzip
Using BZIP2: bzip2

Options:
pie yes
ccdebug no
cwc yes
capmt yes
constcw yes
linuxdvb yes
satip_server yes
satip_client yes
hdhomerun_client no
hdhomerun_static no
iptv yes
tsfile yes
dvbscan yes
timeshift yes
trace yes
imagecache yes
avahi yes
zlib yes
libav yes
ffmpeg_static no
libx264 yes
libx264_static yes
libx265 yes
libx265_static yes
libvpx yes
libvpx_static yes
libtheora yes
libtheora_static yes
libvorbis yes
libvorbis_static yes
libfdkaac yes
libfdkaac_static yes
nvenc no
qsv no
libmfx_static yes
inotify yes
epoll yes
uriparser yes
ccache yes
tvhcsa yes
bundle yes
dvbcsa no
dvben50221 no
kqueue no
dbus_1 yes
android no
tsdebug no
gtimer_check no
slow_memoryinfo no
libsystemd_daemon no
bintray_cache yes
execinfo yes
mmx yes
sse2 yes
W_unused_result yes
getloadavg yes
atomic64 yes
atomic_time_t yes
bitops64 yes
lockowner yes
qsort_r yes
stime yes
gmtoff yes
recvmmsg yes
sendmmsg yes
ifnames yes
py_gzip yes
bin_pkg_config yes
bin_xgettext yes
bin_msgmerge yes
bin_gzip yes
bin_bzip2 yes
ssl yes
linuxdvbapi yes
upnp yes
inotify_h yes
mpegts yes
mpegts_dvb yes

Packages:
openssl 1.0.1e
zlib 1.2.7
liburiparser 0.7.5
avahi-client 0.6.31
libavfilter 6.31.100
libswresample 2.0.101
libavresample 3.0.0
libswscale 4.0.100
libavformat 57.25.100
libavcodec 57.24.102
libavutil 55.17.103
dbus-1 1.6.12

Installation paths:
Prefix: /usr
Binaries: /usr/bin
Libraries: /usr/lib64
Data files: /usr/share
Man pages: /usr/share/man

Files

gdb.txt (9.77 KB) gdb.txt C K, 2016-12-04 10:11
gdb.txt (11.2 KB) gdb.txt frame 2 and print *ebc C K, 2016-12-04 13:13
gdb.txt (18.5 KB) gdb.txt C K, 2016-12-05 02:10

Subtasks

Bug #4115: Crash in lang_code_split2 Rejected

Actions

History

#2

Updated by Morbid Angel almost 8 years ago

have started tvh with:

/usr/bin/tvheadend -f -p /var/run/tvheadend.pid -c /etc/tvheadend -u tvheadend -g tvheadend -6 --http_port 9981 --htsp_port 9982 -l /var/log/tvheadend/tvheadend.log -D -A

but dont see the cordump in /tmp/

what can be the problem?

#3

Updated by Hanspeter Müller almost 8 years ago

Jaroslav Kysela wrote:

I need a backtrace: https://tvheadend.org/projects/tvheadend/wiki/Debugging

Ubuntu 16.04 processes the crashes and stores them under /var/crashes as textfiles, with a CoreDump in base64. Is this helpfull in any way, or does someone know how to get rid of it? Is this the apport-stuff...?

#4

Updated by Mark Clarkstone almost 8 years ago

Hanspeter Müller wrote:

Jaroslav Kysela wrote:

I need a backtrace: https://tvheadend.org/projects/tvheadend/wiki/Debugging

Ubuntu 16.04 processes the crashes and stores them under /var/crashes as textfiles, with a CoreDump in base64. Is this helpfull in any way, or does someone know how to get rid of it? Is this the apport-stuff...?

Install corekeeper..

#5

Updated by Morbid Angel almost 8 years ago

ok it works now with coredump (centos)

now Im waiting for a crash

#6

Updated by Morbid Angel almost 8 years ago

so here the backtrace:

#0 bin2hex (dst=0x7fcd717f89b1 "\001", dst@entry=0x7fcd717f89b0 "\236\001", dstlen=dstlen@entry=33, src=0x140 <Address 0x140 out of bounds>, srclen=srclen@entry=16) at src/uuid.c:83
No locals.
#1 0x00007fcd9b933e59 in idnode_uuid_as_str (in=<optimized out>, uuid=uuid@entry=0x7fcd717f89b0 "\236\001") at src/idnode.c:227
No locals.
#2 0x00007fcd9b94e1d4 in epg_episode_find_by_broadcast (ebc=ebc@entry=0x7fcd9df1b8b0, src=src@entry=0x7fcd9dd44230, create=create@entry=1, save=save@entry=0x7fcd717f9480, changed=changed@entry=0x7fcd717f8b2c) at src/epg.c:956
uri = " \000\000\000\000\000\000\000\300\177\346\243\000\000\000\000\200\224\177q\315\177\000\000\060\324z\243\315\177\000\000P\263\357\241\315\177\000\000\260\270\361\235\315\177\000\000\000\000\000\000\000\000\000\000\022딢\315\177\000\000\200\224\177q\315\177\000\000mݗ\233\315\177\000\000\260\270", <incomplete sequence \361>
ubuf = "\236\001\000\000\000\000\000\000\272j)\227\315\177\000\000P\263\357\241\315\177\000\000\360\327z\243\315\177\000\000P"
#3 0x00007fcd9ba076bd in eit_process_event_one (mod=mod@entry=0x7fcd9dd44230, tableid=tableid@entry=96, sect=sect@entry=8, svc=svc@entry=0x7fcd9f6cf650, ch=<optimized out>, ptr=<optimized out>, ptr@entry=0x7fcda294e87b "]\222\341}\004 ", len=1854, len@entry=1866, local=local@entry=0, resched=resched@entry=0x7fcd717f9484, save=save@entry=0x7fcd717f9480) at src/epggrab/module/eit.c:536
dllen = <optimized out>
save2 = 1
start = <optimized out>
stop = <optimized out>
eid = 23954
dtag = <optimized out>
dlen = <optimized out>
running = 0 '\000'
ebc = 0x7fcd9df1b8b0
ee = 0x0
es = <optimized out>
run = <optimized out>
ev = {uri = '\000' <repeats 256 times>, suri = '\000' <repeats 256 times>, title = 0x7fcd9de135a0, summary = 0x7fcda2dbc3d0, desc = 0x7fcda284bbb0, default_charset = 0x0, extra = 0x0, genre = 0x0, hd = 0 '\000', ws = 0 '\000', ad = 0 '\000', st = 0 '\000', ds = 0 '\000', bw = 0 '\000', parental = 0 '\000'}
changes2 = 1849
changes3 = 0
changes4 = 0
tm1 = "n-\257\233\315\177\000\000\260\223\177q\315\177\000\000\001\000\000\000\000\000\000\000\367\003\000\000\000\000\000"
tm2 = "h\217\177q\315\177\000\000%\276\061\227\315\177\000\000\001\200\255\373\000\000\000\000h\217\177q\315\177\000"
#4 0x00007fcd9ba085e8 in _eit_process_event (save=0x7fcd717f9480, resched=0x7fcd717f9484, local=0, len=1866, ptr=0x7fcda294e87b "]\222\341}\004 ", svc=<optimized out>, sect=8, tableid=96, mod=0x7fcd9dd44230) at src/epggrab/module/eit.c:600
ilm = 0x7fcd9df05a50
ch = <optimized out>
#5 _eit_callback (mt=0x7fcda294e0e0, ptr=0x7fcda294e87b "]\222\341}\004 ", len=1866, tableid=96) at src/epggrab/module/eit.c:724
r = <optimized out>
sect = 8
last = 56
ver = 4
save = 1
resched = 0
seg = <optimized out>
onid = <optimized out>
tsid = 12800
sid = <optimized out>
extraid = <optimized out>
svc = <optimized out>
mm = <optimized out>
map = <optimized out>
mod = 0x7fcd9dd44230
ota = 0x0
st = 0x7fcda2fbe8d0
ths = <optimized out>
ubuf = "c5d33791128fc37711c754e77bf234f1"
#6 0x00007fcd9b9ee978 in mpegts_table_dispatch (sec=<optimized out>, r=<optimized out>, aux=0x7fcda294e0e0) at src/input/mpegts/mpegts_table.c:105
tid = <optimized out>
len = <optimized out>
crc_len = <optimized out>
ret = <optimized out>
mt = 0x7fcda294e0e0
#7 0x00007fcd9b9e6ff6 in mpegts_psi_section_reassemble0 (mt=mt@entry=0x7fcda294e0e0, logpref=logpref@entry=0x7fcd717f9880 "10834V in Hotbird", data=data@entry=0x7fcd741e9880 "otuje kolejne misje.T\002Q\220U\004POL", len=len@entry=184, start=<optimized out>, crc=crc@entry=1, cb=cb@entry=0x7fcd9b9ee8e0 <mpegts_table_dispatch>, opaque=opaque@entry=0x7fcda294e0e0) at src/input/mpegts/dvb_psi_lib.c:122
p = 0x7fcda294e148 "`\376~"
excess = 150
tsize = <optimized out>
#8 0x00007fcd9b9e722e in mpegts_psi_section_reassemble (mt=mt@entry=0x7fcda294e0e0, logprefix=logprefix@entry=0x7fcd717f9880 "10834V in Hotbird", tsb=tsb@entry=0x7fcd741e987c "G", crc=1, cb=0x7fcd9b9ee8e0 <mpegts_table_dispatch>, opaque=opaque@entry=0x7fcda294e0e0) at src/input/mpegts/dvb_psi_lib.c:169
pusi = <optimized out>
cc = <optimized out>
off = 4
r = <optimized out>
#9 0x00007fcd9b9e11e9 in mpegts_input_table_dispatch (mm=mm@entry=0x7fcd9f6a9580, logprefix=logprefix@entry=0x7fcd717f9880 "10834V in Hotbird", tsb=tsb@entry=0x7fcd741e7480 "G@\022\024", tsb_len=9400) at src/input/mpegts/mpegts_input.c:1185
i = <optimized out>
len = <optimized out>
c = <optimized out>
tsb2 = 0x7fcd741e987c "G"
tsb2_end = 0x7fcd741e9938 "e\r"
pid = 18
mt = 0x7fcda294e0e0
vec = 0x7fcd717f9720
PRETTY_FUNCTION = "mpegts_input_table_dispatch"
#10 0x00007fcd9b9e13f6 in mpegts_input_table_thread (aux=0x7fcd9ef945d0) at src/input/mpegts/mpegts_input.c:1576
mtf = 0x7fcd741e7460
mm = 0x7fcd9f6a9580
muxname = "10834V in Hotbird", '\000' <repeats 238 times>
#11 0x00007fcd9b93c3d3 in thread_wrapper (p=0x7fcd9dd33200) at src/wrappers.c:159
set = {_val = {16388, 0 <repeats 15 times>}}
r = <optimized out>
#12 0x00007fcd97cf9dc5 in start_thread () from /lib64/libpthread.so.0
No symbol table info available.
#13 0x00007fcd97306ced in clone () from /lib64/libc.so.6
No symbol table info available.

#7

Updated by C K almost 8 years ago 

[New LWP 8810]
[New LWP 8809]
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1".
Core was generated by `./build.linux/tvheadend -l crashatnight3.log -D'.
Program terminated with signal SIGSEGV, Segmentation fault.
#0  bin2hex (dst=0x7f8a4d7f8b11 "", dst@entry=0x7f8a4d7f8b10 "\276", dstlen=dstlen@entry=33, src=0x140 <error: Cannot access memory at address 0x140>,
    srclen=srclen@entry=16) at src/uuid.c:83
83          *dst++ = "0123456789abcdef"[*src >> 4];

See full log attached

#8

Updated by Jaroslav Kysela almost 8 years ago

This is weird. It appears that ebc->channel in epg_episode_find_by_broadcast() is NULL which is not allowed. The channel is always set when the event is created. Could you inspect ebc ? Just type 'frame 2' and 'print *ebc' in the gdb console when the crash occurs.

#9

Updated by C K almost 8 years ago

See attached gdb.txt

#10

Updated by C K almost 8 years ago 

[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1".
Core was generated by `./build.linux/tvheadend -l crashatnight3.log -D'.
Program terminated with signal SIGSEGV, Segmentation fault.
#0  bin2hex (dst=0x7f8a4d7f8b11 "", dst@entry=0x7f8a4d7f8b10 "\276", 
    dstlen=dstlen@entry=33, 
    src=0x140 <error: Cannot access memory at address 0x140>, 
    srclen=srclen@entry=16) at src/uuid.c:83
83        *dst++ = "0123456789abcdef"[*src >> 4];
(gdb) set logging on
Copying output to gdb.txt.
(gdb) set pagination off
(gdb) frame 2
#2  0x00007f8ac5a17f74 in epg_episode_find_by_broadcast (ebc=ebc@entry=0x7f8a7f53b660, src=src@entry=0x7f8ac93422c0, create=create@entry=1, save=save@entry=0x7f8a4d7f95e0, changed=changed@entry=0x7f8a4d7f8c8c) at src/epg.c:956
956      snprintf(uri, sizeof(uri)-1, "tvh://channel-%s/bcast-%u/episode",
(gdb) print *ebc
$1 = {{uri_link = {left = 0x7f8a7d8548c0, right = 0x7f8a7ecd0ab0, parent = 0x0, color = 0}, id_link = {left = 0x0, right = 0x0, parent = 0x7f8a93c4a3c0, color = 0}, un_link = {le_next = 0x0, le_prev = 0x7f8ac6c47480 <epg_object_unref>}, up_link = {le_next = 0x0, le_prev = 0x7f8adc140ac0}, type = EPG_BROADCAST, id = 992764, uri = 0x0, updated = 1480822372, _updated = 1 '\001', _created = 0 '\000', refcount = 0, grabber = 0x7f8ac93422c0, getref = 0x7f8ac5a130d0 <_epg_object_getref>, putref = 0x7f8ac5a14700 <_epg_object_putref>, destroy = 0x7f8ac5a15b00 <_epg_broadcast_destroy>, update = 0x7f8ac5a141d0 <_epg_broadcast_updated>}, dvb_eid = 89, start = 1480821000, stop = 1480822200, is_widescreen = 0 '\000', is_hd = 0 '\000', lines = 0, aspect = 0, is_deafsigned = 0 '\000', is_subtitled = 0 '\000', is_audio_desc = 0 '\000', is_new = 0 '\000', is_repeat = 0 '\000', running = 0 '\000', summary = 0x7f8a7d93fc10, description = 0x7f8a7f6aeb00, sched_link = {left = 0x0, right = 0x0, parent = 0x7f8adc140a70, color = 0}, ep_link = {le_next = 0x0, le_prev = 0x0}, episode = 0x0, sl_link = {le_next = 0x0, le_prev = 0x0}, serieslink = 0x0, channel = 0x140}
(gdb) quit

I've created a coredump (2,5 GB) if you're interested

#11

Updated by C K almost 8 years ago

Again a crash at TVH's EPG cron at 2:04, see attached file

#12

Updated by Jaroslav Kysela almost 8 years ago

The ebc->channel is not NULL but 0x140 . Could you inspect ilm in 'frame 4' ? 'print *ilm'

#13

Updated by C K almost 8 years ago 

[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1".
Core was generated by `./build.linux/tvheadend -l crashatnight4.log -D'.
Program terminated with signal SIGBUS, Bus error.
#0  lang_str_compare (ls1=0x6e6f696e6967617a, ls2=ls2@entry=0x7f68e01afe00) at src/lang_str.c:279
279       RB_FOREACH(e, ls1, link) {
(gdb) set logging on
Copying output to gdb.txt.
(gdb) set pagination off
(gdb) frame 4
#4  _eit_callback (mt=0x7f68fc488160, ptr=0x7f68fc4881d6 ":\231\341\177", len=473, tableid=79) at src/epggrab/module/eit.c:724
724         if ((r = _eit_process_event(mod, tableid, sect, svc, ptr, len,
(gdb) print *ilm
No symbol "ilm" in current context.
(gdb)
#14

Updated by C K almost 8 years ago

Can upload the coredump, will send you a pm with link in irc

#15

Updated by Jaroslav Kysela almost 8 years ago

Okay, I analyzed the provided core / binary / crash and there are massive memory (data) corruptions for the EPG broadcast structure. The crashes are just a consequence that another part of tvh overwrites memory incorrectly.

I added section "Memory leaks or corruption" to the debugging wiki page - https://tvheadend.org/projects/tvheadend/wiki/Debugging#Memory-leaks-or-corruption . Hopefully, you can log something with these tools.

#17

Updated by C K almost 8 years ago

Here we go:

2016-12-06 08:54:17.465 [   INFO] htsp: Got connection from 192.168.178.29
2016-12-06 08:54:17.465 [   INFO] htsp: 192.168.178.29: Welcomed client software: Kodi Media Center (HTSPv25)
2016-12-06 08:54:17.466 [   INFO] htsp: 192.168.178.29: Welcomed client software: Kodi Media Center (HTSPv25)
2016-12-06 08:54:17.466 [   INFO] htsp: 192.168.178.77: Welcomed client software: Kodi Media Center (HTSPv25)
2016-12-06 08:54:17.466 [   INFO] htsp: 192.168.178.29 [ Kodi Media Center ]: Disconnected
2016-12-06 08:54:17.466 [   INFO] htsp: 192.168.178.77: Welcomed client software: Kodi Media Center (HTSPv25)
2016-12-06 08:54:17.466 [   INFO] htsp: 192.168.178.77 [ Kodi Media Center ]: Disconnected
2016-12-06 08:54:17.466 [   INFO] htsp: 192.168.178.29 [ Kodi Media Center ]: Identified as user 'kodi-wohnzimmer'
2016-12-06 08:54:17.466 [   INFO] htsp: 192.168.178.29 [ kodi-wohnzimmer | Kodi Media Center ]: Privileges updated
2016-12-06 08:54:17.957 [   INFO] htsp: 192.168.178.77 [ Kodi Media Center ]: Identified as user 'terminal01'
2016-12-06 08:54:17.958 [   INFO] htsp: 192.168.178.77 [ terminal01 | Kodi Media Center ]: Privileges updated
2016-12-06 08:54:17.958 [   INFO] htsp: Got connection from 192.168.178.64
2016-12-06 08:54:17.958 [   INFO] htsp: 192.168.178.64: Welcomed client software: Kodi Media Center (HTSPv25)
2016-12-06 08:54:17.959 [   INFO] htsp: 192.168.178.64 [ Kodi Media Center ]: Identified as user 'w1'
2016-12-06 08:54:17.959 [   INFO] htsp: 192.168.178.64 [ w1 | Kodi Media Center ]: Privileges updated
=================================================================
==23074==ERROR: AddressSanitizer: global-buffer-overflow on address 0x7fe1cfac44d8 at pc 0x7fe1ce744050 bp 0x7fe1b7454870 sp 0x7fe1b7454868
READ of size 4 at 0x7fe1cfac44d8 thread T25 (tvh:mi-main)
    #0 0x7fe1ce74404f in parse_mp4a_data /home/waldmeister/src/tvheadend/src/parsers/parsers.c:595
    #1 0x7fe1ce72ee9e in parse_aac /home/waldmeister/src/tvheadend/src/parsers/parsers.c:335
    #2 0x7fe1ce714ae2 in parse_mpeg_ts /home/waldmeister/src/tvheadend/src/parsers/parsers.c:215
    #3 0x7fe1cea52ebc in ts_recv_packet0 /home/waldmeister/src/tvheadend/src/input/mpegts/tsdemux.c:99
    #4 0x7fe1cea507bd in ts_recv_packet1 /home/waldmeister/src/tvheadend/src/input/mpegts/tsdemux.c:247
    #5 0x7fe1cea4980e in mpegts_input_process /home/waldmeister/src/tvheadend/src/input/mpegts/mpegts_input.c:1365
    #6 0x7fe1cea44eb2 in mpegts_input_thread /home/waldmeister/src/tvheadend/src/input/mpegts/mpegts_input.c:1506
    #7 0x7fe1ce26f2f2 in thread_wrapper /home/waldmeister/src/tvheadend/src/wrappers.c:159
    #8 0x7fe1cc5b3183 in start_thread (/lib/x86_64-linux-gnu/libpthread.so.0+0x8183)
    #9 0x7fe1cad5637c (/lib/x86_64-linux-gnu/libc.so.6+0xfa37c)

0x7fe1cfac44d8 is located 8 bytes to the right of global variable 'aac_sample_rates' from 'src/parsers/parsers.c' (0x7fe1cfac44a0) of size 48
SUMMARY: AddressSanitizer: global-buffer-overflow /home/waldmeister/src/tvheadend/src/parsers/parsers.c:595 parse_mp4a_data
Shadow bytes around the buggy address:
  0x0ffcb9f50840: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
  0x0ffcb9f50850: 00 00 00 00 00 00 00 00 f9 f9 f9 f9 f9 f9 f9 f9
  0x0ffcb9f50860: f9 f9 f9 f9 00 00 f9 f9 f9 f9 f9 f9 00 00 00 00
  0x0ffcb9f50870: 06 f9 f9 f9 f9 f9 f9 f9 00 00 00 00 01 f9 f9 f9
  0x0ffcb9f50880: f9 f9 f9 f9 00 02 f9 f9 f9 f9 f9 f9 00 00 03 f9
=>0x0ffcb9f50890: f9 f9 f9 f9 00 00 00 00 00 00 f9[f9]f9 f9 f9 f9
  0x0ffcb9f508a0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
  0x0ffcb9f508b0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
  0x0ffcb9f508c0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
  0x0ffcb9f508d0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
  0x0ffcb9f508e0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
Shadow byte legend (one shadow byte represents 8 application bytes):
  Addressable:           00
  Partially addressable: 01 02 03 04 05 06 07
  Heap left redzone:     fa
  Heap right redzone:    fb
  Freed heap region:     fd
  Stack left redzone:    f1
  Stack mid redzone:     f2
  Stack right redzone:   f3
  Stack partial redzone: f4
  Stack after return:    f5
  Stack use after scope: f8
  Global redzone:        f9
  Global init order:     f6
  Poisoned by user:      f7
  ASan internal:         fe
Thread T25 (tvh:mi-main) created by T21 (tvh:mtimer) here:
    #0 0x7fe1ce18e2d2 in pthread_create (/home/waldmeister/src/tvheadend/build.linux/tvheadend+0x4cc2d2)
    #1 0x7fe1ce26ed0b in tvhthread_create /home/waldmeister/src/tvheadend/src/wrappers.c:177
    #2 0x7fe1cea3f3ef in mpegts_input_thread_start /home/waldmeister/src/tvheadend/src/input/mpegts/mpegts_input.c:1749
    #3 0x7fe1ce1d104e in mtimer_thread /home/waldmeister/src/tvheadend/src/main.c:634
    #4 0x7fe1ce26f2f2 in thread_wrapper /home/waldmeister/src/tvheadend/src/wrappers.c:159
    #5 0x7fe1cc5b3183 in start_thread (/lib/x86_64-linux-gnu/libpthread.so.0+0x8183)

Thread T21 (tvh:mtimer) created by T0 here:
    #0 0x7fe1ce18e2d2 in pthread_create (/home/waldmeister/src/tvheadend/build.linux/tvheadend+0x4cc2d2)
    #1 0x7fe1ce26ed0b in tvhthread_create /home/waldmeister/src/tvheadend/src/wrappers.c:177
    #2 0x7fe1ce1c9f9d in main /home/waldmeister/src/tvheadend/src/main.c:1285
    #3 0x7fe1cac7df44 (/lib/x86_64-linux-gnu/libc.so.6+0x21f44)

==23074==ABORTING
#18

Updated by Jaroslav Kysela almost 8 years ago

Fixed in v4.1-2357-g290cf51, but it's probably unrelated to the EPG data corruption.

#19

Updated by Morbid Angel almost 8 years ago

do you need more input from me?

#20

Updated by Jaroslav Kysela almost 8 years ago

If you like to join - look to the comment 15 and follow the "clang" paragraph on the wiki.

#21

Updated by C K almost 8 years ago

Jaroslav Kysela wrote:

If you like to join - look to the comment 15 and follow the "clang" paragraph on the wiki.

Here we go again: https://gist.github.com/ckarrie/e1bc8404b99e20b9a5902b4b860340f7

#22

Updated by Jaroslav Kysela almost 8 years ago

  • Status changed from New to Fixed

Applied in changeset commit:tvheadend|b3f72d7e4cfd10cc9ad863004ee39a6e9da45b42.

#23

Updated by Jaroslav Kysela almost 8 years ago

Fixed in v4.1-2359-gb3f72d7 .

#24

Updated by C K almost 8 years ago

Jaroslav Kysela wrote:

Fixed in v4.1-2359-gb3f72d7 .

Thank you so much Jaroslav :-) !!! No segfaults so far.

Also available in: Atom PDF