After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 758861 - wavparse: deadlock under some conditions
wavparse: deadlock under some conditions
Status: RESOLVED FIXED
Product: GStreamer
Classification: Platform
Component: gst-plugins-good
git master
Other Linux
: Normal normal
: 1.6.2
Assigned To: GStreamer Maintainers
GStreamer Maintainers
Depends on:
Blocks:
 
 
Reported: 2015-11-30 17:12 UTC by Holger Kaelberer
Modified: 2015-12-01 14:35 UTC
See Also:
GNOME target: ---
GNOME version: ---


Attachments
wavparse: flush upstream when seeking in pull mode (1.31 KB, patch)
2015-12-01 03:04 UTC, Thiago Sousa Santos
committed Details | Review

Description Holger Kaelberer 2015-11-30 17:12:28 UTC
Playing back wav files through QtMultimedia on Linux leads sometimes to a deadlock in/below wavparse.

Not sure if this is a gstreamer-bug or a Qt-bug. But according to a quick look of thiagoss on IRC this might well be a gstreamer-bug.

This occurs both on gst 1.6.x and gst 0.10 (which is still the default for QtMultimedia).

Test-application and backtrace can be found in the corresponding ticket of QtMultimedia:

https://bugreports.qt.io/browse/QTBUG-49689
https://bugreports.qt.io/secure/attachment/52628/trace2.log
Comment 1 Olivier Crête 2015-11-30 20:19:06 UTC
I think the problem is in QtMultimedia, in QAppSrc, on the "need-data" signal, it uses QMetaObject::invokeMethod with  Qt::AutoConnection, which probably makes the call happen on the main thread. But the main thread is already busy doing the seek.
Comment 2 Thiago Sousa Santos 2015-11-30 20:21:30 UTC
There is also a bug in wavparse that it doesn't flush upstream, I'm working on this part.
Comment 3 Thiago Sousa Santos 2015-12-01 03:04:48 UTC
Created attachment 316568 [details] [review]
wavparse: flush upstream when seeking in pull mode

Makes sure upstream will unblock and return the thread so that
seeking can continue
Comment 4 Thiago Sousa Santos 2015-12-01 03:09:51 UTC
Would it be easy to have this flush-upstream check added to validate? Perhaps it would be useful to verify this for all our other demuxers.
Comment 5 Holger Kaelberer 2015-12-01 12:46:10 UTC
You are both right:

- Oliver: on_need_data() changes thread to the GUI thread via the QueuedConnection to pushDataToAppSrc, which seems weird from gstreamer's point of view. Might be because of the thread affinity of the QIODevice involved?

- thiagos: I can't reproduce the (dead)lock with your patch. Pls push if possible!

Thank you guys!
Comment 6 Thiago Sousa Santos 2015-12-01 14:35:31 UTC
commit 763a7e5265f95002eb85bdf57b2899499cd2f04a
Author: Thiago Santos <thiagoss@osg.samsung.com>
Date:   Tue Dec 1 00:03:21 2015 -0300

    wavparse: flush upstream when seeking in pull mode
    
    Makes sure upstream will unblock and return the thread so that
    seeking can continue
    
    https://bugzilla.gnome.org/show_bug.cgi?id=758861

Also merged to 1.6:
commit 9bbcec9191d655118e3b0b6d36aebf43b09d2e0d
Author: Thiago Santos <thiagoss@osg.samsung.com>
Date:   Tue Dec 1 00:03:21 2015 -0300

    wavparse: flush upstream when seeking in pull mode
    
    Makes sure upstream will unblock and return the thread so that
    seeking can continue
    
    https://bugzilla.gnome.org/show_bug.cgi?id=758861