Linux binaries for 0.64.0 (FINAL candidate)

Os: Xubuntu 12.04
Kernel : 3.2.0-41-generic
uname -i : x86_64
processor : 0, 1, 2, 3
vendor_id : GenuineIntel
cpu family : 6
model : 42
model name : Intel® Core™ i3-2350M CPU @ 2.30GHz

Call trace dump :

Thread 1 (Thread 0x7ffff7fc7940 (LWP 4046)):
#0 0x00007ffff6697fce in Gdk::Drawable::draw_rectangle(Glib::RefPtr<Gdk::GC const> const&, bool, int, int, int, int) () from /usr/lib/x86_64-linux-gnu/libgdkmm-2.4.so.1
#1 0x00000000009b0f04 in studio::Widget_Keyframe_List::redraw (this=0x1384840) at widgets/widget_keyframe_list.cpp:103
#2 0x00000000009b4eb1 in sigc::bound_mem_functor0<bool, studio::Widget_Keyframe_List>::operator() (this=0x1b70ae8) at /usr/include/sigc+±2.0/sigc++/functors/mem_fun.h:1787
#3 0x00000000009b4cf4 in sigc::adaptor_functor<sigc::bound_mem_functor0<bool, studio::Widget_Keyframe_List> >::operator() (this=0x1b70ae0) at /usr/include/sigc+±2.0/sigc++/adaptors/adaptor_trait.h:251
#4 0x00000000009b4df8 in sigc::hide_functor<-1, sigc::bound_mem_functor0<bool, studio::Widget_Keyframe_List> >::operator()<synfig::Keyframe const&> (this=0x1b70ad8) at /usr/include/sigc+±2.0/sigc++/adaptors/hide.h:96
#5 0x00000000009b4c83 in sigc::retype_return_functor<void, sigc::hide_functor<-1, sigc::bound_mem_functor0<bool, studio::Widget_Keyframe_List> > >::operator()<synfig::Keyframe const&> (this=0x1b70ad0, _A_a1=…) at /usr/include/sigc+±2.0/sigc++/adaptors/retype_return.h:161
#6 0x00000000009b48d7 in sigc::internal::slot_call1<sigc::retype_return_functor<void, sigc::hide_functor<-1, sigc::bound_mem_functor0<bool, studio::Widget_Keyframe_List> > >, void, synfig::Keyframe>::call_it (rep=0x1b70aa0, a_1=…) at /usr/include/sigc+±2.0/sigc++/functors/slot.h:137
#7 0x000000000091121d in sigc::internal::signal_emit1<void, synfig::Keyframe, sigc::nil>::emit (impl=0x18986a0, _A_a1=…) at /usr/include/sigc+±2.0/sigc++/signal.h:1010
#8 0x0000000000910a7f in sigc::signal1<void, synfig::Keyframe, sigc::nil>::emit (this=0x178c9c0, _A_a1=…) at /usr/include/sigc+±2.0/sigc++/signal.h:2781
#9 0x0000000000910389 in sigc::signal1<void, synfig::Keyframe, sigc::nil>::operator() (this=0x178c9c0, _A_a1=…) at /usr/include/sigc+±2.0/sigc++/signal.h:2789
#10 0x00007ffff7a7b29e in synfigapp::Action::KeyframeAdd::perform (this=0x1ae71a0) at actions/keyframeadd.cpp:124
#11 0x00007ffff7b0f775 in synfigapp::Action::System::perform_action (this=0x1788b80, action=…) at action_system.cpp:128
#12 0x00000000007992d9 in studio::KeyframeActionManager::on_add_keyframe (this=0x131dc80) at actionmanagers/keyframeactionmanager.cpp:167
#13 0x000000000079c7a9 in sigc::bound_mem_functor0<void, studio::KeyframeActionManager>::operator() (this=0x18fbe08) at /usr/include/sigc+±2.0/sigc++/functors/mem_fun.h:1787
#14 0x000000000079c592 in sigc::adaptor_functor<sigc::bound_mem_functor0<void, studio::KeyframeActionManager> >::operator() (this=0x18fbe00) at /usr/include/sigc+±2.0/sigc++/adaptors/adaptor_trait.h:251
#15 0x000000000079c31f in sigc::internal::slot_call0<sigc::bound_mem_functor0<void, studio::KeyframeActionManager>, void>::call_it (rep=0x18fbdd0) at /usr/include/sigc+±2.0/sigc++/functors/slot.h:103
#16 0x00007ffff5be6e08 in Glib::SignalProxyNormal::slot0_void_callback(_GObject*, void*) () from /usr/lib/x86_64-linux-gnu/libglibmm-2.4.so.1
#17 0x00007ffff4f8a140 in g_closure_invoke () from /usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0
#18 0x00007ffff4f9b766 in ?? () from /usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0
#19 0x00007ffff4fa34af in g_signal_emit_valist () from /usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0
#20 0x00007ffff4fa3642 in g_signal_emit () from /usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0
#21 0x00007ffff5e79193 in ?? () from /usr/lib/x86_64-linux-gnu/libgtk-x11-2.0.so.0
#22 0x00007ffff6007389 in ?? () from /usr/lib/x86_64-linux-gnu/libgtk-x11-2.0.so.0
#23 0x00007ffff4f8a407 in ?? () from /usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0
#24 0x00007ffff4fa2df6 in g_signal_emit_valist () from /usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0
#25 0x00007ffff4fa3642 in g_signal_emit () from /usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0
#26 0x00007ffff5e92845 in ?? () from /usr/lib/x86_64-linux-gnu/libgtk-x11-2.0.so.0
#27 0x00007ffff4f8a407 in ?? () from /usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0
#28 0x00007ffff4fa2df6 in g_signal_emit_valist () from /usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0
#29 0x00007ffff4fa3642 in g_signal_emit () from /usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0
#30 0x00007ffff5e9166d in ?? () from /usr/lib/x86_64-linux-gnu/libgtk-x11-2.0.so.0
#31 0x00007ffff5f3add8 in ?? () from /usr/lib/x86_64-linux-gnu/libgtk-x11-2.0.so.0
#32 0x00007ffff4f8a140 in g_closure_invoke () from /usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0
#33 0x00007ffff4f9b2d0 in ?? () from /usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0
#34 0x00007ffff4fa30cb in g_signal_emit_valist () from /usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0
#35 0x00007ffff4fa3642 in g_signal_emit () from /usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0
#36 0x00007ffff6055191 in ?? () from /usr/lib/x86_64-linux-gnu/libgtk-x11-2.0.so.0
#37 0x00007ffff5f38f63 in gtk_propagate_event () from /usr/lib/x86_64-linux-gnu/libgtk-x11-2.0.so.0
#38 0x00007ffff5f392c3 in gtk_main_do_event () from /usr/lib/x86_64-linux-gnu/libgtk-x11-2.0.so.0
#39 0x00007ffff551ccac in ?? () from /usr/lib/x86_64-linux-gnu/libgdk-x11-2.0.so.0
#40 0x00007ffff4ccaab5 in g_main_context_dispatch () from /lib/x86_64-linux-gnu/libglib-2.0.so.0
#41 0x00007ffff4ccade8 in ?? () from /lib/x86_64-linux-gnu/libglib-2.0.so.0
#42 0x00007ffff4ccb1e2 in g_main_loop_run () from /lib/x86_64-linux-gnu/libglib-2.0.so.0
#43 0x00007ffff5f382f7 in gtk_main () from /usr/lib/x86_64-linux-gnu/libgtk-x11-2.0.so.0
#44 0x00000000007914a3 in main (argc=0, argv=0x7fffffffe7f8) at main.cpp:100

Patched not Solved…

In sources/synfig/synfig-studio/src/gui/widgets/widget_keyframe_list.cpp

101| //! draw a background 102| gc->set_rgb_fg_color(Gdk::Color("#9d9d9d")); 103| //get_window()->draw_rectangle(gc, true, 0, 0, w, h); 104| 105| if(!editable_)
As the line 103 is just ‘visual’ and not ‘effective’ …
commenting it and you will have a synfig 0.64.0 keyframable …

see(:ya!

OK, I’ll try to reproduce the bug using a virtual machine with similar settings.

Meanwhile, using Nevimer, could you place a breakpoint at line 89 from widget_keyframe_list.cpp and run the code step by step? On each step, watch the values of the local variables to see if there is something wrong (w or h are zero)
-G

Yep it’s what’s i have noted … Widget_Keyframe_List::redraw() is called two time for each click on “add” / “remove keyframe”, (when i move the timeline just called one time!)…
the second time for “add k” or “remove k” , h and w are set to 1 … that’s can be the prob’ … and worst , “this” is not the same … (part of why h & w are set to ‘1’ … !)

so two question;
is it normal that redraw is called two time for ‘add k’ and ‘remove k’ … ?
where this this come from (i have only one keyframe widget … ) ?

dpkg -l | grep libgtk ii libgtk-3-0 3.6.0-0ubuntu3 GTK+ graphical user interface library ii libgtk-3-bin 3.6.0-0ubuntu3 programs for the GTK+ graphical user interface library ii libgtk-3-common 3.6.0-0ubuntu3 common files for the GTK+ graphical user interface library ii libgtk-3-dev 3.6.0-0ubuntu3 development files for the GTK+ library ii libgtk-3-doc 3.4.2-0ubuntu0.5 documentation for the GTK+

It can be called for anyone who has to update the widget (one action or the windows manager) so it is normal that it should be called several times. What it shouldn’t happen is that each call happens in the same thread because there would be race competition for the data.

w and h are set both to 1?? that’s wrong since the w should be at last the width of the widget that is as long as the drawing area from the work area. The height is a fixed value about 5 pixels IIRC.

It is possible that the problem comes from there. But why doesn’t happen in other linux distributions?

-G

Can you write down the recipe to get a crash step by step? (full details)
It must happen in other distributions if it is a thread problem.
-G

  • Start Synfig
  • Add Key Frame
  • Crash

Nota : my system xubuntu 12.04 is xfce 4.10 since few month (normally 4.8 ), and some other packages from upper distrib (so it’s not an official ‘xubuntu 12.04’ )

Runing Xubuntu 64 bits 8 MB ram, 4 cpu cores, in a virtual machine fresh installation and updated with privative drivers installed.
Can’t reproduce the problem:
0) Dowload and install amd64 bits version debian package from website link.

  1. Start Synfig Studio
  2. Go to Keyframes Panel and press the enabled “Add keyframe” ‘+’ button.
  3. No crash. Result is expected.

-G

Ok, cool!!! … that should come from my partial os update … so it’s a kind of unique feature for me…

for now, i can follow like that : badly patched - see “12 May 2013 09:06” post.

thank’s for help!

So repair your system before complain! :imp: :imp:

:laughing: :laughing:
-G

No no no … i will keep all like that … my system is a kind of stable… :wink: and i want to stay in LTS , but with xfce 4.10 (ppa.launchpad.net/xubuntu-dev/xfce-4.10/ubuntu), libcairo2-dev up to 1.12 and xorg-server 2:1.13 (both two by enabling momently quantal repository)

I’m having this same problem, on a brand new computer no less.
On my 6 year old Toshiba laptop with it’s Windows XP operating system this was never a problem. Everything ran just fine, even after 6 years of all kinds of junk I’d done to that computer. My new computer is a Lonovo with Windows 8, which I hate to no end (it’s like they crammed a phone OS into a computer and called it hip). I got it three weeks ago and now have this stumbling block.

I’m guessing by process of elimination the problem is with the new release of Synfig, not an outside thing.

I wish I knew how to use these files in the old versions of synfig. I know jack squat about programming and would just prefer to use the old version.

witch problem ? keyframe crash ?

see(:ya!

Yes, the key frame crash problem. I wish I was more computer literate and knew coding and all that. But I know poo.