Project

General

Profile

Bug #5841

Crash

Added by Victor S 6 months ago. Updated 2 months ago.

Status:
Invalid
Priority:
Normal
Assignee:
-
Category:
-
Target version:
-
Start date:
2020-01-08
Due date:
% Done:

0%

Estimated time:
Found in version:
HTS Tvheadend 4.3-1857~g221c29b40
Affected Versions:

Description

Ran a scan in DVBViewer via SAT>IP, tvheadend has crashed.

Jan 8 13:49:25 YUbuntu-P7P55-D tvheadend917: mpegts: 12676H in Eutelsat 16E VLo,HLo,HHi (0x7fb22c007ca0) - deleting
Jan 8 13:49:25 YUbuntu-P7P55-D tvheadend917: mpegts: 12678H in Eutelsat 16E VLo,HLo,HHi - tuning on TurboSight TBS 6504 DVB-S/S2/S2X/T/T2/C/C2/ISDB-T #2 : DVB-S #1 (Eutelsat 16E VLo,HLo,HHi + Astra 19.2E VHi)
Jan 8 13:49:25 YUbuntu-P7P55-D tvheadend917: linuxdvb: TurboSight TBS 6504 DVB-S/S2/S2X/T/T2/C/C2/ISDB-T #2 : DVB-S #1 (Eutelsat 16E VLo,HLo,HHi + Astra 19.2E VHi) - failed to tune [e=Invalid argument]
Jan 8 13:49:25 YUbuntu-P7P55-D kernel: [ 8226.424997] TBSECP3 driver 0000:08:00.0: DVB: adapter 2 frontend 1 symbol rate 330000 out of range (1000000..45000000)
Jan 8 13:49:25 YUbuntu-P7P55-D kernel: [ 8226.428645] TBSECP3 driver 0000:08:00.0: DVB: adapter 1 frontend 1 symbol rate 330000 out of range (1000000..45000000)
Jan 8 13:49:25 YUbuntu-P7P55-D tvheadend917: mpegts: 12678H in Eutelsat 16E VLo,HLo,HHi - tuning on TurboSight TBS 6504 DVB-S/S2/S2X/T/T2/C/C2/ISDB-T #1 : DVB-S #1 (Eutelsat 9E HHi,VHi + Astra 19.2E HLo,VLo)
Jan 8 13:49:25 YUbuntu-P7P55-D tvheadend917: linuxdvb: TurboSight TBS 6504 DVB-S/S2/S2X/T/T2/C/C2/ISDB-T #1 : DVB-S #1 (Eutelsat 9E HHi,VHi + Astra 19.2E HLo,VLo) - failed to tune [e=Invalid argument]
Jan 8 13:49:29 YUbuntu-P7P55-D tvheadend917: subscription: 0119: No input source available for subscription "SAT>IP" to mux "12678H in Eutelsat 16E VLo,HLo,HHi"
Jan 8 13:49:31 YUbuntu-P7P55-D tvheadend917: satips: 0/E692EF50/15: subscription fails because mux can't tune
Jan 8 13:49:31 YUbuntu-P7P55-D tvheadend917: subscription: 0119: "SAT>IP" unsubscribing, hostname="192.168.3.224"
Jan 8 13:49:31 YUbuntu-P7P55-D tvheadend917: satips: 192.168.3.224: RTSP/1.0 PLAY (8) rtsp://192.168.1.19:5657/stream=15?src=4&freq=12678&msys=dvbs&plts=off&fec=12&pol=h&ro=0.35&sr=330&mtype=qpsk&pids=0 -- 405
Jan 8 13:49:31 YUbuntu-P7P55-D tvheadend917: mpegts: 12678H in Eutelsat 16E VLo,HLo,HHi (0x7fb22c008600) - deleting
Jan 8 13:49:31 YUbuntu-P7P55-D tvheadend917: CRASH: Signal: 11 in PRG: /usr/bin/tvheadend (4.3-1857~g221c29b40) [19f52baeadbb085598d4b1d314a24346d7c20ca5] CWD: /
Jan 8 13:49:31 YUbuntu-P7P55-D tvheadend917: CRASH: Fault address 0x100000000 (Address not mapped)
Jan 8 13:49:31 YUbuntu-P7P55-D tvheadend917: CRASH: Loaded libraries: linux-vdso.so.1 /usr/lib/x86_64-linux-gnu/libdvbcsa.so.1 /usr/lib/x86_64-linux-gnu/libssl.so.1.1 /usr/lib/x86_64-linux-gnu/libcrypto.so.1.1 /lib/x86_64-linux-gnu/libz.so.1 /usr/lib/x86_64-linux-gnu/libpcre2-8.so.0 /usr/lib/x86_64-linux-gnu/liburiparser.so.1 /usr/lib/x86_64-linux-gnu/libavahi-common.so.3 /usr/lib/x86_64-linux-gnu/libavahi-client.so.3 /lib/x86_64-linux-gnu/libdbus-1.so.3 /lib/x86_64-linux-gnu/libdl.so.2 /lib/x86_64-linux-gnu/libpthread.so.0 /lib/x86_64-linux-gnu/libm.so.6 /lib/x86_64-linux-gnu/librt.so.1 /lib/x86_64-linux-gnu/libmvec.so.1 /usr/lib/x86_64-linux-gnu/libstdc++.so.6 /lib/x86_64-linux-gnu/libc.so.6 /lib/x86_64-linux-gnu/libsystemd.so.0 /lib64/ld-linux-x86-64.so.2 /lib/x86_64-linux-gnu/libgcc_s.so.1 /lib/x86_64-linux-gnu/liblzma.so.5 /usr/lib/x86_64-linux-gnu/liblz4.so.1 /lib/x86_64-linux-gnu/libgcrypt.so.20 /lib/x86_64-linux-gnu/libgpg-error.so.0 /lib/x86_64-linux-gnu/libnss_compat.so.2 /lib/x86_64-linux-gnu/libnss_nis.so.2 /lib/x86_64-linux-gnu/libnsl.so.1
Jan 8 13:49:31 YUbuntu-P7P55-D tvheadend917: CRASH: Register dump [23]: 00007fb22c0087f0000000000000000100007fb22c0023e000007fb26c5b13c000007fb22c0087f0000056544526e493000000000000001100007fb18fffe42000000001000000000000000000000000000000010000000000007fb22c00860000000000000000000000000100000000000000000000000000007fb18fffdf5800007fb26c4b36460000000000010293002b0000000000330000000000000004000000000000000efffffffe7ffbba130000000100000000
Jan 8 13:49:31 YUbuntu-P7P55-D tvheadend917: CRASH: STACKTRACE
Jan 8 13:49:31 YUbuntu-P7P55-D tvheadend917: CRASH: ??:0 0x56544425f32d 0x565444049000
Jan 8 13:49:31 YUbuntu-P7P55-D tvheadend917: CRASH: ??:0 0x7fb26d35e890 0x7fb26d34c000
Jan 8 13:49:31 YUbuntu-P7P55-D tvheadend917: CRASH: ??:0 0x7fb26c4b3646 0x7fb26c402000
Jan 8 13:49:31 YUbuntu-P7P55-D tvheadend917: CRASH: __strdup+0xe (/lib/x86_64-linux-gnu/libc.so.6)
Jan 8 13:49:31 YUbuntu-P7P55-D tvheadend917: CRASH: ??:0 0x5654442f1ca8 0x565444049000
Jan 8 13:49:31 YUbuntu-P7P55-D tvheadend917: CRASH: ??:0 0x565444246109 0x565444049000
Jan 8 13:49:31 YUbuntu-P7P55-D tvheadend917: CRASH: ??:0 0x5654442d4d54 0x565444049000
Jan 8 13:49:32 YUbuntu-P7P55-D tvheadend917: CRASH: ??:0 0x56544422cb59 0x565444049000
Jan 8 13:49:32 YUbuntu-P7P55-D tvheadend917: CRASH: ??:0 0x56544422dd3b 0x565444049000
Jan 8 13:49:32 YUbuntu-P7P55-D tvheadend917: CRASH: ??:0 0x5654442d1b50 0x565444049000
Jan 8 13:49:32 YUbuntu-P7P55-D tvheadend917: CRASH: ??:0 0x565444224330 0x565444049000
Jan 8 13:49:32 YUbuntu-P7P55-D tvheadend917: CRASH: ??:0 0x56544421f128 0x565444049000
Jan 8 13:49:32 YUbuntu-P7P55-D tvheadend917: CRASH: ??:0 0x7fb26d3536db 0x7fb26d34c000
Jan 8 13:49:32 YUbuntu-P7P55-D kernel: [ 8233.379389] show_signal_msg: 23 callbacks suppressed
Jan 8 13:49:32 YUbuntu-P7P55-D kernel: [ 8233.379391] tvh:tcp-start28887: segfault at 100000000 ip 00007fb26c4b3646 sp 00007fb18fffdf58 error 4 in libc-2.27.so[7fb26c402000+1e7000]
Jan 8 13:49:32 YUbuntu-P7P55-D kernel: [ 8233.379398] Code: 0f 1f 40 00 66 0f ef c0 66 0f ef c9 66 0f ef d2 66 0f ef db 48 89 f8 48 89 f9 48 81 e1 ff 0f 00 00 48 81 f9 cf 0f 00 00 77 6a <f3> 0f 6f 20 66 0f 74 e0 66 0f d7 d4 85 d2 74 04 0f bc c2 c3 48 83
Jan 8 13:49:32 YUbuntu-P7P55-D systemd1: tvheadend.service: Main process exited, code=killed, status=11/SEGV
Jan 8 13:49:32 YUbuntu-P7P55-D systemd1: tvheadend.service: Failed with result 'signal'.
Jan 8 13:49:57 YUbuntu-P7P55-D run-one-constantly1772: last run failed; sleeping [0] seconds before next run

History

#2

Updated by Victor S 6 months ago

Flole Systems wrote:

https://tvheadend.org/projects/tvheadend/wiki/Debugging#Incorrect-not-useable-crash-reports

And what about it? You want me to compile debug version and do something with it? Why don't you simply do something about those symbol rates. Is it so hard to code an auto-correcting code to fill up three more zeros at the end if needed? Or at least stop it crashing entire application. Instead of throwing useless wiki link.

#3

Updated by Tom W 6 months ago

Victor - please have a short look at the code contributions from the persons which are currently answering on severe bug reports. I haven't found any and I haven't even even found one ticket which is currently solved from this side.

So: Yes - it is currently difficult to add code to catch the crashes.

But on the other hand it is very easy to compile tvh. "configure && make && make install"

I have seen a very similar behaviour - so it would be interesting to see if similar codepathes are used ....

#4

Updated by Flole Systems 6 months ago

@Tom W: You must have missed my contributions then. You might want to double-check that.

@Victor S: I can't even see what's going on because the crashdump is unusable. If you tell me what's wrong then I am sure that I can correct it. You should've read the wiki before opening a bug report, then I would not have to post a link that clearly explains you something that you didn't know before, otherwise you would not have opened an issue with an incorrect/unusable coredump. So it's not useless.

Other than that: As you think it's easy, this is fully open source software so you are more than welcome to fix this but and submit a pull request.

#5

Updated by Tom W 6 months ago

Oops - really ? Then I have overseen your changesets.

It may have happened that "update to latest" or "I don't even look into old version" is not considered as "contribution" from my side.

Do you have the rights to change the status of tickets ?

#6

Updated by Flole Systems 6 months ago

Check my commit history on GitHub, I think unfortunately not all changesets are displayed here. In fact the last commit was authored by me (and I think it's not shown here while some of my previous ones are). That was for an issue similar to this one by the way.

The reason I don't look into old versions is that sometimes the issue is already fixed but even more important the line numbers are often not accurate anymore, so I would have to go back in GitHub to the version that was used, check that out, then find the bug, then forward again to master, find out where I fixed the bug (which can be at multiple places) and then it's finally fixed. That's not only really annoying work but also it's super easy to prevent this. Anyways, this is for the latest version so it's all good.

I do not have the rights to change the status of tickets, otherwise I would have cleaned up a little already ;) There are some already solved tickets that are still open for example.

#7

Updated by Victor S 6 months ago

Tom W wrote:

Victor - please have a short look at the code contributions from the persons which are currently answering on severe bug reports. I haven't found any and I haven't even even found one ticket which is currently solved from this side.

So: Yes - it is currently difficult to add code to catch the crashes.

But on the other hand it is very easy to compile tvh. "configure && make && make install"

I have seen a very similar behaviour - so it would be interesting to see if similar codepathes are used ....

Open DVBViewer, set device to via SAT>IP, open pre-defined Eutelsat 16E and run a scan of all freqs, right in the middle of process it will crash Tvheadend. Help yourself, I've reproduced it 3 times in a row and you don't need a real LNB pointed to that sat.

#8

Updated by Tom W 6 months ago

Flole Systems wrote:

Check my commit history on GitHub, I think unfortunately not all changesets are displayed here. In fact the last commit was authored by me (and I think it's not shown here while some of my previous ones are). That was for an issue similar to this one by the way.

If they are not displayed - than I cannot talk about. The borders of our repro are the.

The reason I don't look into old versions is that sometimes the issue is already fixed but even more important the line numbers are often not accurate anymore, so I would have to go back in GitHub to the version that was used, check that out, then find the bug, then forward again to master, find out where I fixed the bug (which can be at multiple places) and then it's finally fixed. That's not only really annoying work but also it's super easy to prevent this. Anyways, this is for the latest version so it's all good.

The reason is very clear to me. But from an CM POV this this doesn't makes sense. Your procedure assumes that every single revision is stable, that everyone can switch to latest, that everything works flawlessly with latest. This is not the case.

I do not have the rights to change the status of tickets, otherwise I would have cleaned up a little already ;) There are some already solved tickets that are still open for example.

#9

Updated by Tom W 6 months ago

Victor S wrote:

Open DVBViewer, set device to via SAT>IP, open pre-defined Eutelsat 16E and run a scan of all freqs, right in the middle of process it will crash Tvheadend. Help yourself, I've reproduced it 3 times in a row and you don't need a real LNB pointed to that sat.

Wow - DVBviewer. Is this a windows something prog ?

"Help yourself" ? Actually I dont care if a "TurboSight TBS 6504 DVB-S/S2/S2X/T/T2/C/C2/ISDB" chinamade crap crashes.

You are aware that the error came from the kerneldriver of your card ? Sounds like they are using the outdated (deprecated) old Kernel driver for DVB.

....Holy shit: they are using the "media_built" method. ... and for another card you have to use a special kernel with bin firmware.

Please ask TBS for a working driver for your system. Obviously the card cannot be tuned.

Sure - tvh should not crash when tuning fails. But root cause is "buying china made crap without thinking about driver support".

#10

Updated by Flole Systems 2 months ago

  • Status changed from New to Invalid

No proper coredump provided. Seems like a driver issue though.

Also available in: Atom PDF