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 711791 - gst-inspect-1.0 hangs on libgsttranscode.so (GEntrans) / FUTEX_WAIT_PRIVATE
gst-inspect-1.0 hangs on libgsttranscode.so (GEntrans) / FUTEX_WAIT_PRIVATE
Status: RESOLVED INCOMPLETE
Product: GStreamer
Classification: Platform
Component: gstreamer (core)
1.2.0
Other Linux
: Normal normal
: git master
Assigned To: GStreamer Maintainers
GStreamer Maintainers
Depends on:
Blocks:
 
 
Reported: 2013-11-10 19:32 UTC by George Chriss
Modified: 2015-01-25 05:13 UTC
See Also:
GNOME target: ---
GNOME version: ---


Description George Chriss 2013-11-10 19:32:05 UTC 
Cross-posting here from: http://sourceforge.net/p/gentrans/bugs/4/

"Using the 'Open Video Reference Build', 'make install' for gentrans git checkout 9aec453 (master) causes gst-inspect-1.0 to hang on FUTEX_WAIT_PRIVATE [strace traces in orig. Sourceforge report].

I don't have a proposed solution but a search on FUTEX_WAIT_PRIVATE errors indicates that it's a subtle but show-stopping bug."

'Open Video Reference Build' = https://gitorious.org/openvideo_reference_build
Comment 1 Olivier Crête 2013-12-06 00:07:21 UTC 
Can't reproduce with GStreamer 1.2.1 and GEntrans 1.0 (as installed by Fedora 20). Can you attach gdb to it once this happens and see where it blocks ?
Comment 2 André Klapper 2015-01-24 09:03:50 UTC 
(In reply to comment #1)
> Can you attach gdb to it once this happens and see where it blocks ?

Hi George, 
I am closing this bug report as no updated information has been provided.
Please feel free to reopen this bug if you can provide the information that was asked for in a previous comment.
Comment 3 George Chriss 2015-01-25 05:13:13 UTC 
I've seen it intermittently over the past few months -- not specific to gsttranscode, appears to be a kernel-related race condition of some type: slowing down gst-inspect (verbose mode) via stdout flow control helps.

I'll post here if I can pin down the specific kernel revision number(s) that trigger the error.