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 589146 - crash in rhythmbox with pulse audio output
crash in rhythmbox with pulse audio output
Status: RESOLVED INCOMPLETE
Product: GStreamer
Classification: Platform
Component: gst-plugins-good
0.10.15
Other Linux
: Normal critical
: git master
Assigned To: GStreamer Maintainers
GStreamer Maintainers
Depends on:
Blocks:
 
 
Reported: 2009-07-20 15:58 UTC by Götz Waschk
Modified: 2011-04-26 12:05 UTC
See Also:
GNOME target: ---
GNOME version: 2.27/2.28


Attachments
gdb backtrace as requested (21.29 KB, text/plain)
2009-10-21 22:16 UTC, Colin Guthrie
Details
Full backtrace (36.74 KB, text/plain)
2009-10-21 22:16 UTC, Colin Guthrie
Details

Description Götz Waschk 2009-07-20 15:58:19 UTC
A Mandriva user has reported a crash in rhythmbox on song change here:
https://qa.mandriva.com/show_bug.cgi?id=52346

This is the crash dump:
  • #0 raise
    at ../nptl/sysdeps/unix/sysv/linux/raise.c line 64
  • #1 abort
    at abort.c line 88
  • #2 IA__g_assertion_message
  • #3 IA__g_assertion_message_expr
    at gtestutils.c line 1312
  • #4 gst_pulsesink_init
    at pulsesink.c line 1391
  • #5 IA__g_type_create_instance
    at gtype.c line 1674
  • #6 g_object_constructor
    at gobject.c line 1338
  • #7 IA__g_object_newv
    at gobject.c line 1215
  • #8 IA__g_object_new_valist
    at gobject.c line 1278
  • #9 IA__g_object_new
    at gobject.c line 1060
  • #10 gst_element_factory_create
    at gstelementfactory.c line 385
  • #11 gst_auto_audio_sink_change_state
    at gstautoaudiosink.c line 235
  • #12 gst_element_change_state
    at gstelement.c line 2426
  • #13 gst_element_set_state_func
    at gstelement.c line 2382
  • #14 gst_bin_change_state_func
    at gstbin.c line 2035
  • #15 gst_element_change_state
    at gstelement.c line 2426
  • #16 gst_element_set_state_func
    at gstelement.c line 2382
  • #17 gst_switch_sink_set_child
    at gstswitchsink.c line 161
  • #18 do_change_child
    at gstgconfaudiosink.c line 198
  • #19 gst_gconf_audio_sink_change_state
    at gstgconfaudiosink.c line 290
  • #20 gst_element_change_state
    at gstelement.c line 2426
  • #21 gst_element_set_state_func
    at gstelement.c line 2382
  • #22 gst_bin_change_state_func
    at gstbin.c line 2035
  • #23 gst_element_change_state
    at gstelement.c line 2426
  • #24 gst_element_set_state_func
    at gstelement.c line 2382
  • #25 gst_play_sink_reconfigure
    at gstplaysink.c line 1550
  • #26 no_more_pads_cb
    at gstplaybin2.c line 1991
  • #27 IA__g_closure_invoke
    at gclosure.c line 767
  • #28 signal_emit_unlocked_R
    at gsignal.c line 3247
  • #29 IA__g_signal_emit_valist
    at gsignal.c line 2980
  • #30 IA__g_signal_emit
    at gsignal.c line 3037
  • #31 IA__g_closure_invoke
    at gclosure.c line 767
  • #32 signal_emit_unlocked_R
    at gsignal.c line 3247
  • #33 IA__g_signal_emit_valist
    at gsignal.c line 2980
  • #34 IA__g_signal_emit
    at gsignal.c line 3037
  • #35 gst_decode_group_expose
    at gstdecodebin2.c line 2192
  • #36 source_pad_blocked_cb
    at gstdecodebin2.c line 2455
  • #37 handle_pad_block
    at gstpad.c line 3823
  • #38 gst_pad_push_event
    at gstpad.c line 4554
  • #39 gst_pad_send_event
    at gstpad.c line 4721
  • #40 gst_pad_push_event
    at gstpad.c line 4577
  • #41 ??
    from /usr/lib64/gstreamer-0.10/libgstmad.so
  • #42 gst_pad_send_event
    at gstpad.c line 4721
  • #43 gst_pad_push_event
    at gstpad.c line 4577
  • #44 ??
    from /usr/lib64/gstreamer-0.10/libgstmpegaudioparse.so
  • #45 gst_pad_chain_unchecked
    at gstpad.c line 3977
  • #46 gst_pad_push
    at gstpad.c line 4144
  • #47 gst_tag_demux_chain
    at gsttagdemux.c line 692
  • #48 gst_pad_chain_unchecked
    at gstpad.c line 3977
  • #49 gst_pad_push
    at gstpad.c line 4144
  • #50 gst_type_find_element_chain
    at gsttypefindelement.c line 688
  • #51 gst_pad_chain_unchecked
    at gstpad.c line 3977
  • #52 gst_pad_push
    at gstpad.c line 4144
  • #53 gst_pad_chain_unchecked
    at gstpad.c line 3977
  • #54 gst_pad_push
    at gstpad.c line 4144
  • #55 gst_base_src_loop
    at gstbasesrc.c line 2279
  • #56 gst_task_func
    at gsttask.c line 172
  • #57 g_thread_pool_thread_proxy
    at gthreadpool.c line 265
  • #58 g_thread_create_proxy
    at gthread.c line 635
  • #59 start_thread
    from /lib64/libpthread.so.0
  • #60 clone
    at ../sysdeps/unix/sysv/linux/x86_64/clone.S line 112
  • #61 ??

Comment 1 Christophe Fergeau 2009-07-22 22:16:37 UTC
Here is an excerpt from #fedora-desktop (23/07/2009 around 17:00 UTC)

19:03 <@mccann> warren, mezcalero: http://fpaste.org/paste/19559

19:07 < mezcalero> mccann: hmm?

19:07 < mezcalero> mccann: under no circumstances pa_threaded_mainloop_new can 

                   fail

19:08 <@mccann> oh this was a pidgin crash

19:08 < mezcalero> mccann: the only reason why that call could fail is if 

                   pipe() fails

19:09 < mezcalero> mccann: which afaics can only happen if you run out of fds

19:09 < mezcalero> i.e. something's leaking fds

19:09 < mezcalero> mccann: any chance you can verify that?

19:09 <@mccann> how?

19:09 < mezcalero> just check /proc/$PID/fd

19:10 < mezcalero> i.e. while you are still hanging in gdb

19:10 < mezcalero> that dir shows how many fds are open

19:10 <@mccann> ok i'll just install more debuginfo and wait til it happens 

                again





http://fpaste.org/paste/19559 is:
which aborts on the same assertion as the backtrace from this bug

Program received signal SIGABRT, Aborted.

Thread 140039793871120 (LWP 2882)

  • #0 *__GI_raise
    at ../nptl/sysdeps/unix/sysv/linux/raise.c line 64
  • #1 *__GI_abort
    at abort.c line 92
  • #2 IA__g_assertion_message
  • #3 IA__g_assertion_message_expr
    at gtestutils.c line 1312
  • #4 gst_caps_is_any
    at gstcaps.c line 926
  • #5 ??
  • #6 ??
  • #7 ??
  • #8 IA__g_type_create_instance
    at gtype.c line 1674
  • #9 g_object_constructor
    at gobject.c line 1338
  • #10 IA__g_object_newv
    at gobject.c line 1215
  • #11 ??
  • #12 ??
  • #13 ??
  • #14 ??

Comment 2 Wim Taymans 2009-08-24 15:14:30 UTC
GStreamer currently stops and frees the mainloop (and its fds) when the pulsesink element is finalized. If there would be a refcount leak of pulsesink, we would use up all fds. Hard to tell without more info. 

It could be interesting to attach gdb to the process after it has run for some time and do "info thr" to check the amount of active threads.
Comment 3 Wim Taymans 2009-09-09 16:41:47 UTC
can you attach a gdb thr apply all bt after playing a couple of songs? This would show a lot of threads if there is a leak.
Comment 4 mft 2009-09-10 08:11:08 UTC
>>  < mezcalero> just check /proc/$PID/fd

I held down "next" so that there were many many track changes in succession and fds indeed go into the hundreds after a few seconds.

>>  can you attach a gdb thr apply all bt after playing a couple of songs?

I don't know enough about gdb.
Comment 5 Colin Guthrie 2009-10-21 22:16:06 UTC
Created attachment 145997 [details]
gdb backtrace as requested

Here's a basic backtrace. I've not got all symbols installed so just shout if the critical detail is missing and I'll install them. This is very easy to reproduce. FWIW, I don't acutally use this app, but I've had this bug open in my browser for yonks and figured I could easily give the info needed :)
Comment 6 Colin Guthrie 2009-10-21 22:16:43 UTC
Created attachment 145998 [details]
Full backtrace
Comment 7 Tobias Mueller 2010-04-10 19:29:57 UTC
Reopening as the stacktrace have been provided.
Comment 8 Sebastian Dröge (slomo) 2010-04-12 09:05:05 UTC
There is no crash at all in the two latest backtraces... OTOH there are *many* pulse mainloops in the attached backtraces so something is really going wrong here.

Maybe things crash because too many pulse clients are used and use too much shmem?
Comment 9 Benjamin Otte (Company) 2010-05-05 19:39:56 UTC
I raise you a https://bugzilla.redhat.com/show_bug.cgi?id=589285
Comment 10 Benjamin Otte (Company) 2010-05-05 19:43:08 UTC
Hrm, this seems like it's a different bug, I somehow assumed they affected each other.
Comment 11 Arun Raghavan 2011-03-09 18:08:54 UTC
Is this bug still present?