[mythtv-commits] Ticket #13571: Crash of backend on delete of program being recorded

MythTV noreply at mythtv.org
Sun Apr 5 21:15:00 UTC 2020


#13571: Crash of backend on delete of program being recorded
--------------------------------+-------------------------------
 Reporter:  Klaas de Waal       |          Owner:  Klaas de Waal
     Type:  Bug Report - Crash  |         Status:  assigned
 Priority:  minor               |      Milestone:  32.0
Component:  MythTV - General    |        Version:  Master Head
 Severity:  medium              |     Resolution:
 Keywords:                      |  Ticket locked:  0
--------------------------------+-------------------------------

Comment (by Klaas de Waal):

 Running the iteration test code before the StopRecording goes OK, it does
 not crash.
 I have used valgrind a few times but it has not come up with anything.

 When I change the iteration test code to use a Java-style iterator instead
 of an STL-style iterator, as described in
 https://doc.qt.io/qt-5/qmap.html, then the iteration test code, as shown
 below, runs OK and does not cause a crash.
 {{{
             for (int i=0; i<100000; i++)
             {
                 QMapIterator<int, EncoderLink *> z(*m_encoderList);
                 while (z.hasNext())
                 {
                     z.next();
                     EncoderLink *elink2 = z.value();
                     if (elink2->IsLocal())
                     {
                         (void) z.key();
                     }
                 }
             }
 }}}

 I have also ran tests with comparing all key-value pairs of the
 m_encoderList with the values just after the m_encoderList had been
 created. With a small delay after the StopRecording the list never changes
 as is expected. Without the small delay the content as read back is
 sometimes wrong.

 It is in principle possible that StopRecording causes writes to the
 m_encoderLink of values that are identical to what they already are. In
 that case the end result is identical, but maybe the QMap is then sorted
 again. However if that would be the case then I expect that the Java-style
 iterator should also not work.

 My tentative conclusion is that the QMap is not re-entrant when using STL-
 style iteration.

 Whether this depends on compilers, compiler versions, Qt versions or even
 for-loop coding style I do not know.
 As mentioned in the post, I had this crash not with v30 but only when I
 changed to v31/master.
 For reference, software and compiler versions used are here below.

 {{{
 2020-04-05 22:38:25.299816 C  mythbackend version: master [v32-Pre-234
 -g9b5d6b957f-dirty] www.mythtv.org
 2020-04-05 22:38:25.299828 C  Qt version: compile: 5.13.2, runtime: 5.13.2
 2020-04-05 22:38:25.299851 I  Fedora 31 (Thirty One) (x86_64)

 }}}


 {{{
 [klaas at modu mythtv]$ gcc -v
 Using built-in specs.
 COLLECT_GCC=/usr/bin/gcc
 COLLECT_LTO_WRAPPER=/usr/libexec/gcc/x86_64-redhat-linux/9/lto-wrapper
 OFFLOAD_TARGET_NAMES=nvptx-none
 OFFLOAD_TARGET_DEFAULT=1
 Target: x86_64-redhat-linux
 Configured with: ../configure --enable-bootstrap --enable-
 languages=c,c++,fortran,objc,obj-c++,ada,go,d,lto --prefix=/usr
 --mandir=/usr/share/man --infodir=/usr/share/info --with-
 bugurl=http://bugzilla.redhat.com/bugzilla --enable-shared --enable-
 threads=posix --enable-checking=release --enable-multilib --with-system-
 zlib --enable-__cxa_atexit --disable-libunwind-exceptions --enable-gnu-
 unique-object --enable-linker-build-id --with-gcc-major-version-only
 --with-linker-hash-style=gnu --enable-plugin --enable-initfini-array
 --with-isl --enable-offload-targets=nvptx-none --without-cuda-driver
 --enable-gnu-indirect-function --enable-cet --with-tune=generic --with-
 arch_32=i686 --build=x86_64-redhat-linux
 Thread model: posix
 gcc version 9.2.1 20190827 (Red Hat 9.2.1-1) (GCC)
 [klaas at modu mythtv]$

 }}}

 To summarize, there are now three ways to fix this:
 - Terminate the loop after a match is found. The patch for this is already
 attached.
 - Add a small delay, e.g. 100ms, after the StopRecording. Then traversing
 the m_encoderList continue to the end (although not useful at all)
 - Recode the loop to use the Java-style iterator.

 P.S. Having gone through all the code that uses m_encoderLink and m_tvList
 I found a few places where the code can be improved, e.g. to avoid
 accidental map element creation when using a non-existing key. I did
 actually tentatively fix them all but this did not make any difference.

-- 
Ticket URL: <https://code.mythtv.org/trac/ticket/13571#comment:15>
MythTV <http://www.mythtv.org>
MythTV Media Center


More information about the mythtv-commits mailing list