Tvheadend

The valgrind shows nothing useful for this. There are only avahi/dbus leaks which are not relevant. The dvbcsa uninitialized memory is also fine (and it's ignored in support/valgrind.supp (use "valgrind --suppressions=support/valgrind.supp")). You may also use cclang to detect the unfreed memory (it's faster): https://tvheadend.org/projects/tvheadend/wiki/Debugging#Memory-leaks-or-corruption

Hi,

I compiled tvheadend again with the following script:

#!/bin/sh
make distclean
ARGS="--enable-trace --enable-debugging --enable-ccdebug"
SANITIZER=leak # or address
export CFLAGS="-fsanitize=$SANITIZER"
export LDFLAGS="-fsanitize=$SANITIZER"
./configure $ARGS --disable-pie --enable-ccdebug python=python3 cc=clang ld=clang nowerror
make -j4

Because Ubuntu 16.04 uses a version suffix for llvm-symbolizer (/usr/bin/llvm-symbolizer-3.8) I created a symlink but this doesn't seem to work either. The error logs don't show resolved function names.

ASAN_OPTIONS=symbolize=1 ASAN_SYMBOLIZER_PATH=/usr/bin/llvm-symbolizer-3.8 /home/probook/tvheadend/build.linux/tvheadend -l tvhclang3.log --trace satip,linuxdvb,subscription --noacl -D

or

ASAN_OPTIONS=symbolize=1 ASAN_SYMBOLIZER_PATH=/usr/bin/llvm-symbolizer /home/probook/tvheadend/build.linux/tvheadend -l tvhclang3.log --trace satip,linuxdvb,subscription --noacl -D

don't seem to work. I'm just getting a normal error log specified with "-l tvhclang3.log"

I'm not even getting warning like specified in the tvheadend documentation page for debugging:

==16673==WARNING: Trying to symbolize code, but external symbolizer is not initialized! --> not in my log

Any hints on how to generate the proper error that you would need?

I also tried this but no avail:

ASAN_OPTIONS=symbolize=1 ASAN_SYMBOLIZER_PATH=/usr/lib/llvm-3.8/bin:$PATH /home/probook/tvheadend/build.linux/tvheadend -l tvhclang4.log --trace satip,linuxdvb,subscription,en50221,dvbcam --noacl -D

running this now:

ASAN_OPTIONS=symbolize=1 ASAN_SYMBOLIZER_PATH=$(which llvm-symbolizer) /home/probook/tvheadend/build.linux/tvheadend -l tvhclangfinal.log --trace satip,linuxdvb,subscription --noacl -D

I don't get any error starting tvheadend with this command so I guess it's ok to run it like this? The problem I have is that the tuner becomes unresponsive after a while. Sometimes this happens when memory reaches 59%, sometimes only 18%. If I restart tvheadend, I can start over but it's just waiting for another lockup.

2018-11-04 22:44:46.080 [WARNING] subscription: 0002: service instance is bad, reason: No access
2018-11-04 22:44:48.080 [ NOTICE] subscription : 0002: No input source available for subscription "SAT>IP Slave/TN/314MHz/EUROSPORT HD" to service "TN/314MHz/EUROSPORT HD" in mux "314MHz in TN"

So, I'm not sure if any "useful" errors are being generated. It's really not a tuner issue or driver/firmware issue. My device is very stable with tvheadend when streaming FTA channels.

Same issue on debian 8, debian 9, Ubuntu 18.10

I still can't figure out how to get those clang debug logs? I perform everything as described like here:

https://tvheadend.org/projects/tvheadend/wiki/Debugging#Memory-leaks-or-corruption

When am I supposed to see these kind of messages? (==27911==ERROR: AddressSanitizer: ) ? When tvheadend crashes or during the memory leakage itself?

Because the thing is that tvheadend doesn't really crash. It just drops connection to the tuner and memory usage stalls at a certain %. Are

Can somebody perform a similar test with latest git? Just stream a scrambled channel with the satip server to a client (VLC, DVBViewer,...)

I went back a few months and the problem is also present in the code on 20th of june 2018. This is the furthest I went back yet.

https://github.com/tvheadend/tvheadend/tree/5750826be0cefb1069a08d90608147565954a8b3

Is there another way to debug this issue? Without clang or Valgrind?

It was another issue. Try v4.3-1524-ga093b4371 .

@John Törnblom beton give a look on #4992 i had the same issue... the simptons are 100% equal... on my case thats because a strange exchange of keys between oscam and tvheadend!

so maybe the trouble is the same!

2018-11-08 22:38:58.778 [  TRACE]:descrambler: Obtained CSA keys 77ACD1F4C6E88533:34BDB0A12F0EA3E0 pid 0000 from cccam-192.168.1.7:2222-1801 for service "vtm HD" 
2018-11-08 22:39:28.776 [  TRACE]:descrambler: Obtained CSA keys 77ACD1F4C6E88533:67F487E2C51215EC pid 0000 from cccam-192.168.1.7:2222-1801 for service "vtm HD" 
2018-11-08 22:39:58.778 [  TRACE]:descrambler: Obtained CSA keys DA80A600D157E911:67F487E2C51215EC pid 0000 from cccam-192.168.1.7:2222-1801 for service "vtm HD" 
2018-11-08 22:40:28.768 [  TRACE]:descrambler: Obtained CSA keys DA80A600D157E911:B3C56BE36AF10560 pid 0000 from cccam-192.168.1.7:2222-1801 for service "vtm HD" 
2018-11-08 22:41:28.781 [  DEBUG]:cccam: 192.168.1.7:2222: Obtained DES keys for service "vtm HD" in 184 ms, from cccam-192.168.1.7:2222-1801
2018-11-08 22:41:28.781 [  DEBUG]:descrambler: Obtained CSA keys from cccam-192.168.1.7:2222-1801 for service "vtm HD" 
2018-11-08 22:41:28.781 [  TRACE]:descrambler: Obtained CSA keys 461F3DA2AE086016:3C6CB75FB5F4B55E pid 0000 from cccam-192.168.1.7:2222-1801 for service "vtm HD" 

2018-11-08 22:40:56.578 [  TRACE]:cccam: 192.168.1.7:2222: del card 0000006F message received
2018-11-08 22:40:56.578 [   INFO]:cccam: 192.168.1.7:2222: card ID:0000006f CAID:1801 with 3 providers removed
2018-11-08 22:40:56.578 [  TRACE]:descrambler: close emm caid 1801 (6145) pid 044D (1101) - direct
2018-11-08 22:40:56.578 [  TRACE]:mpegts: table: mux 0x558b6b5b6870 destroy emm 00/00 (0) pid 044D (1101)
2018-11-08 22:40:56.578 [  TRACE]:descrambler: mux 0x558b6b5b6870 close pid 044D (1101) (flags 0x0000) for 0x7fb340002320
....
2018-11-08 22:40:56.579 [  TRACE]:cccam: 192.168.1.7:2222: add card message received
2018-11-08 22:40:56.579 [   INFO]:cccam: 192.168.1.7:2222: Connected as user user1 to a NagraVision-card-00000071 [CAID:1801] with 3 providers
2018-11-08 22:40:56.579 [  DEBUG]:cccam: 192.168.1.7:2222: Providers: ID:00000071 CAID:1801:[0x007611,0x000000,0x007711]
....
2018-11-08 22:40:56.590 [  DEBUG]:mpegts: 306MHz in TN - close PID 044D (1101) [16/0x7fb324005b60]

The CA was removed and added again by cccam, but tvh stops to send the ECM requests after this.

Try v4.3-1526-g42fb10e77 .

Ricardo - I don't think that's a similar issue. It's cccam specific.

And again - another issue - create a new bug next time.

Hi Jaroslav, i just commented because the simptons are equal... sorry!

and thanks!

The initial problem with the unavailable slaves has been solved. I have not found the time to test the CA problem.

Thank you Jaroslav.