[mythtv-commits] Ticket #13519: seg fault while channel scanning hdhomerun connect quatro
MythTV
noreply at mythtv.org
Wed Nov 27 21:48:41 UTC 2019
#13519: seg fault while channel scanning hdhomerun connect quatro
-----------------------------------+-------------------------------
Reporter: Mike Bibbings | Owner: Klaas de Waal
Type: Bug Report - Crash | Status: assigned
Priority: minor | Milestone: 31.0
Component: MythTV - Mythtv-setup | Version: Master Head
Severity: medium | Resolution:
Keywords: | Ticket locked: 0
-----------------------------------+-------------------------------
Comment (by Klaas de Waal):
Hi Mike,
About the offsets. To test that hypothesis you could do a "Full Scan" and
select Netherlands. This has a list of DVB-T/T2 channels/frequencies that
do not have offsets.
In the meantime, thanks to your logs, I have also come to some tentative
conclusions.
1. Device failure
It could be possible that your HDHR device is slowly breaking down.
According to the mailing list the power supply of the HDHR devices does
fail quite often after a few years and this might give incidental errors
like the ones in the hdhr-dbg.log file.
2. Thread-safety (or lack thereof)
The errors as reported by valgrind in file valgrind-19.10-master6.log show
that the failing function, hdhomerun_sock_recv, is called from two
different threads: Thread 37 Signal Monitor (see line 10876) and Thread 36
Scanner (see line 15607).
Looking carefully at the valgrind messages following line 10876 it shows
that the "invalid read" is done by the signal monitor; it is reading the
value just free'd by the scanner.
3. Why does this not happen more often
It is only when the communication fails that in libhdhomerun the
communication is closed and then restarted. This can happen with a broken
HDHR device or with anything else that disturbs the communication.
When the network communications works correct then there are never retries
that involve a close/open/read again. Only when it fails you can have the
situation in which the "cs->sock" is free'd in one thread and used in
another thread.
The valgrind errors are for me the proof that there is a thread-safety
problem. Even if they are only triggered when doing offset scans, what
your test suggest, it is still wrong.
Therefore the next step is to make sure that the calls to the libhdhomerun
functions from the hdhr signal monitor and the hdhr stream handler are
serialized. One more mutex should do the job.
In the meantime, in the case that your problems are caused by the HDHR
power supply please do not throw it away yet otherwise there is no way to
test the fixes....
Klaas.
--
Ticket URL: <https://code.mythtv.org/trac/ticket/13519#comment:12>
MythTV <http://www.mythtv.org>
MythTV Media Center
More information about the mythtv-commits
mailing list