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 728596 - basesrc: A lock is released without being previously locked
basesrc: A lock is released without being previously locked
Product: GStreamer
Classification: Platform
Component: gstreamer (core)
Other FreeBSD
: Normal normal
: 1.2.5
Assigned To: GStreamer Maintainers
GStreamer Maintainers
Depends on:
Reported: 2014-04-20 09:54 UTC by Gustau Pérez i Querol
Modified: 2014-04-21 07:33 UTC
See Also:
GNOME target: ---
GNOME version: ---

Possible simple fix (986 bytes, patch)
2014-04-20 10:23 UTC, Gustau Pérez i Querol
rejected Details | Review

Description Gustau Pérez i Querol 2014-04-20 09:54:24 UTC
In libs/gst/base/gstbasesrc.c:2817 the src object gets unlocked without previously being locked. Because of that the app using gstreamer gets killed because of a wrong unlock in platforms like FreeBSD. 

The GST_LIVE_UNLOCK at the end calls g_mutex_unlock which then call pthread_mutex_unlock. Doing that call to pthread_mutex_unlock breaks badly in some platforms. 

One solution would be to try to lock before unlocking. If we already hold the mutex the pthread_mutex_lock will not block. That way the unlock will not fail.
Comment 1 Gustau Pérez i Querol 2014-04-20 09:55:01 UTC
This is the backtrace of the problem:

  • #0 thr_kill
    at thr_kill.S line 3
  • #1 abort
    at /usr/src/lib/libc/stdlib/abort.c line 65
  • #2 ??
    from /usr/local/lib/
  • #3 g_mutex_unlock
    from /usr/local/lib/
  • #4 gst_base_src_loop
    at gstbasesrc.c line 2818
  • #5 gst_task_func
    at gsttask.c line 316
  • #6 default_func
    at gsttaskpool.c line 70
  • #7 ??
    from /usr/local/lib/
  • #8 g_thread_proxy
    from /usr/local/lib/
  • #9 thread_start
    at /usr/src/lib/libthr/thread/thr_create.c line 284
  • #10 ??

Comment 2 Sebastian Dröge (slomo) 2014-04-20 10:01:34 UTC
commit 63c17280408410d799e1c2f2ed49c5ab04cc80ae
Author: Sebastian Dröge <>
Date:   Sun Apr 20 11:59:02 2014 +0200

    basesrc: Make sure to always hold the LIVE_LOCK when going to the flushing label
Comment 3 Gustau Pérez i Querol 2014-04-20 10:23:36 UTC
Created attachment 274752 [details] [review]
Possible simple fix
Comment 4 Sebastian Dröge (slomo) 2014-04-20 10:28:11 UTC
Comment on attachment 274752 [details] [review]
Possible simple fix

This would deadlock, this is not a recursive mutex and even then you would like to have the same number of unlocks as locks overall.

This is one possible fix:
Comment 5 Gustau Pérez i Querol 2014-04-21 07:33:17 UTC
Thank you, does also fine.