Bug 589146 – crash in rhythmbox with pulse audio output

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


Summary:	crash in rhythmbox with pulse audio output


Status:	RESOLVED INCOMPLETE

Product:	GStreamer
Classification:	Platform
Component:	gst-plugins-good
Version:	0.10.15
Hardware:	Other Linux

Importance:	Normal critical
Target Milestone:	git master
Assigned To:	GStreamer Maintainers
QA Contact:	GStreamer Maintainers

URL:
Whiteboard:

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:

+ Trace 216544

#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.

+ Trace 216579

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?