GNOME Bugzilla – Bug 656886
Dragging preview crashes empathy-call
Last modified: 2011-08-30 15:23:52 UTC
(empathy-call:30835): Clutter-CRITICAL **: clutter_actor_meta_get_actor: assertion `CLUTTER_IS_ACTOR_META (meta)' failed (empathy-call:30835): GLib-GObject-WARNING **: instance of invalid non-instantiatable type `(null)' (empathy-call:30835): GLib-GObject-CRITICAL **: g_signal_emit_valist: assertion `G_TYPE_CHECK_INSTANCE (instance)' failed (empathy-call:30835): Clutter-CRITICAL **: clutter_actor_meta_get_actor: assertion `CLUTTER_IS_ACTOR_META (meta)' failed (empathy-call:30835): GLib-GObject-WARNING **: instance of invalid non-instantiatable type `(null)' (empathy-call:30835): GLib-GObject-CRITICAL **: g_signal_emit_valist: assertion `G_TYPE_CHECK_INSTANCE (instance)' failed Program received signal SIGSEGV, Segmentation fault. _clutter_stage_set_motion_events_enabled (stage=0x0, enabled=1) at ./clutter-stage.c:3483 3483 ./clutter-stage.c: No such file or directory. in ./clutter-stage.c (gdb) bt
+ Trace 228143
I should have mentioned that this crash happens when releasing the preview onto a new location.
Is this reproducible? Dragging the preview always works for me. I've tried both clutter 1.6 and master. Would be good to get a backtrace on the first warning.
Here are backtraces for all the warnings. (Note that I actually broke on g_logv so that the actual messages are printed after the backtrace). http://paste.debian.net/126712/
1. Make a call you know is going to fail or you know will be rejected. 2. Whilst connecting, start dragging the preview but just keep dragging it and wait. 3. The call fails or is rejected. 4. Let go of your left mouse button. If you wait and don't let go you get more warnings but the outcome is still a segfault. For the record, the warning is this: (empathy-call:20678): Clutter-WARNING **: Attempting to map a child that does not meet the necessary invariants: the actor 'EmpathyRoundedTexture' has no parent So, it looks like it breaks because you're destroy the actor when the call ends which is in the process of being dragged around. Come to think of it, you can reproduce this by making a successful call, then just getting the other side to hang up while you're half-way through dragging the preview.
This is a clutter bug. I've opened bug #657681 for it. If it isn't fixed for 3.2, we can workaround this by hiding (not destroying) the preview in reset_pipeline(), though this will leak a bunch of actors.
Created attachment 195214 [details] [review] CallWindow: destroy the preview clone when restarting the pipeline
There are two bugs here: one is the clutter one, which is fixed in git master and fixes the crash, and an Empathy one which is caused because we don't get ::drag-end when destroying the preview in the middle of a drag, so we need to destroy the drag handle in that case. The attached patch fixes the Empathy bug.
Review of attachment 195214 [details] [review]: ::: src/empathy-call-window.c @@ +879,3 @@ gfloat rel_x, rel_y; + self->priv->drag_preview = clutter_clone_new (actor); Is it guaranteed that self->priv->drag_preview is NULL here?
(In reply to comment #8) > Review of attachment 195214 [details] [review]: > > ::: src/empathy-call-window.c > @@ +879,3 @@ > gfloat rel_x, rel_y; > > + self->priv->drag_preview = clutter_clone_new (actor); > > Is it guaranteed that self->priv->drag_preview is NULL here? Yes, because you can't drag the preview twice at the same time. So either drag-end has been called and thus drag_preview = NULL, or reset_pipeline() has been called and we destroy and set it to NULL there too. I can add a g_assert or g_warn_if_fail if you want.
Attachment 195214 [details] pushed as 61fd1d9 - CallWindow: destroy the preview clone when restarting the pipeline