[mythtv-commits] Ticket #13519: seg fault while channel scanning hdhomerun connect quatro

[MythTV]

#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