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 739323 - Segfault in master_clock_advance_timelines
Segfault in master_clock_advance_timelines
Status: RESOLVED OBSOLETE
Product: clutter
Classification: Platform
Component: general
unspecified
Other Linux
: Normal normal
: ---
Assigned To: clutter-maint
clutter-maint
Depends on:
Blocks: 682886
 
 
Reported: 2014-10-28 21:55 UTC by Thibault Saunier
Modified: 2021-06-10 11:31 UTC
See Also:
GNOME target: ---
GNOME version: ---

Attachments
transition: Do not unref the timeline where we own no ref (814 bytes, patch)
2014-11-01 20:19 UTC, Thibault Saunier 		none Details | Review

Description Thibault Saunier 2014-10-28 21:55:13 UTC 
In pitivi with GLib 2.42 and Gtk3.14, we can quite easily have segfault in clutter.

A way to reproduce is to add a clip in the timeline then keep pressing the right arrow key to seek 0.50ms continously. It looks like a refcount issue.

The stacktrace of the segfault looks like:

(gdb) bt

+ Trace 234270

  • #0 g_type_check_instance_is_fundamentally_a
    at gtype.c line 3977
  • #1 g_object_unref
    at gobject.c line 3067
  • #2 g_slist_foreach
    at gslist.c line 877
  • #3 master_clock_advance_timelines
    at ./clutter-master-clock.c line 436
  • #4 clutter_clock_dispatch
    at ./clutter-master-clock.c line 592
  • #5 g_main_dispatch
    at gmain.c line 3068
  • #6 g_main_context_dispatch
    at gmain.c line 3669
  • #7 g_main_context_iterate
    at gmain.c line 3740
  • #8 g_main_context_iteration
    at gmain.c line 3801
  • #9 g_application_run
    at gapplication.c line 2219
  • #10 ffi_call_unix64
    at ../src/x86/unix64.S line 76
  • #11 ffi_call
    at ../src/x86/ffi64.c line 525
  • #12 pygi_invoke_c_callable
    at pygi-invoke.c line 628
  • #13 pygi_function_cache_invoke
  • #14 pygi_callable_info_invoke
  • #15 _wrap_g_callable_info_invoke
  • #16 _callable_info_call
  • #17 PyObject_Call
  • #18 do_call
    at /usr/src/debug/Python-3.4.1/Python/ceval.c line 4485
  • #19 call_function
    at /usr/src/debug/Python-3.4.1/Python/ceval.c line 4283
  • #20 PyEval_EvalFrameEx
    at /usr/src/debug/Python-3.4.1/Python/ceval.c line 2853
  • #21 fast_function
    at /usr/src/debug/Python-3.4.1/Python/ceval.c line 4353
  • #22 call_function
    at /usr/src/debug/Python-3.4.1/Python/ceval.c line 4281
  • #23 PyEval_EvalFrameEx
  • #24 PyEval_EvalCodeEx
    at /usr/src/debug/Python-3.4.1/Python/ceval.c line 3607
  • #25 PyEval_EvalCode
    at /usr/src/debug/Python-3.4.1/Python/ceval.c line 793
  • #26 run_mod
    at /usr/src/debug/Python-3.4.1/Python/pythonrun.c line 2188
  • #27 PyRun_FileExFlags
    at /usr/src/debug/Python-3.4.1/Python/pythonrun.c line 2141
  • #28 PyRun_SimpleFileExFlags
    at /usr/src/debug/Python-3.4.1/Python/pythonrun.c line 1614
  • #29 run_file
    at /usr/src/debug/Python-3.4.1/Modules/main.c line 319
  • #30 Py_Main
    at /usr/src/debug/Python-3.4.1/Modules/main.c line 751
  • #31 main
    at /usr/src/debug/Python-3.4.1/Modules/python.c line 69 






Comment 1


Thibault Saunier





          2014-11-01 13:23:33 UTC
        



Ok, so I have invetigated it a bit and this is what I found:

It happens when clutter_transition_stopped unrefs the timeline that is passed in, and it happens only in one case, when it fails. The difference causing that happening is because when it fails is transition->priv->remove_on_complete that has been set to True. That field is set to true because we previously reached:





+
Trace
    234288






    

  • 
#0
clutter_transition_set_remove_on_complete

    
                at ./clutter-transition.c
                  line
                  438

    

    • 

  • 
#1
clutter_scroll_actor_scroll_to_point

    
                at ./clutter-scroll-actor.c
                  line
                  377

    

    • 








which means that clutter_scroll_actor_scroll_to_point has been called when the transition had not been set yet.

The thing is that I do not see where we suposdely take a ref on the timeline in case we set_remove_on_complete to TRUE, and currently it looks like it is not done at all, so we end up with a refcount issue, leading to unrefing the already destroyed timeline (PropertyTransition) in that case.






Comment 2


Thibault Saunier





          2014-11-01 20:19:36 UTC
        



Created attachment 289805 [details] [review]
transition: Do not unref the timeline where we own no ref

So unless I am missing something, we do not own any ref to the timeline in the
stop signal virtual method so we should not unref it.






Comment 3


André Klapper





          2021-06-10 11:31:33 UTC
        



GNOME is going to shut down bugzilla.gnome.org in favor of gitlab.gnome.org.
As part of that, we are mass-closing older open tickets in bugzilla.gnome.org
which have not seen updates for a longer time (resources are unfortunately
quite limited so not every ticket can get handled).

If you can still reproduce the situation described in this ticket in a recent
and supported software version of clutter, then please follow
  https://wiki.gnome.org/GettingInTouch/BugReportingGuidelines
and create a ticket at
  https://gitlab.gnome.org/GNOME/clutter/-/issues/

Thank you for your understanding and your help.