Hello,

I think above crash is a consecutive crash resulting from this stack trace:

Thread [1] 16033 [core: 0] (Suspended : Signal : SIGINT:Interrupt)	
	__kernel_vsyscall() at 0xf771b430	
	raise() at 0x43ed5b4e	
	rb_debug_stop_in_debugger() at rb-debug.c:282 0x41554149	
	log_handler() at rb-debug.c:299 0x415541b5	
	g_logv() at gmessages.c:545 0x4753726f	
	g_log() at gmessages.c:591 0x475375e4	
	g_return_if_fail_warning() at gmessages.c:600 0x4753784e	
	g_str_has_prefix() at gstrfuncs.c:2.944 0x4754fe1a	
	set_source_properties() at rb-audiocd-plugin.c:107 0xef4d84f5	
	rb_audiocd_plugin_prepare_player_source_cb() at rb-audiocd-plugin.c:140 0xef4d84f5	
	rb_marshal_VOID__STRING_OBJECT() at rb-marshal.c:2.253 0x41564cd2	
	g_closure_invoke() at gclosure.c:774 0x4732a645	
	signal_emit_unlocked_R() at gsignal.c:3.272 0x4733d860	
	g_signal_emit_valist() at gsignal.c:3.003 0x473462ff	
	g_signal_emit() at gsignal.c:3.060 0x47346464	
	source_notify_cb() at rb-player-gst.c:618 0x41551687	
	g_cclosure_marshal_VOID__PARAM() at gmarshal.c:539 0x4732c5cb	
	g_closure_invoke() at gclosure.c:774 0x4732a645	
	signal_emit_unlocked_R() at gsignal.c:3.272 0x4733d860	
	g_signal_emit_valist() at gsignal.c:3.003 0x473462ff	
	g_signal_emit() at gsignal.c:3.060 0x47346464	
	g_object_dispatch_properties_changed() at gobject.c:925 0x4732d837	
	gst_object_dispatch_properties_changed() at gstobject.c:530 0xf753af92	
	g_object_notify_dispatcher() at gobject.c:331 0x4732ccb0	
	g_object_notify_queue_thaw() at gobjectnotifyqueue.c:132 0x4732fa62	
	g_object_notify_by_spec_internal() at gobject.c:983 0x4732fa62	
	g_object_notify() at gobject.c:1.024 0x4732fa62	
	notify_source_cb() at gstplaybin2.c:3.451 0xef1ca938	
	g_cclosure_marshal_VOID__PARAM() at gmarshal.c:539 0x4732c5cb	
	g_closure_invoke() at gclosure.c:774 0x4732a645	
	signal_emit_unlocked_R() at gsignal.c:3.272 0x4733d860	
	g_signal_emit_valist() at gsignal.c:3.003 0x473462ff	
	g_signal_emit() at gsignal.c:3.060 0x47346464	
	g_object_dispatch_properties_changed() at gobject.c:925 0x4732d837	
	gst_object_dispatch_properties_changed() at gstobject.c:530 0xf753af92	
	g_object_notify_dispatcher() at gobject.c:331 0x4732ccb0	
	g_object_notify_queue_thaw() at gobjectnotifyqueue.c:132 0x4732fa62	
	g_object_notify_by_spec_internal() at gobject.c:983 0x4732fa62	
	g_object_notify() at gobject.c:1.024 0x4732fa62	
	setup_source() at gsturidecodebin.c:2.015 0xeef29c4a	
	gst_uri_decode_bin_change_state() at gsturidecodebin.c:2.493 0xeef29c4a	
	gst_element_change_state() at gstelement.c:2.761 0xf7558a9b	
	gst_element_set_state_func() at gstelement.c:2.717 0xf75594c5	
	gst_element_set_state() at gstelement.c:2.618 0xf75587d1	
	gst_bin_element_set_state() at gstbin.c:2.209 0xf7543c0e	
	gst_bin_change_state_func() at gstbin.c:2.518 0xf7543c0e	
	gst_pipeline_change_state() at gstpipeline.c:482 0xf757c2fa	
	gst_play_bin_change_state() at gstplaybin2.c:3.942 0xef1ccd99	
	gst_element_change_state() at gstelement.c:2.761 0xf7558a9b	
	gst_element_set_state_func() at gstelement.c:2.717 0xf75594c5	
	gst_element_set_state() at gstelement.c:2.618 0xf75587d1	
	start_state_change() at rb-player-gst.c:382 0x41552092	
	impl_close() at rb-player-gst.c:761 0x41552f56	
	rb_player_close() at rb-player.c:398 0x41543344	
	bus_cb() at rb-player-gst.c:509 0x4155265a	
	gst_bus_source_dispatch() at gstbus.c:764 0xf7548587	
	g_main_dispatch() at gmain.c:2.441 0x4752e62f	
	g_main_context_dispatch() at gmain.c:3.011 0x4752e62f	
	g_main_context_iterate() at gmain.c:3.089 0x4752ed70	
	g_main_loop_run() at gmain.c:3.297 0x4752f3a7	
	gtk_main() at gtkmain.c:1.362 0x41159155	
	main() at main.c:324 0x804a2e4	

I think this is happening:

bus_cb(): receives an error and try to close the player:

		/* close if not already closing */
		if (mp->priv->uri != NULL)
->			rb_player_close (RB_PLAYER (mp), NULL, NULL);

this will lead to a call to impl_close() that will set the player uri to NULL:
	mp->priv->uri = NULL;
	mp->priv->prev_uri = NULL;

and will call this state change
	if (mp->priv->playbin != NULL) {
->		start_state_change (mp, GST_STATE_NULL, PLAYER_SHUTDOWN);
	}

the state change will trigger gst_uri_decode_bin_change_state():

  switch (transition) {
    case GST_STATE_CHANGE_READY_TO_PAUSED:
->   if (!setup_source (decoder))
        goto source_failed;
      break;
    default:
      break;
  }

that method changes the current source via setup_source():
    /* notify of the new source used */
->  g_object_notify (G_OBJECT (decoder), "source");

this will notify notify_source_cb() in playbin2:
  GST_OBJECT_LOCK (playbin);
  if (playbin->source)
    gst_object_unref (playbin->source);
  playbin->source = source;
  GST_OBJECT_UNLOCK (playbin);

->  g_object_notify (G_OBJECT (playbin), "source");

playbin2 wants to notify all(?) dependent object of the source change in source_notify_cb():

static void
source_notify_cb (GObject *object, GParamSpec *pspec, RBPlayerGst *player)
{
	GstElement *source;
	g_object_get (object, "source", &source, NULL);

->	g_signal_emit (player, signals[PREPARE_SOURCE], 0, player->priv->uri, source);

remember player->priv->uri was set to NULL in impl_close()!

the next object that is triggered is rb_audiocd_plugin_prepare_player_source_cb():

rb_audiocd_plugin_prepare_player_source_cb (RBPlayer *player,
					    const char *stream_uri,
					    GstElement *source,
					    RBAudioCdPlugin *plugin)
{
->	set_source_properties (source, stream_uri, TRUE);
}

set_source_properties() will call 

set_source_properties (GstElement *source, const char *uri, gboolean playback_mode)
{
	const char *device;

->	if (g_str_has_prefix (uri, "cdda://") == FALSE)
		return;

which will trigger this asserion:

g_str_has_prefix (const gchar  *str,
                  const gchar  *prefix)
{
  int str_len;
  int prefix_len;

->  g_return_val_if_fail (str != NULL, FALSE);

after that the rhythmbox application hangs, two seconds before the end of the song. when I now double click on "all artist/songs" again the first crash reported in this bug is triggered.

Thomas - this sounds like the bug is in rhythmbox then? (doing g_str_has_prefix() on a NULL uri)


> bus_cb(): receives an error and try to close the player:
> this will lead to a call to impl_close() that will set the player uri to NULL:
> and will call this state change
>     if (mp->priv->playbin != NULL) {
> ->        start_state_change (mp, GST_STATE_NULL, PLAYER_SHUTDOWN);
>     }
> 
> the state change will trigger gst_uri_decode_bin_change_state():
> 
>   switch (transition) {
>     case GST_STATE_CHANGE_READY_TO_PAUSED:
> ->   if (!setup_source (decoder))
>         goto source_failed;
>       break;
>     default:
>       break;
>   }

This doesn't seem right - why does shutting down the pipeline lead to an *upwards* state change? it should be PAUSED_TO_READY or READY_TO_NULL.

I'm not sure yet where the bug is... when removing the audiocd plugin, which triggers the assertion error, rhythmbox just hangs two seconds before the song ends. no assertion, nothing. It just get's stuck. pressing pause, play, or dobule-clicking an different song doesn't do anything! i'm not sure how to debug this error. stack trace of all threads in this "hung" state is:

/usr/bin/rhythmbox [4982] [cores: 0]	
	Thread [5] 5134 [core: 0] (Suspended : Container)	
		__kernel_vsyscall() at 0xf777e430	
		poll() at 0x43df9fb0	
		g_poll() at gpoll.c:132 0x4753d83c	
		g_main_context_poll() at gmain.c:3.402 0x4752ec76	
		g_main_context_iterate() at gmain.c:3.084 0x4752ec76	
		g_main_loop_run() at gmain.c:3.297 0x4752f3a7	
		0xf748f235	
		g_thread_create_proxy() at gthread.c:1.962 0x47555f45	
		start_thread() at 0x43ecdcd3	
		clone() at 0x43e0483e	
	Thread [4] 5135 [core: 0] (Suspended : Container)	
		__kernel_vsyscall() at 0xf777e430	
		poll() at 0x43df9fb0	
		g_poll() at gpoll.c:132 0x4753d83c	
		g_main_context_poll() at gmain.c:3.402 0x4752ec76	
		g_main_context_iterate() at gmain.c:3.084 0x4752ec76	
		g_main_loop_run() at gmain.c:3.297 0x4752f3a7	
		gdbus_shared_thread_func() at gdbusprivate.c:276 0x4f90b74b	
		g_thread_create_proxy() at gthread.c:1.962 0x47555f45	
		start_thread() at 0x43ecdcd3	
		clone() at 0x43e0483e	
	Thread [3] 5201 [core: 0] (Suspended : Container)	
		__kernel_vsyscall() at 0xf777e430	
		pthread_cond_wait@@GLIBC_2.3.2() at 0x43ed185c	
		g_async_queue_pop_intern_unlocked() at gasyncqueue.c:408 0x47500630	
		g_async_queue_pop() at gasyncqueue.c:447 0x47500d1f	
		action_thread_main() at rhythmdb.c:2.841 0x44d6a3af	
		g_thread_create_proxy() at gthread.c:1.962 0x47555f45	
		start_thread() at 0x43ecdcd3	
		clone() at 0x43e0483e	
	Thread [1] 4982 [core: 0] (Suspended : Signal : SIGINT:Interrupt)	
		__kernel_vsyscall() at 0xf777e430	
		poll() at 0x43df9fb0	
		g_poll() at gpoll.c:132 0x4753d83c	
		g_main_context_poll() at gmain.c:3.402 0x4752ec76	
		g_main_context_iterate() at gmain.c:3.084 0x4752ec76	
		g_main_loop_run() at gmain.c:3.297 0x4752f3a7	
		gtk_main() at gtkmain.c:1.362 0x41159155	
		main() at main.c:324 0x804a2e4	

but this isn't helpful at all as each threads just wait for some events...
do you have any idea how to obtain the address of the playbin2 "object"? do you have an advice where to set break points to investigate what's going on here?

This is the path from the main() method of rhythmbox:

*(rb_shell->priv->player_shell->priv->mmplayer)	struct _RBPlayerGst	{...}	
	obj	GObject	{...}	
	priv	RBPlayerGstPrivate *	0x98c6418	
		prev_uri	char *	0x0	
		uri	char *	0x0	
		stream_data	gpointer	0x0	
		stream_data_destroy	GDestroyNotify	0	
		next_stream_data	gpointer	0x0	
		next_stream_data_destroy	GDestroyNotify	0	
		playbin	GstElement *	0xaba7918 [GstPlayBin2]	
		audio_sink	GstElement *	0x9a4ecf0 [GstGSettingsAudioSink]	
		state_change_action	enum StateChangeAction	DO_NOTHING	
		playing	gboolean	0	
		buffering	gboolean	0	
		stream_change_pending	gboolean	0	
		current_track_finishing	gboolean	0	
		playbin_stream_changing	gboolean	1	
		track_change	gboolean	1	
		emitted_error	gboolean	1	
		stream_tags	GList *	{...}	
			[0]	gpointer	0xaa08800	
			[1]	gpointer	0xa0bae48	
			[2]	gpointer	0xaeab368	
			[3]	gpointer	0xab4b130	
			[4]	gpointer	0xa91f2c0	
			[5]	gpointer	0xa91f108	
			[6]	gpointer	0xa9cd750	
		volume_changed	gint	1	
		volume_applied	gint	1	
		cur_volume	float	1	
		tick_timeout_id	guint	0	
		waiting_tees	GList *	{...}	
		sinkbin	GstElement *	0xaa7fac8 [GstBin]	
		tee	GstElement *	0xa520c48 [GstTee]	
		waiting_filters	GList *	{...}	
		filterbin	GstElement *	0xaa7f858 [GstBin]	

You need to cast the RBPlayer "object" to an RBPlayerGst object. a "sub class"!

Next segfault i'm hitting:

Thread [1] 4982 [core: 0] (Suspended : Signal : SIGSEGV:Segmentation fault)	
	0x0	
	rhythmdb_entry_update_availability() at rhythmdb-entry-type.c:125 0x44d7e8ce	
	do_next_not_found_idle() at rb-shell-player.c:3.410 0x44d0e175	
	g_idle_dispatch() at gmain.c:4.801 0x4752a471	
	g_main_dispatch() at gmain.c:2.441 0x4752e62f	
	g_main_context_dispatch() at gmain.c:3.011 0x4752e62f	
	g_main_context_iterate() at gmain.c:3.089 0x4752ed70	
	g_main_loop_run() at gmain.c:3.297 0x4752f3a7	
	gtk_main() at gtkmain.c:1.362 0x41159155	
	main() at main.c:324 0x804a2e4

*** Bug 660001 has been marked as a duplicate of this bug. ***

this seems to be a rhythmbox bug. When recompiling rhythmbox version 2.90.1 (i.e. the current Fedora 16 version) with -O0 the rhythmbox doesn't seem to hang anymore. same for 2.95.

For gst-plugins-base and gstreamer I'm using the plain version of Fedora 16.

any ideas?

Opps! Sorry! Rhythmbox still hangs with -O0. Sorry for the noise.

Have you tried running it in valgrind ? 

   $ G_SLICE=always-malloc rhythmbox 2>&1 | tee valgrind.log

Perhaps it shows something interesting?

Perhaps it should be moved to rhythmbox for now? After all it crashes when accessing memory managed by rhythmbox, if I understand the previous comments correctly.

(In reply to comment #9)
> Have you tried running it in valgrind ? 
> 
>    $ G_SLICE=always-malloc rhythmbox 2>&1 | tee valgrind.log
I guess you meant
G_SLICE=always-malloc valgrind --tool=memcheck rhythmbox 2>&1 | tee valgrind.log

Yes, I did, sorry.

*** Bug 674477 has been marked as a duplicate of this bug. ***

Finally looking at this a bit, it appears that after an error, the uridecodebin for the failed stream doesn't get removed from playbin2, so it gets included in the state change to PAUSED for the next track, which causes it to produce more errors, so playback stops working.  I'm not seeing any crashes though.

Created attachment 212508 [details]
valgrind log

With "G_SLICE=always-malloc valgrind --tool=memcheck rhythmbox 2>&1 | tee
valgrind.log" and the steps in my dup report bug 674477 it does not hang or crash initially.
Instead Rhythmbox seems to iterate on every remaining song in my music library list and fails for each of them.
After watching this for a while I clicked the last song to stop this behavior. After rhythmbox had recognized that it cannot play that song, I clicked the last but one song. Rhythmbox finally crashed.

I switch from rhythmbox 2.90.1 (Fedora 16) to 2.95 (3a5b74ee288e52255ee3786f89e389289c22d756) and had not any crash/hang since then. for gstreamer and playbin2 I still use the plain Fedora 16 versions. So this bug must be part of rhythmbox. But I don't care anymore since 2.95 runs fine.

Created attachment 212515 [details]
second valgrind log (with --leak-check=full --track-origins=yes), part 1 of 2

Part 1 of results for "G_SLICE=always-malloc valgrind --tool=memcheck --leak-check=full --track-origins=yes rhythmbox 2>&1 | tee valgrind2.log" while *trying* to follow the same steps from comment 15 (at first didn't succeed at the end of the music library list, so I had to change the sort order and try again).

Created attachment 212516 [details]
second valgrind log (with --leak-check=full --track-origins=yes), part 2 of 2

Second part, as Bugzilla has a file size limit of 1MB.

gstplaybin2.c:activate_group will add a uridecodebin to playbin, but if its state change fails, we exit the function with group->active set to FALSE and the uridecodebin still in the pipeline.  All of the paths that call deactivate_group check that group->active is TRUE first, so the uridecodebin doesn't get removed.  With that uridecodebin still in the pipeline, attempts at starting playback fail because it won't change to PAUSED.

Is this something I'm supposed to deal with?  If so, how?

*** Bug 676501 has been marked as a duplicate of this bug. ***

Any gstreamer dev around to answer comment 19? Tim maybe?

(In reply to comment #19)
> gstplaybin2.c:activate_group will add a uridecodebin to playbin, but if its
> state change fails, we exit the function with group->active set to FALSE and
> the uridecodebin still in the pipeline.  All of the paths that call
> deactivate_group check that group->active is TRUE first, so the uridecodebin
> doesn't get removed.  With that uridecodebin still in the pipeline, attempts at
> starting playback fail because it won't change to PAUSED.
> 
> Is this something I'm supposed to deal with?  If so, how?

No, this looks like a bug in playbin. Thanks for analyzing. Do you want to provide a patch? playbin should probably remove the uridecodebin immediately if something goes wrong before it sets group->active=TRUE.

This was a duplicate of bug 673888, works fine with current 0.10 branch.

*** This bug has been marked as a duplicate of bug 673888 ***

Great!

I can confirm I did not see this problem on Fedora 17.