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 314076 - Playbin segfault when switching from READY to PAUSED state
Playbin segfault when switching from READY to PAUSED state
Status: RESOLVED FIXED
Product: GStreamer
Classification: Platform
Component: gst-plugins
0.8.x
Other All
: High critical
: 0.8.12
Assigned To: GStreamer Maintainers
GStreamer Maintainers
Depends on:
Blocks:
 
 
Reported: 2005-08-21 12:22 UTC by Raphael Slinckx
Modified: 2005-09-24 17:02 UTC
See Also:
GNOME target: ---
GNOME version: 2.11/2.12


Attachments
Test case (2.02 KB, text/plain)
2005-08-21 12:26 UTC, Raphael Slinckx
  Details
Simplified Test Case (1.09 KB, text/plain)
2005-08-24 14:06 UTC, Raphael Slinckx
  Details
Updated valgrind output (7.47 KB, text/plain)
2005-08-24 14:10 UTC, Raphael Slinckx
  Details
Multifdsink patch (41.96 KB, patch)
2005-08-24 15:22 UTC, Raphael Slinckx
none Details | Review
gst-multi.patch (1.15 KB, patch)
2005-08-31 11:56 UTC, Raphael Slinckx
none Details | Review
add a finalize function (2.04 KB, patch)
2005-09-23 13:35 UTC, Luca Ognibene
none Details | Review

Description Raphael Slinckx 2005-08-21 12:22:23 UTC
Steps to reproduce:
1. Modify the media filename in the test case
2. Compile using:
gcc $(pkg-config --libs --cflags gstreamer-0.8 ) gst-test.c -o gst-test
3. Run gst-test

I manage to crash it at attempt 3 most of he time, other people report 10 or 2à
attempts, while thomasvs didn't got any crash.

I think it's a race condition, given these random reproducability problems.

Stack trace:
Program received signal SIGSEGV, Segmentation fault.

Thread 16384 (LWP 24145)

  • #0 IA__g_hash_table_destroy
    at ghash.c line 179
  • #1 gst_multifdsink_close
    at gstmultifdsink.c line 1709
  • #2 gst_multifdsink_change_state
    at gstmultifdsink.c line 1742
  • #3 gst_element_set_state_func
    at gstelement.c line 2872
  • #4 gst_element_set_state
    at gstelement.c line 2815
  • #5 set_kid_state_func
    at gstbin.c line 841
  • #6 gst_bin_foreach
    at gstbin.c line 805
  • #7 gst_bin_change_state
    at gstbin.c line 903
  • #8 gst_element_set_state_func
    at gstelement.c line 2872
  • #9 gst_bin_set_state
    at gstbin.c line 950
  • #10 gst_element_set_state
    at gstelement.c line 2815
  • #11 gst_play_bin_change_state
    at gstplaybin.c line 878
  • #12 gst_element_set_state_func
    at gstelement.c line 2872
  • #13 gst_element_set_state
    at gstelement.c line 2815
  • #14 tick
  • #15 g_timeout_dispatch
    at gmain.c line 3293
  • #16 g_main_dispatch
    at gmain.c line 1934
  • #17 IA__g_main_context_dispatch
    at gmain.c line 2484
  • #18 g_main_context_iterate
    at gmain.c line 2565
  • #19 IA__g_main_loop_run
    at gmain.c line 2769
  • #20 gst_main
    at gst.c line 864
  • #21 main

Other information:
Valgrind's output: http://pastebin.ca/raw/20422
Comment 1 Raphael Slinckx 2005-08-21 12:26:45 UTC
Created attachment 51058 [details]
Test case

The simple testcase, a playbin with a bin as audio sink, which in turn contains
a tee giving the output to both alsa and a tcpserversink.

The serversink is causing a segfault in g_hash_table_destroy
Comment 2 Christian Kirbach 2005-08-22 08:34:44 UTC
unique stack trace
Comment 3 Raphael Slinckx 2005-08-24 14:06:16 UTC
Created attachment 51259 [details]
Simplified Test Case

Same one, but remove unnecessary cruft, same backtrace
Comment 4 Raphael Slinckx 2005-08-24 14:10:56 UTC
Created attachment 51260 [details]
Updated valgrind output

This is the valgrind --trace-children output
Comment 5 Colin Walters 2005-08-24 14:27:12 UTC
Hmm...I don't think multifdsink should be calling g_hash_table_destroy in its
_close method.  Or if it should be, it should be doing the g_hash_table_new in
its init_send method.  It seems to me that currently if multifdsink transitions
to NULL->READY->NULL->READY, you'll get a double-free of the hash.
Comment 6 Raphael Slinckx 2005-08-24 15:22:48 UTC
Created attachment 51265 [details] [review]
Multifdsink patch

This fixes the problem.

I love Colin.
Comment 7 Wim Taymans 2005-08-24 15:36:09 UTC
yes, indeed,  but also the CLIENTS_LOCK_FREE in the stop method is not correctly
INITED again.
Comment 8 Wim Taymans 2005-08-24 15:38:01 UTC
also the bufqueue is leaked...
Comment 9 Raphael Slinckx 2005-08-24 17:54:45 UTC
Is it ok to introduce a gst_multifdsink_finalize, where you can free the bufqueue ?

I moved CLIENTS_LOCK_INIT(this) to the init_send function
Comment 10 Raphael Slinckx 2005-08-31 11:56:32 UTC
Created attachment 51607 [details] [review]
gst-multi.patch

This one fixes the lock init and hashtable double free.

I don't know how to fix the leak, though.
Comment 11 Luca Ognibene 2005-09-23 13:35:08 UTC
Created attachment 52547 [details] [review]
add a finalize function

Add a finalize function to the previous patch so we can free the array
Comment 12 Luca Ognibene 2005-09-24 17:02:55 UTC
committed. thanks!