GNOME Bugzilla – Bug 755194
GESClip: Crash related to <binding>
Last modified: 2015-10-12 22:26:42 UTC
Created attachment 311591 [details] crash backtrace SIGSEGV when extracting timeline from project (before "loaded" signal). Will provide additional info and way to reproduce soon.
http://cgit.freedesktop.org/gstreamer/gst-editing-services/tree/ges/ges-clip.c#n185 container->children == 0 tmp points to some wrong address
>> SIGSEGV when extracting timeline from project (before "loaded" signal). I lied.
Sorry, night here. >> I lied. I didn't.
Created attachment 311592 [details] Ya gesclip crash In case I pause program in ges_container_remove crash moves to ges_timeline_trim_object_simple
Second kind of crash is random and caused by bad memory, ignore it. Looks like _destroy_auto_transition_cb causes clip to get rid of it's children.
Sorry, it's night here. I feel stupid, I feel race for children between _set_duration and ges_container_remove, but I see no calls from different threads.
(In reply to Kyrylo V. Polezhaiev from comment #1) > http://cgit.freedesktop.org/gstreamer/gst-editing-services/tree/ges/ges-clip. > c#n185 > > container->children == 0 > tmp points to some wrong address if container->children == NULL, we won't enter that loop. (In reply to Kyrylo V. Polezhaiev from comment #0) > Will provide additional info and way to reproduce soon. Could you please ? :)
>> if container->children == NULL, we won't enter that loop You don't say! :) Maybe someone sorts the list same time (after we enter)?
Or removes an element (NULL case)
(In reply to Kyrylo V. Polezhaiev from comment #8) > >> if container->children == NULL, we won't enter that loop > You don't say! :) > Maybe someone sorts the list same time (after we enter)? Unless you are wrongly concidering GES in MT, that can't happen :)
Something wrong with my logic. I spy for container->children update and when I execute pause / unpause program in debugger, step by step, everything works fine. But every call to either crashing function or to code changing children list is done in main thread via invocation. So this isn't race because we only have one thread operating with that list.
Also what version of GES do you use? From you backtrace the segfault happens in #0 0x00007ffff795c34a in ges_timeline_trim_object_simple (timeline=0x674ff0, element=0x675720, layers=0x0, edge=GES_EDGE_END, position=36000000000, napping=1) at ges-timeline.c:1495 But that line can not really segfault: http://cgit.freedesktop.org/gstreamer/gst-editing-services/tree/ges/ges-timeline.c#n1495 :)
Sorry, I put incorrect version in description: my server uses GES 1.5.2: http://cgit.freedesktop.org/gstreamer/gst-editing-services/tree/ges/ges-timeline.c?id=1.5.2#n1495
OK, how can I reproduce?
Have no crash anymore after switch to 1.5.90. Should I dig deeper or can we abandon this? Problem is that I can not just give you .xges for ges-launch. It's hard to give you minimum stuff to reproduce an error.
If it works on master, I would say it is obselete? Otherwise you should be able to give me .xges + media files no?
Do we have some fix for something like this between 1.5.2 and 1.5.90? >> Otherwise you should be able to give me .xges + media files no? Sure.
Possibly, tbh I do not remember :)
I have the same problem with 1.5.90 :-( now. >> Unless you are wrongly concidering GES in MT, that can't happen :) GES isn't MT enough? I should call every function from main loop?
And I do. Only from signal handlers / bus messages.
Please try with 1.6 and provide a testcase.