Added fix for Ticket 8182 #1
Closed
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Beirdo
pushed a commit
that referenced
this pull request
Sep 5, 2012
This fixes an error in the job creation options that causes all user jobs to be created as user job #1, rather than the type actually selected.
stuarta
added a commit
that referenced
this pull request
Apr 25, 2018
jpoet
pushed a commit
that referenced
this pull request
Jun 19, 2019
New segmentation types and support for AudioDescriptor in SCTE 35 2019 Closes #1 See merge request MIQ/mythtv-dn!2
ijc
added a commit
to ijc/mythtv
that referenced
this pull request
Sep 28, 2019
The thread running HLSReader::Cancel calls HLSPlaylistWorker::Cancel with the
stream lock held, which blocks waiting for the thread to exit.
The HLSPlaylistWorker::run thread however can be at the point between the
m_cancel check and the call to HLSReader::PlaylistRetrying. Since
PlaylistRetrying also takes the stream lock we are therefore deadlocked.
See stack traces below.
To address this introduce a separate worker lock covering the m_playlistworker
and m_streamworker fields. This means that HLSReader::Cancel only needs to take
this new lock and therefore cannot deadlock against the use of the stream lock
in HLSReader::PlaylistRetrying.
When they need to be held together the new lock is consistently nested within
the old.
Strack traces:
Thread 1571 (Thread 0x7ffefa7fc700 (LWP 13196)):
#0 futex_wait_cancelable (private=0, expected=0, futex_word=0x7fff08101380) at ../sysdeps/unix/sysv/linux/futex-internal.h:88
MythTV#1 __pthread_cond_wait_common (abstime=0x0, mutex=0x7fff08101330, cond=0x7fff08101358) at pthread_cond_wait.c:502
MythTV#2 __pthread_cond_wait (cond=0x7fff08101358, mutex=0x7fff08101330) at pthread_cond_wait.c:655
MythTV#3 0x00007ffff10d01bb in QWaitCondition::wait(QMutex*, unsigned long) () from /lib/x86_64-linux-gnu/libQt5Core.so.5
MythTV#4 0x00007ffff10cf66e in QThread::wait(unsigned long) () from /lib/x86_64-linux-gnu/libQt5Core.so.5
MythTV#5 0x00007ffff55a3255 in MThread::wait (this=0x7fff0806fc60, time=18446744073709551615) at mthread.cpp:315
MythTV#6 0x00007ffff619c476 in HLSPlaylistWorker::Cancel (this=0x7fff0806fc60) at recorders/HLS/HLSPlaylistWorker.cpp:30
QMutexLocker lock(&m_stream_lock);
MythTV#7 0x00007ffff61a1b82 in HLSReader::Cancel (this=0x7fffc8023ac0, quiet=false) at recorders/HLS/HLSReader.cpp:184
MythTV#8 0x00007ffff61a11d5 in HLSReader::Close (this=0x7fffc8023ac0, quiet=false) at recorders/HLS/HLSReader.cpp:150
MythTV#9 0x00007ffff619edf6 in HLSReader::~HLSReader (this=0x7fff200bbd80, __in_chrg=<optimized out>) at recorders/HLS/HLSReader.cpp:42
<...>
MythTV#31 0x00007ffff6196a63 in HLSStreamHandler::~HLSStreamHandler (this=0x7ffedc040e60, __in_chrg=<optimized out>) at recorders/hlsstreamhandler.cpp:113
MythTV#32 0x0000000000000000 in ?? ()
Thread 1566 (Thread 0x7ffefb7fe700 (LWP 13191)):
#0 futex_reltimed_wait_cancelable (private=0, reltime=0x7ffefb7fd920, expected=0, futex_word=0x7fff08029d90) at ../sysdeps/unix/sysv/linux/futex-internal.h:142
MythTV#1 __pthread_cond_wait_common (abstime=0x7ffefb7fd9e0, mutex=0x7fff08029d40, cond=0x7fff08029d68) at pthread_cond_wait.c:533
MythTV#2 __pthread_cond_timedwait (cond=0x7fff08029d68, mutex=0x7fff08029d40, abstime=0x7ffefb7fd9e0) at pthread_cond_wait.c:667
MythTV#3 0x00007ffff10d009c in QWaitCondition::wait(QMutex*, unsigned long) () from /lib/x86_64-linux-gnu/libQt5Core.so.5
MythTV#4 0x00007ffff61b7321 in HLSStreamWorker::run (this=0x7ffedc018370) at recorders/HLS/HLSStreamWorker.cpp:91
MythTV#5 0x00007ffff55a3c1c in MThreadInternal::run (this=0x7fff0803dab0) at mthread.cpp:79
MythTV#6 0x00007ffff10cfa07 in ?? () from /lib/x86_64-linux-gnu/libQt5Core.so.5
MythTV#7 0x00007ffff0ff3fa3 in start_thread (arg=<optimized out>) at pthread_create.c:486
MythTV#8 0x00007ffff0bad4cf in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:95
Thread 1565 (Thread 0x7fff16ffd700 (LWP 13190)):
#0 syscall () at ../sysdeps/unix/sysv/linux/x86_64/syscall.S:38
MythTV#1 0x00007ffff10c2995 in QBasicMutex::lockInternal() () from /lib/x86_64-linux-gnu/libQt5Core.so.5
MythTV#2 0x00007ffff5a49bb0 in QMutexLocker::QMutexLocker (this=0x7fff16ffcc80, m=0x7ffee401fd00) at /usr/include/x86_64-linux-gnu/qt5/QtCore/qmutex.h:206
<...>
QMutexLocker lock(&m_stream_lock);
MythTV#6 0x00007ffff61b055e in HLSReader::PlaylistRetrying (this=0x7fffc8023b20) at recorders/HLS/HLSReader.cpp:1025
<...>
MythTV#12 0x00007ffff619d791 in HLSPlaylistWorker::run (this=0x7fff0806fc60) at recorders/HLS/HLSPlaylistWorker.cpp:83
MythTV#13 0x00007ffff55a3c1c in MThreadInternal::run (this=0x7fff081082a0) at mthread.cpp:79
MythTV#14 0x00007ffff10cfa07 in ?? () from /lib/x86_64-linux-gnu/libQt5Core.so.5
MythTV#15 0x00007ffff0ff3fa3 in start_thread (arg=<optimized out>) at pthread_create.c:486
MythTV#16 0x00007ffff0bad4cf in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:95
Signed-off-by: Ian Campbell <ijc@hellion.org.uk>
ijc
added a commit
to ijc/mythtv
that referenced
this pull request
Sep 28, 2019
The thread running HLSReader::Cancel calls HLSPlaylistWorker::Cancel with the
stream lock held, which blocks waiting for the thread to exit.
The HLSPlaylistWorker::run thread however can be at the point between the
m_cancel check and the call to HLSReader::PlaylistRetrying. Since
PlaylistRetrying also takes the stream lock we are therefore deadlocked.
See stack traces below.
To address this introduce a separate worker lock covering the m_playlistworker
and m_streamworker fields. This means that HLSReader::Cancel only needs to take
this new lock and therefore cannot deadlock against the use of the stream lock
in HLSReader::PlaylistRetrying.
When they need to be held together the new lock is consistently nested within
the old.
Strack traces:
Thread 1571 (Thread 0x7ffefa7fc700 (LWP 13196)):
#0 futex_wait_cancelable (private=0, expected=0, futex_word=0x7fff08101380) at ../sysdeps/unix/sysv/linux/futex-internal.h:88
MythTV#1 __pthread_cond_wait_common (abstime=0x0, mutex=0x7fff08101330, cond=0x7fff08101358) at pthread_cond_wait.c:502
MythTV#2 __pthread_cond_wait (cond=0x7fff08101358, mutex=0x7fff08101330) at pthread_cond_wait.c:655
MythTV#3 0x00007ffff10d01bb in QWaitCondition::wait(QMutex*, unsigned long) () from /lib/x86_64-linux-gnu/libQt5Core.so.5
MythTV#4 0x00007ffff10cf66e in QThread::wait(unsigned long) () from /lib/x86_64-linux-gnu/libQt5Core.so.5
MythTV#5 0x00007ffff55a3255 in MThread::wait (this=0x7fff0806fc60, time=18446744073709551615) at mthread.cpp:315
MythTV#6 0x00007ffff619c476 in HLSPlaylistWorker::Cancel (this=0x7fff0806fc60) at recorders/HLS/HLSPlaylistWorker.cpp:30
QMutexLocker lock(&m_stream_lock);
MythTV#7 0x00007ffff61a1b82 in HLSReader::Cancel (this=0x7fffc8023ac0, quiet=false) at recorders/HLS/HLSReader.cpp:184
MythTV#8 0x00007ffff61a11d5 in HLSReader::Close (this=0x7fffc8023ac0, quiet=false) at recorders/HLS/HLSReader.cpp:150
MythTV#9 0x00007ffff619edf6 in HLSReader::~HLSReader (this=0x7fff200bbd80, __in_chrg=<optimized out>) at recorders/HLS/HLSReader.cpp:42
<...>
MythTV#31 0x00007ffff6196a63 in HLSStreamHandler::~HLSStreamHandler (this=0x7ffedc040e60, __in_chrg=<optimized out>) at recorders/hlsstreamhandler.cpp:113
MythTV#32 0x0000000000000000 in ?? ()
Thread 1566 (Thread 0x7ffefb7fe700 (LWP 13191)):
#0 futex_reltimed_wait_cancelable (private=0, reltime=0x7ffefb7fd920, expected=0, futex_word=0x7fff08029d90) at ../sysdeps/unix/sysv/linux/futex-internal.h:142
MythTV#1 __pthread_cond_wait_common (abstime=0x7ffefb7fd9e0, mutex=0x7fff08029d40, cond=0x7fff08029d68) at pthread_cond_wait.c:533
MythTV#2 __pthread_cond_timedwait (cond=0x7fff08029d68, mutex=0x7fff08029d40, abstime=0x7ffefb7fd9e0) at pthread_cond_wait.c:667
MythTV#3 0x00007ffff10d009c in QWaitCondition::wait(QMutex*, unsigned long) () from /lib/x86_64-linux-gnu/libQt5Core.so.5
MythTV#4 0x00007ffff61b7321 in HLSStreamWorker::run (this=0x7ffedc018370) at recorders/HLS/HLSStreamWorker.cpp:91
MythTV#5 0x00007ffff55a3c1c in MThreadInternal::run (this=0x7fff0803dab0) at mthread.cpp:79
MythTV#6 0x00007ffff10cfa07 in ?? () from /lib/x86_64-linux-gnu/libQt5Core.so.5
MythTV#7 0x00007ffff0ff3fa3 in start_thread (arg=<optimized out>) at pthread_create.c:486
MythTV#8 0x00007ffff0bad4cf in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:95
Thread 1565 (Thread 0x7fff16ffd700 (LWP 13190)):
#0 syscall () at ../sysdeps/unix/sysv/linux/x86_64/syscall.S:38
MythTV#1 0x00007ffff10c2995 in QBasicMutex::lockInternal() () from /lib/x86_64-linux-gnu/libQt5Core.so.5
MythTV#2 0x00007ffff5a49bb0 in QMutexLocker::QMutexLocker (this=0x7fff16ffcc80, m=0x7ffee401fd00) at /usr/include/x86_64-linux-gnu/qt5/QtCore/qmutex.h:206
<...>
QMutexLocker lock(&m_stream_lock);
MythTV#6 0x00007ffff61b055e in HLSReader::PlaylistRetrying (this=0x7fffc8023b20) at recorders/HLS/HLSReader.cpp:1025
<...>
MythTV#12 0x00007ffff619d791 in HLSPlaylistWorker::run (this=0x7fff0806fc60) at recorders/HLS/HLSPlaylistWorker.cpp:83
MythTV#13 0x00007ffff55a3c1c in MThreadInternal::run (this=0x7fff081082a0) at mthread.cpp:79
MythTV#14 0x00007ffff10cfa07 in ?? () from /lib/x86_64-linux-gnu/libQt5Core.so.5
MythTV#15 0x00007ffff0ff3fa3 in start_thread (arg=<optimized out>) at pthread_create.c:486
MythTV#16 0x00007ffff0bad4cf in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:95
Signed-off-by: Ian Campbell <ijc@hellion.org.uk>
This was referenced Oct 24, 2020
This was referenced Oct 31, 2020
kmdewaal
referenced
this pull request
Apr 27, 2021
Using the same json format returned by Dvr::GetRecorded(), allow a recording to be imported into the MythTV system. Useful if you have a few favorites you want to back up which may be hard to find otherwise.
kmdewaal
added a commit
that referenced
this pull request
Oct 6, 2021
Recode the logic in the PAT handling for the Single Program Transport Stream. SPTS without a valid program ID is a supported format used by IPTV and ExternalRecorder. Error messages like the following: 2021-10-04 21:41:48.522019 E [908876/909057] ExternSH recorders/dtvsignalmonitor.cpp:328 (HandlePAT) - DTVSigMon[12]: Program #1 not found in PAT! Program Association Section PSIP tableID(0x0) length(13) extension(0x807) version(0) current(1) section(0) last_section(0) tsid(2055) programCount(1) program number 19043 has PID 0x0a28 2021-10-04 21:41:48.522021 E [908876/909057] ExternSH recorders/dtvsignalmonitor.cpp:333 (HandlePAT) - DTVSigMon[12]: But there is only one program in the PAT, so we'll just use it which were given on every channel change have now been replaced by an informational message like this: 2021-10-06 17:02:24.020853 I DTVSigMon[12]: Program 19043 found in PAT of SPTS The error message is still given when a program cannot be found in a stream with multiple programs and in that case the recording fails.
linuxdude42
added a commit
to linuxdude42/mythtv
that referenced
this pull request
Aug 8, 2024
1) The clang-analyzer-unix.Stream checker warns that the file position of the stream might be "indeterminate" after a failed operation, which can cause undefined behavior. The code is correct, but the GCC attribute indicating that a function never returns isn't being used. Restoring these markings eliminates the warning. 2) Remove the check for GCC version less than 3 (aka the year 2001). 3) After fixing MythTV#1, tidy now indicates there is a potential resource leak in the error handling. Add a call to close a file descriptor before returning. https://clang.llvm.org/docs/analyzer/checkers.html#unix-stdclibraryfunctions
linuxdude42
added a commit
to linuxdude42/mythtv
that referenced
this pull request
Aug 8, 2024
1) The clang-analyzer-unix.Stream checker warns that the file position of the stream might be "indeterminate" after a failed operation, which can cause undefined behavior. The code is correct, but the GCC attribute indicating that a function never returns isn't being used. Restoring these markings eliminates the warning. 2) Remove the check for GCC version less than 3 (aka the year 2001). 3) After fixing MythTV#1, tidy now indicates there is a potential resource leak in the error handling. Add a call to close a file descriptor before returning. https://clang.llvm.org/docs/analyzer/checkers.html#unix-stdclibraryfunctions
linuxdude42
added a commit
to linuxdude42/mythtv
that referenced
this pull request
Aug 9, 2024
1) The clang-analyzer-unix.Stream checker warns that the file position of the stream might be "indeterminate" after a failed operation, which can cause undefined behavior. The code is correct, but the GCC attribute indicating that a function never returns isn't being used. Restoring these markings eliminates the warning. 2) Remove the check for GCC version less than 3 (aka the year 2001). 3) After fixing MythTV#1, tidy now indicates there is a potential resource leak in the error handling. Add a call to close a file descriptor before returning. https://clang.llvm.org/docs/analyzer/checkers.html#unix-stdclibraryfunctions
linuxdude42
added a commit
to linuxdude42/mythtv
that referenced
this pull request
Aug 9, 2024
1) The clang-analyzer-unix.Stream checker warns that the file position of the stream might be "indeterminate" after a failed operation, which can cause undefined behavior. The code is correct, but the GCC attribute indicating that a function never returns isn't being used. Restoring these markings eliminates the warning. 2) Remove the check for GCC version less than 3 (aka the year 2001). 3) After fixing MythTV#1, tidy now indicates there is a potential resource leak in the error handling. Add a call to close a file descriptor before returning. https://clang.llvm.org/docs/analyzer/checkers.html#unix-stdclibraryfunctions
linuxdude42
added a commit
to linuxdude42/mythtv
that referenced
this pull request
Aug 9, 2024
1) The clang-analyzer-unix.Stream checker warns that the file position of the stream might be "indeterminate" after a failed operation, which can cause undefined behavior. The code is correct, but the GCC attribute indicating that a function never returns isn't being used. Restoring these markings eliminates the warning. 2) Remove the check for GCC version less than 3 (aka the year 2001). 3) After fixing MythTV#1, tidy now indicates there is a potential resource leak in the error handling. Add a call to close a file descriptor before returning. https://clang.llvm.org/docs/analyzer/checkers.html#unix-stdclibraryfunctions
linuxdude42
added a commit
to linuxdude42/mythtv
that referenced
this pull request
Aug 9, 2024
1) The clang-analyzer-unix.Stream checker warns that the file position of the stream might be "indeterminate" after a failed operation, which can cause undefined behavior. The code is correct, but the GCC attribute indicating that a function never returns isn't being used. Restoring these markings eliminates the warning. 2) Remove the check for GCC version less than 3 (aka the year 2001). 3) After fixing MythTV#1, tidy now indicates there is a potential resource leak in the error handling. Add a call to close a file descriptor before returning. https://clang.llvm.org/docs/analyzer/checkers.html#unix-stdclibraryfunctions
linuxdude42
added a commit
to linuxdude42/mythtv
that referenced
this pull request
Aug 9, 2024
1) The clang-analyzer-unix.Stream checker warns that the file position of the stream might be "indeterminate" after a failed operation, which can cause undefined behavior. The code is correct, but the GCC attribute indicating that a function never returns isn't being used. Restoring these markings eliminates the warning. 2) Remove the check for GCC version less than 3 (aka the year 2001). 3) After fixing MythTV#1, tidy now indicates there is a potential resource leak in the error handling. Add a call to close a file descriptor before returning. https://clang.llvm.org/docs/analyzer/checkers.html#unix-stdclibraryfunctions
linuxdude42
added a commit
to linuxdude42/mythtv
that referenced
this pull request
Aug 9, 2024
1) The clang-analyzer-unix.Stream checker warns that the file position of the stream might be "indeterminate" after a failed operation, which can cause undefined behavior. The code is correct, but the GCC attribute indicating that a function never returns isn't being used. Restoring these markings eliminates the warning. 2) Remove the check for GCC version less than 3 (aka the year 2001). 3) After fixing MythTV#1, tidy now indicates there is a potential resource leak in the error handling. Add a call to close a file descriptor before returning. https://clang.llvm.org/docs/analyzer/checkers.html#unix-stdclibraryfunctions
linuxdude42
added a commit
to linuxdude42/mythtv
that referenced
this pull request
Aug 10, 2024
1) The clang-analyzer-unix.Stream checker warns that the file position of the stream might be "indeterminate" after a failed operation, which can cause undefined behavior. The code is correct, but the GCC attribute indicating that a function never returns isn't being used. Restoring these markings eliminates the warning. 2) Remove the check for GCC version less than 3 (aka the year 2001). 3) After fixing MythTV#1, tidy now indicates there is a potential resource leak in the error handling. Add a call to close a file descriptor before returning. https://clang.llvm.org/docs/analyzer/checkers.html#unix-stdclibraryfunctions
linuxdude42
added a commit
to linuxdude42/mythtv
that referenced
this pull request
Aug 10, 2024
1) The clang-analyzer-unix.Stream checker warns that the file position of the stream might be "indeterminate" after a failed operation, which can cause undefined behavior. The code is correct, but the GCC attribute indicating that a function never returns isn't being used. Restoring these markings eliminates the warning. 2) Remove the check for GCC version less than 3 (aka the year 2001). 3) After fixing MythTV#1, tidy now indicates there is a potential resource leak in the error handling. Add a call to close a file descriptor before returning. https://clang.llvm.org/docs/analyzer/checkers.html#unix-stdclibraryfunctions
linuxdude42
added a commit
to linuxdude42/mythtv
that referenced
this pull request
Aug 10, 2024
1) The clang-analyzer-unix.Stream checker warns that the file position of the stream might be "indeterminate" after a failed operation, which can cause undefined behavior. The code is correct, but the GCC attribute indicating that a function never returns isn't being used. Restoring these markings eliminates the warning. 2) Remove the check for GCC version less than 3 (aka the year 2001). 3) After fixing MythTV#1, tidy now indicates there is a potential resource leak in the error handling. Add a call to close a file descriptor before returning. https://clang.llvm.org/docs/analyzer/checkers.html#unix-stdclibraryfunctions
This pull request was closed.
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
http://svn.mythtv.org/trac/ticket/8182