[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