High sample rate wavpack fails, higher sample rate crashes #6302
Comments
|
I am able to reproduce this. Clementine is handling a pad-added signal after it has already handled the error message from GST. In the pad-added handler, it tries to call a method in a member that was freed in the error handler. |
jbroadus
added a commit
to jbroadus/Clementine
that referenced
this issue
Mar 11, 2019
As reported in issue 6302, playing a stream that causes gstreamer to error at start can cause a crash. The problem occurs when the MoodbarPipeline receives a pad-added signal after it has handled an error callback. In the error callback, the builder_ is freed. In the pad-added handler (NewBufferCallback), this object is accessed. This change adds a MoodbarPipeline::IsRunning that uses the existance of builder_ to determine if the pipeline should be running. In NewBufferCallback, check the result of that method before doing anything else. See clementine-player#6302
jbroadus
added a commit
to jbroadus/Clementine
that referenced
this issue
Mar 18, 2019
As reported in issue 6302, playing a stream that causes gstreamer to error at start can cause a crash. The problem occurs when the MoodbarPipeline receives a pad-added signal after it has handled an error callback. In the error callback, the builder_ is freed. In the pad-added handler (NewPadCallback), this object is accessed. This change adds a running_ flag that we is set when the pipeline is started and cleared on an error. We check this flag at the beginning of NewPadCallback. For sanity sake, we also check the builder_ pointer before dereferencing. This solution is not complete as there still some syncronization issues. With this specific situation, the error and new pad callbacks appear to always occur on the same thread, but it's probably not true for all error conditions. The object is also destroyed by a different thread, so it's possible that an async callback may occur at the wrong time during the deletion of the object. See clementine-player#6302
jbroadus
added a commit
to jbroadus/Clementine
that referenced
this issue
Mar 18, 2019
As reported in issue 6302, playing a stream that causes gstreamer to error at start can cause a crash. The problem occurs when the MoodbarPipeline receives a pad-added signal after it has handled an error callback. In the error callback, the builder_ is freed. In the pad-added handler (NewPadCallback), this object is accessed. This change adds a running_ flag that is set when the pipeline is started and cleared on an error, end of stream, or object destruction. We check this flag at the beginning of NewPadCallback. For sanity sake, we also check the builder_ pointer before dereferencing. Note that checking the state of the pipeline wasn't an option since the pipeline is in the process of changing states during the pad-added callback and gst_element_get_state wants to block during a state change. This solution is not complete as there are still some syncronization issues. With this specific situation, the error and new pad callbacks appear to always occur on the same thread, but that's probably not true for all error conditions. The object is also destroyed by a different thread, so it may be possible that a callback can occur at the wrong time during or after the deletion of the object. See clementine-player#6302
|
Note that PR 6308 only addresses the crash reported here. |
sjohannes
pushed a commit
to exaile/moodbar
that referenced
this issue
Jun 22, 2019
(Patch taken from Clementine rev 55edcf5321051e44281f067a7e3ee44871982c12. The following is the original commit message.) As reported in issue 6302, playing a stream that causes gstreamer to error at start can cause a crash. The problem occurs when the MoodbarPipeline receives a pad-added signal after it has handled an error callback. In the error callback, the builder_ is freed. In the pad-added handler (NewPadCallback), this object is accessed. This change adds a running_ flag that is set when the pipeline is started and cleared on an error, end of stream, or object destruction. We check this flag at the beginning of NewPadCallback. For sanity sake, we also check the builder_ pointer before dereferencing. Note that checking the state of the pipeline wasn't an option since the pipeline is in the process of changing states during the pad-added callback and gst_element_get_state wants to block during a state change. This solution is not complete as there are still some syncronization issues. With this specific situation, the error and new pad callbacks appear to always occur on the same thread, but that's probably not true for all error conditions. The object is also destroyed by a different thread, so it may be possible that a callback can occur at the wrong time during or after the deletion of the object. See clementine-player/Clementine#6302
sjohannes
pushed a commit
to exaile/moodbar
that referenced
this issue
Aug 31, 2020
As reported in issue 6302, playing a stream that causes gstreamer to error at start can cause a crash. The problem occurs when the MoodbarPipeline receives a pad-added signal after it has handled an error callback. In the error callback, the builder_ is freed. In the pad-added handler (NewPadCallback), this object is accessed. This change adds a running_ flag that is set when the pipeline is started and cleared on an error, end of stream, or object destruction. We check this flag at the beginning of NewPadCallback. For sanity sake, we also check the builder_ pointer before dereferencing. Note that checking the state of the pipeline wasn't an option since the pipeline is in the process of changing states during the pad-added callback and gst_element_get_state wants to block during a state change. This solution is not complete as there are still some syncronization issues. With this specific situation, the error and new pad callbacks appear to always occur on the same thread, but that's probably not true for all error conditions. The object is also destroyed by a different thread, so it may be possible that a callback can occur at the wrong time during or after the deletion of the object. See clementine-player/Clementine#6302
sjohannes
pushed a commit
to exaile/moodbar
that referenced
this issue
Aug 31, 2020
(Patch taken from Clementine rev 55edcf5321051e44281f067a7e3ee44871982c12. The following is the original commit message.) As reported in issue 6302, playing a stream that causes gstreamer to error at start can cause a crash. The problem occurs when the MoodbarPipeline receives a pad-added signal after it has handled an error callback. In the error callback, the builder_ is freed. In the pad-added handler (NewPadCallback), this object is accessed. This change adds a running_ flag that is set when the pipeline is started and cleared on an error, end of stream, or object destruction. We check this flag at the beginning of NewPadCallback. For sanity sake, we also check the builder_ pointer before dereferencing. Note that checking the state of the pipeline wasn't an option since the pipeline is in the process of changing states during the pad-added callback and gst_element_get_state wants to block during a state change. This solution is not complete as there are still some syncronization issues. With this specific situation, the error and new pad callbacks appear to always occur on the same thread, but that's probably not true for all error conditions. The object is also destroyed by a different thread, so it may be possible that a callback can occur at the wrong time during or after the deletion of the object. See clementine-player/Clementine#6302
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
System information
Expected behaviour / actual behaviour
Playback of 176.4kHz and higher sample rates should be transparent. 176.4 stutters badly, stalling for many seconds at a time despite plenty of CPU reserve and the same file playing back fine on other media players (such as mpv.) 352.8kHz and higher sample rates (eg 705600) outright crash the player with some kind of gstreamer error
Backtrace:
Steps to reproduce the problem (only for bugs)
Create a 176 and 352 kHz 24 bit wavpack file from an existing file:
sox input.wav -b 24 output176.wv rate 176400
sox input.wav -b 24 output352.wv rate 352800
Add output files to playlist then playback.
The text was updated successfully, but these errors were encountered: