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 677946 - Crash while switching tabs
Crash while switching tabs
Status: RESOLVED FIXED
Product: gnome-control-center
Classification: Core
Component: general
unspecified
Other Linux
: Normal critical
: ---
Assigned To: Control-Center Maintainers
Control-Center Maintainers
Depends on:
Blocks:
 
 
Reported: 2012-06-12 13:51 UTC by Matthias Clasen
Modified: 2012-06-20 18:15 UTC
See Also:
GNOME target: ---
GNOME version: ---

Attachments
stacktrace (4.66 KB, text/plain)
2012-06-12 13:51 UTC, Matthias Clasen 		  Details
some hint whats going on (211 bytes, text/plain)
2012-06-12 19:02 UTC, Matthias Clasen 		  Details
Be robust against extraneous signal emissions (956 bytes, patch)
2012-06-12 19:22 UTC, Matthias Clasen 		committed Details | Review

Description Matthias Clasen 2012-06-12 13:51:38 UTC 
Created attachment 216206 [details]
stacktrace

Fairly easy to reproduce crash. Open the control-center, then use shell menus to switch pages a few times: a11y, sound, bt, network is enough to make it crash here.
Comment 1 Bastien Nocera 2012-06-12 14:36:14 UTC 
Can't reproduce it here.

Ran gnome-control-center in one terminal and run this in another:
for i in `seq 1 20` ; do gnome-control-center universal-access & gnome-control-center screen & done

It took a while to finish, but it worked without crashing. What clutter did you use? Can you try with the latest gnome-control-center master?
Comment 2 Matthias Clasen 2012-06-12 16:05:00 UTC 
$ rpm -q control-center clutter
control-center-3.5.2-1.fc18.x86_64
clutter-1.11.4-1.fc18.x86_64
Comment 3 Matthias Clasen 2012-06-12 19:02:02 UTC 
Created attachment 216228 [details]
some hint whats going on

After instrumenting the delayed remove machinery a bit, it seems that we occasionally get more than one ClutterTimeline::completed. Which is bad news for the code as currently written...
Comment 4 Matthias Clasen 2012-06-12 19:22:49 UTC 
Created attachment 216229 [details] [review]
Be robust against extraneous signal emissions

It seems that we are occasionally get duplicate ClutterTimeline::completed
emissions. Make the code robust against that.
Comment 5 Ray Strode [halfline] 2012-06-12 19:23:08 UTC 
setup_delayed_remove connects to the "completed" signal of the "scroll-to" transition of the scroll actor.

_cc_notebook_select_page changes the "scroll-to" transition (potentially mid flight?).

On theory is "completed" is called on the old transition after the new one is put in place.
Comment 6 Bastien Nocera 2012-06-20 18:15:43 UTC 
(In reply to comment #5)
> setup_delayed_remove connects to the "completed" signal of the "scroll-to"
> transition of the scroll actor.
> 
> _cc_notebook_select_page changes the "scroll-to" transition (potentially mid
> flight?).
> 
> On theory is "completed" is called on the old transition after the new one is
> put in place.

The problem is that unexpectedly (for me at least) this line:
clutter_actor_remove_transition (self->priv->scroll, "scroll-to");
still emits a "completed" signal.

Matthias' patch should be enough to avoid that.
Comment 7 Bastien Nocera 2012-06-20 18:15:54 UTC 
Attachment 216229 [details] pushed as 8c9a1ee - Be robust against extraneous signal emissions