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 141828 - gst-launch deadlocks
gst-launch deadlocks
Status: RESOLVED FIXED
Product: GStreamer
Classification: Platform
Component: gstreamer (core)
git master
Other Linux
: Normal normal
: NONE
Assigned To: GStreamer Maintainers
GStreamer Maintainers
Depends on:
Blocks:
 
 
Reported: 2004-05-04 16:47 UTC by Benjamin Otte (Company)
Modified: 2005-06-30 15:12 UTC
See Also:
GNOME target: ---
GNOME version: ---


Description Benjamin Otte (Company) 2004-05-04 16:47:42 UTC 
1) run gst-launch fakesrc ! fakesink
2) press ctrl-c
3) if (!deadlock) goto 1)

Eventually you'll end up here:

+ Trace 46633

  • #0 __pthread_sigsuspend
    at ../linuxthreads/sysdeps/unix/sysv/linux/pt-sigsuspend.c line 54
  • #1 __pthread_wait_for_restart_signal
    at pthread.c line 1203
  • #2 __pthread_alt_lock
    at restart.h line 34
  • #3 *__GI___pthread_mutex_lock
    at mutex.c line 123
  • #4 __libc_free
    at malloc.c line 3360
  • #5 g_free
    at gmem.c line 186
  • #6 g_get_charset
    at gutf8.c line 508
  • #7 g_print
    at gmessages.c line 950
  • #8 sigint_handler_sighandler
    at gst-launch.c line 289
  • #9 __pthread_sighandler
    at sighandler.c line 39
  • #10 <signal handler called>
  • #11 __libc_free
    at malloc.c line 3359
  • #12 g_free
    at gmem.c line 186
  • #13 gst_fakesink_chain
    at gstfakesink.c line 346
  • #14 gst_pad_call_chain_function
    at gstpad.c line 4317
  • #15 gst_pad_push
    at gstpad.c line 3155 






Comment 1


Stephane Loeuillet





          2004-12-12 18:52:02 UTC
        



on third test, it deadlocked for me too






Comment 2


Stephane Loeuillet





          2004-12-15 11:12:05 UTC
        



could this be a dupe of bug #149791 ?

gst-launch and fakesink used there too







Comment 3


Benjamin Otte (Company)





          2004-12-15 15:12:50 UTC
        



Nope, this is an issue with using print and malloc/free in a signal hamdler
which is not allowed.






Comment 4


David Schleef





          2004-12-15 18:46:56 UTC
        



Makes sense.  I moved the g_print() to main() and disabled the ones for SIGUSR1
and SIGUSR2.  The SIGUSRx handler could still cause deadlocks, since it
manipulates the core from a sighandler, which is not supported.